改善型開発 〜 システムを作るのではなく育てるという発想

SIer

現在のシステム開発という開発モデルを考えてみると、そのシステムを必要としており開発の依頼を発注する発注側と、実際の開発作業を請け負う開発側の間で、プロジェクトに対し契約を結んだ段階からシステム開発は始まる、というのが当たり前の話。そして、この当たり前と思われている関係でビジネスを続けると問題があるのでは、と考察したのが以前のエントリ、「ディフェンシブな開発*1」だった。

今回は、その当たり前だと思われているところについて、発想の転換を取り入れて考えてみようと思う。社会における通念や物事を大きく変えるためには、コペルニクス的転回が必要だからだ。

ノウハウを集約できないSI企業

まずこの「プロジェクト開始してからシステム開発を始める」という点について、ディフェンシブであるということ以外にも、SI企業として重大な問題点が隠されている。それは、IT技術に対するノウハウの蓄積に関する問題である。今のビジネスでは、顧客が支払った対価に対して、その時間で実際に開発作業をしているため、基本的にはそこで活用された技術については、顧客が所有権を持つことになる。SIerには何も残らないのである。とある顧客のシステム開発で作ったソースコードを、他の顧客のシステム開発にそのまま適用することは、普通であれば許されない。それは当然、先にシステム開発を依頼した顧客にとっては、後者に比べ過剰にコストを支払ったかのように見えるためだろう。このことは、勿論ご存知の通り、システムの価値を人月計算によって算出することに起因した問題である。この問題に対しては、契約の内容によってうまく再利用できるようにすることもできなくはないし、今のところの実際はそういう運用がなされているのだろうが、道理に適っていないように感じる。

要するに、“はてな”のようなIT企業であれば、自社で作った部品やノウハウはどこでだって使いまわすことができるが、SI企業の場合、顧客からお金を頂いているその時間内で作っているがために、部品を自由に流用することができないのである。かといって、使いまわしたい部品については、その開発コストはSI企業が出資すれば良いという話になったとしても、その顧客から頂いた対価の時間か、自社で出資している時間か、の線引きは非常に難しい上、今のプロジェクトマネジメントでは、その境界を管理することは実質不可能であろう。

SI企業にとって重大な問題と言ったのは、そもそものSI企業としての強みであるはずの成果としてのノウハウが、前述のように会社にたまらない仕組みにあるからというのもあるが、結局のところ、ソースコードなどの成果物を共有できないのであれば、それを開発した開発者にしかノウハウが残らないことが問題の起点なのである。この業界における人材の流動が激しいのも、技術の空洞化などと言われているのも、このことが原因と言えなくもないだろう。SI企業の経営者はもっと、従業員をもっと優遇すべきであるが、その話はまた別の機会にしよう。

改善型開発*2という解決案

さて、前置きが長くなったが、そういう現状に対しての1つの解決案として、【改善型開発】というものを考えてみた。

改善型開発とは、顧客とのプロジェクトの一番初めにリリースを行い、その後は、
保守と改修を繰り返すことで、システムの改善を推進する開発モデルのことである。

ポイントは、受発注の関係を結ぶ以前に、最小の形でのシステムを作り上げ、プロジェクト開始時には、ファーストリリースを行なってしまうというところにある。今までであれば、プロジェクトが開始してからでないと、開発作業は始めないし、ましてやプログラミング作業などは開始後、ずいぶんと経過してからでないと行なわなかった。そこにコペルニクス的転回とも言える発想を持ち込むのである。従来であれば、要求定義⇒設計⇒プログラミング⇒テスト⇒リリースという流れがあったが、大きな枠で見た場合に逆転させてみて、まずは最小のリリースを行なった後、要求を明確化していき、設計を見直し、都度テストを繰り返してシステムを改善させていくのである。

改善型開発を実施することで、SI企業にとっては再利用かつ流用できるソースコードを手に入れることができる。なぜならば、顧客からの対価で開発したシステムではなく、明確に自社の投資によって開発した資産であるからだ。そう、従来であれば納品物として自社に残らなかったソースコードを含む一式の成果物が、SI企業の資産とすることができるのである。このことは、沢山あるSI企業にとって、それぞれの強みとすることができ、かつ、明確にコアコンピタンスをもつことができるようになる。技術力をビジネスに転化することのできる仕組みとしても考えられる。そして、そのことはSI業界全体の健全な競争原理を生むことになるだろう。

改善型開発のビジネスとしての価値

