エンジニアは日々現場で学ぶ
開発現場で学べること（1）
第1回　忙しいのはユーザーだ

クロノス 山野寛
2003/10/31

エンジニアにとって最も大切なことの1つが、開発現場での経験だ。それがエンジニアに多くの知識と勘をもたらす。そんな開発現場で若きエンジニアが失敗し、そこで何を学んでいくか。それを毎回紹介したい。

■プロジェクトスクーリング

　「あなたの開発現場は順調ですか？」という質問に「はい」と答えられる人は、案外少ないかもしれない。過去に多くの開発に携わり、経験も豊富なシニアエンジニアは、その過去の経験を生かしていまの開発を順調に進めることができているのだろうか。私の知っているエンジニアは、最近よくこんなことをいう。

　「なぜか毎回同じような失敗を繰り返してしまう。毎回反省はしているのだけど……」

　かくいう私も、毎回現場で同じような失敗を繰り返し、そのたびに反省していることは多い（もちろん、開発現場にきて数年で、経験不足という面もあるだろうが）。では、どうすればうまく開発を進めていけるのだろうか。

　私はいま、とあるシステム開発プロジェクトの要求定義に参画しており、私にとっては久しぶりにキックオフからのプロジェクト参加である。今回の連載では、私が実際に開発を進めていくうえで生じた問題や課題などを紹介していきたい。その際、開発現場の視点から報告し、プロジェクトの成功や失敗、そして今後の開発において同じような失敗を繰り返さないためのコツなど、エンジニアとして必要なスキルを読者の皆さんとともに学び取ることを目的としている。これはまさに、実際の現場から学ぶ「プロジェクトスクーリング」であり、もちろん私もその受講者の1人である。

■今回のプロジェクト内容

　まずは簡単に今回私が参加するプロジェクトの内容を説明しよう。

　今回のプロジェクトは某サービス業A社の債務管理システムの開発である。われわれ開発者側からはプロジェクト責任者1名、プロジェクトマネージャ兼プロジェクトリーダー（以下、PM）1名、それにコンサルタント1名と、私を含めたシステムエンジニア（以下、SE）3名がこのプロジェクトの要求定義に参画している。

　クライアントは、現在メインフレームで稼働しているすべてのシステムをオープンシステムに移行していくという経営方針を持っている。開発内容は、メインフレーム上で稼働している債務管理システムを、機能改善および拡張を考慮してオープンシステム化するというものである。

　今回の開発で特に大きな特徴としては、現在はまったくの別システムとして稼働しているグループ会社の債務管理システムとして統合し、グループ全体で活用可能なシステムを構築するという点が挙げられる。つまりわれわれ開発者側は、各グループ会社で扱っている、異なるフォーマットのデータを統合することを意識する必要があり、これには各グループ会社の業務自体を変更しなければならない可能性があることも考慮しておかなければならない。

■開発プロセスの決定

　プロジェクトを進めるにあたり、今回採用された開発プロセスは、いまやオブジェクト指向開発の代名詞となったRUP（ラショナル統一プロセス）を採用している。RUPの詳しい解説についてはほかの文書に任せるとして、RUPの大きな特徴の1つにカスタマイズが可能という点が挙げられる。RUPは開発プロセスとしてのフレームワークを提供しており、われわれ利用者は組織やプロジェクトにフィットした形でRUPをカスタマイズして利用できるという利点がある。われわれはその利点を生かし、今回の開発コスト、クライアントおよびわれわれ開発者側の体制、そしてプロジェクトの内容等を加味した結果、以下のようなプロセスで開発を進めていくことに決定した。

• 要求定義フェイズは反復しない（プロジェクト冒頭の1度だけ）
• 設計開発フェイズは3〜4回の反復を行う（1回の反復は1〜1.5カ月）
• ユースケース駆動は忠実に行う

　要求定義フェイズでは反復を行わない、ややウォーターフォール型開発っぽい部分や、1回の反復期間が長いといった部分に関しては、本来のRUPの特徴から外れる部分であるようにも思えるが、取り合えずは開発プロセスはこれで決定した。

■いざキックオフ！

　今回のクライアントはキツイ。私がプロジェクト開始に当たって「キックオフミーティング」の場で最も感じたことである。ここで誤解のないように補足しておくが、私のいっている「キツイ」というのは、別に「性格が悪い」だとか「毒舌」だといった意味ではなく、「個性が強烈」で「主張が激しく」て「自我が強い」、そして何より「頭の回転が物すごく速い」ということである。

　毎回要求定義のミーティングに、クライアントの担当者（システム担当者、各部担当者、各部課長など）は5人くらい参加するが、どの人もまさに「キツイ」という言葉が当てはまる面々ばかり。私がこれまで参画したプロジェクトの中で、ここまで個性的なメンバーはちょっと見たことがない。その中でも某担当者は、まともに目を見ることができないくらい威圧感のある人である（別に見た目が怖いっていうことではない）。

　しかし、私はこんな個性的なメンバーは嫌いではなく、むしろ大歓迎である。自己主張がないクライアントに限って、実装作業（製造開始）後の仕様変更などが多く、手戻りが多く発生するという過去の経験がある。このように意見をハッキリといってもらえるのは、プロジェクトを進めていくうえで非常にありがたいことなのである。

