困難は分割せよ
近代科学はおしなべて「困難は分割せよ」という姿勢で文明を発展させてきた。しかし、部分は全体を構成しているが、部分がわかったと言って全体が理解出来たとは言えないのである。脳細胞レベルで記憶の仕組みが解明されてきたからと言って、記憶の再生の仕組みや心の解明が出来たとは言えない。
要件定義で発生する「顧客要求が発散して収束しない」という問題について考えてみよう。
「顧客要求が発散している」のは顧客が要求を言い尽くしていないからであり、要求が発せ続けられれば「収束」しなくなる。顧客要求が増え続けているという心のアラームは何を根拠にしているのだろう。ヒアリングをしながら、スケジュール、予算、進捗会議のことが頭をよぎり不安になるのは良くあることだが、それだけだろうか。
なんらかの基準があるからこそ、量が多いとか増え続けていると言えるはずだが、要求項目の数と実装する機能とは必ずしも一致しない。逆に多くの要求を少ない実装で満たすことができればそれはエンジニアとしての醍醐味ではないだろうか。Aという要求が出されその条件が1つ明確になれば頭の中では「フラグを立ててif文で分岐させよう」、条件が2つになって増えそうな予感がすれば「ステータス管理にして、switch〜caseで分岐させよう」と考える。次にBという要求が出されそれには最初から3つの条件が示されていたが、その中に要件Aの結果に起因するものがあったとする。そうしているうちに要件Cが出され、それには要件Bの結果に起因する条件が示されていたとするとエンジニアには「複雑だ」というスイッチが入る。事実、2つだと溶ける問題が3つになると解けなくなってしまう「三体問題」に近い。実際には要件そのものの数より処理条件の組み合わせで「多い」と感じ始める。プログラミング経験があり網羅的なテスト項目の洗い出しで苦労したことのある人なら解決策を考えながらある感情が芽生え始める。「これはやばい」。論理的に組み合わせの数がどうだとか言う前にそう感じるのは、エピソード記憶ではなくプライミング記憶がそう感じさせていると考えられる。その証拠に、要件が増えたときの言い訳としてスケジュールと予想要求数を越えていると言い、実装工数超過の予測を立て始める。
「細分化したら問題が増えた！」大ざっぱな要件を聞いて解決可能な形に細分化していくと、実装イメージをもとにして実現イメージを考え始める。そこでは実装での吸収出来ない問題が明確になり、顧客に確認する。答えが得られたのと同時に要件が増えることもある。
いずれにしても要件は増える。新たな要件を聞いたとき「解決のヒントをもらった」と考えるか、「また、要求が増えた」と感じるか。「解決のヒントをもらった」と捕らえれば、それまで網の目のように絡まったいくつかの要件がするするっとほどけていく予感がする。絡まった糸を解きほぐすのに、ある程度たるませておいた方がほどけやすいのと同じだ。「また、要求が増えた」と捕らえ、力任せに複雑に絡まった糸を引っ張ったら、もはやほどくことは出来ない。
脳細胞は複雑なネットワークを成している。絡まった糸の比ではない。しかし、必要な情報は１秒あたり100メートルという電気信号（１秒あたり30万キロ）に比べると遙かに遅い速度で処理を始める。脳がコンピュータと比較にならないほど凄いのは膨大な並列処理にある。神経細胞の複数の経路で伝わった信号が同じ経路で出会ったとき、より強い信号として「発火する」。目の前にいる顧客の口から発せられる要求という散弾を受けながら、じっと全体を見つめながら何を問題としているのかを発見しようとしていれば、神経細胞は答えを出そうとして発火を繰り返す。要件を聞きたくないと思っていれば、言葉面だけをとらえて頼りない発火を繰り返すだけだ。
科学者の多くが「ある日突然解決方法がひらめいた」という。砂浜から砂金を探すようなものだが答えがあると信じて思考を続けることにより答えが導き出される。ただし、時間がかかるのが難点だが。
個は全体の一つではあるが、個が解明されたとしても全体の説明にはならない。
大学キャンパスの拡張整備計画について長期的かつ実験的な取り組みが書かれた「オレゴン大学の実験」ではマスタプランの無力性を説いている。小さな単位の計画はマスタプランの一部にはならず、マスタプランは小さな単位の計画の積み上げにはらない。小さな計画が実行されるとそこにいる人も環境も変わる。その小さな予測出来ない結果の積み上げはマスタプランに反映されることはない。しかし、我々は大日程(マスタプラン）、中日程、小日程と計画を作る。なぜオレゴン大学の実験に学ばないのだろうか。違いがあるとすればマスタプランの終焉が見えているかどうかであろう。システム開発では納期というゴールが明示される。街造りの場合無限に続く。
システム開発プロジェクトの開始から納品までの期間に顧客のビジネス環境が変化しないことはありえない。開発が終わるまで変わることはないと思える業務が、開発対象となったとたんに変化し始める。
我々はありえないゴールという蜃気楼を目指して進んでいることもある。
システム開発が街造りと同じように捕らえたらどうだろう。小さなシステムをリリースすればそのシステムの存在によって使う人の仕事や生活に少なからず変化が生じるはずである。導入したシステムが意図したとおり効率化に寄与すれば、社員の帰宅時間が早くなり、それまで翻弄されていた業務から開放され、生活そのものが変わるかも知れない。もっと稼ごうと思ったり、自分の趣味に没頭したりするかもしれない。逆に、効率が悪かった場合は、さらに非効率になり、仕事に対する不信感が募り、残業してがんばるか、転職を考えるだろう。
個人単位の小さな変化はやがて組織の変化に発展する。
そこにはマスタプランでは予想もつかない事態が発生する。
脚注）
「感性チームハックス」参照
要件定義で発生する「顧客要求が発散して収束しない」という問題について考えてみよう。
「顧客要求が発散している」のは顧客が要求を言い尽くしていないからであり、要求が発せ続けられれば「収束」しなくなる。顧客要求が増え続けているという心のアラームは何を根拠にしているのだろう。ヒアリングをしながら、スケジュール、予算、進捗会議のことが頭をよぎり不安になるのは良くあることだが、それだけだろうか。
なんらかの基準があるからこそ、量が多いとか増え続けていると言えるはずだが、要求項目の数と実装する機能とは必ずしも一致しない。逆に多くの要求を少ない実装で満たすことができればそれはエンジニアとしての醍醐味ではないだろうか。Aという要求が出されその条件が1つ明確になれば頭の中では「フラグを立ててif文で分岐させよう」、条件が2つになって増えそうな予感がすれば「ステータス管理にして、switch〜caseで分岐させよう」と考える。次にBという要求が出されそれには最初から3つの条件が示されていたが、その中に要件Aの結果に起因するものがあったとする。そうしているうちに要件Cが出され、それには要件Bの結果に起因する条件が示されていたとするとエンジニアには「複雑だ」というスイッチが入る。事実、2つだと溶ける問題が3つになると解けなくなってしまう「三体問題」に近い。実際には要件そのものの数より処理条件の組み合わせで「多い」と感じ始める。プログラミング経験があり網羅的なテスト項目の洗い出しで苦労したことのある人なら解決策を考えながらある感情が芽生え始める。「これはやばい」。論理的に組み合わせの数がどうだとか言う前にそう感じるのは、エピソード記憶ではなくプライミング記憶がそう感じさせていると考えられる。その証拠に、要件が増えたときの言い訳としてスケジュールと予想要求数を越えていると言い、実装工数超過の予測を立て始める。
「細分化したら問題が増えた！」大ざっぱな要件を聞いて解決可能な形に細分化していくと、実装イメージをもとにして実現イメージを考え始める。そこでは実装での吸収出来ない問題が明確になり、顧客に確認する。答えが得られたのと同時に要件が増えることもある。
いずれにしても要件は増える。新たな要件を聞いたとき「解決のヒントをもらった」と考えるか、「また、要求が増えた」と感じるか。「解決のヒントをもらった」と捕らえれば、それまで網の目のように絡まったいくつかの要件がするするっとほどけていく予感がする。絡まった糸を解きほぐすのに、ある程度たるませておいた方がほどけやすいのと同じだ。「また、要求が増えた」と捕らえ、力任せに複雑に絡まった糸を引っ張ったら、もはやほどくことは出来ない。
脳細胞は複雑なネットワークを成している。絡まった糸の比ではない。しかし、必要な情報は１秒あたり100メートルという電気信号（１秒あたり30万キロ）に比べると遙かに遅い速度で処理を始める。脳がコンピュータと比較にならないほど凄いのは膨大な並列処理にある。神経細胞の複数の経路で伝わった信号が同じ経路で出会ったとき、より強い信号として「発火する」。目の前にいる顧客の口から発せられる要求という散弾を受けながら、じっと全体を見つめながら何を問題としているのかを発見しようとしていれば、神経細胞は答えを出そうとして発火を繰り返す。要件を聞きたくないと思っていれば、言葉面だけをとらえて頼りない発火を繰り返すだけだ。
科学者の多くが「ある日突然解決方法がひらめいた」という。砂浜から砂金を探すようなものだが答えがあると信じて思考を続けることにより答えが導き出される。ただし、時間がかかるのが難点だが。
個は全体の一つではあるが、個が解明されたとしても全体の説明にはならない。
大学キャンパスの拡張整備計画について長期的かつ実験的な取り組みが書かれた「オレゴン大学の実験」ではマスタプランの無力性を説いている。小さな単位の計画はマスタプランの一部にはならず、マスタプランは小さな単位の計画の積み上げにはらない。小さな計画が実行されるとそこにいる人も環境も変わる。その小さな予測出来ない結果の積み上げはマスタプランに反映されることはない。しかし、我々は大日程(マスタプラン）、中日程、小日程と計画を作る。なぜオレゴン大学の実験に学ばないのだろうか。違いがあるとすればマスタプランの終焉が見えているかどうかであろう。システム開発では納期というゴールが明示される。街造りの場合無限に続く。
システム開発プロジェクトの開始から納品までの期間に顧客のビジネス環境が変化しないことはありえない。開発が終わるまで変わることはないと思える業務が、開発対象となったとたんに変化し始める。
我々はありえないゴールという蜃気楼を目指して進んでいることもある。
システム開発が街造りと同じように捕らえたらどうだろう。小さなシステムをリリースすればそのシステムの存在によって使う人の仕事や生活に少なからず変化が生じるはずである。導入したシステムが意図したとおり効率化に寄与すれば、社員の帰宅時間が早くなり、それまで翻弄されていた業務から開放され、生活そのものが変わるかも知れない。もっと稼ごうと思ったり、自分の趣味に没頭したりするかもしれない。逆に、効率が悪かった場合は、さらに非効率になり、仕事に対する不信感が募り、残業してがんばるか、転職を考えるだろう。
個人単位の小さな変化はやがて組織の変化に発展する。
そこにはマスタプランでは予想もつかない事態が発生する。
脚注）
「感性チームハックス」参照
2008年03月02日(日) 00:09:17 Modified by ko_teru