|
[2009 年 1 月号] |
［技術講座］
前編では、10 月初旬に大阪、名古屋（豊田）、東京で開催したジョー・マラスコさんの「21 世紀のソフトウェア開発管理」セミナーの講演の概要を紹介しました。講演質疑編では、そのセミナーで行われた質疑で講演内容の理解するために大事だと思われるものをいくつかピックアップして紹介します。なお、マラスコさんの回答の中で思い出せないものについてはマラスコさんに後日問い合わせた回答を記しています。そのため、本記事の回答はセミナー当日のものとは異なるかもしれませんが、その点はご容赦頂きたいと思います。
--リーダーとマネージャーとはどう違うのでしょうか？
リーダーとは、構想を作り、人々に進むべき方向を示し、励ます人である。それに対して、マネージャーは期間と予算の管理を行い、プロジェクトの細かい運営に責任を持つ人である。理想的にはこれら2つの能力を兼ね備えた人がいればよいのだが、現実にはあまりいない。そのため、これらのどちらか片方が得意な人は、他方が得意な人と組むというのが現実的である。
 |
--ソフトウェア開発では、「人が大事である」とおっしゃっていましたが、プロジェクトマネージャーとしてプロジェクトメンバーのメンタルヘルスを損なうのをどのように防いだらよいでしょうか。
まず、プロジェクトマネージャーとしてプロジェクトが追い詰められた状態に陥らないようにすることが大事である。開発の早い段階で深刻なリスクを軽減することにより、開発の終盤で追い詰められた状態になることを防ぐことができる。
さらに、以下の2点でプロジェクトメンバーの状態を把握した方がよい。
一般的には、米国の企業では転職することでそこまで追い詰められた状況にならないように思われているかもしれない。しかし、私が勤務していたラショナル社は従業員があまり転職しなかったので、質問されたようなプロジェクトメンバーのメンタルヘルスの問題は私も経験している。私自身としても、戦場にいった兵士があとで後遺症で悩むような状況は防ごうと努力してきたので、質問されたお気持ちは良く分かる。
--反復的な開発の計画をどのように教えたらよいでしょうか？
反復的な開発では、開発に関する潜在的なリスクを反復ごとに特定し、もっとも深刻なリスクから順に対応するように目標設定することが基本になる。すなわち、「リスクを搾り出す(risk squeezing)」のである。また、リスクが実際にどの程度深刻なものであるかをできるだけ早く突き止めることが重要である。
--開発内容をあまり理解していない初期の反復の計画はどのように立案すればよいでしょうか？
例えば、開発対象のソフトウェアのアーキテクチャを構成する要素として、特性が良く分かっているリレーショナルデータベースと、新たに採用しようと考えている、特性がよく分かっていないデータベースアクセス機能や通信ミドルウェアがあるとする。このように、アーキテクチャに今まで適用したことがなく、特性が分かっていない部分がある場合、この部分の特性や適合性に高いリスクがあると考えた方がよい。また、このようなアーキテクチャに関するリスクには開発の早い段階に高い優先度で対応した方がよい。そのため、動作するプログラムで一番深刻な通信ミドルウェアの特性を確かめることを最初の反復の目標と設定した方がよいということになる。肝心なのは、難しいことから順番に取り組んでいくということである。
開発の初期段階で問題をどの程度の期間で対処できるか見当がつかない場合は、まず問題の大きさを理解するということをまず目指してもよい。その場合、反復の目標は、問題を理解し、問題への対処に必要な期間を見積もれるようになることに設定する。また、開発の途上で立ち止まってプロジェクト全体のリスクを評価してみるようなチェックポイントを設けた方がよい。
藤井注：ここで言う「チェックポイント」とは、反復よりも大きな単位でのプロジェクトのマイルストーンを意味する。チェックポイントについてマラスコさんに質問した内容を、本記事の後編で紹介する予定である。
--XP (eXtreme Programming) のようなアジャイル開発を実践したことがあるのですが、要望に対応し続けてもお客様が満足しないために開発が収束しませんでした。結局、反復的な開発はうまく行かないのではないでしょうか。
ウォーターフォールであろうと反復的な開発であろうと、終点を設定することが大事である。つまり、どこまで開発したら完了という基準を設けるということである。結局、予算は際限なくある訳ではないからである。また、要望には現在のアーキテクチャで対応できるものとできないものがある。
藤井注：皮肉なことに、「納期」などの開発上の制約を単純になくしてもソフトウェア開発が成功する可能性は高まらず、むしろ悲惨な失敗をする可能性が高まるのではないかと思う。限られた期間と予算という制約があって、「現実的に何ができ、それがどんな価値を持つか」を開発者と開発依頼者が真剣に議論し、合意できることが多いのではないだろうか。ただ、そのような議論を行う際に紙のドキュメントや理論だけでは現実的な判断を行うことが難しい。反復的な開発の大きな利点の 1 つは、動くソフトウェアを早い段階で作ることにより、作ったものとそれに要した労力に基づいて現実的な終点の議論及び合意ができる点ではないかと思う。むろん、アジャイル開発でもやろうとすれば同じ事はできるはずである。
例えば、バーサ号の場合では、「現在のアーキテクチャで満足するか」、「要望に対応するために新たな船を作るか」という選択肢を示して国王とリリースポイントを交渉すべきだった。それら2つの選択肢を別々のリリースで対応するということも可能だろう。
開発の途上では、基本的には「現在のアーキテクチャで対応できる」範囲で要望に対応すべきだし、特に終盤では新たな要望が限られた期間と予算で対応かどうかを考えることが大事である。
--Ivar Jacobson が RUP (Rational Unified Process：ラショナル統一プロセス)は重すぎるので、もっと軽量なプロセスが望ましいと最近述べていますが、どう思いますか？
方法論者は、常に自分自身の考えをプロモートするということでそのような発言をするのだと思う。RUP は、プロセスの実装の方法によって重くも軽くもなる。Jacobson は、自分自身も統一プロセスの提案者であるということを思い出した方がよいと思う。
--日本では反復的な開発を実践する人たちは依然として少数派ではないかと思います。米国では反復的な開発を行う場合、RUP を実践することが多いのでしょうか？
実際のところは、米国では現在アジャイル開発を推進している人たちの声が大きい。でもそれらの人たちが大勢ではなく、少数だが声が大きく、カンファレンスで目立つ人たちなのだと思う。
|
|
|
|
|
開発プロセスは、技術とビジネスの両方の因子で決まる。米国での開発プロセスの主流の移り変わりは、振り子にたとえることができると思う。25年前には米国で開発プロセスの主流は、図 1 に示すようにウォーターフォール開発だった。そこから、20-25年かかってウォーターフォール開発の位置から振り子は離れたが、(RUP のような) 反復開発の位置を通り過ぎ、アジャイル開発の位置に振り子は現在きている（図 2 ）。しかし、この振り子は再び向きを変えて、最終的には反復的な開発の位置に戻って落ち着くだろうと私は考えている (図 3 )。
日本では、ウォーターフォール型開発がいまだに大勢で、反復的な開発に少しずつ移動し始めているところならば、悲観することはない。そのまま進めば、アジャイル開発の側に振れなくても、反復的な開発という最終状態に落ち着くのだから。
アジャイル開発は、ユーザの開発への関与という点ではよい。でも、ドキュメントを軽視しすぎている。私は、開発では創造性と規律のバランスを取ることが大事だと考えている。例えば、反復ごとの計画のようなドキュメントを作らないで、ひたすら動くソフトウェアだけを作ってユーザにそれを示す形で開発を行った場合、下手をすれば最悪同じようなことを繰り返してしまい、スラッシングのような状態に陥りかねない。気がつくと、今行っていることは3週間前に検討したことではないかという事態に陥ったりするということである。
ウォーターフォール開発は、硬直的であり、開発途上で学んだことを取り入れる余地がないのが欠点であるが、アジャイル開発は反対に自由度が大きすぎる。たぶん、それら両者の中間に望ましいところがある。
--「ヨット」の方が「家の建築」よりも良いアナロジーであると話されていましたが、私自身はお客様に説明する際に「家の建築」のアナロジーを良く使っています。「家の建築」のアナロジーはよくないのでしょうか。
「家の建築」をアナロジーとして使った場合に、ソフトウェアに未知の事柄があり、それに対処しなくてはならないや、イノベーションが求められるということがうまく伝えられない。そのようなアナロジーを使うと、「ソフトウェア開発に不確定要素がない」し、「イノベーションは必要ない」し、「リスクはない」というようにお客様が誤解をするリスクがある。
--ハードウェアの製造を経験した人が上に多いのですが、そのような人たちにソフトウェア開発の違いをどのように説明すればよいでしょうか？
ソフトウェアは、ハードウェアの製造そのものではなく、新たなチップの開発という作業の方に似ている。新たなチップを開発する場合、論理的なアーキテクチャやレイアウトを考え、さらに物理設計を行い、さらにそれを評価して設計を改良していくというサイクルを繰り返すと思う。そのような作業をアナロジーとして用いた方がよいと思う。
--バーサ号の悲劇の原因として、国王の要求に拒むことができなかったというリーダーシップの弱さを挙げておられましたが、実際に顧客の要求を拒むというのは難しいのではないでしょうか。
まず、追加/変更の依頼には現在のアーキテクチャで対応可能なものとそうではないものがある。前者であれば、現在の開発期間で対応できるかを考え、必要に応じて開発の範囲（スコープ）を調整して対応することは可能である。それに対して、後者のようにアーキテクチャの根本的な変更が必要になるものには対応できないと考えた方がよいだろう。私がバーサ号の建造リーダーであったならば、国王に以下の 2 つの選択肢を示しただろう。
--バーサ号のようにプロジェクトの途上でアーキテクチャを変える場合、要員を増員するとともに納期を遅らせたり、スコープを削ったりすることでは対処できないのか？
アーキテクチャの変更をプロジェクトの途中で実行するのには、常に大きな危険とリスクを伴う。基本的には、現在のアーキテクチャで許容できる範囲での変更や追加を行うように努力した方がよい。というのは、土台となるアーキテクチャを変えることにより、底なしのリスクに陥りかねないからである。そのため、アーキテクチャの変更は常に次の開発サイクルまで保留した方がよい。
また、アーキテクチャの変更が必要なフィーチャーを追加するならば、それは1、2回の反復では対応できず、開発計画全体を根本的に見直す必要があることをプロジェクトマネージャーは依頼者に必ず忠告すべきである。
なんらかの理由で、どうしてもアーキテクチャを変更しなければならない場合には、それを開発のやり直しサイクルと考えた方がよい。
藤井注：「開発のやり直しサイクル」とは、いわゆる「仕切りなおし」（今までの開発計画は捨て、開発を最初からやり直す気持ちで新たな開発計画を作ること）を意味すると思う。思い切って現実的に開発計画を再立案すれば、やり直しに至るまでの開発の経験を活用し、やり直す前の開発よりも効率的に開発が行える可能性がある。もっともまずいのは、新たな計画でも無理な計画を立案し、その計画も守れず、泥沼にはまっていくパターンである。
--日本では、プロジェクトメンバーのモチベーションを高めるために宴会を行うという手段を用います。プロジェクトメンバーのモチベーションを高める方法としてどんな方法がよいでしょうか。
米国でもプロジェクトの開始時に宴会を行ったり、お揃いのTシャツを作ったりする。しかし、私はそんな方法ではなく、プロジェクトメンバーにプロジェクトの計画を説明し、議論するための短い打ち合わせを持つようにしている。
そのような短い打ち合わせでプロジェクトの計画の説明と議論を行った際に、ベテランの開発者から「似たような計画の話はこれまで散々聞いてきた。一生懸命頑張ったがどれも計画どおりにいかなかった。今回の計画はそれらとどこが違うのか？」との質問を受けた。私は、即答できなかったが、非常に大事な質問だと思い「明日の打ち合わせで回答する」と約束した。私は、１日考えて翌日「今回はこれまでとどこが違うのか」を説明した。
ソフトウェア開発者はプロなのである。プロは、宴会や T シャツのような子供だましでモチベーションが高まらない。本物や本当のことを示すことでモチベーションが高まるのである。
--みんなが真剣にコミットする文化を育むには、どうしたらよいでしょうか？
もっとも大事な側面は、メンバーを信頼するという「高い信頼に基づく組織を作る」ことである。さらに、組織の隅々まで高い信頼に基づくようにするということも大事である。つまり、各メンバーが互いを信頼し、従業員が上の人を信頼し、上の人が従業員を信頼するということである。
「信頼の基本単位」は、組織のすべての階層に属す、個々の人のコミットメントである。従業員に、仕事を果たすための期間の見積もりを行うように依頼する際には、「軽々しく考えるべきではないコミットメントを行っている」ということを意識してもらった方がよいだろう。より良く見積もりをするために時間がもっと必要であれば、現実的ではないと後でわかるような完了予定日を述べるのではなく、考えるための時間を求めるべきだろう。
藤井注：要は、「誰もが信頼を置ける仲間である」ということを会社の基本原則とし、それを経営陣を含めて社員全員が対等な立場で実践していくということである。そのような原則のもとでは、「コミットメントを守らない」ことは「信頼を損なう」ことであり、基本原則を破る行為なのである。実際には、社内の人間だけでもなく、顧客に対しても「信頼を置ける相手である」ようになることも目指すべきである。
結果としてコミットメントが果たされない場合には、言い訳を許すべきではない。
次回の記事では、講演内容や質疑をさらに補足するために筆者がマラスコさんにインタビューした内容を紹介する予定です。
| © 2009 OGIS-RI Co., Ltd. |
|
