システム開発のトラブル、根本原因は何？：情シスの本棚（9）

「作る人」と「使う人」でビジネスゴールが異なっていると、真に役立つシステムを開発するのは難しい。ゴールを一致させる一つの方法とは？

» 2014年07月15日 18時00分公開

[内野宏信，＠IT]

※本記事はアフィリエイトプログラムによる収益を得ています

連載目次

ソフトウェア開発の目的とは？

●著者：倉貫義人●日本実業出版社●ISBN-10: 4534051948●ISBN-13:978-4534051943●発売日：2014/6/12

　「これまでのソフトウェア開発のプロジェクトであれば、顧客に納品するまでが『開発』で、納品以降のソフトウェアを稼働させていく期間は『運用』として分けられていました。そして、多くの場合は開発と運用で担当者が違うのです。担当する会社が違うこともままあります」。「しかし、『納品のない受託開発』にはその分断がないのです」。「開発と運用を分けずに、ソフトウェアの裏方業務のすべてをお任せいただくというスタイルだからです」。「開発と運用の両方を受け持つことで、ムダな引き継ぎのコストがかからず、顧客からすれば運用をしながらずっと開発を続けることができるのです」――。

　本書「『納品』をなくせばうまくいく」は、以上のような「納品のない受託開発」を行い、多数の企業に支持されているソニックガーデン代表取締役社長倉貫義人氏が、その開発手法のコンセプトから具体的なメリット、進め方、エンジニアのマネジメント手法まで、実践の要点を網羅的にまとめた作品だ。

　市場変化が速い現在、「数カ月かけて作った後に、できたものを発注した顧客に納品してお金をいただく」という受託開発の「一括請負」のスタイルでは、相次ぐ仕様変更で納期が遅れてしまう、納品時には市場やビジネスのニーズと乖離したシステムになってしまうなど、「トラブル」が起きやすい状況になっている。事実、「デスマーチなどと呼ばれる、エンジニアにとっての過酷な労働環境」も、「納品間際でのトラブルに起因」することが多い。倉貫氏はそうした問題を見据え、冒頭のような顧客と共にソフトウェア開発、改善し続ける「納品」をなくしたビジネスモデルを考案。その実践を通じて確認したメリットや、方法論を具体的に説いている。

　中でも重要な指摘は「目指しているのは、ソフトウェアの完成ではなく、顧客のビジネスの成長」という点だろう。言うまでもなく、顧客にとっては「単にソフトウェアが完成されただけでは価値を得ることは」できない。「どれだけソフトウェアを『使う』ことができるか」に意味がある。そこで同社では開発案件ベースの料金体系ではなく、「月額定額」の料金体系とし、毎月の決まった金額の中で「精一杯の『開発と運用』」を行っているという。

　具体的には、「一人のエンジニアが顧客の顧問として担当」。「顧客と話し合い、何を作るべきかを決定して、それを実際にソフトウェアとして開発し、日々の運用までを担当」する。一人で足りなくなれば、担当エンジニアを増やす。ただ、打ち合わせの場には、必ず「顧客の事業責任者に同席」してもらい、「事前に行った設計の報告や確認をするのではなく、その場で方向や具体策を考えて決めて」いく。少しずつ開発し、実際に動くソフトウェアを共に確認しながら、手戻りなく次の段階に進む。これにより、「要件を一度に決めなくてもいい」「どれだけ仕様変更してもいい」といった顧客にとってのメリットを担保しながら、経営環境変化に応じた柔軟かつスピーディな開発を狙う。

　とはいえ、こうした「精一杯の『開発と運用』」とは、決して「顧客のいいなりになる」ということではない。「仕様変更や優先順位の変更はいつでも受け付ける一方で、顧客の思いつきで考えたような機能はすぐには作らない」。場合によっては「作らない提案」もする。従来型の受託開発では、たとえ顧客が思いつきで言ったことでも「すぐに見積もりや提案書に」なってしまいがちだ。だが、“顧問エンジニア”として要望を聞き、「本当に必要ですか？」「何のために必要ですか？」と聞くことによって、正しい判断を促す。なぜなら、「目指しているのは、ソフトウェアの完成ではなく、顧客のビジネスの成長」であり、エンジニアの評価指標も「どれだけ事業に貢献できるか」にあるためだ。

　さて、いかがだろう。言うまでもなく、ここで語られているのはアジャイル開発だ。「開発と運用を請け負う」「顧問として、共に顧客と同じビジネスゴールを目指す」といったあたりはアジャイルを核とするDevOpsにも通じる取り組みといえる。特に注目すべきは「月額定額」の料金体系としていることだろう。従来型の一括請負がベースとなる受託開発では、最初に決めた要件通りに進める必要がある他、受注側は「作ること」、発注側は「使うこと」といった具合に、どうしてもゴールがずれてしまう。これを「月額定額」とし、エンジニアの指標も「どれだけ貢献できるか」とすることで、難しいとされている受託開発へのアジャイル適用の1つの在り方を提示している。この点は大いに参考になるのではないだろうか。

　また何より印象的なのは、「月額定額」という料金体系の根底にある、エンジニアという仕事に対する筆者の認識だ。筆者は「本来、ソフトウェア開発におけるエンジニアの仕事は、時間に換算できるものではない」、仕事場に座り続けている時間ではなく、「仕事の成果を見るべき」だと指摘している。というのも、エンジニアとは各社各様の顧客やエンドユーザーの要望をデザインに落とし込む「ナレッジワーカー」、すなわち「マニュアル化できない仕事をする人」であるためだ。

　そうした認識を基に、筆者は「ナレッジワーカーには常に新しい価値を創造していくことが求められて」おり、創造性ある人材の育成やマネジメントが「納品のない受託開発」の核であることを力説している。無論、一部の大規模システムのように、こうした開発スタイルが全ての開発案件にマッチするわけではない。だが、受託、内製を問わず、ビジネス部門とともに考える開発スタイルや、エンジニアを人月に換算しない捉え方は、「ビジネスゴールへの寄与」を実現するための重要なポイントを示唆しているといえるのではないだろうか。

　本書ではこの他、「扱う技術の統一化」「クラウドを活用した自動化と合理化」など、こうした開発体制を実践する上で必要な技術面の要点、マネジメント面での要点なども詳しく解説している。自社の開発・運用体制を真のゴールに結び付ける上で、一つの参考としてはいかがだろう。

※引用箇所の仮名遣いは、紹介書籍の仮名遣いを踏襲しています。

「情シスの本棚」バックナンバー