コンサルタントの眼

第５回「早く走り過ぎて、見逃しのないように？」by 山田 晴美

衝撃的な出来事は、2000年代の前半に起きた。
半導体の微細化向け検査装置開発の現場、システム検証の最後の１シーン、メーカ担当M氏が深いため息をついた。
　　M氏　　　　「僕が欲しいのは、これじゃない…」
　　AI側　　　「？！」
　　M氏　　　　「わかるでしょ？僕が欲しいもの…」
　　AI側　　　「・・・・・」（絶句…）
　　M氏　　　　「操作画面は、結構いいんだけどね。」

一枚の要求仕様書も提示されなかったが、M氏は決して、無責任な担当ではなかった。
世界最大のMPUメーカから世界最大の装置メーカ、そして日本の装置メーカに引き抜かれ、半導体製造装置の有るべく姿をアトリエ　イシカワと共有することができる数少ない技術者だった。
彼の言葉の発し方は、いつもつぶやきのようだが、非常に重大なことが含まれていることが多かった。アトリエ　イシカワは、読唇術を駆使して、その行間を常に読み続けていたつもりだった。

我々は徹底的にシステム製造工程を見直した。原因は、いくつか見つかった。

・要求分析工程での詰めの甘さ
開発会議で話していた内容は、ほとんどがホスト通信仕様であり、それ以外の議論はされていなかったが、要求仕様は、議事録記載はなかったが、言うまでもなく「ウェハ全自動検査として当たり前に動作することを前提として」だった。議論に上がる内容だけでユーザが満足する訳ではないのだ。

・社内開発仕様書の内容
議事録より作成された社内用の仕様書は、会議の内容と同様に、ホスト通信仕様を中心にしたものだった。
プログラマーが必要とする全体の要求仕様が明確に記述されたものではなかった。ソフトウェア仕様書が不備では、プログラマーは何をどう作ればよいか、分からない。開発期間のほとんどが、迷子の状態であったのだ。

・テスト内容
エミュレータを使用して行うオフラインテストを徹底的に行ってから、装置実機を使用するデバッグを行うのがアトリエ　イシカワのスタイルだった。
しかし、このテスト内容にも問題があった。オフラインテストの内容は、通信に特化したものとなり、装置機能のあるべき姿をテストする内容ではなかった。

・開発工程管理
プロジェクトのビジョンが徹底していなかった。
プログラマーが実際にコーディングする時点で、あちこちの仕様に疑問があるようでは、品質の高いものは制作できない。制作に入る前に、プロジェクトは何を作るのか？そのビジョンが共有されていなかった。

ユーザ要求を確実に把握し、行き違いを補正するには、プロジェクト管理方法を改革するしかなかった。

ユーザ要求内容を矛盾なく解析する為に、”100％のWBS”作成を徹底させた。
そして、アジェンダ・議事録・要求仕様(アクションアイテム)をプロジェクトの３種の神器として推進させた。
ユーザとの誤解を生じさせない為、プロジェクトにイテレーションを採用させた。
動くもので、見えるもの、細かなイテレーション＝繰り返し仕様を確認し、『システムへの見えない化』を止めた。

そして、あえてプログラマは変えずに、プロジェクトマネージャ以下、プロジェクト管理方法を徹底的に変えて、リベンジに成功した。 本装置は、現在、最先端の微細化用レチクル検査に使用されている。

マネジメントを改革することで、現場のポテンシャルを引き出せる証明となったこの経験は、その後大いに役立った。このマネジメントを体得していないマネージャは、その後も現場のポテンシャルを引き出せなかったが、マネジメントを理解したチームは複数の開発チームとの共同プロジェクトを成功させたのだ。

さらに、この経験を元にして、現在当社ではソフトの中身までを可視化した仕組みThe Daihonを独自開発し、現場で採用し続けている。
また、イテレーションという短い期間単位を採用し、その間でdaihonを構成する”パーツ”をユーザに見せ確認・承認をとり、それらを繰り返し行いパーツを追加作成し、一つの製品に仕上げる形式のプロジェクトを推奨している。

先日、ユーザから再度、衝撃的なつぶやきがあった…。
　　ユーザ　　　「あれ、なんかイメージ違うんだけど…」
　　私　　　　　「既に前回でご了解いただいた内容かと思いますが…？」（おそるおそる）
　　ユーザ　　　「え？そう？　これなんか初めて見るよ」
　　私　　　　　「・・・？・・・」
　　　　　（え!?　いいんじゃない、って言ってたじゃない！！！、なんで覚えてないんだ～）

確認・承認を重ねる事が、的確なユーザ要求を掴み重ねられるとは限らないのである。
忘れてはならないのは、人を相手にしている、という事である。
『人はあまり覚えていない』ものである。
見せられたもの５種以上あれば、最初の１種目については、忘れてしまっている可能性がある。
プロジェクトの最後の最後で、「欲しいのはこれじゃない」ということが起こらない為に、見せるものでの承認を重ねての製品完成という方法論は、ユーザ要求を満たす手法としては間違いないアプローチである。

ただ、短いイテレーションでは、“繰り返し見せる”事に気をとられると、走り過ぎてしまう。
走る事だけに気を取られ、ユーザを置いてきぼりで走って行ってしまった。
振り返ったら誰もいなかった、ユーザの状況を見逃していた、という事態が起こるのである。

イテレーションを取り入れるアジャイル開発においても、いろんな方法論、手法が存在している。が、結局のところ、どの手法を用いるかが問題なのではなく、大事なのは「ユーザと共に、適度な的確な早さで進む」ことであり、その為に「ユーザの心を読む思考力を持つ」 ことである。
この思考力を持っていなければ、どんな手法を適用したところで結果は同じであろう。ユーザ要求の変動とともに、早く機敏に対応できたとしても、振り返ったら誰もついてきていなかったでは、本末転倒である。

短いイテレーションの中、三歩進んで一歩下がるペースを一緒に作ることが大切だった。
ありがとう！明日から、早く走りすぎて、見逃しのないように！努力します！


2012/12/16
山田　晴美
    システムベンター勤務後、システム開発現場、プロジェクトマネジメント／コンサルティング分野を専門とする。 自ら立てた戦略を戦術、戦法に具体的にブレイクダウン（WBS）し、実際に現場を率いて実践する。実戦型独自のスタイルを持つ。体育会系。
    アトリエ イシカワ コンサルタント