全然よくわかんない
こんな悩みをお持ちではありませんか？
上流工程（要件定義や設計）のやり方って明確にこれだ！っていう方法ってないと思いませんか？
ウォータフォールモデルのプロセスはわかっても、その中でじゃあどう手を動かしていけばいいかというのは、かなり曖昧ではないでしょうか。
教科書的な回答は見かけるのですが、それでいざ手を動かせるってやり方は、私はあまり見たことありません。
そのため、今回いち個人として、IT企業でSIer10年働いてきた筆者のやり方を共有したいと思います。
主にWEB系システムやバッチプログラムを開発してきたので、うちとやり方が違うというのが出てくるかもしれませんが、その点はご了承ください。
名前と教科書の意味はわかってるけど、全くわからんって人の参考になればと思います。
本記事の狙い
・上流工程（要件定義や設計）で手を動かせるようになる
上流工程でも何でも基本的にはコレ！
上流工程に限らず、あらゆることに共通していますが、
結論としては、あいまいな言葉を具体的に言語化・イメージ化して定義・整理するだけです。
あいまいな言葉とは？
ここで言うあいまいな言葉というのは、下記のような定義です。
- 誰が、どうしたい、何のために、という情報が抜けていたり、定義が明確でないもの。
- 良し悪しが明確でないもの
もっと言うなら、あいまいな言葉の基準は、
その言葉を聞いて具体的なものがすぐに想像できなければ、あいまいな言葉と判断して良いです。
例えば、IoTデバイスの管理がしたい、分析がしたい、いい感じの画面、など、「それって具体的にどういうこと？」と思うものです。
言語化とは？
具体的に言語化とは、あいまいな言葉を具体的な言葉に分解することです。
あいまいな言葉というのは、具体的な言葉の集合体なので、具体的な言葉に表現を変えて分解することができます。
具体的な言葉に変える方法は、何ができればあいまいな言葉として表現できるのかを考え、
何がの部分を洗い出すことです。
例で説明します。
例１
例えば、「IoTデバイスの管理がしたい」であれば、「管理する」という部分があいまいです。
「管理する」という場合、たいてい、参照・登録・変更・削除は基本セットなので、下記のように分解できます。
情報を参照する場合、だいたい一覧と詳細画面が存在するので、それもあるだろうと想像できます。
- IoTデバイスの情報を参照する（一覧、詳細）
- IoTデバイスの情報を登録する
- IoTデバイスの情報を変更する
- IoTデバイスの情報を削除する
また、誰が、何のためにという情報も抜けています。
こういう抜けている部分の情報への対処は、下記の2点です。
- 想像できるなら仮置きして要望している人（顧客、プロダクトの責任者など）に確認する
- 想像できないなら要望している人（顧客、プロダクトの責任者など）への確認事項として記録し、確認する
完成形としては、下記のような表現です。
完成形例
管理者がリモート監視するためにIoTデバイスを管理する
- IoTデバイスの情報を参照する（一覧、詳細）
- IoTデバイスの情報を登録する
- IoTデバイスの情報を変更する
- IoTデバイスの情報を削除する
もっと言うと、管理者というのは、アクセス権限が管理者となるユーザなのか？と疑問を持ち、そうであるならば、参照のみの権限も必要か？権限設定で操作を限定する機能も加える必要があるのか？ということを考えて定義していきます。
考えていく上で不明点が出てきたら確認して詰めていけばOKです。
例2
例えば、「分析がしたい」というのであれば、誰が、どんなデータを、どのように、何のために、と言った情報が抜けています。
こういうものは、抽象度が高いので、最初に目的から定めましょう。
目的に合わせて、指標となる数値や使用するデータを決めて、どのように可視化したり、扱っていくのかを要望している人に確認しながら決めていきましょう。
それを言語化できればOKです。
イメージ化とは？
具体的にイメージ化とは、あいまいな言葉を具体的なイメージの絵や図で表現することです。
言語化することが難しいものは、絵や図で表すと良いです。
その方が共通のイメージを確認できるため、わかりやすく、意志疎通も早く済みます。
例
例えば、「いい感じの画面」というのは、良し悪しが不明確なものです。
良し悪しというのは、主観であり、人によってかなり異なるので、こういうものは、画面イメージを作成したり、参考となるサイト、アプリなどを提示して、確認すると良いです。
整理するとは？
整理するとは、あいまいな言葉の言語化、イメージ化できたら、それらを分類して並び替えをすることです。
分類の仕方は、基本的に目的ごとに名前を付けて分類すればOKです。
例えば、前述で示した例で分類すると、下記のようになります。
- 「IoTデバイス管理したい」 ⇒ 小目的「IoTデバイス管理」に分類
- 「分析したい」 ⇒ 小目的「IoTデバイスエラー分析」に分類
- 「いい感じの画面」⇒ 小目的「IoTデバイス管理参照画面」や「IoTデバイスエラー件数参照画面」に分類
並び替えは、抽象度が高いものが先で、具体的なものが後というぐらいです。
何か並び順の条件があれば、それに従えばいいでしょう。
前述の例を並び替えると下記のようになります。
- 「IoTデバイス管理」
- 「IoTデバイス管理参照画面」
- 「IoTデバイスエラー分析」
- 「IoTデバイスエラー件数参照画面」
要件定義のやり方
要件定義と設計との違いは、インプットとなる情報のあいまいさ（抽象度）が異なる点だと思っています。
要件定義の場合は、直接顧客やプロダクトの責任者から、解決したい課題や実現したいことという抽象度が高い情報を聞いて、要件として抽象度を下げた情報に落とし込みます。
その際、使える方法が前述の あいまいな言葉の言語化やイメージ化です。
アウトプットとして、どこまで作るかはその会社やそのプロジェクト次第ですが、個人的には、下記のものは最低限必要だと思っています。
- 解決したい課題や要望の一覧
- 要件一覧
- 開発する機能一覧
- システム構成図
- 性能要件
既存のプロジェクトを参照できるなら、どのようなものをアウトプットとして定義しているか参考にすると良いでしょう。
最近では、ウォータフォールではなく、アジャイル開発を行う会社も増えてきたと思いますが、アジャイル開発でもあいまいな部分は往々にして頻発しますので、言語化とイメージ化は必須だと思っています。
設計のやり方
設計では、要件定義で決まった内容やその前段の情報がインプットになります。
それらの情報を基にさらに抽象度を下げた情報に落とし込み、基本設計書や詳細設計書というアウトプットを作ります。
ここでも、同様に、あいまいな言葉の言語化やイメージ化を行って詰めていきます。
アウトプットとして、何を作るかはその会社やそのプロジェクト次第ですが、個人的には、下記のようなドキュメントが最低限必要だと思っています。
- 画面遷移がわかる
- 画面イメージがわかる
- 画面ごとのインプットとアウトプットがわかる
- 画面ごとの処理の流れがわかる
- バッチプログラムごとのインプットとアウトプットがわかる
- バッチプログラムごとの処理の流れがわかる
- データの定義がわかる
ポイントとしては、この情報があれば実装ができるという段階まで整理できれば十分でしょう。
その基準は、開発者のレベルに依存するので、開発者に合わせてよくコミュニケーションを取り、情報を整理していきましょう。
まとめ
- 上流工程の基本的なやり方は、あいまいな言葉を具体的に言語化・イメージ化して定義・整理するだけ
- 要件定義のやり方は、顧客のやりたいことの情報を具体的にすること
- 設計のやり方は、要件定義の情報を具体的にすること
SIer10年やっていく中で、実用でき、自分で納得もできているため、私はこのような方法でやっています。
周りには、上流工程の要件定義や設計とはこうやるんだ！と胸を張って教えてくれる人がいなかったので、
様々な案件の情報を解釈・実践して、このような独自のやり方にしています。
結果的に、上流工程に限らず、あらゆる物事を行う上で役立つやり方になっているので、私は、他の工程や物事を進める上でも活用しています。
読んでくれた方の「要件定義や設計について、何をすればいいのかわからない」という悩みの状態を少しでも緩和できたら幸いです。
プログラミングができても、こういった部分もできなくては、人のやりたいことを実現できるエンジニアにはなれないと思いますので、一つの参考にしていただければ嬉しい限りです。
紹介は以上です。
読んでくださった方ありがとうございました。