SI業務、特に要件定義や見積もりについて語ってみる

この記事は福岡若手Sier_bc Advent Calendar 2019の４日目の記事です。

はじめに

SIerとしての(アプリ)開発の仕事ってどんな感じなんですかね？

という後輩の言葉を聞いたことがきっかけです。
この記事を読む人の対象は

• SIで(アプリ)開発をしたことがない人
• Webやネイティブの業務アプリを作ったことがない人
• SIer企業に入社した新入社員や若手の人

です。
また、この記事には

• 筆者の経験による主観

を含みます。ご留意下さい。

そもそもの話(重要)

そもそも、SIerって何よ？って話です。いろいろな説明があるとは思いますが、この記事では、

SIerとはお客様(企業)にとって価値のあるものを、お客様が保有する様々なシステムを組み合わせたり新しく作ったりして、お客様に提供する人たちのこと

としておきます。ここで

1. お客様にとって価値のあるものは、みんな(自分たちとお客様)で決めるもの
2. お客様が既に保有するシステムは、自分たち以外のシステム会社やメーカーがお客様に提供しているもの

ということを認識しておかないといけません。言い換えるなら、

1. SIerの独断、あるいはお客様の独断だけで要件を決めてはならない(正確には「決めない方がいい」)
2. お客様だけでなく、お客様保有システムに関する様々なステークホルダーと関わる必要があるし、そのステークホルダーや彼らのシステムによって制約を受けることがある

ということです。SIerについてはこれくらいの認識でいいでしょう。

SI業務の流れ

SI業務の流れについてざっくりと説明します。ウォーターフォール開発を実施することを前提にしています。

1. 要件定義
2. 見積もり・注文(契約)
3. 基本設計
4. 詳細設計
5. 製造
6. 単体テスト
7. 結合テスト
8. 総合テスト
9. 受入れ(リリース)
10. 検収

という流れになるかと思います。筆者としては本当に、本当に上流工程が重要だと考えているので、この記事では、

1. 要件定義
2. 見積もり・注文(契約)

について説明していきます。

要件定義について

要件定義とは

お客様にとって価値のあるものを、システム化するための要件を決める作業

です。ここで重要になってくるのが価値のあるものって何？ということになります。筆者の私見になりますが、これは

• お客様の売り上げを増やすこと
• お客様のコストを改善すること
• 売り上げやコスト以外にお客様が望んでいるもの(多種多様)

正直たくさんあると考えています。要件定義でSIerが注意しなければならないことは、

• お客様が求めている期待(効果)が何か
• 期待を実現するためのシステムは何か

ということです。なぜこれを注意しなければならないかというと、

• SIerが構築するシステムに集中すると、お客様の期待を忘れてしまう
• お客様自身が元々求めていた期待を忘れてしまう
• システムを構築することを目的化する

という問題に直面するからです。これらに直面すると待っているのは、

システムを構築したのにお客様がコレじゃないと言い出して戻りが発生する

という事態です。炎上PJですね。このような事態に陥らないために、SIerとしては以下のことが必要かと思います。

• お客様の業務を理解する
• お客様のITリテラシを見極める
• お客様のステークホルダーを把握する
• システム化の範囲(スコープ)を確定する
• お客様の要望を聞いて、SIによって実現するゴールを設定する
• 設定したゴールと現在の状況のギャップをITで埋められるかを検討する

以下、上記のことについてそれぞれ述べていきます。

お客様の業務を理解する

業務を理解すると、アウトプットとして「現在の業務フロー」を作成することができます。お客様の業務を理解するために以下のことを実施する必要があります。

• どのような業種なのか、その業種について調べる
• お客様の業務目標は何か理解する
• 日々の業務はどのようなものか調べる(部署で異なるか？地域で異なるか？役職で異なるか？)
• 業務はどのようにオペレーションされているのか

コレをしないと少なくとも「お客様と関係ないシステム」が出来上がってしまいます。これらの活動によって、「現在の業務フロー」を作成していきます。

お客様のITリテラシを理解する

