IT側では上流といわれるシステム分析(要件定義)を担当するSEについて、要求確認レベル、要求分析レベルの2種類に分類できます。そして、この両者では、要求される業務知識・業務スキルにはかなり大きな差があります。⇒関連ブログ記事:SEから上流、そしてビジネスアナリストへと業務スキルの養成方法 

 

1.2つのレベルのシステム分析の違い

   システム分析の前半工程は要求の把握フェーズであり、後半工程のITソリューション設計フェーズだけがITソリューションに依存します。要求の把握には、次の2つのレベルがあります。

(1)「要求の確認」というレベル

  要求の把握が要求の確認」レベルだと、ユーザが言う要求は正しい、正しく言えるという前提で、要求をヒアリングします。したがって、システム分析者には高度な業務知識は要求されません。

  しかしながら、ユーザ自体がドキュメントなしの業務引き継ぎで、自分の業務を本当に分かっているとは思えない現状では、前提条件が成立していません。これはSI企業にとっては自殺行為に等しいでしょう。

(2)「要求の分析」というレベル 

  要求の把握が要求分析レベルだと、ユーザは自分の要求を正しく言えず、必ず洩れたりすることを前提とします。業務面からユーザの要求を質問によって引き出していきます。したがって、システム分析者に高度な業務知識が要求されます。

2.私がSI企業に在籍している時に、システム分析にどう取り組んだか

  20年弱の以前に、私がSI会社でSAPなど複数種類のパッケージを導入する部隊を率いていた時、システム分析(要求分析)を担当するSEは、パッケージに依存しないで共通化しました。なぜならば、要求分析を行う前半工程の方が重要であり、業務知識に富んだベテランをこれに充てました。

  後半工程のソリューション設計は私が開発したフィット・ギャップ分析の手法に沿えばいいし、パッケージの詳細機能は導入を担当するSEに支援させればいいのだから。

  当時、私がシステム分析の前半の要求分析工程に力を入れたのは

(1) ベテランSEをパッケージ間で共通化して、こなせるプロジェクト数を増やすため

  この理由は、システム分析がきちんと完了すれば後は外注でも何とかなるからです。

(2) 重要でない全ての要求は、上流においてユーザを納得させながら排除するため

  この理由は、ユーザに期待を後工程まで持たしてしまうと、それは最後の方では実現すべき要求に変わってしまうからです。たとえば、テスト工程でモレた要求が出てくると、ユーザはそれが実現されないと、業務が回らないとか言い出します。

(3) プロジェクトリスクを早期に発見するため

  この理由は、商談段階で見極めが付かなかった見積違いプロジェクトは、準委任契約の段階で「継続するか撤退するか」の選択肢を持てるためです。

工程が進んでしまうと、上記2のようにテスト工程での要求増加にも、SI企業はそれまでの投下コストを回収しなければならないので、かなり立場が弱くなってしまいます。

 3.要求分析レベルのシステム分析できるSEの短期、育成方法

  関連ブログ記事SEをビジネスアナリストへ育成するための5ステップ において述べたように、SEをビジネスアナリスト育成への最初のステップとして、以下の2つがあります。

  ①プロセスモデリングへの守備範囲の拡大

  ②ビジネスプロセスからIT要求の引き出し

  これによって自然と、要求分析レベルのシステム分析ができるようになります。超上流は上流を含みます

  BABOKV2では、システム分析はビジネスアナリストの仕事の範疇ではないようです。しかし、米国ではビジネスアナリストがここまで担当して、8時間単位のSOWを作成して、RFPを作成していると聞きます。要求分析レベルのシステム分析を担当できるSEを育成するのは、GUTSY-4によるビジネスアナリスト育成が一番、短期で低コストの方法です。SEが経験を積むのを待っては居られません。その間に赤字プロジェクトが発生してはコストがかかり過ぎです。 

 

カテゴリ