色んな書籍で振り返りは大切，と記載されていたので，いや，言うまでもなく大切なので，ここにまとめていきます．
同僚がPDCAを回しまくっていることに気付いて焦燥感を感じたのも理由
良いこと
タスク分割法と時間分割法
タスク分割法：優先度を決定し，タスクごとに順次処理していく実施方法
時間分割法：各プロジェクトごとに一定の時間を割り当て，順次処理していく実施形式
タスク分割法が優先度と工数を鑑みて処理していくのに対して，時間分割法は時間を割り当てたプロジェクト内の優先度が高いタスクから処理します．
それぞれの手法を試してみましたが，自分はどちらかというと時間分割法のほうが仕事を進めやすかったと感じました．
おそらく抱えているプロジェクトの数で分岐点が存在します．抱えているプロジェクトが1個であれば，タスク分割法と時間分割法に差はありません．1-2個でもタスク分割法の方が的確に優先度の高いタスクから処理できるのでいいでしょう．
しかし3個以上となった場合，時間分割法を取り入れることも視野に入ります．理由はプロジェクト間の脳のスイッチコストが大きいためです．
例えば，
プロジェクトA: task1 (優先度１)，taks2(優先度3)
プロジェクトB: taks3 (優先度２)
のようにタスクが存在した場合，安直なタスク分割法ではプロジェクトA -> B -> Aとプロジェクトを行き来します．ましてやtask1,2に関連性があった場合には悲惨です．Bのtask3を実施している間にAのtask1で培った経験が頭の奥に収納され，task2に取り組む頃にはまた引っ張り出してこないといけません．
これがプロジェクトを3個以上持つと頻繁に発生します．確かに優先度・納期的にはプロジェクトを渡ることが正解ですが，脳のスイッチコストを考慮するとある程度まとめて処理してしまった方が楽なのです．
かといってプロジェクトが同一だからといって優先度の低いタスクを全て実施するわけにはいきませんので，区切りのいい時間で分割します．
まだ答えは出ていませんが，3時間程度がベストな気がしています．始業が8:30なので，12:00からの休みで丁度タイミングがいいことと，3時間以上一つのプロジェクトを続けた場合集中が持続できないことが理由ですね
有識者をぶつける
会議に出席しているこちらのメンバー全員が有識者ではなく，相手の問い合わせに即座に答えることもできず，自分がただ単に仲介役になっている場合，少なくとも一度は自メンバーに有識者を召喚すべき．
これは早ければ早い方がいいです
有識者の意見自体は事前に自メンバーに共有し，こちら側の総意としておくことが重要です．有識者の意見がこちらの思惑と異なる場合，予め擦り合わせておきます．
その後，極力早く相手方と有識者を引き合わせます．正直，有識者の方は忙しいし他部門の方と余計にハードルがあがり，切羽詰まるまで依頼を我慢することもあるかと思いますが，正確な方針を立てるために可能な限り早いタイミングで実施すべきです．
有識者にはしっかり感謝を伝えるのも大事です．もし怒られても，そうしないとプロジェクトが正しく進まない旨を伝えて説得，あるいは，上司から依頼してもらう形を取るのがベター．
正直，自分が有識者でないのにうんうん悩むのは最も無駄な時間．有識者に聞けば3秒で終わります．
物事を判断する際に優先軸を決める
業務では当たり前ですが，複数の要素が絡み合い，何も考えずに優先度付けを実施すると，どの事項も大切に見えて取捨選択ができません．
この際に関係者へのアカウンタビリティを確保するために，優先軸を1，２個決定するといいです．失敗した時も明確な原因分析ができます．
最も悪手なのは何となく決めた場合で，学びが得られません．ただ仕事を進めているだけなのでやめるべきです．
振れらたタスクに少しだけ先に手を付ける
多忙な際に，更にタスクを振られる，あるいは既存のタスクに関連して発生してしまうことがあります．そういった場合は後回しにせずに，まずは10分だけでも手を付けてしまうのがいいです．
タスクの難易度把握，必要な情報の過不足をその際にチェックすることで，作業工数の見積もり・作業を始めたい時に必要な情報収集を実施できます．
また，未知のタスクが残っているという精神的な不安からも解消され，頭の中が整理されます．特に作業の妨げとなることが多いのは，つい別のタスクが気になってしまうということが多々あるかと思いますが，そのタスクの不明点，アンハンドルな点を洗い出すことでその頻度を下げることができます．
個人的にもこの手法は結果的にタスクを素早く解消することに役立っている経験があります．
初動を再確認する
何かしらの作業当日には関係者でその日一日のスケジュールを確認します。これは勿論実施されることだとは思いますが、いざ行動に移そうと思ったら初動を忘れてしまった・・、ということは複数人いたら必ず1名は存在します。そのため、必ず解散する前に初動を確認してスムーズな動きとなるように配慮することがベターです
先輩を見ていて有能に感じる場面は業務の漏れのなさですが、それは意図を確認して必要な事項を確認しているからです。一面的ではなく、多面的に物事を捉えた方が精度が上がるのは言うまでもない。
と言われた場合、Aに必要な最低限のタスクを洗い出すことができますが、それらのタスクが必要十分なのか確認するには再度相手に確認しなければなりません。その場で聞いてくれたらいいのに・・と相手は感じてしまうことは必至なので、予め何のためにAを実施するのか確認するのが大切です。
再現性のない成功に意味はない
なぜ成功したのか、を分析的に明らかにすべきである。結果的に成功したからといって、それはあなたの実力にはつながらない。なぜ成功したのかを把握し、それをチームに還元できてこそ成長につながる
タスク間の依存性を明確化する
あるタスクがどのタスクに依存するのかを明確化することが大切です。例えば、あるタスクの遅れが発生したときに、そのタスクの遅れとは何に影響が波及するのか？を検討する際に、予めタスク間の依存性が分かっていれば、そのタスクAが遅れることでタスクBが遅れ、それがクリティカルパスであるならばプロジェクト完成見積はこの時期になるという見積もりを、すなわち、影響範囲を特定することができます。
特に、マネジメントサイドの方にとってこの情報は非常に重要です。もしそれがプロジェクト全体に影響を与えるような遅滞であるならばマネージャーに相談すべき事項です
仮説、ストーリーを立てて話す
PDCAの根幹を成す事項ですが、現段階で分かっている事実から、仮説を立てます。この仮説でもってストーリーを決定します。どのように分かりきった事実とストーリーであっても、言語化して文章として記載することをマストととします。こうすることによって、事実と仮説との間の矛盾に気づくことができ、矛盾がなければ自信をもって現段階でのストーリーとしてマネージャーに説明することが可能です。
その時点で仮説が合っているかどうかの確証性はどうでもいいのです。なぜならその時点で判明している事実から導き出した仮説がそれであるのならば、その時点でのベストエフォートだからです。
後は仮説の確証性を高めるために必要なタスクと、現時点での確度を表現できていればOKです
仮説を立てて調査を実施する
実地調査を行う際にも、漠然と”Aの事項について調査する”とするよりも、”Aという事項について、現時点で我々はBと想定しており、結果はCであった”というストーリーを予め意識して、仮説Cを立てることが大事です。予め仮説を立てることでAに対する脳内知識が整理され、現地でAを調査した際に、仮説と合致する・合致しない、合致しない場合にはなぜなのか、を瞬発的に判断することが可能です。より有意義な実地調査とするためにも、予め仮説を立てて臨みましょう
プロジェクト全体として累乗的に効果を発揮するタスクは予め実施すべき
・ナレッジベースの作成
・開発管理体制
・タスク管理体制
・その他、プロジェクト全体で共通的に利用し、全員が共通実施するもの
上記のようなものについては、プロジェクトの早い段階で実施すべきです。というよりこれらの体制構築を完了しないうちに、プロジェクトが開始すると進捗が明らかに悪くなります。あるべきもの、するべきことを当たり前の順序で実施できるように努めることがプロジェクトマネジメントです。
悪いこと
話さない
話さないことほど勿体ないことはないと思います．意識の定着なり，コネクションの確立なり．せっかく立ち合いの会議の場に行ったのに，交流を図らなかったり．
性格的な問題ですが，社会人として働いている以上個人の性格などおいておいて，特攻すべきでしょう．
見込みを立てない
長期出張から帰ってきた後や見込みが立ちにくい場合に，自分が抱えているタスク・計画を見直さないことがあります．つい積まれたタスクを闇雲に解消することに目が向いてしまい，整理が後回しになってしまうことがありますが，これは悪手です．
知らない間にタスクがスケジュールにどう足掻いてもマッチしない状態になっていては手遅れです．そうなりかけた段階で関連する人と相談するのが社会人としてのあるべき姿です．
会議の着地点を想定する
会議の着地点を予め規定しておくことが大事です。
ただし、特に
- トレードオフな関係
- あるべき将来像が曖昧
である議題については、最終結論を得るためのハンドリングが難しいです。特にマネージャーサイドの決定があれば助かりますが、マネージャーサイドも決めかねている場合、自分で会議をリードする必要があります。
まずは、会議の参加者で以下についてコンセンサスを取ります。
- 不明点
- 懸念点
- あるべき論
- 暫定対策論
ここまでは問題なく進行することが多いと思いますが、時間も少ないので最終結論を決めねばなりません。
- 無視できない制約
が判明すればまずはそれの緩和策を考慮します。緩和策が有効でない場合は一方の策を取得するしかありません。
- あるべき論
あるべき将来像から逆算します。多少の暫定的な策であったとしても、将来的な改善であるべき姿に迎えるのであれば工数は無駄にはなりません。
いずれにしても重要なのはコンセンサスを取ることで、参加者に意見を促すことがファシリテーターとして重要です。自分の考えがまとまっていればベターですが、自分の考えがまとまっていない場合でも積極的に意見を求めましょう。
気付き
思ったより上司は気にしていない
重要な点以外は上司は仔細を気にしていないし，結果が良ければそれでいいのです．
細かなことを確認しすぎるのは1-3年で卒業し，4年目以降はその経験から阿吽が分かっているはずなので，結果の方針・KPIのみを共有し，プロセスは全体への影響度を見て，必要な部分のみ相談しましょう．
業務指示だけではなく，目的を
よく本に記載されていますね．業務指示だけでは相手は意図をくみ取ってくれません．業務指示以外に良いやり方を思いついていてくれたとしても，それをフィードバックしにくくなります．その業務指示通りに実施するのが目的なのか，目的を達成するための手段なのか分からないからです．
マネジメントの観点では，業務指示に傾倒すると自主性が育たないので悪手とされています．
特に協調して何かを作製するパートナーで，まだ阿吽の呼吸が出来上がっていない，定期的なミーティングに留まっているような場合には，質問＋目的を投げかけたほうが建設的な意見が返ってくることが多いです．
逆に手段だけを提示された場合には，目的を聞くことが大事です．
質問、業務指示、とにかく何でも相手方には意図がある
当たり前だろ何を言っているんだ、と言いたくなりますが、これを意識するかしないかで、相手の質問に対する回答の精度、その後の行動の円滑さ、相手からの評価が変わります。相手方が何をもってその行動に至ったかの把握するだけで必要な回答、行動が判明し、手戻りが発生する可能性が少なります。気の利く相手ならいざ知らず、往々にして相手方は質問しか発しないことが多いです。そのため、「それはどういう意図・目的ですか？」と確認することが重要です。
質問の場合
「Aのことについて教えてほしい」
と言われた場合、Aのことについて答えることは誰でもできます。ただ、Bのためなのか、Cのためなのか、で教える粒度は異なります。また、意図を把握しないと質問事項以外にも答えた方が相手のためになる情報を伝えることができません。
業務指示の場合、
「Aを実施してほしい」
実験日の振り返り事項
実験日の関係者間での振り返り事項は主に以下を決定します
- 不具合事象
- 原因
- Critical度合いの決定
- 対策
- 対策のアクター
- 対策納期
- 対策の効果確認日程
TODOにも言えることですが、誰がいつまでにどのようにを決定しておくことが大事です。暗黙の了解となっていても漏れはあるので明確に決定しておきます。
関係者間のスケジュールの決め方
複数関係者間のスケジュールを決定する場合の方法です。複数関係者間のスケジュールを調整する場合、先にたたき台を提出してしまうのが早いです。拙速を貴ぶとは正にこの時のための言葉だと思います。自分が複数間の間に入って調整を行って精密なスケジュールを一度に作り出すよりも、概ねでいいのでたたき台を作成して関係者間で共有したほうが早く進みます。
たたき台の作成方法は優先事項を決定し、各アイテムに予想される時間を概算し、許容される期間内でスケジュールパズルを行います。
作業を自動化する
同じ作業を、同じコマンドを3回以上たたいていると感じたら、そこには自動化したほうが作業があります。特に実験日等では定型作業を削減できることは大きな意味があります。
実質的に削減できる時間が数秒であったとしても、思考のスイッチが不要になるため作業効率は非常にあがります。また、自動化することで他人に作業を委譲しやすくなります。複数のコマンドを叩いてというのは初学者には難しいかもしれませんが、このファイルを実行して、というのは簡単です。
意思決定
背景と目的を正確に理解できていれば、その後の意思決定が可能です。意思決定ができない理由は、必要な材料が揃っていないからです。必要な情報として不可欠なものとしては既存仕様の決定背景と、それぞれに仕様に振った場合のリスクさえ認識できていれば意思決定が可能です。
常に頭の中で
- 既存仕様の背景（ファクター）
- 新仕様とした場合に影響を受けるファクター
- それぞれのメリット・デメリット
- 今回のプロジェクト全体の判断軸
を明確に意識しておく必要があります。
そもそもこれの背景は何でしたか？と聞くだけで、判断の助けになります
全部チャットで書くな
これは本当に遅い、承認が必要とか、明確に文章で残しておく必要がある、
相手の事前知識がないため予め情報を入れておきたい
のような状況でもない限り、チャットベースは悪手です。ただただ速度が悪くなります。