■ここでの失敗と教訓

　さて、私は今、そんな個性的なクライアントと要求定義を進めているのだが、その中で自らの失敗談から得た1つの「教訓」を紹介しよう。

　システム化における懸念事項を解決していくためのミーティングを行う場面でのことである。今回のシステムにおける懸念事項に対して、われわれ開発者側は、それらを解決するための案を「PowerPoint」のファイルにまとめ、ミーティングでプレゼンテーションを行いつつヒアリングをしながら解決しようとした。そのための準備として、具体的に次のようなことを行った。

（1）現在の懸念事項の具体的な内容を再確認する
（2）ユーザーが求める業務の方向性を確認する
（3）懸念事項を解決できそうな案をすべて洗い出す
（4）出された案のメリット、デメリット、必要事項、それに伴う懸念事項を考える
（5）提案内容をPowerPointにまとめる

　われわれは社内でのミーティングを繰り返した結果、その問題を解決できる6つの案を考え出した。その6つの中には、恐らく採用には至らないだろうという案もあったが、ほかの案との相違点や、その実現可能性を見いだすきっかけにできるという意味で、6案すべてをわれわれからの提案内容とし、PowerPointにまとめることにした。

　さて、この提案に関するミーティングの日を迎え、今回は私がプレゼンターの役目を担うこととなった。前日に作成したPowerPointの資料をプロジェクターでスクリーンに映し、指示棒を使いながらクライアントに向かって提案内容の発表を開始した。

私　「今回の懸念事項に対して、われわれから6通りの案を提案させて頂こうと思います」

　その瞬間、クライアントから「6つもあるの？」という感じの苦笑が聞こえたため、すかさず私は、

私　「これら6つの案のメリット、デメリットを把握して頂いたうえで、その中でほかの案と比較して最善と思われるものを決定して頂こうと思っています。」

と説明した。「ふ〜ん」といった表情でいるクライアントを尻目に、早速私は1つ目の案から説明を始めた。

私　「まず1つ目の案ですが……」

私　「次に2つ目の案ですが……」

　私は、これらの案を必死に説明している途中、ふとクライアント側の担当者（クライアント側の中心的人物）の顔を見てみると……。明らかに退屈そうだ。聞くのも面倒くさいといった表情である。挙句の果てには会議室に備え付けのパソコンに向かって仕事をし始めた。「失敗かなぁ……」と思いながらもすべての案を全員で確認し、最終的にその中の1つの案で進めることで合意した。ここまでの所要時間はおよそ3時間。今回の懸念事項に対する方向性が決まったことにわれわれは満足し、ミーティングを無事終了させることはできた。

　しかし、PMだけはミーティングの後にクライアント側システム担当者に呼ばれていたため、われわれは先に会社へ戻ることになった。

　数時間後、会社に戻ったPMが、「これから社内ミーティングをやろう」と声をかけた。PMは先ほどのミーティング後、システム担当者から次のような注意を受けたらしい。

　システム担当者　「今日のミーティングは正直だるかった。私にはこの懸念事項の解決策は大体最初から見えていたし、3時間もかけてやるのはハッキリいって時間の無駄だと思う。次回からは一番自信のある本命案と次にありそうな対抗案だけを提案して頂きたい」

　私はその担当者の態度を見ていたため、そういった反応があるという予想はついていた。が、もちろん私には私なりの主張はある。先ほど述べたように、考え得る案のメリット、デメリットをきちんと確認したうえで実現案を検討したいという意思と、恐らくはないだろうと思っていた案からいろいろな発見が見いだせるかもしれないといった可能性もあると考えていたからだ。

■ユーザーに無駄な時間を使わせてはならない

　以前、知り合いのコンサルタントが開催した研修で次のような話があったことを思い出した。

　ユーザーに物事を決定してもらうときに、「どうしますか？」と聞いてはならない。「○○○はどうですか？」という尋ね方をしなければならない。つまり、こちらから何かを提案をする場合は、ユーザーが「Yes／No」で答えられるように尋ねなければならない。ユーザーにその解決策を考えさせてはならないということである。

　今回、われわれは6つという多くの選択肢を持ち込んだため、「どうしますか？」という尋ね方に近くなっていたのかもしれない。逆に「この本命案はいかがですか？」という提案をすればユーザーにとって判断は楽だ。もしその案が却下されたのであれば、それに次ぐ「対抗案」を出せばいい。私は、今回のミーティングでそのコンサルタントの研修での話を実感したとともに、次のことを学んだ。

　「ユーザーは忙しいのだ。ユーザーに無駄な時間を使わせてはならない。そして、ユーザーが決断のしやすい提案をしなければならない。」

　もちろん私としては、これがすべての提案に当てはまるわけではないようにも思う。難しい課題や、理解が完全ではない場合の提案など、ユーザーと多くの時間を使ってディスカッションをする必要がある場合には、複数案を持っていくのも1つの手段であるようにも思う。

　さて、あなたはどう考えるだろう？

筆者プロフィール

山野寛（やまのひろし）●クロノスに勤務するシステム・アーキテクト。立命館大学理工学部 卒業。クライアント／サーバからWeb系システムを中心にいくつかの開発現場に参加し、ここ数年はJ2EEをメインとしたオブジェクト指向開発にアーキテクトとして設計から携わっているという。