Hatena::ブログ(Diary)

kuranukiの日記(移転しました)→ http://kuranuki.sonicgarden.jp このページをアンテナに追加 RSSフィード

2006-02-28

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

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

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

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

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

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

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

平鍋平鍋 2006/02/28 16:10 ---
そのソフトウェアというそのものの特性に着目した開発モデルを改善>型開発で、と考えている。確かに他の業界には学ぶべきところは沢山あるが、そろそろソフトウェアの開発を、他の業界のアナロジーで考えるのではなく、正面から取り組んだ開発モデルというのもあって良いのではないだろうか。
---
↑これがすばらしい!やっぱりこうでなきゃ。

河村河村 2006/03/02 15:54 遅ればせながら。
SIerって結局他人の土俵で戦うことに慣れきってしまったんですよね。でも、そろそろ自分たちの武器をちゃんと持って自分たちの土俵で戦うべきなのでしょう。
この話を軸にまた議論したいですね。

出羽出羽 2006/03/02 19:41 > 改善型開発に踏み切るための、妨げになるものとしては、
> 経営者から見た場合に最初の投資が必要となることだろう。
>
> SI業界は、あまりに手ぶらでビジネスをしてきたと言わざるを得ない。

今後、SI企業の経営者が現場の頑張りに甘えることなく『最初の投資』に伴うリスクに対し上手く対処して改善型開発の成功事例が数多く出てくれば、SI業界は良い方向に変わる気がします。

び 2006/05/23 19:18 初めまして。こちらは偶然発見しました。正におっしゃる通りですね。私は元電算機メーカーの研究開発部門にいた者ですが,家庭の事情で帰省し1人で細々とコンサルとシステム開発&提供を致しておりました。
 メーカーでは見向きもされない中小企業にも,おこがましいですがシステムの恩恵を提供できたらの念で臨んで来ましたが,開発側の意識改革と同時にユーザー側の経営者,キーマン,社会的なコンセンサスの改革と定着も大きな鍵になると思い知らされた事がありました。

私は図らずもここ10年以上「改善型開発」を実践して来ました。ユーザーとはコンサル&システム利用費として,負担にならない程度の月額で顧問契約を交わし,当初のシステム提供は一部分からで無料・・・これとて既存市販パッケージを上回るレベルと自負。その後成長を重ね,殆どの業務から財務,管理会計,経営情報に至る統合システムを構築致しました。

ところがある日突然解約の告知。会計事務所の指導に従ってとのこと。理由は,

1.我が社の規模では現システムは素晴らしすぎる。オーバー・スペックだ。世間ではパッケージ使用が主流だ。
・・・確かに「これでどうだ!」「他で作れるものなら作ってみろ」という自負で構築しました。クラサバでDBの障害対策や運用システムもほぼ万全。ハードさえ増強すれば大企業でも通用するスペックです。
なお多機能で高信頼ですが,運用担当者も不要。統一思想で操作も容易です。

2.おびただしい回数の改善と拡張がなされた。それほどまでに改善を必要とするいい加減なものを提供された。
・・・当初に比べ大きく成長しています。陳腐化とも無縁です。

3.何らのトラブルもなく保守契約は納得できない。
・・・信頼性最重視でバグも出さず,転ばぬ先の杖と障害対策やデータ保全も万全,確かにシステム・ダウンはゼロでした。

4.今までの支払額を累計すると多額になる。我が社は膨大な損害を被った。
・・・長い付き合いです。先方の要求でハードも増え,地方展開,役員の家庭,家族用も含めると結構な数に。勿論全数稼働中。なお,ハード,アプリは原価提供でした。悲しいことにシステムの恩恵はカウントなし。

5.怪しげな会社に基幹を任せるわけには行かない。
・・・経営者と役員から懇願されて始まったおつき合い。

