はじめに
整理されていない要求・状況からものを作るのって難しいですよね
ものを作るにはそれを仕様書として記録する「箱・書式・ルール」が必要なんですが、その形状は対象・規模・複雑度によって変わります
そして状況に最も適した仕様書を作るには、思考を深いレベルまで練り上げる必要があり、本当に大変です
世の中には、さまざまな思考法・表現方法があるとは思うのですが、僕がいつも使っている簡単にできる方法があるので紹介したいと思います
この記事はどんな人に読んでもらいたいか？
要求・思考を整理する手法を調べてみたが、むずかしいなーと思っている方
事前に整理してから、仕様書の箱（ユースケース・ユーザーストーリー・要件定義など）を作ると良いでしょう
やり方
思考レベルを段階的に上げるよう、テキストを追記していくだけです
扱う事案の複雑度・範囲によって、練り上げる回数は変わります
自分に対してのセルフ議論として使うことが多いですが、テキストであるので議事録代わりに他の人と議論する時にも使います
僕の場合ざっと次のステップで考えていく事が多いです
- LEVEL1：雑多に列挙する（カオスな状態）
- LEVEL2：カテゴリ整理（多少整理される）
- LEVEL3：カテゴリごとに深堀り検討（思考を練り上げる）
- LEVEL4：まとめる（一旦整理）
- LEVEL5：仮説検証（実際に試しながら改良を加える）
LEVEL1：雑多に列挙する
思いついたものをひたすら書いていきます
課題、メリットデメリット、解決策、参考事例などとにかく書き起こしていきます
体裁を気にせずこの時点で思っている事を全て書き出すようにします
>>かなりカオスな状態
書きながら考えたカテゴリ
やりたいこと
雑多な考えやタスク
その深堀
思いついたメリットや
思いついたデメリットなど
その深堀
以前困った事
あるべき姿
なんでそう思ったか？
ほぼ決定で良いような案
なんで決定しないんだっけ？デメリットを考えてみる
あらためて課題を列挙してみる
課題
過去事例
LEVEL２：カテゴリ整理
LEVEL１の文章をコピーし、重複削除とカテゴリ整理を行います
これから深く考える為の順序整理が出来ていれば良いでしょう
またこの整理する過程で思い出した事項も自由に追記していきます
>>多少整理された状態となるが、まだ自由な感じ
多少整理されたカテゴリ
課題
現状あずいず・・・
こうしたら嬉しい
過去事例
解決策
その１
メリット
この課題を解決できる
デメリット
これが解決できない
その２
解決策（初期でボツになったもの）
デメリット
ほか
未整理な事象
今の思いなど
多少整理されたカテゴリその２
・・・
LEVEL３：カテゴリごとに深堀り検討
LEVEL２の文章をコピーし、課題・解決策（メリットデメリット代替手段）・仮の結論を自分自身で議論しながら深く考えていきます
セルフ議論をしても良いですし、GoogleDocで共有しながら他の人と議論することもあります
特にデメリットに対して、本当にデメリットとなりえるのか？代替え手段はないのか？を深堀検討していくことが多いです
この段階では、納得感のある結論がある程度は出るかと
>>一旦は答えが出ている状態となる
整理されたカテゴリ
背景・課題・要求
・現状あずいず・・・
参考事例
過去事例
解決策（いちおし）
メリット
デメリット
解決できない事象
代替え手段はないか考える
この方法は？
ダメだ・・・
じゃあこの方法は？
うまくいく！つまりこれはデメリットではない
結論（仮だよ）
結論の理由（仮だよ）
詳細仕様（仮）
項目
機能
解決策（他の案）
ボツとなった理由
整理されたカテゴリ
整理が不十分なカテゴリ
残課題
ざった
LEVEL4：まとめる
LEVEL３の文章をコピーし、結論・理由を精査しながら余分な情報を取り除きます
前のレベルで一旦の結論は出ているものの、改めて全体をまとめることで自身の考えを決定的なものにします
ここまでくると、ほぼ完了・・・・
と思いきや、実際に設計・仕様書として記録する「箱・書式・ルール」に起こしてみないとわからない事もあります
>>仮説検証ができる状態
整理されたカテゴリ
背景・課題
要求
解決策
解決策にいたった理由
詳細仕様
申し送り事項
未整理事項
LEVEL5：仮説検証
仮説検証していく過程・実務で見つかった改善点をスポット的に自己議論しながら解決していきます
検討・結論が不十分であったかどうかを、この検討過程で記したこのテキストノートを見返し、必要に応じて検討を追加していきます
>>細部が改善されていく状態
見つかった課題
課題
改良案
その１
メリット
デメリット
その２
結論
実務で迷ったらこのテキストノートに立ち戻り、継続的に改良していくわけです
最後に
実例があるとイメージ湧きやすいかと思うので、参考として実際のお仕事で作成した思考ノートを載せます
仕様作成の過程と結論を記した論点表なるものを整備するにあたり、どういった様式・仕様にすべきかをセルフ議論して結論づけを行ったものです
みなさまの思考整理方法の１つとして参考になれば幸いでございます
論点表作成過程での思考ノート
LEVEL1：雑感（形式にとらわれずに書きなぐる。書きながらカテゴライズもする）
作るもの
論点表
論点表とは何か？
仕様作成の過程で疑問点・質問事項・決定した根拠等を記録するもの
過去同じような検討事項がないかも見たい
決定した仕様の理由・根拠を見たい
この表を元に他の人と議論する
どれが検討中でどれが決定したかを把握したい
以前困った事
複数の部署がまたがる場合、論点表が分散して転記するのが非常に面倒だった
結果、更新が追いつかなかった
やりたいこと
個人ごとに見たいものが異なる。なので個人ごとにフィルタリングしたい。
まだ確認していない
あとで確認が必要
確認いらない
確認中
自分に関するもの
確認完了
論点表を全部署で共通の１つにするか？
NOかな？
プロダクト固有のUIに関する論点も出てくる
じゃあ、このプロダクト固有の論点は別で管理するのはどうだろう？
どっちに記載して良いか迷う場合がある
管理責任が曖昧になってしまい、放置タスクを誰が整理するの？問題
プロダクト固有の情報列を追加したくても自由にできない
結論
それぞれで論点表を作り、それぞれの責任範囲で更新する
お互いの論点表を持ちより、すり合わせを行う
じゃあ、論点表プロダクトごとにするとして、我々は何単位にする？
27サービスもある
サービスごと？お仲間グループごと？思い切って１つ？
それぞれで考えてみる
サービスごととした場合
メリット
対象範囲がわかりやすい
サービス固有のものはこっちにしたい
デメリット
同じ加算減算が他サービス種別に登場する
本来論点は加算減算ごとになると思う
お仲間グループごととした場合
メリット
類似の加算減算がまとまる
デメリット
他のお仲間にある場合に漏れる
他のお仲間にある場合に冗長記載となる
１つにした場合
メリット
横断的に管理できる
デメリット
数が膨大となり管理しずらい
横断管理不要、つまりサービス種別固有のものが入ってくる
書きながら他気になったメモ
仕様の更新履歴もこの論点表に書いちゃうとか？
やりすぎか・・・
ここまで書いて次にまとめることは何かを考える
次の２つに分けて、それぞれ深堀検討を行う
論点表とは何か？
何単位で管理するか？
LEVEL2：何単位で管理していくか？（LEVEL1検討メモを元に整理する）
はじめに
思考方法
メリット・デメリットを上げる
デメリットに対して代替手段を考え、デメリットの最小化を行なっていく
前提条件
基本報酬をサービス固有となるケースが多い
加算減算は横断といなるケースが多い
加算減算の中でも全サービス種別共通となるものがある
サービスごととした場合
メリット
１つのサービスに着目した場合は非常に書きやすい
サービス固有のものを書きやすい
デメリット
同じ加算減算が他サービス種別に登場する
そもそも、算定要件ごとの論点が中心となり、サービス種別は付随情報のはずである
✖️目的軸が異なっている時点で、どんなにメリットがあってもこれを選択すべきではないと思う
お仲間グループごととした場合
メリット
類似の加算減算がまとまる
ある程度分類しておいた方が確認範囲がわかりやすい
デメリット
横断共通のものが冗長記載となる
横断共通シートを用意するか？
✖️どこまでを横断共通とするかの定義が難しい
他のお仲間にある場合に対応範囲がもれる
他にある旨を記載する
他のお仲間がある場合にどちらに論点を載せるべきか迷う
優先シートを決める？
✖️常に優先シートをチェックしないといけない。確認漏れが発生する可能性もある
検索する時にシート指定するのがめんどい
ここまでの所感
回避できないデメリットがあり、メリットが薄れる気がする
１つにした場合
メリット
横断的に管理できる
被りがない。転記漏れがない
デメリット
数が膨大となり管理しずらい
カテゴリ・フィルターを作る
サービス種別やお仲間グループ
正直、GitHubProjects作った方が良い気もするな・・・
サービス種別固有のものが入ってくる
カテゴリ・フィルターを作る
ここまでの所感
デメリット回避方法がシンプル
LEVEL2：論点表とは何か？（LEVEL1検討メモを元に整理する）
論点表の目的
仕様作成の過程での疑問点・質問事項・決定した根拠等を記録するものである
この事により、決定仕様の理由・根拠を明確に把握できるようにする
共有することで、自部署・他部署間でのコニュニケーションをスムーズに行えるようにする
運用フロー
自部署内で完結する表をもちいて管理・議論を行う
TODO検討：他部署管理の論点表へのリンクを貼るか？管理が複雑になるので
TODO検討：決定までのステータス変更管理を考える
他部署と協議する場合は、それぞれの管理している論点表を元に議論・すり合わせを行う
他部署管理の論点表への記載は行わない。責任範囲・更新管理責任が曖昧になるので
LEVEL3：一旦まとめる
論点表とは何か？
論点表の目的
仕様作成の過程での疑問点・質問事項・決定した根拠等を記録するものである
この事により、決定仕様の理由・根拠を明確に把握できるようにする
共有することで、自部署・他部署間でのコニュニケーションをスムーズに行えるようにする
運用フロー
自部署内で完結する表をもちいて管理・議論を行う
TODO検討：他部署管理の論点表へのリンクを貼るか？管理が複雑になるので
TODO検討：決定までのステータス変更管理を考える
他部署と協議する場合は、それぞれの管理している論点表を元に議論・すり合わせを行う
他部署管理の論点表への記載は行わない。責任範囲・更新管理責任が曖昧になるので
機能
TODO検討：個人フィルタリングは後ほど検討
個人ごとに見たいものが異なる。なので個人ごとにフィルタリングしたい。
まだ確認していない
あとで確認が必要
確認いらない
確認中
自分に関するもの
確認完了
何単位で管理していくか？
１つにまとめる
メリット
横断的に管理できる
被りがない。転記漏れがない
デメリット
数が膨大となり管理しずらい
カテゴリ・フィルターを作る
サービス種別やお仲間グループ
正直、GitHubProjects作った方が良い気もするな・・・
サービス種別固有のものが入ってくる
カテゴリ・フィルターを作る
LEVEL4：詳細検討（実際に作ってみて感じた詳細項目を検討する）
サービス種別は選択式にする？
最初選択式にしたが、複数サービス種別があるものがあるので、テキスト形式にすべし
＞済み
残項目（論点として議論すべきものだけ）で絞り込みたい
さくっとアクセスできるようにする
となると、フィルターかな・・・
そのフィルターへのリンクを上部に設置するのが良さげ
＞済み
解決後に実装するけど、実装ステータスはここで共有すべきか？
実装状況を他部署に共有する必要があるかどうか？
微妙・・・元々あったので残しておく
＞済み
実装状況を内部で共有する必要があるかどうか？
ない。GitHubProjectsで管理すれば良いので
LEVEL5：詳細検討（実際に運用を開始してみて改善点を検討する）
現在の仕様
ステータス
未確認 初期状態。誰にも共有していない
確認中 誰かに相談した状況。議論中。回答待ち
解答待ち 仮の解答、解決案が提示された状態。
解決済 結論が出た状態
保留 他の資料が出てこないと結論が出せない状態。
未実装 しばらく使わない
変更者
起票者が責任を持って変更しましょう。
現在の課題（雑多）
起票者はステータス変更を変更しずらい
ほぼPLが変更行っている
未確認→確認中 など起票者ではなく確認者が行うケースが多いので
ボールを誰が持っているか不明
次に行うべきアクションが不明
議論としてはCLOSEしているが、仕様書への反映などの残作業がある場合に完全CLOSEして良いものか
会議で確認すべきものがどれかがわからない
解決案（課題ベースで）
起票者はステータス変更を変更しずらい
起票者ではなく、次に誰がどうするを明確にする
ボールを誰が持っているか不明
次に誰がどうするを明確にする
次に行うべきアクションが不明
次に誰がどうするを明確にする
議論としてはCLOSEしているが、仕様書への反映などの残作業がある場合に完全CLOSEして良いものか
議論と作業状況を分ける
会議で確認すべきものがどれかがわからない
作業状況にステータスを設ける？
議論状況にステータスを設ける？
解決案（カテゴリわけ）
次に誰がどうするを明確にする
処理者＝次に行動を起こすべき人
処理内容＝ざっくり何をすべきか？
→⭐️これでいく！。前職でもそうしていたしね
議論と作業状況を分ける？
論点状況と作業状況で分ける案
メリット
議論CLOSEしやすい
デメリット
ステータスを複数持つチケット管理システムはあまりない
なので複雑になる可能性がある
現状ステータスに追加する案
メリット
ステータス管理が１つなのでルールがシンプル
その昔使っていたシステムは１ステータスでやっていた
デメリット
あらためてステータス設計を行う必要がある
→一旦これで検討
ステータス変更案
フローを考える
起案
初期状態
ステータス：
未確認
内容確認
チーム内議論の前に内容を確認する
ステータス：
未確認→確認中
内容を精査中。まだ他に人に共有できる状態でない
確認中→*報告あり
内容が良くわからないので、会議で詳細を確認したい状態
仮の結論を出したので、会議で他の人に共有したい状態
確認中→解決済み
チケットの分割、要望・質問に対して回答を行い、起案者に個別連絡の必要がないもの
チーム内議論
要議論に対してチームで議論を行う
ステータス：
*報告あり→確認中 ：持ち帰る必要がある場合
*報告あり→*報告あり ：内容は決定したが、他部署に確認が必要な状態
*報告あり→解決済み：チーム内の議論としては終了している状態。特に共有の必要はない
議論は終了したが内部での残作業がある
解決済み(残あり)
→⭐️よさげ。実際に適用して詳細検討に入る