改善型開発に踏み切るための、妨げになるものとしては、経営者から見た場合に最初の投資が必要となることだろう。現状のシステム開発ビジネスでは、そういった事前の投資ということでは、あまり考えられてこなかったためで、投資するとしても、全社的な生産性向上を画策するための本部組織にしか投資の手段はなかったからである。しかし、そもそも、いずれのビジネスにしても、本来であれば、何かに投資をし自社の付加価値を持った上で、商売相手との商いを成立させるのが道理というものだろう。そういう意味では、SI業界は、あまりに手ぶらでビジネスをしてきたと言わざるを得ない。

ファーストリリースをプロジェクト開始時に行なって、後は、拡張を繰り返すという方法をとることで、ディフェンシブな開発として問題視してきた保守性についても再検討することができる。ディフェンシブな開発であれば、保守性を考慮した設計や実装というのは、必ずしも、開発側SI企業にとっても最重要事項とはなりえなかった。というのは、保守に関しては、別途契約であることが多いし、保守コストを下げてしまうと売り上げが下がってしまうこともありえるからだ。このことはあまり触れられていないタブーの部分である。しかし、改善型開発の場合、基本的に改修と拡張の繰り返しであるため、開発側のSI企業としても、保守性を向上することは重要な要素となってくるのである。システム設計指針としての、保守容易性*3が重要なファクターとしてリアリティを持たせることができる。また、発注側と受注側で同じ品質特性を重要視することは、Win-Winの関係構築には必要不可欠な条件だろう。

パッケージビジネスとの違いは何か、それは、そもそものビジネスモデルが異なる。何で商売をするかという点と、パッケージという形からのカスタマイズやフィット＆ギャップを行なうかというのではなく、それだけでも価値のある動くシステムを最初にリリースしてしまうという所で大きく違う。勿論、改善型開発の中で、ファーストリリースのために、パッケージを使うのは重要なことだと思えるし、その中でパッケージを開発すると言うのも、それこそ投資がうまく働いていると言えるだろう。同様に、フレームワークやライブラリも考えることができる。後はオープンにするかどうかは、その企業のビジネス的判断だけだ。

何で商売をするか、という点での話で言えば、改善型開発での契約は人月契約ではなくなるだろう。従来であれば、保守として契約してきた形の応用が一番しっくりくると思われる。つまり、期間契約である。ただ、それだけであれば、改善と呼ばれる部分の要素が少なくなってしまうし、単に人貸しということではSI企業もビジネスとしては成立しなくなってしまう。そこで、実績報酬の考え方も取り入れると良いのではないかと考えている。期間契約での工数精算方式で基本的なコスト計算を行い、後は、それに加えどれだけの実績を残したかによってその報酬額を決めておくことで、開発側からも積極的な提案を出すことのできるオフェンシブな開発を実現させることができるのではなかろうか。

改善型開発のもたらす顧客への価値

改善型開発は、SI企業のビジネスだけを考えている訳ではなく、顧客にとっても様々なメリットがある。前述のように開発側からの積極的な提案を受けられたり、保守性を重要視した開発を実現できたりするほかにも、プロジェクト開始時の段階でファーストリリースが行なわれるので、要求定義という形で目に見えないものに対して、長時間検討を繰り返したりすることはなく、実際に動くシステムを見ながら、追加したい機能を追加したい時に追加していくことができるのである。つまり、その瞬間その瞬間に欲しい機能を手に入れることができ、もしかしたら使わない機能についてあれやこれやと考えることがなくなるのである。えてして、人間と言うものは、実際に存在するものに対してであれば、何が足りない、これができないといった具体的な要求を出しやすいのである。とても理に適ったやり方と言える。

また、顧客にとっては、受発注の段階で、小さいながらも実際に動くシステムと、そのソースコードを見ることができるのである。そうすると、セカンドオピニオンとして、別の監査企業などによって、どういった作りをしているのか、どれほどの実力があるのかなど、判定することができるし、単なるプレゼン資料の出来のよしあしで判断することもなく、より良い企業を選択することができる。このことは、RFP(Request For Proposal)の事前にRFI(Request For Information)を要求するなど、顧客側もディフェンシブにならざるを得なかった状態に比べると格段と良い方向に向いているような気がする。

前向きな保守としての改善型開発

ここまで書いてきた改善型開発だが、実のところ、従来における保守開発の前向きな解釈と言えなくもない。実際に作業する内容は、保守開発でやっていることと大きく違わないはずだ。だからこそ、顧客との距離も近いし、フィードバックもすぐに得られるという保守と同等の利点もあるわけだ。では、保守開発との違いは何か、というと、最初のリリースの大きさが大きな違いになる。

