エンジニアリングチームの業務プロセスデザイン　＃ワーク

チームのパフォーマンスは大変良いのであるが、それは個人のエンジニアに依存しているところもある。これは次のステップでは伸び代が少ないかほぼ売りきている可能性を示唆していると仮定する。

その仮定を放置しておくと、個人のエンジニアは現状のタスク＋入れ替わるタスクだけとなってしまう。エンジニアの成長に必要な機会があったとしても、現実的にはそれに手を挙げられるだけのリソースを引き当てできないから、エンジニアにとってはストレスになる。

チームとしても、在りたい姿＝ToBeを実現したい。ToBeはチームメンバの全員の総意として目指したい。

チームがToBeに成れたとき（踏み越えたとき）、チームとして何を実現できるかを言語化することは、ToBeに同意し、総意に導ける。この総意を頼元として、メンバは同じ方向に顔を向け続ける。

チームのToBeを実現していく行程の中で、エンジニアは自分でできる、やりたいことを見つけるか、コンピテンシで求められる能力を実践可能性を持っているだろうタスクを見つけなければならない。この2つを結びつけることにより、エンジニアはチームの中で自分の存在理由を得られる。ストレッチの成果を得るためのOKRは、その点において関連づけられる。

実行フェーズにおいて、PlanとDoの軌道修正は小さなインターバルで行うことがチームのToBeからの乖離を小さくする方向に寄与する。エンジニアの業務の考え方、組み立て方の弱体化はここ最近よく聞くキーワードであるし、以前から発しているテーマである。これを他のエンジニアの頭の中を覗く場を作ることで、解消できると仮説をおく。日常は進捗と障害共有からの対処にフォーカスし、それをサイクリックな断面で成果のスナップショットをとっておく。

これで運用できると、期末の評価時のワークがチーム内においては平準化される効果を得られる。

モデル
チームのToBe
　↑
チームミートアップ
　↑　done（evidence, feed back）
デイリースタンドアップミーティング
　↑↓　doing
症例研究会ぽい会
　↑　Ready
各エンジニアのKR（担当のアサイメントのwill）
　↑　will
各自の将来のエンジニア像＋チームのOKR
　↑
ランチミーティング＋チームのToBe

チームのToBeイメージ合わせ（頻度：1〜同意するまで）
チームの中から見たらメンバはどの方向に進むのか、チームが見上げる北極星を指し示そう、という主旨。その北極星を言葉にしたときのワーディングは、たたき台を作り、その方向に顔を向け続けられる程度がゴール。これとコンピテンシの各自の次のステップのバンドが各エンジニアのKRを支えるスキルセットになる。
デイリースタンドアップミーティング（頻度：日次）
継続する。制約条件の納期はもう少しはっきりと明示的にした方がいいかもしれない。現状は運用はできているが、やりたいとやれるの線引きをセルフで判断できるように。
症例検討会ぽい会（頻度：週次）
メンバが担当している業務課題で各エンジニアとしてはこう進めていこうと考えているやり方について、観点の漏れ、技術的な知見からコメントをする場の枠を設ける（イメージ）。
感覚的には、FunDoneLearnのLearnだけを抜き出したイメージが近い。
ランチミーティング（頻度：月次）
接点の少ないメンバの接触の場にすることと、仕事でこんなことがあった（気づいた）を話してチームのチャンネルにメモしておく。業務の違和感を定点観測するようなイメージ。
チームミートアップ（頻度：四半期に1回。月次でやりたい）
成果発表会的なものとして。真の狙いは、各メンバのRのエビデンス集めと他のメンバからのフィードバックのメモ。これをトリガーに、各エンジニアはRを整理できるだろう。