経緯

匠の考案者である、萩本さんに勉強会の開催を提案する際に、
思い切って今までの自分の設計や要件定義の理解力を試すつもりで、
図解しながら、ドキュメント化するガチな提案を作ってみたという流れです。

価値デザインモデル

私の思う、Socity5.0っていうものは、
単なるアーキテクトという文脈を超えているため、匠や脅威モデリングなどの思想が
マストであると思っています。
そこで、イメージ絵には、上記のようなものを使いました。

価値分析モデル

工夫ポイント① -アジャイルモデリング精神の導入-

今回は巻き込みたいステークホルダーが、超ピンポイントであったため、
ステークホルダーモデル図と価値分析モデルをあえて１つで表現しました。

ステークホルダーモデルに、沢山の利害関係者が列挙される場合には、
価値分析モデルと分けることを推奨しますが、
今回はたった1種類のセグメント像であったため、分けるメリットが特にないと感じたため、
１つのモデル図に表現しました。

このモデリングの考え方は、まさに以下のアジャイルモデリングから得た知恵です。

工夫ポイント② -脅威の記述-

主張

匠では、嬉しいことを価値記述として定義しますが、
そこに伴う強烈な不安要素は、絶対に目をつぶってはいけないと考えています。

事実

むしろ積極的に、批判的になって、視点を切り替え
起きてほしくないことを事前に考えているかいないかで、
後々になってから足元をすくわれるなんてことを予防できます。

主張

でもだからといって、脅威ベースで嬉しいことを考えろという意味ではありません。
嬉しいことと、起きてほしくないことは目線を切り替えて、
最初は完全に分けて考えることをお勧めします。

もちろん時間がないときには、嬉しいことを先に考えて、
そこに伴う不安要素のみをまずは優先的に脅威記述として定義するという手法でもいいです。

ただしその際に、リスク観点の抜け漏れが起こりうるという代償はつきものです。

要求分析ツリー

今回は、価値分析モデルと価値デザインのコンセプトを眺めてみて、
以下のように読み上げて暗算でチェックができたので、要求分析ツリーモデルをあえて定義しませんでした。

これも上記のアジャイルモデリングの精神をもとにしています。

ネタバレ

匠のモデルは、価値デザインから作成しようが、価値分析から作成しようが、正解はありません。

しかしながら今回は、最初から自分の中で「信頼が出来上がっている少数精鋭で自分たちを磨き上げたい」という強い思いがあったので、価値分析モデルから作成しました。

提案時に要件定義の形式を意識した

読み手に伝える際には、たらたらと書くよりも、
「ここには、こういったものが書かれてるのか」ということが、
一発でわかるように、単一責務の原則の考えに沿って、改行したりすると解りやすいと感じます。

参考図

以下は参考例ですが、
「背景」「主張」「提案の具体的内容」という流れです。

どうなりたいのか？　やロードマップに関しては、
すでに上記での価値デザインとかで表現しているので省きました。

曖昧さをあえて残す部分

開催頻度に関しては、参加者によって曜日がズレるため、
余幅を持たせて、「平日夜」というようにしています。

最初から「平日月曜の19-20時」としてしまうことによって、
以下のようなメリットとデメリットが出てきます。

批判的思考を用いて長所と短所の両側面から観察する

この際に、必ず

批判的思考を使って、強制的にデメリットを出す

ことによって、価値観、提案の方針がより強固なものとなります。

これは、アーキテクチャを考える際にも同じメカニズムです。
どの設計案を採用するにしても、必ずメリット・デメリットを列挙します。
デメリットを考える時には、実は無意識に感情面での脅威を考えていることになります。
今回の図では、想定参加者である「匠・SE4BSの常連メンバー」目線での脅威記述を描きました。

このように見える化することによって、自分たちがどちらをより嬉しく、
どちらをより脅威と捉えるのか？を再認識しやすくなります。

抽象・具体にすることによるメリット・デメリットを必ず考える

このようにどこが具体であり、どこが曖昧さをあえて残す部分なのか？
抽象的にあえてすることによるメリット・デメリットなどを見える化します。

今回は、角がまるい付箋で状態を表現し、四角い付箋で利害関係者の感情を表現しました。

決定事項

ここでは、ADR的な思想を使って、提案内容の要件定義設計のWhyを残します。

今回の価値記述には、そもそも
「外部環境への変化に強く対応できるようになりたい」(☆)という強い想いが表現されております。

具体的日時の場合

ここで、【具体的な日時にする】という選択をしたらどうでしょうか？
スケジュール変更という部分への柔軟な対応力の強化にはつながりません。
これは(☆)の思いに矛盾する選択です。
よって、却下されます。

抽象日時の場合

では、【余幅を持たせた日時にする】というinterface抽象な日時にしたらいかがでしょうか？
付箋で表現されたように、スケジュール設計において多態性を用いた設計力が求められ、
結果的にそれに慣れることによって、変化への対応力が向上するというロジックです。
これは(☆)の思いに一貫しています。
よって、今回はこちらの選択肢が採用されます。

まとめ

今回、勉強会の提案を要件定義や設計を考える際のロジカルに、
図解ベースでメリット・デメリットなどを列挙しながら、
全体のつながりを見つつ、方向性を固めました。

そして、最初から抽象さをあえて残す部分などを考察していきました。
これらの流れを通して、日常の中で要件定義や設計のメカニズムに応用していただければ嬉しいです。