<HOME> ― <XP (エクストリーム プログラミング)> ― <ソフトウェア開発プロセスを見直そう>
XP (エクストリーム プログラミング) 関連のイベントに参加して，ソフトウェア開発プロセス関連で学んだり考えたりしたことを少し
以下は，XP (エクストリーム プログラミング) 関連イベント参加レポート集で書いた文を合成したものである．
ソフトウェア開発における最大の課題は，開発期間の短縮化，低コスト化，そして目まぐるしく変化するユーザニーズやビジネスニーズへの柔軟で迅速な対応である．そして，これらを解決するためには従来の開発方法では中々難しいということが段々判ってきた．
ソフトウェア開発以外の工業製品の場合は，工業的に比較的最適化された開発プロセスが多くの企業の工場において採用され成果を上げている．だが，ソフトウェア開発ビジネスにおいては，まだまだ，勘に頼った家内制手工業のような段階にある企業が多く，工学的に一定の成功を得られていないのが現状であろうかと思う．
例えば，米国で 1994 年からの 23,000 の大中小の会社のプロジェクトを対象に行われた大規模な調査 ("The Standish Group CHAOS" と云う処の調査) によると，プロジェクトの成功率は以下のような数字になっている．
※ プロジェクトの成功の基準は，納期・コスト・顧客満足度が計画通りまたはベターだったかどうか
ソフトウェア開発においても，ビジネスに勝つためにソフトウェア開発のプロセスを最適化しようという動きが最近になって大きくなってきている．
「ソフトウェア開発がうまく行かない，どうしてだろう．どうすればうまく行くのだろう」
ソフトウェアの開発者がずっと考えてきたことである．
中には，「うまく行かないとかどうすればうまく行くかなんて，そんな風に考えたことはない．そして問題は起こっていない」と言う人も居るかも知れないが，そんな人は自分の失敗に気付いていないか，失敗しなかったことにしたいだけであろう．
従来の開発方法では中々うまく行かない．これは現実である．何故従来の開発手法ではうまく行かないのであろうか．
ここでいう「従来の開発方法」とは以下のようなものである．
この遣り方は，元々，まだソフトウェアが「ハードウェアのおまけ」だった頃に，ハードウェアの製造工程をソフトウェアに流用したものである．
しかし当然のことながら，ハードウェア開発とソフトウェア開発では性質が大きく異なる．ハードウェアでは製造途中や製造後に機能を変更する事はないが，ソフトウェア開発ではそれを行うことが特に重要となる．
この従来の開発方法では，
というアプローチを取ることが多い．
だが，このソフトウェア開発を小さな構成要素に分解しそれぞれの確かさを上げることで全体としての確かさを確保しようというアプローチは，大概うまく行かないようである．
納期が近づいてくると，決まって仕様変更が相次ぎ，設計はぼろぼろに成っていく．皆が当たり前のように残業や休日出勤を始め，それによりどんどん開発コストがふくらんでいく．
ここで例題をあげてみたい．
例題．
或るシステムを開発するための数十人の開発要員からなるプロジェクトが有るとする．
このプロジェクトで納期迄にきちんとしたシステムを作り上げるにはどうしたら良いだろうか．
これを従来の考え方で解くと，多分こんな感じになる．
「従来の思考プロセス」
そして，次にあげるような会話が，日本の多くのソフトウェア開発の現場で交わされているのではないだろうか．
仕様作成者:「こういうようなプログラムを作って欲しいのですが，どの位掛かりますか」
プログラマ:「うーん．何とも約束できないです．もっと仕様が具体的でないと」
仕様作成者:「仕様書はここにあります．見積もりを出してもらえますか」
プログラマ:「えっと… そうですね… 全体でざっくり四ヶ月くらいでしょうか」
仕様作成者:「もっと確実な数字が必要なんです．機能毎に細かく日数を書いた見積もり書を出してもらえますか」
プログラマ:「だって紙二枚分の仕様書しかもらってませんし… 仕様の精度以上の精度での見積もりは無理ですよ．それに，また途中で仕様変更があるでしょうし」
仕様作成者:「少しでもプロジェクトの納期を厳密にしたいので，少しでも確実な見積もりが必要なんです．何とか頼みますよ．このプロジェクトは是非とも成功させたいんです」
プログラマ: (仕方ない．いつものように，残業と休日出勤で調整するか)
…納期間近になって，実際に動かしながらレビュー…
仕様作成者:「うーん… なんかイメージと違います．使い勝手が悪過ぎますね．入力がもっとこうスムーズに行かないと」
プログラマ:「でも仕様通りですよ (いつも納期間近になってからなんだから)」
仕様作成者:「いやー とにかくこれではお客さんも納得しませんから，こういう風に変えないといけないです」
プログラマ:「納期的に今からだとかなり厳しいんです．もう少し早ければなんとでも成ったのですけれど」
仕様作成者:「ちゃんと動くものを見たのは今日が初めてなもので」
プログラマ:「…でもまあ，そういうことなら直すしかないでしょう．仕様変更ですね (仕方ない．いつものように，残業と休日出勤で調整するか)」
そして，プロジェクトの管理者はこう言うかも知れない．
管理者:「昔からこの遣り方でやってきたんだ．開発ってのはこういうもんなんだ．昔は今よりもっと残業だって多かったし，残業代だってまともに出なかったんだぜ．良く会社に泊まったもんだ」
そして勿論，昔からそれら
従来の開発方法の場合，残業は「予定通り」のものでなければならない．当初の計画に入っていない残業や休日出勤の分は，すべて余計なコストとなってしまう筈である．上記のような計画外の残業や休日出勤が行われてコストが予定を大幅に上回るということは，即ちプロジェクトの失敗を意味しているべきである．
ところが現実の開発においては，プロジェクトが終わったときにプロジェクトの構成員には失敗したかどうかすら判らないことがある．
そして，最後には決まって，仕様の不十分さや見積もりの甘さが指摘される．
だが，本当にそれが原因なのだろうか．或るいは，仮にそれが原因だとして，そこを解決できるのだろうか．
だとしたら，なんで「いつもいつも仕様は不十分」で，「いつだって見積もりは甘い」のだろう．本当に．もう何十年も．
「従来の開発方法」には何か欠陥があるのだろうか．
以下では，「従来の開発方法」の抱える根源的な欠陥について考察して行きたい．
ここで「従来の開発方法」というのは，所謂「ウォーターフォール型」(注 1.) のもので上流工程から下流工程に進むと再び上流工程に戻って来ないようなものを指している．
つまり「分析」→「設計」→「実装」→「テスト」→「リリース & 保守」と，各工程が終わってから次へと順に進んでいくようなもののことである．
この方法では，「実装」の終わりの方に成らないと動くものが見られないことが多い．その為に，その頃になると様々な問題点が表面化して来ることに成る．リスクが工期の後ろの方まで解消されない
(注 1.) 「ウォーターフォール モデル」の基と成ったとされるのは 1970 年の米国のロイス (W.W.Royce) の論文と云われているが，この論文で提案されたもともとの開発モデルでは「フィードバック ループ」が用意され，上流工程を見直すことが推奨されていた．また，この論文自体ではこの開発モデルを「ウォーターフォール モデル」とは呼んでいない．
その後，一般的に良く用いられるようになった開発モデルでは「フィードバック ループ」が無い「逐次開発モデル」となり，滝が上から下へと流れ落ちるように開発していくことから「ウォーターフォール モデル」と呼ばれている．
「何をどのようにするかを最初に十分な精度をもって決めて，その通りにやる」というのは，ソフトウェア開発では次の二つの理由でうまく行かない．
それを以下で示してみたい．
何故「従来の開発方法」ではうまく行かないのか．まずはそれを「複雑系」という観点から考えてみたい．
ここに「ソフトウェア開発というのは複雑系である．だからそれではうまく行かないのだ」という説がある．
以下，複雑系に関して，ソフトウェア開発に関係有りそうな部分を少し述べてみたい．
気象学者エドワード・ローレンツ (Edward N. Lorenz) の 1972年の講演は，
『予測可能性：ブラジルで一匹の蝶が羽ばたくとテキサスで大竜巻が起こるか』
(Predictability: Does the Flap of a Butterfly's Wings in Brazil set off a Tornado in Texas?)
と題されていた．天気予報はなぜ外れるのか，という点からカオス的な性質に関して説明したものである (未だカオスと云う言葉は無かったが)．
天気予報では，気象を観測し，流体力学の方程式によって未来の大気の状態を計算する．日本で一番速いスーパーコンピュータはこの為に使われている，と聞いたことがあるが，計算量はともかく計算自体は出来る．
ところが，ローレンツは大気の対流運動の式を持ち出し，その計算結果がカオス的な性質を持つことを示した．初期データの僅かな誤差が，時間とともに指数関数的に広がって仕舞うのである．
「バタフライ効果」とは，一匹の蝶の羽ばたきのような小さな大気の動きが時間とともに指数関数的に広がって遠方で大竜巻となることもあるかも，という喩えである．
映画化もされた「ジュラシック・パーク」と言う小説の中でイアン・マルカム博士と称する数学者が複雑系について語っていたのを覚えている方もいるであろう．
「これを一名、バタフライ効果という。北京で蝶々がはばたけば、ニューヨークの天気が変わるというやつだ」
少し言葉が変化してはいるが，これはイアン・マルカム博士が，「ジュラシック・パーク」というシステムが何故うまく行かないかを説明していく中の一節である (「ジュラシック・パーク」 マイクル・クライトン 著 酒井昭伸 訳 早川書房)．
「或る強さで或る方向にボールを投げて，未来のこのボールの位置を予測する」のような線形 (linear) な問題の場合にはこのようなことは起こらず，ほぼ正確に予測が可能である．初期値の精度を上げれば上げただけ予測の精度を上げることが出来る．
ところが，非線形 (non-linear) な対象の場合，式で表されていて計算可能で本来決定論的 (初めの状況によって未来が決定する) であるにもかかわらず，或る程度遠い将来では予測が不可能になってしまう場合が有る．これをカオスと呼ぶ．
複雑系は，高次元なカオスである．非線形な多くの要素と要素間の非線形な相互作用から成るシステムで，或る要素の性質をいくら解析してもシステム全体の振る舞いが予測出来ないという性質を持っている．
例えば，大気の流れの中には非線形な相互作用が多く存在していて，大変複雑な動きをして予測が困難である．また，人間の脳も非線形な性質を持つ神経が相互作用し合うことで機能している．その他の生物の組織や生物自体，生物の集まり (生態系や社会) 等も同様である．
そして複雑で予測困難ではあるが，全体としては或る秩序を有している．
脳の構成要素である神経は非線形でカオス的な振る舞いを持っている．そして沢山の神経は並行して動作し，また相互に作用する．それでいて脳は，全体としては極めてうまく機能している．
このような系では，ギリシャ以来の伝統的な学問の手法，つまり出来るだけ簡潔な基本原理 (例えばニュートンの運動方程式) に還元して理解しようとする手法が使えない．
多くのソフトウェア開発者によるチームで開発が行われるような場合．個々のソフトウェア開発者は製造機械のような単純なものではなく，「エージェント」として振舞う．即ち，自分を取り巻く環境と適応していくように自ら環境と相互作用をしていく存在である．
※ 「マトリックス」という映画を御覧になった方は，コンピュータの作り出した世界を意思をもって自由に行き来する「エージェント」という監視プログラムの事を覚えているかも知れない．
「エージェント」から成り立つチーム全体は，複雑系の性質を持っている．非線形な性質を持っている為，「全体は部分の総和」ということが云えない．そしていくら個々の構成要素を細かく規定しても全体としての振る舞いの予測が大変困難である．
これはつまり，「従来の開発方法」式の計画の立て方が無意味であることを表している．
複雑系においては，最初に立てた仕様・見積もりの誤差が，例えば1％よりずっと小さくとも，或る程度の開発期間が過ぎると，それが桁違いの誤差を生むことと成るだろう．そして実際には，そのような小さい誤差で仕様・見積もりをすることは不可能である．
このことから，もっとこの複雑系の持つ予測不可能性を前提とした上で，時間と共に生じる「ずれ」に臨機応変に対応していくような開発方法が必要であると云える．
さて次に，「暗黙知」と「形式知」という観点から考えてみたい．
次にあげるのは野中郁次郎氏の「SECI モデル」と云われるものである．
これは，組織において知識が創造されるときの四つの知識変換プロセスのモデルについて説明したものである．
知識には暗黙知と形式知の二つがある．
そして，共同化 (Socialization)，表出化 (Externalization)，連結化 (Combination)，内面化 (Internalization) の四つのプロセスが相互に作用することで，組織及びその構成員としての個人の知識レベルが上がっていく．
私事で申し訳ないが，今年の私のテーマは，「学而不思則罔，思而不学則殆 (学びて思はざれば則ち
形式知を暗黙知にし暗黙知を形式知にしていくことが知識の習得には大切だと考えている．単に情報を持っていることと，知識としていることは異なる．実際に体験したり考察してみることで自分のものとしなければ知識として使えるものにはならない．
暗黙知というのはその儘では，他の人の知識とすることは難しい．一旦形式知とする必要がある．
ここで，暗黙知を形式知として伝えるプロセスの例をあげてみたい．
仏教において，釈迦は深い思考の末真実を悟ったとされる．
そして，釈迦は自分の知識を人に伝えるのに，それが一般の人には余りに難解であったがために，直接的には語らずメタファー (暗喩) を使って語ったそうである．
「真理・悟りの世界は比喩で語るしかない」という言い方をよくされる．釈迦が直接その概念を口にできたとしても，言葉だけでは中々他の人の知識にはならない．言葉として文法的に理解できたとしても体感できないのである．
アインシュタインの言葉に「何かを学ぶためには，自分で体験する以上に良い方法はない」というものがある (この言葉は最近マイブームに成っている)．体験なくして知識を吸収することは困難である．知識を己のものとする為には，体験によるフィードバックが必要になる．
そこで，メタファーを使い，その人との共通の他の体験に喩えることで，知識の一部を伝えようとするのである．
これは，つまりこういうプロセスである．
釈迦の暗黙知 →形式知 (メタファー) → 弟子の暗黙知
メタファーが形式知の役割を果たしている．
ちなみに，イエス・キリストも同様に弟子に対してたとえ話を多用している．
さて，「従来の開発方法」の場合をもう一度振り返ってみたい．
ここでは，「十分な要求分析に基づく精度の高い仕様」が計画通りにプロジェクトを成功させる前提となっている．
この仕様であるが，考えるに，仕様には，暗黙的な仕様と明示的な仕様があるのではないだろうか．それぞれ，先に述べた暗黙知と形式知に当たる．
仕様書は勿論明示的な仕様である．その部分に関する知識はプロジェクト内で共有される．しかし，暗黙的な仕様がない完璧な仕様書を作成することはできない．もし完璧な仕様書があれば，それを完全に別の二つのチームに渡しても瓜二つのものができることになるが，そのような全てを網羅した仕様書は作れない．
最終的に望まれる仕様は，初めはその一部が暗黙知の形で存在しているに過ぎない．暗黙知が暗黙知である間は文書化できない，のである．
顧客であれエンドユーザーであれ開発者であれ，既存のプログラムを移植するというような特殊な場合は別として，開発の初期には十分な精度をもって仕様を明示できない．
顧客やエンドユーザーは，何らかの問題を抱えていて，ソフトウェアを買うことでそれを解決しようとしている訳である．ところが大概の場合，それがどんな問題であり，どのように解決すべきか，を初期の段階で完全に明言・文書化できる訳ではないのである．それらは，開発者等や実際に動くソフトウェアからのフィードバックを経て徐々に表面化してくる．
つまり，これが「従来の開発方法」が無効である理由の一つなのではないだろうか．
「従来の開発方法」による精度の高い開発には，精度の高い見積もりが必要だが，その為には精度が高い仕様が必要になってしまう．しかし，初期段階では，仕様の一部は暗黙知であり個人的な知に過ぎないため，その部分に関してはコミュニケートできない．仕様を共有する為の文書が存在しえない．
最終的な仕様となるためには，暗黙的な仕様が共有され，そして表面化することで更に新たな仕様が生まれていく必要がある．
即ち，
共同化 → 表出化 → 連結化 → 内面化
という繰り返しが必要になる．暗黙知を共有し，形式知として明示し，組み合わせて新しい知識を作り，それを各自が自分のものとしていく．
その為には，体験による数々のフィードバックが必要となる．一気に行うことはできず，スパイラルなアプローチが不可欠となる．
このことは，「何故，最初に言われた要求仕様通りに作ったのに満足してもらえないか」の答えにもなっているように思う．
開発を成功させるためには，様々な面で，上記のような「SECIモデル」による知識変換プロセスが重要となるのではないだろうか．
開発に関するノウハウの多くは「暗黙知」によって蓄えられている．それぞれの開発者は，多くの経験により専門分野に通じ，実際の開発をこなすことができる．非常に有用な知識であるが，それらは各自の胸の中にしまわれているものが多い．形式知の形になっていないため，それらのノウハウを他の人が役立てることが難しい．
開発プロセスを改善することにより，これらの知識も，「共同化 → 表出化 → 連結化 → 内面化」のプロセスにより，より深いノウハウへと変えていくことも可能ではないだろうか．
その為にはそのようなことが起きるような開発プロセスが必要である．何もせずにいてこのような知識変換プロセスが起きることは期待しない方が良いようである．
ここで，いつまでも個人の暗黙知の段階に留まっているプロジェクトの例をあげてみたい．
「どこに情報があるのか，誰に責任と権限があるのか．問題があるのかないのか．そしてプロジェクトの目的は何?」
どこにも明らかになっていない．熟練者の心の奥にそっとしまわれている．
他から新しくプロジェクトに加わった人は，試行錯誤しながら手探りしていくしかない．
UP (ユニファイド・プロセス) や XP (エクストリーム プログラミング) をはじめとして解は幾つか用意されているのである． これらは，ベストとは限らないが少なくともベターである．「銀の弾丸」ではないが「実践可能で現実的な」解となっている． 少なくとも「従来の開発方法」にしがみつく理由ばかり考えている場合ではないのではなかろうか．
参考資料:
「ジュラシック・パーク」 マイクル・クライトン 著 酒井昭伸 訳 早川書房
(財)岐阜県産業経済振興センター主催 北陸先端科学技術大学院大学知識科学研究科長 野中郁次郎氏 の講演会 (1997/09/02) 「知識創造企業」
Copyright © 1997-2008 Sho's Software
<HOME> ― <XP (エクストリーム プログラミング)> ― <ソフトウェア開発プロセスを見直そう>