スキルを第三者に理解させるためにFearless Changeのパターンを使う

エンジニアは、第三者に技法や方法論などの知識を持ち、実務で適用できることを証明を求められることがある。例えば、組織内での認定の口頭試問や昇進試験などである。

そういった機会では、ただ案件であれをやった、これをやったと書いてもそれは事象だけで、エンジニア本人の実力で出来たかどうかは判別しにくく、結果、疑義がつけられリジェクトされてしまう。

そうした状況での証明方法として、パターンの構成を流用する方法が考えられる。

Fearless ChangeのP15〜16では、次のように構成について記載している。

• はじめに
• 要約
• 状況
• 問題
• フォース
• 解決方法
• 結果状況
• 使用例

この構成をこのまま使うかどうかは諮問の要求に応じてテーラリングすればよい。少なくとも、『はじめに』はパターンの紹介であり、『要約』はパターンの概要であるから諮問の対策とするのであれば不要である。同じように『状況』もパターンを適用する当事者の置かれた環境下を指す。口頭試問を受けるエンジニアの置かれた立場であるから、自己の置かれた環境下を言語化するのであれば書けば良いがスキップする。

『問題』は、第三者に対して技法を持っていることをストーリを持って状況を伝えるための場面設定である。ここでこの後、方法論を適用したと証明するために伏線を張っておく。

ここの『問題』で張る伏線は、1つにしておくこと。複数の方法論を語りたい場合は、事例自体を分けること。

『フォース』では、問題に対して適用した方法論を明示する。プロジェクトマネジメント 、PMBOKのクリティカル・シンキングであれば、それを適用した、と表明する。

『フォース』でも、適用した方法論は1つにしておくこと。1つの問題に対し、1つのフォースとしておく。

『解決方法』では、『問題』に対してどのように『フォース』を適用したかを書く。『問題』の場面で『フォース』を適用するわけだが、効果的に受け止められるように書く。

『問題』の置かれた状況に対して、

1. 問題を特定し、
2. 適切に分析し、
3. 最適解に辿り着く

手順を踏むことを示す必要がある。『問題』の中から真の問題を見つけ出し、問題の原因の分析を行い、いくつか考えられる解決方法の選択肢の中から最適解を選び出した、とシナリオを紡ぐ。

『結果状況』では、『問題』に対して適用した『フォース』の結果を書く。口頭試問に対する説明であるから、期待する結果を得られている必要がある。

『使用例』は、パターンでは事例である。その意味では、『解決方法』ではなく、『使用例』で口頭試問で説明するストーリを書くと収まりは良い。ただ、順序的な意味合いを優先して上記の紐付けとしている。

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン