読者です 読者をやめる 読者になる 読者になる

hiroktsのブログ

IT開発系の勉強会の感想とか雑記とか

「Whyの依存関係を明確にすることにフォーカスした質問」をどう活用するか?

暗黙知になっていること、とくにタスクや課題の依存関係などを明快にするには質問を「いい感じに考えるべきポイントにフォーカスして」繰り返すといいなと最近思っています。
というのもそういう質問の仕方がうまい人が同僚に入ったからなのですが。

『考えるときには考えるべきポイントを間違えないことが大事だ』

俺ガイル2期で平塚先生が何回もおっしゃっています。いや、何回も言ってるんじゃなくて何回も見てるんだった。

会社なら会社としてのビジョン、ミッションというのがまずあるはず。
ビジョン、ミッションにより近い質問からブレイクダウンしていく。

「プロジェクトのこの作業はこのミッションに貢献しているからやっているのですか?」

ということに答えるために、なぜなぜ分析っぽく

「会社の目標は何か?」
「会社のミッションは何か?」
「IT部門として成し遂げたいミッションは何か?」
「利益向上、コスト削減、リードタイム短縮のために作りたいインフラ基盤・アプリケーション開発基盤は何か?」
「なぜこのプロジェクトをやるのか?」

という依存関係のわかる化につなげていきます。
ハイコンテキストからローコンテキストへ置き換える作業でもあると思います。

で、その場で質問とその答えを聞いた人はわかるんだけど、それだけじゃなくて見える化したい。

そうすることで「ぶれないマニフェストをサジェスチョン」(※俺ガイル2期の意識高い系会議より)することが可能になると思うのです。

『「Whyの依存関係を明確にすることにフォーカスした質問」をどう構造化するか?』

前回参加したDevLove関西のイベントの情報設計の話ともつながると思います。

f:id:hirokts:20160403150616p:plain

やり方自体はツリー構造でいいんじゃ、ってことなのですが。
メンバーだけで通じる暗黙知、ハイコンテキストを少なくし、周囲の人(ステークホルダー)に、常に見える状態にして『透明性』を出したいです。

その上で「本当に透明になっているか?正しいか?」ということを『検証』できる状態にしたいです。
さらには検証した結果を常に改善、『適応』できるようにしたいです。
それも楽に。

『ぶれないマニフェストをサジェスチョン』

Whyを共有できてないことに起因する本当に無駄な会議をしたくない。
やるべきことにフォーカスして仕事していきたいものです。