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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

それ、scrumでやらないんですか

色々と話を聞く機会があると、システム開発でどのような手法を取っているかを尋ねることがある。エンタメの業種で何人かのエンジニアの方にシステム開発手法を聞いてみたら以外な答えが返ってきた。

会話をするまでは、エンタメの界隈ではアジャイル開発の手法ばかりなのだと思っていた。これは1つの思い込みなのであるが、その思い込みは話を聞けば『あーそういうことか』と腹落ちするのである。

観測範囲で言えば、エンタメの開発は思った以上に、半分はウォーターフォールで開発している。残りの半分は、scrumとウォーターフォールのいいとこ取り、残りがscrumだった。

どうだろう、全く逆ならイメージ通りなのだが、そうではない。

それでなぜウォーターフォールなのかを尋ねると、リリースサイクルを決めている。それに合わせてイベントを仕掛けるとしても、スコープは決まっているからscrumを選ぶ理由がない、と。

なるほど、である。

スコープが決まっているなら開発テーマは全部スケジュールに収めることになるからscrumを選ぶ理由も必然性もない。

逆に、スコープが決まっているなら、労働集約で生産性をあげられる（はず）の理屈も付いてくる。

まあ、それはさておき、業界の外から見ている時の思い込み、バイアスは中の事情を想像しようともしないという学びでもある。

外野からあれこれと妄想するよりは、中の人にどうやっているのかを聞く方が早いという典型である。

なお、技術的にはCIやCDをやっているので古典的な人海戦術のウォーターフォールではないが、バックログはやっぱりexcelですね、というところは面白い。

ポケットモンスター Let's Go! イーブイ モンスターボール Plusセット- Switch (【Amazon.co.jp限定】オリジナルタンブラー320ml(イーブイVer.) 同梱)

エンジニアが業績評定を自己評価できるチートシート

12月が期末の組織ではそろそろ、業績評定の季節に入るだろう。3月が期末の組織でも残りは半年をきっている。改めて、2018年の自分の業績を自分で点検して良い時期である。

そこで、エンジニアが自身で客観的な業績評定を可能とするチートシートを公開する。利用については、以下を一読いただき倣って欲しい。個人が個人のために使う分には何も制限がないと思っていただいて構わない。

ライセンス

エンジニアが自身の自己評定で使う分には、自由に使用できる。他へ掲載等する場合は、出典されたい。

万が一、組織の人事部や人材開発担当部門が利用される場合は、個別に連絡いただくことを前提とする。

使用方法

目標…（今年度の）目標を記入する。

エビデンス…目標達成を第三者が確認できる確証を記入する。

出来るようになったスキル…（今年度に）新たにできるようになったスキルを記入する。

目標以外で出来るようになったスキル…（今年度の）目標以外で新たに出来るようになったスキルをここに移す。

経験知として得たスキル…出来るようになったが、エビデンスのない目標をここに移す。

持っているスキルでの成果…目標で成果を第三者が確認できる確証があるが、目標設定時点で持っているスキルで達成した成果をここに移す。

達成した目標…目標若しくは目標以外で、出来るようになったスキルで且つ第三者が成果を確認できる確証がある成果をここに移す。

みなさんの成果確認と使用した感想を教えていただけるととても嬉しい。

NEVER SURRENDER(※劇場版アニメ「魔法少女リリカルなのは Detonation」主題歌)

とにかく楽しい仕事

今ちょっと、『とにかく楽しい仕事』をやっている。趣味と実益を兼ねているとか成功報酬があるとかではない。貰うものは何も変わらないし、仕事を変わったわけでもない。
その『とにかく楽しい仕事』も初めから『楽しい』というわけではなかった。突如、気づきがあって『とにかく楽しい』に格上げとなった。

このような経験は、実は以前にしていて、それはPMPを取ろうと決めたときに体験している。それの2回目である。ただ、今回は、何か資格を取ろうということではないところが違う。

それではどうして『とにかく楽しい仕事』になったのか。

今やっている仕事のタスクの進め方や得られる経験知が、他で役に立つ度合いが違うと気づいたからだ。気づいたらどう変わるというと、このタスクで得られる経験知を最大化しようと企むわけである。

自分の能力として、再現できるように、ただやりましたではなく、あーそれできますよと言えるようにしておこうと。

