ObjectSquare [2009 年 3 月号]

[技術講座]


ジョー・マラスコ氏
「 21 世紀のソフトウェア開発管理」セミナー報告

補足インタビュー前編

( 株 ) オージス総研 藤井拓

今回と次回の 2 回に渡り、「 21 世紀のソフトウェア開発管理」セミナーの全日程を終えた 10 月 3 日にオージス総研の田町オフィスでマラスコさんに行ったインタビューの内容を報告します。今回は、反復的な開発におけるチェックポイント、そもそもなぜ反復的な開発に行き着いたのか、開発ドキュメントについてお聞きしました。




2 つのチェックポイントと終点

--最初の質問は、チェックポイントと反復(イテレーション)との違いに関するものです。反復がもっとも細かいチェックポイントであることは明らかですが、マラスコさんの著書には大きなレベルのチェックポイントを開発途上に 6 つ設けた方がよいと書かれています。反復と大きなレベルのチェックポイントの違いを説明して頂けないでしょうか。

プロジェクトには、通常「方向づけ」、「推敲」、「作成」、「移行」の 4 つのフェーズがあることを理解することが大切である。各フェーズを完了するためには、複数回の反復を要するかもしれない。これらの各反復において、これまでの反復を通じて学んだ事は何かということを理解することが大事である。しかし、フェーズの区切りにあるチェックポイントは反復単位のチェックポイントよりはるかに大事なのである。例えば、推敲フェーズと作成フェーズの間のチェックポイントはプロジェクトを問わず最も重要なチェックポイントである。しかし、そのことが理解されていないことが多い。アーキテクチャの妥当性が検証されていないならば、決して作成フェーズに進んではならないのである。多くのプロジェクトでは、推敲フェーズが完了したと考えて作成フェーズに進むが、それは時期尚早であることが多い。その結果として、大きな災難に陥るのである。そうなので、私は以下のように考えている。

藤井注:「方向づけ」、「推敲」、「作成」、「移行」は統一プロセスの 4 つのフェーズである。

これらの両方が必要なのだ。別の言い方をすると、小さなチェックポイントの1つで間違いを犯すかもしれないが、その間違いは次の反復で取り戻せるので凌げる。それに対して、大きなチェックポイントで間違いを犯したら、ほとんど常に失敗へと至る。

インタビュー終了後
インタビュー終了後

藤井注:大きな判断ポイントとは、プロジェクトを続けるか、止めるかの判断を行うポイントという意味である。反復毎に反復の目標が達成されたかどうかのチェックを行い、軌道修正を行う。しかし、そこで大局的な判断を下すことは難しいので、大きく軌道を外れていてもプロジェクトを続けてしまう可能性が高い。大きな判断ポイントは、そのような事態に対する歯止めの役割を果たす。

--セミナーの質疑において、反復的な開発とアジャイル開発の違いは終点が決まっているか否かという点にあるとおっしゃっていました。反復的な開発では、反復ごとに軌道修正をするにも関わらず、終点が決まっているのはどうしてだと疑問に思われた方も多かったのではないかと思います。どのようにして、反復ごとに軌道修正と決まった終点を両立できるのでしょうか。

それは、なんらかの秩序と享受している自由とのバランスを取るからである。このやり方と比較して、アジャイルの問題の 1 つと私が思うのは、プロセスを通じて非常に自由なのだが、自由がありすぎて終点を見失うことが多いということである。そのために、2 つのリスクがある。1 つ目のリスクは、終点に決して達しないというリスクである。というのは、要求は変化し、プロジェクトが目指す方向が変わり、さらに要求が変化し、変化が収まらず、安定化しないからである。だから、15 週目に行った作業を 17 週目にやり直し、19 週目に再び 15 週目に行った作業を行うというようなことが起こりかねないのである。このような状況を私は「スラッシング」と呼ぶ。これが大きなリスクの 1 つだ。もう 1 つの大きなリスクは、たゆまない変更の過程で終点を見失ってしまうというものである。目標となる円がどんどん大きくなるのである。その結果、到達したところがどこであれ、終点に達したと主張するのである。最終的に到達したところが最初に目指していた終点からはるかに遠くてもだ。終点が大きくなるのは問題ではないが、大きくなるにつれて元々の円の中心がどこだったかを思い出せなくなるのである。



各フェーズの目標

--多くの場合、少なくとも日本では、方向づけのような早い段階でお客様がはっきりとした開発構想や新たなシステムのあるべき姿に関するアイデアを持つのは難しいことが多いように思います。その結果として、システムのあるべき姿を推敲フェーズの中で苦労して模索することになります。新しいシステムの構想について、より早い段階で合意を形成するのを助ける、よい方法はないでしょうか。