これは主観になるのですが、SIerのエンジニアが会話するのはお客様企業のシステム担当者の方である可能性が高いです。システム担当者の方は社内で比較的ITリテラシが高い方なので、打ち合わせなどでシステムに対する認識を合わせやすいです。
ケースバイケースですが、システム担当者の方と会話した内容がシステムの要件に占める割合が多いため、非常に重要なポジションの方となります。

基本的に、経営者の方や営業の方はITリテラシが高いとは言いにくいことが多いです。最悪のケースの場合、

• 経営者の方が現実の業務と乖離したゴールを設定する
• 営業の方がシステムに関することをシステム担当者に丸投げしている

ということがあります。「現実の業務と乖離したゴールを設定する」とは、車で例えるなら、「オートマ限定の免許で軽自動車しか乗ったことがないのに、ミッション車のターボ付きスーパーカーに乗りたがる」といったことです。要件を確定する上で経営者の方のご意向を汲む必要があるのですが、現在の状況から経営者の方の理想を実現するためのロードマップを示してステップアップ的な提案を行うなど、工夫が必要だと思います。お客様のITリテラシ、言い換えれば理想のシステムが実現可能かどうかをお客様自身が理解できているかどうかを見極めることは重要です。

お客様のステークホルダーを把握する

これはお客様の業務を理解する上でも重要なことですが、

• お客様のお客様(場合によってはエンドユーザになり得る)
• お客様の保有するシステムの提供者(保有システムとのI/Fを考える際に打ち合わせを行う必要がある)

これらのステークホルダーは意識しておいた方がいいでしょう。先述したように、お客様の保有するシステムによって制約を受けることがあります。制約としては、

• システムの提供時間、休止時間
• システム間I/Fのプロトコルなど

といったことです。そしてそれらのシステムは提供者が最も正確な仕様を把握しています。したがって、お客様が既に保有するシステムと連携、I/Fを考える場合はその提供者と打ち合わせやI/F仕様の調整を実施する必要が出てきます。

システム化の範囲(スコープ)を確定する

これはお客様と決めることですが、主にシステム開発をする場合は納期とコストを考慮してシステム化の範囲を決めると良いでしょう。範囲とは、

• システム化する業務の範囲
• 地域的な範囲(特定の事業所だけシステム化する)
• 期間的な範囲(特定の期間だけシステム化する)

といったことになります。こちらも意識しておいた方がいいでしょう。

お客様の要望を聞いて、SIによって実現するゴールを設定する

ここでいうお客様の要望とは、お客様のなりたい姿、実現したい業務のことだと思っていて差し支えないでしょう。しかし、お客様の要望は具体的じゃないことが多いです。例えば「売り上げを増やしたい」というお客様の要望があったとしたら、「具体的にどんな事業で売り上げを増やしたいのか、どのくらいの投資を見込んでいるのか」など、イメージを具体化させましょう。

設定したゴールと現在の状況のギャップをITで埋められるかを検討する

ここでやっとエンジニアとしてのお仕事になってきます。上記で記載したことをまとめて、いかにITで埋められるかを検討します。検討の結果、最終的に要件定義書を作成します。

特に(Web)画面イメージを要件定義書として作成する場合は、モックアップや紙芝居を作成して、お客様と打ち合わせをしましょう。打ち合わせの際、

• お客様が業務の中で画面をどのように操作するのか
• 業務の流れに画面の操作が合致するか

を確認しましょう。その他の要件定義書は、IPAのサンプルにあるようなものを揃えればいいかと思います。

見積もり・注文(契約)

要件定義が終わって要件定義書が作成できたら、システム化に必要な工数を見積もりましょう。見積もりを実施する場合は、

• 過去の実績から工数を算出する
• 基準となる作業と工数を利用する

といった方法が効果的です。正直絶対的な工数の算出は非常に困難だと思います。したがって、上記のように基準を設けて相対的に工数を算出するのがいいかと思います。見積もりに関する記事はこちらの記事が非常にわかりやすく、重要な指針となると思います。

まとめ

以上で、要件定義や見積もりについて述べました。まとめると、PJを成功へ導くためには、お客様の業務を理解し、お客様と密に連絡を取り、ゴールとなるイメージを共有することが重要です。
今回記載したことが全てだとは思いませんが、みなさんの指針に少しでも影響を与えられたらいいな、と思います。