要求仕様書をまとめるアナリストの役割

アナリスト(Analyst)と言うキャリアパスがあります。

しかし、現実にはあまりこのキャリアを導入しているＩＴ企業というのはありません。なんでもかんでもエンジニアに任せておけば成立する…と考えているのかもしれませんが、そもそも専門領域が異なるのできちんとこうした人たちが用意できていなければいずれ大きなトラブルとなりやすかったりすることをもう少し理解しておいたほうがいいかも知れません。

アナリストとは「分析する人(analysis + st)」という意味です。

「分析者」という和訳もありますが、システム開発の現場では一般的に英語の「アナリスト」をそのまま使います。これまでは「システムアナリスト」を指していましたが、最近では「要求アナリスト」も意味するようになっています。

なぜならフロントに立ってお客さまの要求を聞き出してシステム化領域を決めて要求を要件化し、

　・要求そのものが何を言っているのか
　・実現可能なのか
　・どのように実現することがお客さまのニーズに最も適っているのか

といったことが把握できなければ、正しくシステム開発できるわけがないからです。これをおろそかにして「モノづくり」にしか興味がないようなエンジニアに任せていると「何を作るか」「どう作るか」ばかりに注力して、お客さまの抱えている課題や望むニーズを理解することなく進め、結局後で揉めることになりかねなかったりします。

事実、私が知るだけでも５～６件ほどのプロジェクトで億単位の赤字を生み出すトラブルが発生しているのを目の当たりにしています。それだけでも、モノづくりにしか興味がないようなエンジニアだけに変な権限を与え、要求分析や要件定義を任せるべきではないと断言できます。

システムアナリスト（System Analyst）

大規模システムを開発する場合、お客さまの要求を満たしたシステムを開発するために必要となる情報を入手する役割を担っていたのが「システムアナリスト」です。

システムアナリストの仕事は、お客さまから提出された要求仕様書をベースにシステムの実現性を調査したり、現行システムに関する情報収集や問題点を収集することです。

また、お客さまから提出された要求仕様書の信頼性を確かめるために詳細な調査をしたり、完成したシステムを使うであろう利用者のスキルや希望などの情報を聞き出したりします。

昨今は、「仕様書」がどういうものかを理解していない人も増えました。

そのため、設計書の延長線上のようなシンプルな情報整理だけすればよいと思っているエンジニアやプロジェクトマネージャーも少なくありません。

実際には、

　「現状と理想とのギャップを整理し」
　「要求仕様を満たせるのか／満たせないのか」
　「満たすための手段としてはどんな選択肢があるのか」
　「それぞれの選択肢のメリット／デメリットはどうなっているのか」

などを分析し、それぞれの特徴とお客さまの目的を突き合わせて最適解を選択し、お客さまに合意をいただくところまでが仕様書作成の定義なのですが…。

要求アナリスト（Requirements Analyst）

お客さまが要求仕様書を作成できなくなって以降、「要求アナリスト」と呼ばれる職種が生まれて来ています。

システムアナリストと要求アナリストとの本来的な違いは、解析のスタート地点です。

システムアナリストは要求仕様書が存在するところから解析を始め、情報をまとめるところまでが仕事ですが、要求アナリストは、

　業務要求が明確になった時点から始め、
　システムに関するお客さまの全ての要求を発掘して、
　要求仕株書を完成するまで

が仕事です。

小規模システムの開発では、以前からエンジニアにはシステムアナリストの役割が期待されてきました。

近年、お客さまから口頭で要望項目が指示されるだけでシステム開発をしなければならなくなってから、システム完成時のお客さまの「これは違う」発言が多くなってしまっています。

これにはお任せ状態でシステムを依頼したお客さま側の問題以外に、開発側のコミュニケーション上の対応不備にも原因があります。口頭で大まかな要求しか指示されていないエンジニアから見れば、システム開発を「おまかせ」状態で受注したと考えてしまう傾向にあるからです。

しかし、実は口頭で要求を指示したお客さまの意識は違っています。

　「エンジニアたちはシステム開発のプロだから何でもできる」

と考え、エンジニアがお客さまの要求を「以心伝心」で正確に把握し、お客さま側で何もしなくてもお客さまの思っているシステムを完成させることを要求しているのです。

これはエンジニアからすれば想定外の要望かもしれませんが、多くのお客さまの要望なのです。特に、請負や準委任契約で着手するソフトウェア開発においては、主管は開発側にあってお客さまが主体的に開発チームを誘導することはありません（それをやってしまったら偽装請負となりかねません）。

お客さまが口頭で要望項目を指示した時に開発チームに対して期待していたことは、口頭での要望を中核的な要望として

　お客さまのシステムに対する全ての要望を
　洗い出してまとめること

だったのです。

つまり、暗黙的に要求アナリストとしての役割が期待されていたのです。

このことを感覚的にでも理解し、お客さまの要求を汲み取り、提案し、納めてきた人もいるかと思います。しかし、それが理解できていない人を「エンジニアリング能力が高い」と言うだけでリーダーやマネージャーに抜擢し、フロントに立たせると、自ずとトラブルが発生します。

口頭で要望項目を指示されたエンジニアやプロジェクトマネージャーが要求アナリストとしてしなければならなかったこと、それは

　「現状の把握」
　「要求の収集」
　「現状と要求のギャップ分析」
　「要求仕様書の完成」

そして

　「顧客への確認と承認」

です。

お客さまが面倒がっても要求を収集分析する

お客さまがインタビューや要求項目の提出を面倒がったり、顧客質問への回答が遅くなることも多々あります。そのような場合にも我慢強くお客さまの要求を全て洗い出す努力が必要です。

お客様の言いなりになっていては解決はできない

要求仕様書として必ず完成する

開発チームにとって要求仕様書をまとめることは顧客の作業の代行であり、「余分な仕事」と感じられるかもしれません。そのため十分に要求をまとめず、自らの経験だけで要望リストだけを「作文」し、要求仕様書を完成させず、すぐに基本仕様書にあるいはプログラミングに取り掛かりたい衝動にかられます。

しかし、これは危険なことです。
必ず要求仕様書を完成させなければなりません。

　「お客さまが何を望んでいるのか？」
　「どう解決することが望まれているのか？」

そこがブレてしまうと、どんなに優れたソフトウェアを作ったとしてもお客さまにとっては無価値にしかならないためです。お客さまにとって無価値であるにもかかわらず、

　「言われたとおりにしてやったんだから、金くれよ」

と請求するのではヤ〇ザ（反社組織）と変わりません。

要求仕様書に対する承認をお客さまからもらう

要求仕様書は、開発チームが代筆したとしても顧客の要求をまとめたものでなければなりません。

顧客には、要求仕様書に書かれた内容を理解してもらい、確認してもらう必要があります。そして、最後に「これで間違いない」という証明のために承認をもらう必要があります。

過去に大きなトラブル等が発生した方は当時を思い起こしてみてください。

こうしたことが欠落していたと思い当たる節がありませんか？

これらのことをすべて完璧にこなしていれば、まったく同じ結果にはならなかったのではないでしょうか。