私は、方向づけと推敲において 2 つのことが大事だと思う。1 つ目は、モデリングを活用するということである。モデリングは非常に有用である。というのは、モデリングによりユーザーと開発チームの間のコミュニケーションが促進されるからである。例えば、開発対象のシステムがなぜこのようなアーキテクチャになったかをユーザに対して開発チームに説明してもらうのである。今日、クラウド・コンピューティングについて多くの話をしたが、ユーザはどこでコンピューティングが行われるかを知らない。ローカルでコンピューティングが行われることもあるだろうし、サーバで行われることもあるだろうし、他の場所で行われることもあるだろう。その結果として、ユーザが何らかのリクエストを行う場合に、それが簡単に実現できるか、実現できないかが分からない。というのは、ユーザはアーキテクチャをまったく理解していないからだ。方向づけと推敲の間に、モデリングを行い、システムがどんな感じになるかを図で見せようとする。このような視覚的な情報は、コミュニケーションの大きな助けになると思う。これが 1 つ目だ。開発チーム自身がモデリングをある程度受け入れているということは、開発チームが自分たちの作業を行うためよりも、ユーザに対するコミュニケーションを行うという点で重要である。開発チームの中では、技術的な用語で図がなくてもコミュニケーションができるだろうが、そのような技術的な用語はユーザに通用しない。そのため、図がコミュニケーションの手段として非常に価値あるものになるのである。

藤井注:クラウド・コンピューティングについては、10/3 に行った出版社のインタビューで話題にあがった。それ以外に、マラスコさんの息子さんが人事系の SaaS を提供している会社に勤務しているという話もお聞きしました。

2 つ目に、方向づけと推敲の両方において、プロトタイプを開発し、動くコードを持つということは、単なるシミュレーションにすぎないとしても、非常に価値があることである。というのは、このプロトタイプによりユーザが最終的なシステムがどのような形になるかをより良く理解することができるからである。そのため、方向づけや推敲で必ず動くコードを持つようにした方がよい。非常に大事で見逃せないアーキテクチャの問題で、コードを書かないと明らかにならないようなものがある。そのようなアーキテクチャの問題を、コードを動かすことで発見できるかもしれない。

反復的な開発では、方向づけがあり、推敲があり、作成があり、移行があるのだが、各フェーズに 1 回以上の反復があり、各反復でほとんど同じ開発作業を行う。反復的な開発の大きな課題は、それらの作業の力点が異なるということである。多くの開発組織で目にするのは、「反復的な開発を実践しているよ。方向づけでは、要求だけを作るんだ。推敲では、かつて設計と呼んでいたことを行うんだ。作成では、コーディングを行うんだ。移行では、テストを行うんだ」という認識である。このような対応付けを行い、いわゆる「方向づけ」では要求だけを定義するのである。そして、方向づけで本来行うべき他の開発作業は一切行わないのである。次に、「推敲」に移り、紙の上での設計を行うという感じで開発を進めるのである。結局、開発作業の名前を変えているだけで、根本的なプロセスを変えていないのである。「作成」でコーディングを始めるが、その時点ではアーキテクチャの妥当性は全然検証されていないということが起きたりするのである。これは、非常に危険である。用語を単に使うだけではなく、反復的な開発プロセスがウォーターフォール開発プロセスとは異なることを理解することが大事である。

--各フェーズの目標を理解することが大事ですよね。

まさにそのとおりである。方向づけが終わる時点で、要求をよりよく理解していなければいけない。そのことは正しいが、方向づけでは他にも達成すべきことがある。推敲についても同じようなことが言える。推敲の終わりでは、設計の基本部分が得られる。でも、それ以外の開発作業も行うということがさらに重要である。これが、危険性の1つである。反復的な開発を実践しているといって失敗したプロジェクトの原因調査を行うと、プロセスは全然変わっておらず、呼び方だけが変わっていたということを見つけることが多い。


インクリメンタル開発と反復的な開発

--最近、ウォーターフォール開発を複数回行い、各開発でシステムの部分を追加的に開発する、インクリメンタルな開発を行えば反復的な開発と同様な効果を実現できるんだという意見を耳にすることがあります。

同意しない。

--なぜですか。

(反復的な開発は)根本的にリスクを軽減するからである。反復的な開発では開発の進行とともにリスクが減るが、ウォーターフォール開発では開発が進行してもリスクが減らないままである。リスクが減らない根本的な原因は、アーキテクチャの妥当性が全然検証されていないからである。開発要員、時間、お金への大きな投資を開始する区切りにおいて、良好なアーキテクチャがないのである。

