要件定義・仕様設計のレッスン

0
634
views

n番煎じですが。

ソフトウェア・システム開発でよく起きるボタンの掛け違いがあります。顧客の要求をまじめに実現しようとた結果、結局顧客にとっては複雑で使いにくい製品が出来上がってしまう。

失敗の原因は開発メンバの怠慢や勝手な思い込みと思いきや、実は最初に顧客が説明した要件からして間違っていた。そんな「他山の石」とすべき、要件定義・設計の教訓。それが有名な「顧客が本当に必要だったもの」という風刺画です。

顧客が本当に必要だったもの

  

①顧客 ②PM ③設計 ④PG ⑤営業
顧客が説明した要件 プロジェクトリーダの理解 アナリストの設計 プログラマの実装 営業の表現・約束
顧客が説明した要件 プロジェクトリーダーの理解 アナリストの設計 プログラマの実装 営業の表現・約束
⑥書類 ⑦運用 ⑧費用 ⑨サポート ⑩真の要件
プロジェクトの書類 実際の運用 顧客への請求金額 得られたサポート 顧客が本当に必要だったもの
プロジェクトの書類 実際の運用 顧客への請求金額 得られたサポート 顧客が本当に必要だったもの

①顧客が説明した要件

顧客が説明した要件

ちょっと機能過剰なブランコの製造依頼。一度に3人乗るつもりだろうか。明らかにピントのズレたシステムを提案する顧客。

もちろん金を払う立場でもあるのでシステム開発を請け負う側もあまり批判的なことは言えない状況が多いかもしれない。それでも顧客自身に最終的な問題解決策を提案させてはいけない。それは開発者側が行うべき仕事である。

重要なのは、プロジェクトを開始するにあたって、本当に解決すべき問題の本質とその理由が正しく見極められているのか何度も問い直すことである。だれかがいつの間にか提案した「解決策」らしきものに考えなしにいきなり飛びついてはいけない。

②プロジェクトリーダの理解

プロジェクトリーダの理解

木にぶら下がったブランコが欲しいという顧客の要求はなんとか理解できた。そして顧客の提案にある非現実的な部分は専門家として排除したつもりだが、それでもまだ動くかどうか疑わしいブランコの構想。ちょっと技術を知る人が側にいればその妥当性を検証できるのだがそういう体制はないようである。

顧客にいちばん近い位置で開発に必要な情報を取り入れ、顧客のためのシステムを提案し、開発チームに完成品のビジョンを共有させる立場(のはず)。ここで既に顧客との意思の疎通に齟齬が発生している。また実際に動くかどうか分からないシステムが構想されているが妥当性を検証する手段を持っていないということなのか、検証している時間がないのか、それでなければ自信過剰というところか。

③アナリストの設計

アナリストの設計

プロジェクトリーダーの構想のままではブランコが動かないことに気づいたのでブランコがなんとか揺れることができるように設計されている。

プロジェクトリーダーの意図はとりあえず反映するが、そもそも当初の見通しが間違っているため顧客の要求と両立させるために不自然な歪んだシステムが設計される。妥当性を検証し上流工程に差し戻してやり直しを要求することは立場として難しいのか、あるいは腕の見せ所と張り切った結果か。また、無意味に新技術を導入したがる設計者が多いのも問題かもしれない。

④プログラマの実装

プログラマの実装

木の幹にブランコが繋がれている状態。第三者の目にはかなり異様な光景に映るがさっさと仕事を終えたいプログラマは気にしない。一昔前なら「ステップ数でこれだけの進捗がありました」と報告するような職場での仕事ぶりだろうか。

これがブランコの設置だからまだ見た目分かりやすいが、プログラマの労働の成果であるプログラムの構造や動作を第三者が手早く評価したり欠陥を見抜くのは容易ではない。 設計者の意図は正しくプログラマに伝わっておらず、まともに動かないシステムが生まれゆく状況である。木とブランコが「とりあえず繋がっている」ので、「間違ってはいない」レベルで設計が実現された状態。プログラマが顧客の要求を知る術もない。

ここでも成果物の妥当性を検証する機会はないようだ。成果は見かけ上増えていくが後々捨てられる部分が大半を占める。

⑤営業の表現・約束

営業の表現・約束

ソファを搭載した無駄に豪華な光り輝くブランコ。第三者の目にはかなり異様な光景に映るが売り込みに熱心な営業担当者は気にしない。