「顧問の会計事務所にパソコン好きの若手がいるので,以後そちらに任せる」とのことでした。私が介入以前はその会計事務所経由でパソコンを購入していたのですが,その事務所からは凄まじい有形無形の中傷の連続で,まぁ10年以上続いたのが奇跡かも。

会計事務所主導でリプレース作業が始まり,大幅なグレード・ダウンでパッケージとエクセルの継ぎ接ぎで運用しているようです。ファイル・サーバーとクラサバの違いも知らず,スタンドアロン運用に。
結果的に旧システムを上回るパッケージは見つからず,契約打ち切り後も無償提供を要求されましたが,「旧システム一掃」が目的のリプレースであるため,これは丁重にお断りしました。

これは極端な例ですが,ユーザー・サイドの意識改革も重要だと申し上げたかった次第です。開発側が先方のことを最重視し良かれと思っても,上記の特に1〜4は全く想定出来なかった考えで,先に解約ありきの状況では説明する気力も失せました。将来的には業界の淘汰が進み10年後には「改善型開発」が当たり前かも知れませんが,20年ほど早かったようです。

またシステムを妥当に評価出来るのは,その開発者と同等かそれ以上のレベルが必要なのが悲しいですね。

小さなことでは2000年問題・・・当初から対策済み,消費税変更・・・設定画面のテーブルに日付と率を登録すれば,自動的に・・・等々世間のビジネス・チャンスも逃して来ました。
 バグ連発しメンテ作業に忙殺され,システム・ダウンと回復作業,陳腐化と再開発の繰り返し・・・等々で徹夜作業に明け暮れるが
「運命共同体でとても良く頑張ってくれるベンダー」という,ユーザー・サイドの意識からの脱却も必須のようですね。

ちなみに当方コア・メモリーの時代から,ほぼ全業務の大規模SI,OSや通信システム,DBの開発や規格化の経験があります。目前のPCの統一規格も・・・

長文失礼しました

AranskAransk 2006/07/12 14:28 書かれた改善型開発には大いに啓発される
部分がありました。
しかしポイントは:
>ポイントは、受発注の関係を結ぶ以前に、
>最小の形でのシステムを作り上げ、プロジェクト
>開始時には、ファーストリリースを行なって
>しまうというところにある
この最初に作る最小のシステムがユーザーの
業務において最小限の実用的な仕様を満たして
ないと始まらないところにあるのではないで
しょうか?
即ち、何が最小限の仕様なのか、どこまでの性能を
満たせば良いのか?まず当然ユーザーとベンダーの
間で議論になりますよね?単なるファーストリリースだと
言って強引に導入してもユーザーの現場から総スカンを
くらったりする可能性もあります。
つまり、現場の人間はそれで日々仕事をこなさなくては
ならない。気長にシステムの完成を待つ余裕はないように
思うんです。
そこである程度、完成度の高いものをファーストリリース
することになれば、結局元の開発型に逆戻りせざるを
得ない…

上記はXPによるスパイラル開発で既存のフレームワークや
テンプレートを利用してちょこちょこっと使えるものを
リリースしたつもりが、全然使えなかった、使って
もらえなかったという、個人的な苦い経験からの危惧で
あります。
「技術レベルの低いもの」からの
長文コメント失礼致しました。

aaaaaa 2009/01/10 20:34 テスト

aaaaaa 2009/01/10 20:43 3DCGソフトのMAYAなどはこの開発思想に近いものがあったと思います。
しかし進化改善というよりも新機能の追加というほうに注力するあまり
旧態依然としたコア部分に束縛されながらもシステム全体は複雑肥大化し
抜本的なバグ解消・操作性向上はなおざりにされている感があります。
BtoC的側面が強い商品だからかもしれませんが、システムの完成度よりも
余計な新機能の方が顧客アピールがしやすいというのが原因かと考えています。
改善型開発にもそれなりの問題点は含まれていると思いますが
現状の完全下請け体制よりは健全なのではないかと、共感いたしました。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証