--もっと具体的な例で言えば、3 ヶ月のウォーターフォール開発を複数回行い、1 回目の開発でアーキテクチャの妥当性を検証するためにユーザ機能をいくつか実装するとします。その後、さらに機能を追加する形で開発を行います。このような形であれば、反復的な開発と同等だといえるのでしょうか。

それでもなんとかなるかもしれない。しかし、アーキテクチャで想定していない新たな機能を追加するということが起きる可能性がある。その時点で、その新たな機能を開発範囲に入れないか、その新たな機能を入れるがアーキテクチャを変更するというコストを支払うことになる。もしアーキテクチャを作るチームが非常に優秀であり、将来求められる機能を予期し、その機能のアーキテクチャへの影響を予測できれば、その開発プロセスでうまくいくかもしれない。

聞いてお分かりのように、私はアーキテクチャを非常に重視している。アーキテクチャは、システム全体の背骨である。手や足、耳に少しの変更を行っても大丈夫だが、背骨を変更するのは非常に難しい。



反復的な開発を始めた経緯

--次の質問は、マラスコさんの著書「新・ソフトウェア開発の神話」についてのものです。なぜ反復的な開発を実践し始めたという点は、著書に書かれていません。反復的な開発を行い始めたのは、どういう動機からでしょうか?

まず、従事したプロジェクトの多くが失敗したからである。

その失敗を通して、私自身は大きなプロジェクトが失敗する原因について自分の考えをまとめたのである。特に、結論の 1 つ、というよりはソフトウェア開発の失敗の原因で非常に嫌だったのは、非常にたちの悪い失敗モードであるという点である。多くのプロジェクトで、リーダーが指揮し、マネージャがリーダーに進捗の報告を行うが、「問題なし」、「問題なし」、「問題なし」、「すべて順調」、「すべて順調」という感じで、納期の直前、例えば納期の2週間前になって初めて「開発が遅れそうだ」というアナウンスがされる。そこで、「どれくらい遅れそうだ」ということを質問すると誰も答えられないのである。それから数週間、プロジェクトがどれくらい遅れそうかということを調べると、大変な状態になっていることが判明するのである。2、3週間どころではなく、6ヶ月は遅れるということが分かるのである。そんな状況に陥った時に、どうしてそうなったのかを考えたのである。みんなが順調に行くと思ったのに、なぜプロジェクトが火を噴いたのかを考えたのである。

最初の結論は、みんながうそをついているということであった。本当の進捗について、うそをついているのである。でも、すぐにその結論は却下した。というのは、それは正しくないからである。みんなは、順調に開発が進むように努力していたからであった。だから、正直さが問題だったのではない。

システムが早い段階に部分に分割され、すべてのグループが自分達の担当部分で作業を行い、すべてのグループが自分達の担当部分について進捗を報告できるだろうし、その後ビッグバンのような統合作業が行われる。本当の問題は、この統合の段階に至って初めてすべての問題が表面化するということである。悪い知らせが非常に遅い時期にもたらされたのは、統合作業が遅れたからである。私が、ラショナル社に入社した際に既にこのような考えに至っていたのだ。しかし、ラショナル社のやり方は異なっていた。ラショナル社では、方向づけや推敲という早い段階からシステム全体を作っていた。その段階では、すべての機能は作れないが。早い段階で統合が行われていたのである。そのような早期の統合により、アーキテクチャの妥当性が検証できるのである。典型的なウォーターフォール開発のプロジェクトにおいて、ビッグバンの統合が失敗する時に露見するのはアーキテクチャの問題である。でも、その問題は統合段階に至るまで見つからなかったのである。統合が遅い段階まで先延ばしされることで、問題が生じるのである。私は、ラショナル社の人たちに問題をよく理解していると述べた。というのは、ラショナル社のプロセスでは早い段階で統合を行い、アーキテクチャの妥当性を検証しなければならなかったからである。ラショナル社に入社する時点で、私自身もプロジェクトの失敗の原因に気づいていたのだが、ラショナル社でそれがはっきりしたのだ。

2006年夏Ravenflow社にて
2006 年夏 Ravenflow 社にて

興味深いことに、その結論へと至る道は実際には 3 つあったのだ。ラショナル社の道と私の道があり、それら 2 つの道は合流した。さらに Ravenflow社 の Tom King 氏は、それら 2 本の道とはまったく別にほとんど同じ結論に至っていたのである。私がラショナル社を辞めて Tom King 氏に出会ったのだが、King 氏は私の本を読んでおり、2人で反復的な開発とリスクの軽減についての考えを比べてみた。その結果、結論がまったく同じだと分かったのである。まったく別々にその結論に至ったのである。Tom King 氏は、最優秀なプロジェクトマネージャーの 1 人であり、これまで働いてきた会社で成功を収めてきた。これが反復的な開発の妥当性を示す、もう1つの証拠だと思う。だから、これら 3 つの道の中心部分にはなんらかの真実があり、それが別々に発見されたのだ。