本質的でない上に過剰な機能の搭載を売り込む営業。製品はまだできていないんだから何とでも言える。また、顧客の要望が廉価なタイヤなど、枯れた技術の水平思考で代用実現できる可能性に仮に気づいていても、絶対に営業側から顧客に言い出すことは無い。顧客側から「もっと安く代替できるのでは?」と指摘されても「でもこちらのソファの方がお尻が痛くないですよね。」と誘導していく。なるべく高価で大量に機能を盛り込んだプランで契約を取るのが彼らの仕事だからである。顧客が技術的なことを理解できない場合はなおさら有効なのだろうか。

ところで営業担当者たちは実際の開発現場とどんな交流があるのだろうか? たぶんほとんどない。

⑥プロジェクトの書類

プロジェクトの書類

ブランコの開発に関する記録が何もない。なにかしらそこに存在した痕跡はあるようだが……という状態。振り向けば開発に関するドキュメントの類が一切残っていない。仕様がコロコロと変わるため記録しても意味がないのかもしれない。

しかも顧客から次々とやってくる追加要求を安請け合いして情報量的には膨らんでいるかもしれない。また開発スタッフも、仕様書を丁寧に書いたところで開発成果に直接繋がらない上に上司からもそんな仕事は評価されないため誰も書きたがらないのかもしれない。

後々開発メンバーが交代したりするとシステム保守・改良がやり難くなる一因にもなるはずだが。

⑦実際の運用

実際の運用

ロープ一本だけが枝からぶら下がっている。とりあえず、枝からぶら下がって揺られて遊べる。辛うじて遊具の体をなしている状態。腕の力が弱い人・体重の重い人には厳しい遊具である。

当初の設計案をすべて盛り込むには納期に間に合わないと判断され、予定よりも大幅に縮小された機能だけを載せて納期に間に合わせて顧客へ渡った状態。約束されたシステムとは程遠い不完全で使い勝手の悪い状態で顧客は運用を強いられることとなる。顧客の日常業務がこのシステムに依存・維持させるために、システム導入前とは別の手間とコストかかるものにならないか心配である。

この時点で、一体何のためにシステム導入を検討していたのかを覚えている人も少なくなっているのではなかろうか。

⑧顧客への請求金額

顧客への請求金額

ジェットコースターらしき遊具。ブランコの設置なのに遊園地のアトラクションの建造費用レベルの法外な請求額ということか。初期の設計にあった仕様すら満たしていないというのに。

もしくは、『高速で乱高下する』ジェットコースターの様を請求金額に例えて、「別途料金追加の連続で、当初の見積額からうなぎ登りに上昇」→「運用開始した顧客や世間に実態がバレて叩かれだした途端、運用自体は何も変えてないのに急激に安くなる」という手の平返しを皮肉っているのかもしれない。

⑨得られたサポート

得られたサポート

切り株だけが存在する。あるいは、ブランコが設置された木が根本から切り倒されてしまった状態。「実際の運用」にあたって顧客からの「ロープに腕だけでぶら下がるのは余りにも辛いので、とりあえずは『腰掛けて』楽に使えるようにしてほしい」という要望に、サポート担当者が場当たり的に対処した結果にも見える。

このように、システムの存在を根幹から台なしにするような不適切なサポートが行われた結果か。あるいは、顧客が実際に受けることのできたサポートの質や量・期間がこの程度のショボいものだったということか。もっと最悪の場合、「企画倒れ」「サポートの打ち切り・フェードアウト」「システム運用自体の打ち切り・凍結・放置」という事態とも受け取ることができる。

⑩顧客が本当に必要だったもの

顧客が本当に必要だったもの

タイヤをぶら下げたブランコ。本物のブランコほどではないが、木にぶら下がって(腕に負担をかけず体重を預けた状態で)揺れて遊ぶという本来の要求を十分に満たす機能を持った遊具。おまけに本物のブランコよりも安上がりな実現方法である。もちろん材料のタイヤも新品である必要はない。顧客がパンダであろうと申し分ないはず。

顧客には見えていなかった理想的製品像。ひょっとしたら開発者側も見えていなかった可能性も大きいが、開発者側が探り当てて提示すべき到達点。

それでも現実問題として、タイヤを使ったブランコ型遊具(顧客に必要な機能は十分に盛り込んでいるシステム・最新技術とは言い難いがお値段お手頃)を顧客が、「これで十分、わが社に導入するには最適」ときちんと理解・納得して受け入れるのか?という疑問は残るのであるが。

どこで、どうして、こうなったのでしょうか。