LoginSignup
1
1

背景の視える化

Last updated at Posted at 2023-12-26

背景

要求定義の際のシステム化のための本当の目的を明らかにする際、
その目的の出てきた経緯とかは暗黙知化されやすい。
また「だったらこの方法ですぐに解決できそうじゃん」っていう解がすぐに浮かんでも、
組織的な文化や内部圧力といった目に視えない要因によって、
できると思っていた選択肢が全然妥当でないなんてことがある。

その組織内の圧力含めた背景が浮き彫りになった上で、
「こんな経緯があって、だからこんな理想像を思い浮かべました。」
というように、背景+目的のセットでないと、
最上位の目的を見失い、方針がブレブレになりやすいと感じている。

しかしながら、この背景は文章でタラタラ述べられても記憶に定着しにくい。

目的

要求定義の際の、トップ目的をみなが一様に具体的にイメージしやすくするために
背景をモデルで視える化することをこの記事の目的とする。
前提となる5W1Hや帰納法・演繹法などの詳細には触れない。

やることは視える化

モデル図を使って、背景の軌跡を視える化し共有することで、
たとえ途中で方針が変更されようとも、今までにどんな経緯があって、
その上でなぜ目的が途中で変わったのか?といったことが暗黙知化されにくい。

因果関係と前提

物事の現象は、原因があって結果がある。
この前提のもとに背景のモデル化を進めていく。
この時、アブダクションという原因メカニズムを仮説ベースで類推する手法を用いる。
さらにその仮説の検証のために演繹法を用いる。
そのためアブダクション・演繹法を前提知識としてこの後の記事は続く。
また、あるイベントの原因になった直前のイベント、というようにイベントで背景の軌跡を表現する。

5W1Hで視えるか化

スクリーンショット (299).png (70.3 kB)

5W1Hまたは、状況に応じて6W2Hで各要素を分割して
中央の起きたイベントであるコトに結びつける。
(この時、そのコトが起きた際に、値段とかが組織内で関心ではない要素であるなら、
この時点で削ってしまってOK。
ただし、そのコトに対して【誰が何をした】など重要で関心のある要素は必ず残す!)

この時、各要素はそれぞれ点要素であるのに対して、
【なぜ?】だけは点では表せられない、線としてでしか表せられない要素である。
それをこの後の平面図で表現する。

原因→結果というように視える化

スクリーンショット (298).png (208.3 kB)

今もの前で起きた現象であるイベントと、
その原因となった直前のイベントとの因果関係モデルを作成する。
この因果関係は経験則であったり、絶対的な解ではないため、
あくまでもアブダクション手法を用いて、
「この現象が起きた理由は、あのイベントがもっとも理由として大きいと考えられる。」という仮説をベースに作成する。
ただし、実際に正しい因果関係モデルか?は検証してみて妥当性の確認を要する。

その際には、すでにある因果関係法則を一旦正しいと仮定を置き、
別の似たような事例で当てはめて検証する演繹法でチェックする。

上記を繰り返す

スクリーンショット (300).png (231.6 kB)

このようにあるイベントが原因としてあったから、結果に相当するイベントが起きた
というWhyの軌跡をモデルとして視える化することで、
最上位の目的ビジョンがより骨格をハッキリとさせてくれる。

この理屈は是非ともADRの運用にも役立ててほしいと感じています。
一度定義したアーキテクチャを次のリアーキテクティング活動というイベントをする際に、
どのような理由があって、どのように変えるか?という意思決定の記録として
残すわけだから、当然過去に議論したようなアーキテクチャ決定のメカニズムを
再度議論するのは車輪の再発明をして時間を浪費してしまっている。

付加価値

これによって以下のことも浮き彫りにしやすいと感じる。
たとえば「なんかいっつも同じようなことに悩まされるな」ということないだろうか?
その勘は結構当たっていて、同じような悩みの事例が繰り返される。
つまりは、根本原因はいまだに解決されていないっていうことを知らせてくれている。

そんな時はちょっと面倒に感じても、上記の因果関係モデルを作成してみてほしい。

複数の事例として同じような軌跡を辿っている現象にぶち当たり続けていることが分かると思う。
(またそれを素早く気付くためにも、日ごろから起きたイベント同士の因果関係モデルを作成する文化があると望ましいかもしれないですね。)

イベントA→イベントBという因果関係の事例を事例①とします。
イベントX→イベントYという因果関係の事例を事例②とします。
イベントM→イベントNという因果関係の事例を事例③とします。
複数の事例をもとにそれらの1つ1つの現象を個別具体でみると異なる事例だけども、
共通法則を浮き彫りにするために帰納法で抽象化してみると、
どういった真因が潜んでいて、それがまだ解決されていないから、
何度も同じようなことが再発するのでは?という推測がきっと考察しやすくなります。
共通法則.png (12.2 kB)

こういった目に視えない現象メカニズムを明らかにせず、
何でもシステム化することが目的となっているとプロジェクトは失敗しやすいですね。

生産性が落ちているなと感じる際の、組織文化の再検討の時とかに必ず必須の考え方と感じますので、
規模の大きな組織になるほど、この背景の視える化を徹底してほしいなと感じています。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1