藤井注:Ravenflow 社は、英語の文章からアクティビティ図やユースケース図を自動生成し、同時に矛盾や間違いを検出するツールのベンダー。マラスコ氏は、Ravenflow社の出資者の 1 人であり、2008 年まで CEO も勤めていた。Tom King 氏は、製品開発担当の副社長。



よいドキュメントとは

--これまでの質問から離れて、数学的なモデルについて質問したいと思います。著書の中で示唆に富んでいるポイントの1つは、様々なパラメータの生産性への影響を示している部分だと思います。特に、よいドキュメントを作成することで、Dというパラメータによる生産性の低下を防げるというところです。

藤井注:D は、プロジェクトや開発組織に新たに加わった人が立ち上がるために、既存のメンバーが失う時間の割合。詳しくは、講演概要編や書籍[1]を参照してください。

よいドキュメントには、D を小さく抑えるという効果がある。

--難しいのは、ドキュメントの適度な量やレベルというのをどう判断すればよいかという点だと思います。

まったくそのとおりである。まず、理解しなければならないのはドキュメントの価値は、ドキュメントの厚みや重さで測ってはいけないということである。ドキュメントの価値は、その質で測るべきだろう。少量のドキュメントで全然構わないことも多い。そのよい例としては、UNIX 環境でのマニュアル( man )である。UNIX のマニュアルはとても簡潔である。それほど多くの量の説明があるわけではないが、情報はとても密度が高い。これが、よいドキュメントの例である。ドキュメントを書く上で、大切な点に絞る必要がある。そのようにすることで、大切な点が読者に伝わる。コードを読んで分かる内容を繰り返しただけのドキュメントはダメである。そんなドキュメントを目にすることもあるだろう。さらに大事なのは、コードにないものを説明するということである。なぜ、ある決断が下されたのか、他のやり方ではなく、なぜこのやり方に落ち着いたのかという点である。例えば、性能を非常に重視したので、このやり方を選んだのだというようなことである。それが設計目標の 1 つだったのである。そのために、このデータベースやアルゴリズムを選択したのだということを書くのである。

--それは、アーキテクチャ説明書のように聞こえますね。

そうだ。アーキテクチャスタイルに関するドキュメントがもっとも大事である。というのは、それが後に続くすべての設計上の判断に対する枠組みと文脈を提供するからである。なんらかの変更を行おうとする際に、その変更が前の設計判断と整合するか、しないかが分かるのである。

--そのような簡潔なドキュメントを書くためには、ある程度の訓練が必要ですよね。学術論文を書くのと似ているかもしれませんが、どのように訓練すればよいのでしょうか。

学術論文を書くのと似たところもある。最高のドキュメントを書くのは、もっとも熟練した技術者である。多くのプロジェクトでは、ドキュメントを書くことがもっとも若い技術者に委ねられる。

でも、それが大きな間違いなのだ。もっとも若い技術者は、高いレベルの視点を持たず、詳細に目がいってしまうのである。詳細は、それほど大事ではない。大事なのは、全体像(big picture)である。全体像をもっともよく理解しているのは、もっとも熟練した技術者である。例えば、高いレベルのドキュメントはアーキテクト自身が書くべきだと私は思う。このことを開発メンバーの人たちと議論したこともあるが、それはドキュメントが作り過ぎないようにとか、ドキュメントがコテコテしすぎないようにするためである。ある最低限のドキュメントがないと、もっと大変なことになるだろう。例えば、推敲の最後にアーキテクチャ説明書があることを私は常に求める。もしアーキテクトが書いたアーキテクチャ説明書がなければ、プロジェクトが作成に進むことを私は許さない。必須なのだ。

実際には、プロジェクトにおいて重要なドキュメントは 2 つある。方向づけの最後には、ユーザの協力の下で開発対象のソフトウェアの構想をまとめた開発構想書ができていなければならない。推敲の最後には、アーキテクトによって書かれたアーキテクチャ説明書がなければならない。


補足インタビュー前編のおわりに

次回の記事では、講演内容から離れて筆者の興味の赴くままマラスコさんにインタビューした内容を紹介する予定です。


参考文献



© 2009 OGIS-RI Co., Ltd.
Next Index Next
Prev. Index Next