新規案件として、後ほど減価償却されることを考えて、色々な仕組みを加えて作り上げたシステムを、保守担当が引き継いで、メンテナンスをしていくというのが、一般的な保守のイメージだろう。つまり、保守のイメージとは「変化しないこと」を前提としている。それに対し、改善型開発では、機能の追加や拡張は、改善の途中で実施していくことであり、改善のイメージは「変化すること」なのだ。変化というよりも、進化、と呼んでも良いかもしれない。

もう一点異なるのが、最初のリリースを行なうメンバーと、改善型開発を続けるメンバーが同じだという点だろう。ウォーターフォールで良く問題視されているのが、工程間の断絶だと考えられている。そこでは、設計をした要員と実装する要員が別にされているために無駄が発生しているだとか、同じ要員なのに、作業内容を断絶させているだとかが無駄を生じていると考えられる。そういった面からのプロセス改善は考えている人も多いだろう。改善型開発では、断絶についてそういった新規開発の中だけで考えるのではなく、もっと大きなシステムのライフサイクルの面から考えてみた場合の断絶を回避しようとしているのである。それは、新規案件と保守開発の断絶である。この断絶が、システムのライフサイクルから見た場合の一番大きな断絶と言っても良いし、ドキュメントなどについての必要性を問う時に必ず言われることである。改善型開発をすることで、そこでの断絶による無駄すらなくそうと考えている。

プロセスだけでなくシステムそのものを改善する

改善（KAIZEN）という言葉をイメージするとき、よくあるのが、プロジェクトの改善だったり、プロセスの改善だったりなど、人の作業や現場のあり方などを良くしていこうという働きかけだと思う。改善型開発では、そういったプロジェクトそのものの自浄作用としての改善活動であると同時に考えたいのは、システムそのものを改善していこうという考え方だ。作っていく作業の改善もさることながら、作っていこうとしているそのものも、改善していくことでより良いものに仕上げていくのである。

ビルディングなどの建築物であれば、一度完成してしまった後は、それこそメンテナンスをして使い続けるしかないけれども、ソフトウェアというものは形があってないものなので、一度作って完成ではなく、改善していくことのできるものである。そのソフトウェアというそのものの特性に着目した開発モデルを改善型開発で、と考えている。確かに他の業界には学ぶべきところは沢山あるが、そろそろソフトウェアの開発を、他の業界のアナロジーで考えるのではなく、正面から取り組んだ開発モデルというのもあって良いのではないだろうか。

改善型開発のキーワードは、「連続性」と「成長」ということになるだろう。システムそのものの改善が続くこと、そして、そのシステムの成長と共に、使う側の人間と作る側の人間が成長していくことで、さらにシステムも成長させることができるのだと思う。

改善型開発を実現するためには、いくつかのポイントがある。まず重要なのは、なるべく早く動くものを作り上げるための技術、そして、作ったものを容易に変更するための技術である。また、システムの導入形態（デプロイメント）についても、考えなおすためのテクノロジーが必要となるだろう。前者については、Agileがヒントになり、後者については、SAS(Software as a Service)の考え方がヒントになるだろう。こういった実践のための具体的な手法については、別のエントリにしよう。

さいごに

今回の改善型開発の提案のポイントは、開発プロセスの部分ではなく、受発注契約を結ぶ前にSI企業が投資をしてシステム開発をして、それをもって売買のきっかけとするSIビジネスのビジネスモデルの転換にある。改善型開発は、その新しいビジネスモデルを具体化したものという位置づけになる。本文中で開発プロセスと言わずに、あえて開発モデルと書いたのは、そういう意図からである。

改善型開発という、発想の転換を取り入れて検討をしてみたが、何か気づきは得られただろうか。このアイデアは、とある会話*4の中で出てきたものだが、視点を変換(change vision)し、議論しあうことは、なんらかのきっかけを生むのだな、と感じている。

さて悲しいかな、コペルニクス君の地動説はその死後数十年後にようやく正しいとみんなに認められた。今の時代、さすがに迫害されることはないと思うが改善型開発はどうなることだろう。もし改善型開発を読んで、「理想的だけどできない」とでも思ってもらえれば、理想的であることは間違いないのだから、それに向かって進んでもらえれば嬉しい。具体的には、改善型開発をきっかけに議論が広まって、気づきを得て色々と考える人が増えれば、この業界が少しは変わっていくかもしれないな、なんて楽観的に考えている。

*1:http://d.hatena.ne.jp/kuranuki/20060116/p1

*2:改善開発、改善型開発、呼び方はどちらでも良いと思ってます。

*3:保守容易性については、平鍋さんのこちらのエントリが詳しい。

*4:この改善型開発のアイデアの源泉は、id:pastanolyとの会話の中でうまれた。彼に感謝の意を表します。