専門家として。

自分は、もともと仕事に対して入れ込みとか思い入れとかをしないタイプである。心理的には、仕事は組織のもので、自分のものではないという考えによる。だから、仕事での生産物は、率先して、共有できるようにしておく。

自分で体験し、経験知として得たものは、自分のアセットである。そのアセットも、必要とされればいくらでも見せる。

ただ、そうしたアセットの作り出すマインドや技術は、教えようにも教えられない。その人自身の性質に深く根ざす。個人によりセンサーが反応する対象と感度が違うということだ。

それはともかく、『とにかく楽しい仕事』だと認識した瞬間、とても楽しくで仕方がないのである。

仕事は楽しいかね？ (きこ書房)

仕事は楽しいかね？２

課題管理をしなかった話

プロジェクトに関わらず、仕事をしていれば進捗上の障害が大なり小なり発生する。進捗上の障害と認識するのは、段取りや手順で想定していたことと違うことを事象として捉えたからである。

多くの場合は、そうした進捗上の課題を認識するが、わざわざ課題を管理しようとしない。個々の裁量の中で取り扱う。

一人で行なっている仕事であり、後続工程がなければそうした課題を放置していてもなんら影響はしないため、しばしば放置される。

後続工程があったり、複数の人員で作業を行い、その課題が他者に影響する場合は、課題管理と称して管理表やチケットに記録し、課題解決までトレースされる。

プロジェクトマネジメントにおいて、プロジェクトを成功させるためのテクニカルで不可欠な要素に『課題ログ』が挙げられている。

調査によると、有能なプロジェクト・マネジャーが一貫して示すいくつかの重要なスキルには 次が含まれるが、これらに限定されるものではない。 ●自らがマネジメントする各プロジェクトのためのテクニカル・プロジェ
不可欠な要素に焦点を当てる。このことは、容易に入手できる適正な生成物を確保するのと 同じくらいシンプルである。このリストの上位にあるのは次のとおりである。

■プロジェクトの重要成功要因

■スケジュール

■ 選択された財務報告書

■課題ログ

引用　PMBOK 6th

プロジェクトであるから、複数人数のプロジェクトチームでの活動を前提として、ステークホルダも考慮して課題はログとして管理することの重要性を記しているのだろう。

実際の現場でも、QCDSで何かしら失敗しているプロジェクトやオンゴーイングなプロジェクトでおかしい状態になっているプロジェクトでは、しばしば課題管理がなされていないか放置されていることが多い。

複数の事象とプラクティスからは課題管理をしなくても良いとは到底言えない。

あるプロジェクトは短期で関係者が多いものだった。コンサルタントを入れ、コンサルタントチームとしては課題管理をしていた。一方、エンドユーザのPMの立場では課題をすることのリソースを確保することが難しい状態だった。

それで、どうしたか。

課題にしないことにした。全て、ToDoとして振り分けることにした。

どういうことかというと、課題になる前に、作業計画として振り、計画どおりに進めた。コンサルチームとして認識する課題はほぼコンサルの課題である。

エンドユーザ側のPMとしては、関係者が分担する作業は次回か次回の前の指定日までに対応するように指示することにした。その際に、実現可能なスケジュールであるかと最遅日を押さえ、その前には片付くように促した。

あとは対応を待つだけである。もちろん、指定日までに別件で会う機会があれば、進捗を尋ね、裏を押さえる手間を掛けるだけでほぼ確実に進捗するのである。

大したことではない。

少しの手間をかけることで、課題管理の作業を無くしただけである。まあ、これも関係者が全て同じ方向を向いて要られたからできたことではある。

Yogibo Traybo (ライムグリーン)

実行できる形式知を持っていることを証明する事例：クリティカル・シンキング

専門家として形式知を保持していることを第三者が評価するには実績で十分だと思われがちだが、第三者の立場で評価しようとすると実績は結果であって、その結果に至る中で、どの形式知を適用したかは説明されないと評価に至ることができない。

よって、申請や口頭試問でそれを問うことでエビデンスを確保することになる。

プロジェクトマネジメント の専門家としてPMPを持っているからと言って、その形式知を適用しているか、それとも経験から得た個人の暗黙知を使っているかは外見からは判断できない。

