開発工程の中の要求定義の説明です。
１．要求定義でやること
企画がとおるといよいよ次は要求定義です。要求定義は、ユーザー部門がやりたいことをまとめる工程です。
ただ実際には「要求定義書」もシステムのドキュメントの一つなので、ユーザー部門だけではまとめられないので、システム部門がユーザー部門からヒアリングをしてまとめます。要求定義書に記載する内容は、主に以下のものになります。
①機能要求（目的や背景含む）
②非機能要求
③プロジェクト期間／納期
④役割分担／体制図
⑤予算
①がユーザー部門からの要求です。「こんなことをやりたい」というユーザー部門の要求をまとめたものが機能要求です。改修レベルの案件の場合、機能要求だけ記載することが多いです。
②は性能やセキュリティー、可用性、クラウドかオンプレかといったサーバー環境、保守性等の要求です。新規でシステムを構築する場合には非機能要求をきちんと提示しないと、まともに動かないシステムが出来上がる可能性があります。
③と④はRFPとしてまとめる場合が多いです。④は特にデータ移行や教育、マニュアル作成、受入テストの支援、本番稼働直後のサポートといった開発そのものでないものについて、どこまでベンダーに依頼するのかを明確にします。
⑤は予算をベンダーに伝えることは少ないですが、公開していい場合には「この予算内でできるシステムを提案してくれ」といった形で提示します。公開しない場合でも、非公式では予算感を候補のベンダーには伝えることが多いですが。
またある程度の規模の場合には、「要求定義書」の他に「要求一覧」も作成します。要求一覧を作ることで、要求が構造化されるため、後々の管理（特に品質管理やスコープ管理のトレーサビリティー）で大きく役立ちます。
２．RFPとの違い
RFPはベンダー選定をするために、ベンダーに提案を求めるためのドキュメントです。
RFPには、ベンダーが見積り含めた提案をするために必要な情報と、発注者側がベンダーを選定するために必要な情報の大きく２種類の情報が含まれます。
前者は、基本的には要求定義書が該当します。ただし、発注者の業務や現行システムを知っていることが前提の要求定義書（既存ベンダー向け）と、知らない相手に出す要求定義書では後者の方がボリュームは多くなります。
後者は、要求定義書に記載すること以外の情報で、主に以下のようなものを提案書に盛り込むように要求します。
①類似システムの他社での構築実績
②プロジェクトメンバーのキーマンの経歴
③プロジェクト体制（委託先の会社名含めて）
④想定している開発手法やプロジェクト管理の方法
ベンダーの提案に良いことばかり書いてあっても、本当にそれを実現できる実力のある会社や体制なのかを、こういった情報で評価します。
３．民間と官公庁の違い（余談）
余談ですが、このRFP、民間と官公庁とでは位置づけが異なります。
正確には官公庁の場合（政府資本の入っている会社の場合）、RFPに相当するものは「調達仕様書」と呼びます。
RFPとの大きな違いは、受託したベンダーは調達仕様書の内容を実現する義務がある、ということです。
民間のRFPの場合、ベンダーが受託後に準委任契約で要件定義を実施し、そこでスコープと費用が確定して基本設計以降の請負契約という流れになります。つまりRFPで提案したことは必ずしも実現する必要はありません。もちろん、受託するために出来もしないことをRFPに書いてしまうと要件定義で揉めることになるので、通常は全て実現するつもりでベンダーも提案はしてきます。
それに対して調達仕様書の場合には、ベンダーの提案書が契約書の一部になります。要件定義以降の工程を請負で契約するため、ベンダーは落札した金額で、提案書に記載したことを実現する義務が生じます。要件定義をやる前に費用が決まってしまうので、ベンダーはリスクをかなり多く乗せて入札することになります。税金の無駄遣いです。
４．要求定義の例
紙で回付している稟議書のワークフロー化の要求定義を考えてみます。
システムで実現したいことを記載します。ほとんどの場合には、今やっている
あるいは、これからやろうとする運用を記載することになります。
・機密区分（社外秘、機密、厳秘）の選択ができる
・社外秘は、同じ部署の人は全員が参照、ダウンロード、印刷が可能
・機密は、稟議を回付した人だけが参照、ダウンロード、印刷が可能
・厳秘は、稟議を回付した人だけが参照のみ可能で、ダウンロードや印刷は不可
・稟議を起案したタイミングで稟議番号を発番する
・起案した稟議は稟議整理簿で、年度ごとに管理できる
・稟議整理簿には、稟議番号、件名、起案者、起案日、決裁者、決裁日、機密区分を出力する
・稟議整理簿の件名は、厳秘の場合には空白とする
・決裁する金額によって、自動で部長決裁、担当執行役決裁、社長決裁が決まる
・回付ルートは、起案者の所属と決裁者によって自動で決まる
・各所属の管理者のみ途中承認者をスキップできる
・承認者は、承認、否認、差し戻しの３種類が可能な
・承認者は、個人、組織、組織＋役職の３パターンの設定が可能な
・承認者が複数の場合、全員の承認が必要なパターンと誰か一人の承認で良いパターンの２種類が選べる
・起案者は起案後に、決裁前であれば引き戻しが可能
・起案者は引き戻し後に再申請か廃案が可能
・保管期限は起案者が５年、７年、１０年の中から選択できる
・保管期限が過ぎた稟議は、自動で削除する
上記の記載は、要求一覧のイメージです。要求定義書は、これらの情報が表形式で記載されたり、フロー図で記載されたり、イラストで記載されたり、様々な表現方法で記載されます。
【振り返り】
今回は要求定義の説明でした。次回は要件定義の説明をしていきたいと思います。
猫タイプだと言われます。
猫よりも犬の方が好きだし、自分自身も素直で従順なので犬タイプだと思うのですが、なぜか友人たちからは猫タイプだと言われます。
まあそれはいいとして、社会人になって一人暮らしをはじめてから、１０歳離れた妹が黒猫「歳三」を飼い出しました。子猫で結構凶暴で、実家のあらゆる壁がぼろぼろに。それでも子猫なのでかわいくて、実家に帰るのが楽しみでした。
ある日の朝、実家に泊まって寝ていると、足の親指に違和感が。意識がはっきりして足下を見てみると、布団から出ていた私の足の親指、歳三が噛み付いていました・・・。ちょびっと痛い。
しばらく目が合った後、「しまった」という表情をして、ゆっくりと噛み付いていた口を離す歳三。
何事もなかったかのように部屋を去っていく歳三を眺めながら、やっぱり犬だなと思いました。
新型コロナウイルスの対策で、極力、時差出勤するように通達が出ました。
オフィスの最寄り駅は８時から９時半まで混雑するので、その時間帯を外すのが望ましいとのこと。
私は夜型ではなく朝型なので、普段よりも１時間早く出勤をして、７時５０分に到着。確かにオフィスの最寄り駅は人が少なかったのですが、自宅から途中駅までは電車がすし詰め状態。普通の時間に出勤した方が、電車が空いているので逆効果でした。
１５年くらい前に、アベニーパファーという淡水フグを飼っていたことがあります。
生まれてはじめて自分で飼ったペット。コレド日本橋の雑貨屋で見かけて一目惚れしました。
名前はふぐ太郎。餌は細長い赤虫。懐くと手から食べてくれるので、ちょっと気持ち悪い赤虫でも、我慢して触ることができました。
ふぐ太郎は魚なのに、悩みます。食い意地がはっているので、お腹がいっぱいになっても餌の前で立ち止まって、食べようかどうしようか苦悩します。無理して食べると、お腹から餌がぴゅっと飛び出します。そして、それをまた追いかけて食べます。
ふぐ太郎は魚なのに、ぐで〜っと寝ます。さすがに横になっては寝ないけれど、石のベッドから落ちて、頭を下にして寝ていることもあります。瓶を叩いても、ちょっとやそっとじゃ起きません。
ふぐ太郎は魚なのに、歯を鳴らして食べます。細長い赤虫を、歯をガチガチ鳴らして、ものすごい勢いで食べます。そして頬を膨らませて、とても良く噛んで食べます。おいしい赤虫だと、犬の尻尾のようにヒレを振って喜びます。
ふぐ太郎は魚なのに、人間でした。
そんなふぐ太郎。たったの２ヶ月で天国に旅立ちました。
苦しそうなふぐ太郎が事切れる瞬間に立ち会ってしまったせいか、何故か涙が出てしまい・・・。たかが魚一匹に、大の大人がバカみたいだと思いながらも、涙が止まりませんでした。
たったの２ヶ月だったけれど、家族以外ではじめて毎日一緒に過ごしたふぐ太郎。「人」ではないけれど、そのときの自分にとって、何かとても大切な存在だったみたいです。
開発工程の中の戦略・企画の説明です。
１．IT戦略
IT戦略は基本的にはCIOの仕事です。
企業がITをどうやってビジネスに活用していくかを中長期的な視点で策定し、必要な予算を確保します。
最近ではDXなどが話題になっていますが、企業のITを今後、どのようにビジネスに活かしていくのか？そのために必要なことは何なのか？一番重要な人材の確保や育成はどうしていくか ？セキュリティーやコンプライアンスは？そのための予算は？投資対効果は？といったことを策定していきます。
老朽化したシステムを刷新するロードマップを作るのもIT戦略です。サーバー環境はオンプレからクラウドに移行し、最大限パッケージを活用して業務をパッケージにあわせ、ビジネス環境の変化に低コストで柔軟に速やかに対応していくことができるシステムにしていく計画を作ったりします。
IT部門が会社の組織のどこに位置づけられているかで、その会社でのITの位置づけが分かります。
社長直下に位置づけられていたら、それはCIOの立場が強いということです。でも例えば経営戦略室とかの下に位置づけられていると、CIOと社長の間にもう一人役員（経営戦略室長）がいるということになるので、思うようにIT戦略が描けない可能性があります。
２．システム企画
新しいビジネスを発掘するようなシステム企画ができるといいのですが、実際にはそのようなケースは稀です。
システム企画の大多数は、今できていないことの実現です。
こんなことができたらいいな、と思ったことを具体化していくことがシステム企画です。セキュリティーの課題があれば課題解決の企画、システムが老朽化してくればリプレースの企画、クラウド移行によるコスト削減の企画、点在する顧客情報を一元管理する企画、手作業の業務のシステム化の企画、などなど。
大変なのは費用対効果や投資対効果です。
コスト削減や老朽化対応は比較的に難易度は低いですが、業務改善系は効果の算出が非常に難しいです。
名のある大企業でも、システム化できていない手作業が大量にあります。その大半は、この費用対効果のハードルに阻まれています。DXだとか言っている時代になっても、システム化されずにいる業務は意外と多いのです。
３．システム企画の例
紙で回付している稟議書のワークフロー化の企画を考えてみます。
手作業をシステム化すること、そのものに対して反対する人はいないので、目的とか背景といった情報は、さらっと企画書に記載する程度で大丈夫です。
重要なのは費用対効果です。
まずは複数のベンダーから見積りを受領します。通常は、企画の段階では中間の費用をターゲットとして、費用対効果を算出します。
まずは削減できる費用の項目を洗い出します。
・紙代や印刷代
・稟議書を綴じるファイルの費用
・稟議書の保管場所の費用
・稟議書の番号を発番・記録する時間
・稟議書を印刷する時間
・承認者が自席にいるか確認する時間
・稟議を承認者のところに持参する時間
・決裁された稟議書を保管する時間
・過去の稟議書を探す時間
・保管期限の切れた稟議書を廃棄する時間
これらの削減できる費用（効果）が、システム開発のイニシャルとランニングの合計を例えば３年で上回れば、３年後にシステム費用を回収できることになります。
ただ残念ながら回収できない場合が多いので、定性的なメリットも追加します。改ざん防止、紛失防止、意思決定の時間短縮などです。効果が少し下回るくらいなら、定性的な効果を加えることで、承認を得やすくなります。それでも駄目なら、システム開発の費用削減を検討していくことになります。
また費用対効果とは別に導入計画の概要も必要になります。全部署一斉なのかパイロットの部署で効果を測定してみるのか。パイロット運用する場合には、使い勝手の部分での改善要望をアプリケーションに取込むスケジュールや費用も考慮します。
そしてこられの企画には、当然、ユーザー部門の積極的な協力が欠かせません。効果の算出もユーザー部門のお墨付きが必要です。実際にそのシステムを使うユーザー部門に「ぜひ導入したい」と思ってもらえるかが、企画が通るかどうかの成否を左右します。
【振り返り】
今回は戦略・企画の説明でした。次回は要求定義の説明をしていきたいと思います。
