背景と目的
昨今のDX推進プロジェクトといったものも、
要求が複雑化し、マルチステークホルダーの要求同士の関係性や
その人々の置かれた前提条件の不透明さによって、
正しく要求が抽出できていないこと がボトルネックに感じている。
そのため、ここではまずは真の要求、人間の本質的に求めていて、
要望とは違って、あまり変化が起こりにくい価値概念を抽出するための考え方を示す。
前提
顧客が背景も曖昧なままこんなもの作ってくださいって言ってきているものは、
基本的に要求事項ではなく、ただの要望。
この要望とは、不純物にまみれた一見要求っぽく視えてしまうものって意味。
これを要求と捉えて、実現手段まで落とし込んだとしても、
完成する頃には顧客の要望は移り変わっているので、全然満足いくようなものにはなり得ない。
そもそも顧客が自分の本当の要求を言語化できている、て思うのは非常に危険である。
仮に言語化できているのであれば、外部に委託してくるなんて可能性は低い。
言語化が当たり前にできているなら、まずは内製化できないか？と優先して考えるから。
ロジカル、ラテラル、クリティカルシンキング
ググっていただければいくらでも情報商材はあるし、
UdemyやSchooといった動画コンテンツサイトでは専門コンサルの方が解説してくれているので、そちらを参照してください。
エンジニアはロジカルシンキングは得意でも、他２つをおざなりにしている人を多く見かけます。
他の選択肢はないかな？ってことをやった上でより適切な選択意思決定できる
人になるためにも、ビジネスの必須スキルとしてもっておくべきものです。
SLAP原則
抽象度や粒度を揃えましょうっていう原則。粒度の異なる要素は比較できないし。
あと、メンテしていく中で「あれ？実はこれとこれ粒度ちがくね？」ってこともある。
データ、プロセス、価値の粒度、コンポーネントの粒度 など
あらゆる場面で重要な原則なので、常識にすべきものです。
ADR(アーキテクチャデシジョンレコード)
どんな背景があって、そのアーキテクチャにすると決定したのか？
といったことを記録するものです。
コンテスト、決定、影響の３部構成からなっているものであり、
これがあると
・過去に検討したアーキテクチャ案などを参照できる
・その上でより適切なアーキテクチャ案を議論できやすい
・すでに１度議論したことある検討を再度やるっていう俗にいう車輪の再発明も防げる
・組織ナレッジとしても蓄積できる
といった恩恵があります。より詳細はADRでググってください。
わたしはこれをパクってIDRというものを導入しようとしています。
方針(AsIsとToBeを結ぶベクトル)
方針は向かう方向性でありながらも、
ろくにToBe-AsIs分析もされない段階からプロジェクトで暗黙化されたまま何となくで運用されがちです。
そしてそのようなプロジェクトは判断軸が多数決であったり、
だれか専門家や声の大きい人の経験則からなるもので決められてしまいがちです。
しかしいきなり暗算でできると妄信して何となくでやっている人は多いです。
あくまでも方針は、長期目標ToBeに対する、AsIs分析をされた上で、
短期目標の粒度まで分解して、そこに法律などの制約を踏まえて、
どの短期目標ToBeがもっともAsIsとギャップがあり、
組織の強みを生かせて、競合が強みとしていないか？といった分析をした上で、
「まずはこの短期目標ToBeから始めよう！」と決まった段階で初めて方針が決まります。
また実際に進む中で、あれ？いまの活動って方向違くない？ってことを
スプリントレビューの時などに定期的に振り替えることで、
方針から逸脱していないか？の検証を行うことが重要だし、
やっていく中でAsIsやToBeが変われば、当然方針ベクトルの大きさと向きも変わります。
主張
素早さ、継続的デリバリーという言葉をよく耳にするが、
結局はこのより本質に近い層の要求を明らかにしないことには、
永遠にコロコロ変わる目の前の課題解決に悩まされることになるし、
どこかで変化に取り残されて、使われないサービスになっていく。
そのため、素早さを出すには、まずは継続的により本質的な要求(深い要求)を
常にステークホルダーとの対話の中で自分たちで立てた仮説と照らし合わせながら検証するスタンスが求められる。
その際に要求は図のような階層レイヤーになっていることをイメージするとわかりやすい。
下位のよりWhyの層に行けば行くほど、より安定していて変化が遅くなる。
上部の表面的に明らかになりやすい層は顧客自身も言語化は容易だが、
深い層の本質的な願望である要求、つまりその人にとっての価値は、
視えない概念でしかなく、簡単に言語化なんてできるはずがない。
それに「こういったことを口にしたらダメそう、、、」という社内文化といった
制約によって、もっとも重要な要望を出さないケースなんかもあり得る。
用語の定義
要望
これは要求以前の顧客が「こうしてほしいです」「こんな機能ほしいです」
と言語化できるレベルのもの。
この時点では、複数様々な要望が出てきて、それらに一貫性はないし、
ここを実現しても顧客の価値を実現はできない。
要求
要望のリストをまとめたり、後述の帰納法や演繹法を使って蒸留作業を行った上で
明らかとなる顧客にとっての価値。
これは顧客自身が容易に言語化はできないし、目に視えるものではないため、
なぜ？というヒアリングをしつつ、蒸留作業をしながら仮説ベースで洞察しなくてはいけない。
この要求が明らかとなり、メンバーで具体的なイメージの認識が取れているほど
・方針は明確→判断軸が明確にあるので、何をやるべきで何をやらなくていいかが明確。
・どんな機能、データが必要かが明確。
・優先されるべき品質特性、優先しなくていい品質特性が明らか。
・具体的な指標の要件定義がしやすく、１回で要件定義できなくとも、
実験的に複数イテレーション回す中で具体的な指標は明確になりやすい。
なので、無駄な手戻りを最小限に抑えられる。
価値
人それぞれ用語の認識は違うが、ここではまず明確に定義しておく。
要求と価値は似て非なるものとしておく。
価値は下図のもっとも深いところ、要求のその先の最深部、
もっとも本質的な要求＝価値 とここでは定義する。
後述の帰納法や演繹を使って要求を炙りだし、
ステークホルダーと合意形成を得たとしても、この価値を実現できていなければ開発をする意味はないといえる。
ここを履き違えたシステムをどんなにアーキテクチャとか議論しても、
価値に紐づかないものはただのゴミになってしまうから。
仮説検証型アジャイルとの関係性
余談だが、市谷さんの仮説検証型アジャイルでは、
論点・仮説思考をベースにこの解く効果の高い実現すべき問い、
つまり前提となる論点を探索する活動と、
それをシステム開発などで実現すべきか？を詳細化しつつ作成したMVPで検証し、
解く意味はあまりないってことが分かれば、速やかに別の論点探索を行う
ということをイテレーティブに繰り返す。
この際に個人的には論点構造ツリー(別名イシューツリー)を作成することを推奨している。
時間は多少かかるかもだが、この最初のスタートでこけては無駄な手戻りが発生するので、
アジャイルだろうとウォータフォールだろうとやるべきである。
なすべきこと -帰納法・演繹法・アブダクション-
そこで要望の集合から、自分たちで顧客の置かれた状況などから
仮説ベースで抽象化していき、本質の層の要求を浮き彫りにする活動が求められる。
この際によく使われるのが、有名な「なぜなぜ」を5回繰り返せ、というやつである。
しかし、ただ単になぜを繰り返しても、本質要求にはたどり着けない。
そこで帰納法と演繹法を使った手法がもっとも体系的であり、かつミスの少ない深堀りが可能である。
慣れてくればこれは頭の中で暗算のようにやってもいいが、それまでは図式化するのが望ましい。
なぜなら、階層ごとに変化が起きるスピードが違うし、
どの層は組織内の文化の変化を受けるレイヤーなのか？とかが分かっていた方がいい。
最終的には１つの本質的要求に集約される形が望ましい。
帰納法を使って抽象化
複数の要望(要望リストABCとする)、
顧客が言語化できるもっとも表面的になっているものから１段階抽象化する。
この時WhyとWhatを関心分離できているかも常にチェック。
それによって概念化された２段目の要求もどきをXとする。
A、B、Cを抽象化したらX。XならA、B、Cも成り立つかの両方チェックをする。
成り立たないならうまく抽象化できていないってこと。
これと同じことをより深い層でも繰り返すことで、要求は集約される。
一番下のもっとも深層で求めている要求まで、初回からたどり着くことは難しくても、
せめて３回程度のなぜなぜ？は聞き出したうえで、より深い階層の要求を浮き彫りにする。
アブダクションで原因分析
これは当初の仮説が的中しようが、外れようが必ずやった方がいい。
たとえば上図でITの要求を叶えた先の業務要求が満たされているかのチェック。
(注 ここでいう【満たせている】とは要件化された誤差含めた指標に達しているか？で判定される。)
さらにその先の戦略要求が満たせているかのチェック。
満たせていれば仮説は正しかったと言えるので、この価値の因果関係は一旦正しい。
(この環境など含んだ背景下において正しいってだけ)
満たせていなかったら、要求分析ツリーの因果関係の仮説は間違っていたということが分かるので、
別の実現手段をレイヤーごとに考える。
ただしこの際、仮説をたててから前提条件が変わらないうちに素早く検証すること。
前提条件などが変わると、要求分析ツリーの結果も変わり、
因果関係も要求の指標も変わってしまうから。
なので、指標に達していようが達していなかろうが、
こういう前提条件下でこの要求を実現すると→上位レイヤーの要求が実現される。
因果関係は成り立つが指標に達していないため、別の手段の要求を探す って考える。
演繹法を使って随時前提の妥当性チェック
上記の帰納法で明らかにした要求X。
ここに新しい要望が追加で来たとする。
この時、その新しい要望は 前提となっている要求Xに従っているか？を検証する。
(SOLID設計原則のリスコフの置換原則を満たしているか？のチェックのようなもの)
この時、以下の２パターンで取るべき行動が変わる。
前提に従っていた場合
今の時点ではその前提である要求Xが前提として正しいといえるため、
置かれている環境とかは変わっていないか？のヒアリングチェックだけで充分。
ただ、その変化の兆候くらいは把握しておいた方が、ステークホルダーマネジメントが楽。
前提に従っていなかった場合
上図のように前提に従っていなかった場合、
まずは「それって本当に必要なんですか？」って質問返してみる。
もしも「AもBもCも新しい要望も全部同じくらい必要です」と返ってきたり、
ヒアリングする中で新しい要望の方が重要そうな返答であれば、
さっきまでの前提条件であった要求Xではなく、
別の前提条件となるものをなぜ？と抽象化して探さないといけない。
そうやってでてきたものを図のように要求Yと名付ける。
ここですぐやってはいけないのは、すぐに要求XとYを実現しようとすること。
そうではなく一回さらになぜ？と抽象化し、
要求XやYのさらに上位概念要求である、より本質層に近い要求を炙りだす。
参考にしてほしい考え方や書籍
個人的に思考のベースとして大規模エンタープライズや、ウェブ関係なく
以下の考え方を取り入れながら状況に応じて守破離してほしいと考えている。
推論の技法
https://amzn.asia/d/8JaR9zW
この書籍に上記で扱っている
・帰納法(起きた事実から一般法則を抽出)
・演繹法(前提の法則に当てはめて未来を予測)
・アブダクション(起きた現象の原因メカニズムの解析)
の３つとそれらを関連付けた題材も交えた解説が詳しく載っているので、
興味のある方は読んでみてください。
匠メソッド
これは価値デザインや価値分析モデルを作成した上で、要求トレーサビリティマップを作成し、
どの要求を実現すればもっとも最小限の労力で最大限の価値実現効果を発揮できるか？
このステークホルダーの要求を実現しても
を議論するうえで非常に役立つフレームワークのようなものである。
わたしはこれを独自に守破離して、クリティカルシンキングを使い、
その価値は同じ組織内の他の人にとって逆に嬉しくないことでは？という
真逆の観点からの考察も交えるようにしている。
詳細は別記事で記載するが、ここで具体的な価値のストーリーを考えておくと、
シナリオベースやどんなMVP作成すべきか？や
価値の粒度(昨日の単位ではなく価値の単位)が明確になりやすいので、
クリティカル・ラテラルシンキングとセットで学習した方がいいと考えている。
仮説検証型アジャイル
一回の議論で一番深い所の要求つまり価値を探索する活動が開発の前にある。
これは仮説ベースで論点を整理し、その論点は本当に論点(解く意味があるのか？)
をMVPなどを作成した上で検証するってことをしていく。
当然これはシステムを開発することが目的ではない。
あくまでも価値の探索をするために、検証目的で最小限のシステムなどを創る。
さらに何が正解なのかが不明だったり、前代未聞なことをやるDX系プロジェクトでは、
価値探索を続ける中で「これでもない。これも違うか。」っていう
正解でない軌跡(下図で言う黄色領域)を明らかにしつつ、
その領域以外のもの(ピンクの領域)が正解だよねって探し当てる。
その際に思考の基盤として、
・仮説思考＆論点思考
・クリティカル、ラテラル、ロジカルシンキング
を用いつつ、上の匠メソッドで価値モデルをステークホルダーと一緒に作成し、
定期的にメンテを入れていくことが重要だと考えている。
注意事項
この価値モデルのメンテは、たとえば繰り返す検証の中で、
この価値は優先的に向き合うべきだ！ それこそが論点だ！って思っても、
ステークホルダーの関心の強さや権限の強さ、置かれている立場や、
組織文化の変化、組織外部環境の変化といった力学によって時間経過で変化するからである。
詳細は長くなるので別の記事に記載するが、この際の思考として、
コンポーネントの凝集原則を土台として考えるようにすることをオススメする。
気を付けるべきポイント
要求の変更が起きた際に、必ずやってほしいことがある。
それは要求の変化に伴い、ステークホルダーの関心の強さ、権限の強さ、
置かれている前提条件の変化などの目に視えないものを踏まえて、
価値モデルや要求トレーサビリティ図をメンテしてほしいってこと。
よくこれはPMさんがやっているステークホルダーマネジメントていうものである。
以下にわかりやすい動画を貼っておくので参考にしてください。
https://youtu.be/ZIP5LJGD-UQ?si=-UY0f7nhSpRCAiB9
https://youtu.be/hxlb3st-0e8?si=i7hmVXbHaPtyNWOQ
気を付けていても人間は忘れてしまう生き物なので、
わたしはADRの考え方と同じようにIDRを残すことを推奨しています。
それと共に方針のメンテをして判断軸の更新をするわけです。
IDR(イシューデシジョンレコード)
早い話が、何をいま論点として考えるべきなのか？を残すってことです。
過去、論点として向き合ってきたものがいま論点である保証はないです。
なぜいまそれを論点とするのか？といった背景や経緯
たとえば文化の変化や外部環境変化、といった内外要因含めて視える化し、
上記の匠メソッド用いた価値モデルを根拠として
論点定義の理由を明示することで、方針ベクトルを明確にメンテするためです。
方針は全ての判断軸のもととなっているし、すぐ暗黙化されてしまいがちなので、
論点の変更と同時にすぐに更新し、共有できるようにしましょう。
つまり、論点が変更されて方針が更新されたら、
「昨日まではその活動は意味のあるものだったけども、いまは方針が変わったからあまり意味のないものです。」ってことが起きます。
でもって、変化が遅いor変化に順応できない人々の特性として、
一度定義された方針ベクトルが変わっても、今までの成功体験
「この活動をしていて結果が出たもん！！」っていう経験にしがみつき続け、
全く方針からかけ離れたことをやっているってことをしがちです。
IDR & ADRをアナロジー展開
またこのIDRに関しては、他のプロダクトにもアナロジー展開することで、
似たような外部環境下において何を論点として定義したけどあまり意味がなかった。
とか、勝ちパターン的なものがあったらそれを実験的に打ち出したうえで、
当たれば最小限コストで実現できたことになるし、
当たらなくても効果検証を分析データを元にしてみるなんてことをすることで原因分析
することで次に生かせると考えられます。
似たような環境下で、また同じようなアーキテクチャ案の議論をしても
組織にすでにナレッジとしてあるものを再発明するだけ時間の無駄です。
過去の知見をもとに再検討するか、よりブラッシュアップした方が
もっとコストカットできる部分が増えて開発生産性も向上します。