斜に構えて見れば、実績があるのであれば、どちらであったとしても大勢に影響はない。ただ第三者の立場としてエンジニアの能力を推し量るのであれば、どのような場合に置かれたとしても保持する能力を発揮して期待する結果を得られるとして評価したい。

知識を活用する事例

クリティカル・シンキング

クリティカル・シンキングとは

あらゆる物事の問題を特定して、適切に分析することによって最適解に辿り着くための思考方法である。

引用　批判的思考 - Wikipedia

適用事例

例えば、グループ会社共通の新規業務を策定する際に、共通となる業務の根拠となる規程を策定し準じる必要がある。

なぜ規程が必要かというと、主体の違う事業体に対して、同一の規程を遵守しなければならない義務を課すためである。

最初に取り掛かることは、新規業務の策定について義務化することを各グループ会社の責任者により合意しておくことである。

それを踏まえ、グループ会社として権限を持つ担当者を選出させ、合議形式で新規業務の策定に取り掛かる。

新規業務の検討を始めると、具体的な業務が詳細化され、現実感が増すことにより、各社の担当者はリアリティを持ち始める。

ここまで到達するとこれまでグループ会社共通の新規業務の共通化に賛成していたはずの担当者は、各社の意思決定プロセスを持ち出し、個別事情を取り込むことを要求し始める。

こうした状態全てが『問題』である。

共通の業務を規程に織り込むためには、個別事情を取り込んでは各社の合意形成には至ることは難しい。また、取り込み始めるとケースが増え、規程を適用する各社で混乱が生じるなど規程の履行に対する不確実性が高まる。

よって、共通の業務の規程では、どのグループ会社においても同一に適用可能な構成とする。グループ会社の意見を明示することが問題の特定にあたり、モデリング化する試みが分析に相当する。

グループ会社共通業務を目的に制定された規程は、クリティカル・シンキングを適用することで、規程制定に掛かる問題の特定と分析を行うことで得られた最適解である。

世界一やさしい問題解決の授業―自分で考え、行動する力が身につく

改訂3版 グロービスMBAクリティカル・シンキング (グロービスMBAシリーズ)

ストーリーを語れるエンジニアでなければPMになれない

一兵卒のエンジニアからプロジェクトマネージャ（PM）やプロダクトマネージャ（PdM）になれるかどうかの条件にプロジェクトをスタートするにあたり、その

『プロジェクトのストーリーを語れるか』

 という条件がある。条件というよりは、これから始まるプロジェクトが終わるまでのライフサイクルで起きる様々なできことに纏わる設定を含め、語ることができるかが問われる。

プロジェクトのストーリーを語るとはどういうことか。

1つは、プロジェクトを完了させる＝成果物とそれを補完する中間生産物や成果物でないプロジェクトチーム向けの補足資料をつなぎ合わせることができるということである。

契約に記載の成果物だけ作ればいいと思っているのは甚だ間違いである。それでできるというPMがいたらそれは、成果物に対して記載するコンテンツをクリープさせているだけではない。本来成果物に入れる必要のない内部資料まで成果物としてしまうことで、内部資料に当たる資料に瑕疵担保責任を広げるというリスキーなことをやっているのである。

2つ目は、プロジェクトの特性を把握して、適切な工程や開発サイクルに分割できなければならない。プロジェクトを一本槍の、一気通貫でやるということは、ある意味ビックバンプロジェクトのようなものである。全部ができてから、これが欲しいのかと初めて顧客に尋ねて正解を得られなければどうなるかは想像に難くない。

プロジェクトの不確実性が高いとか不確実性のコーンの図を出すまでもなく、設計自体が仮説なのであることを認識しているかどうかPMやPdM自身が暗黙に問われているに過ぎない。

仮説を検証するためには早々に実装することが唯一の手段であるから、それを実現する計画が必要なのである。超大型のプロジェクトであればあるほど、期間が長ければ長くなるほど、頭出しの局面でToBeを実体験させることを企てる必要がある。

これも、ストーリーを語るという文脈なのである。

あなたはストーリーを語れるエンジニアだろうか。

東京ラブストーリー 文庫版 コミック 全3巻完結セット (小学館文庫)

プロフェッショナルは「ストーリー」で伝える