マネージャーとしてのアウトプットを最大化する
はじめに
自分がマネージャーとして学び経験としてきたことをまとめてみました。新任マネージャーの方などに役立てていただけると幸いです。
もともと所属する企業内での成長サポート目的で作成したドキュメントなので、文脈が欠落している部分があるかもしれません。ご了承ください。
なお、ここでのマネージャーはエンジニアリング組織のマネージャーを想定しています。
ステークホルダーと私たち
ステークホルダーから私達に対しては、様々な期待が寄せられています。(X)
そして、私達自身がそのミッションを遂行するためにやるべきだと思っていることが存在します。(Y)
私達のケイパビリティをZとします。Z >= X+Y となる場合、そこに制約はありません。期待されていること、やるべきだと思っていることをやるだけです。
でも、そんな状況ってあるでしょうか。多くの場合、ステークホルダーからの要望は溢れ、自分たちがやるべきだと考えていることは置き去りになりがちです。Z < X+YなのでYを落とす。
それでもZ < Xとなってしまうから、Xの中でも調整する。ステークホルダーとしてはやってほしくて要望を出しているわけだから、先送りするにしても理由を欲しがります。その理由を言語化し納得してもらうのにまた時間が必要だったりします。マネージャーって大変ですね。
Zを大きくし、X,Yを小さくする
さて、マネージャーの仕事とは何でしょうか。アンディ・グローブはマネージャーのアウトプットについて、著作HIGH OUTPUT MANAGEMENTの中で以下のように定義しています。
“マネージャーのアウトプット＝自分の組織のアウトプット＋自分の影響力が及ぶ隣接諸組織のアウトプット“
そう、だからこそステークホルダーからの期待に応えつつ自身がやるべきことをやる、という離れ業が求められるのです。がんばれマネージャー。
じゃあ、そのような離れ業を実現するにはどうするか?
おおまかにいって、以下の二点がマネージャーに求められる仕事です。
マネージ対象のケイパビリティ(Z)を向上させること
ステークホルダーからの期待(X)と自身がやるべきこと(Y)を整理し(Z)におさめるサイズにすること
ケイパビリティを向上させる
チームのケイパビリティは以下の要素で決定されます。
チームを構成する要員のスキル
チームを構成する要員のモチベーション
チームが開発する対象のDeveloper eXperience
必要なスキルを可視化する
どのようなスキルが必要なのか、星取表などで可視化します。
チームとして必要な能力が備わっていればよいので、全員が全員同じスキルを有している必要はありません。むしろ何かを捨てて得意なものに全振りすることでしか得られないものもあります。
ただ、チームとしてはお互いに背中を預け合い協働することが前提となるので、HRT(謙虚、尊敬、信頼)を持ち合わせた人物であることが前提になります。
HRTという言葉は初耳だよ、という方は、ぜひTeam Geekをご一読ください。
業務に学習を組み込む
チームの現時点での能力を最大限発揮することにフォーカスするならば、得意なことは得意な人だけに任せることが得策です。しかし、それではスケールしません。属人化にも繋がります。まだ得意ではないが得意になりたいと思っているメンバーをその領域にアサインするなど、学習前提でのアサインを行いましょう。（それができるのは余裕がある時だけなので、余裕を作り出していくことが大事）
モブプログラミングは業務を通して技術伝承を行うことができる有効なプラクティスです。それでいて「チームの現時点での能力を最大限発揮する」という目的に合致させることもできる柔軟なプラクティスでもあります。積極的に取り入れていきましょう。
モブの目的をはっきりさせよう
チームのスキルを総動員してスループットを最大化するモブか、チーム内でのスキル移譲を狙った学習目的のモブかでふるまい方も変わってきます。
このスタンスが参加者によって異なっていると、狙ったモブ効果を生むことができません。事前にモードを明らかにしておきましょう。
学習の段階を設計する
業務を通しての学習を行う際には「正統的周辺参加」を念頭において設計するとよいです。たとえば初めてチームに参加したメンバーにはまず問い合わせ対応をやってもらい、理解を深めながら徐々に中核のタスクを担当してもらう、などです。
問い合わせ対応は一見地味ですが、以下の特性を備えているため初学者のオンボーディングに非常に向いています。
チームに寄せられる期待を肌で感じることができる
プロダクトコードにDeep Diveし理解を深めるきっかけを得られる
一人では遂行が困難であるため、必然的にチームメンバーとのコミュニケーションが発生する
モチベーションの源泉を知る
さて、スキルのベースが整ってきたら、今度はモチベーションについて確認してみましょう。モチベーションに関して重要なポイントは、「一人ひとりモチベーションの源泉は異なる」ということです。自分にとってモチベーションとなるものが、チームメンバーにとってもそうであるとは限らないのです。
「ドラッカー風エクササイズ」のようなワークを用いて一人ひとりの価値観を見える化し共有することは、モチベーションの源泉が一人ひとり異なることを明らかにし、相互理解を促進する効果を産みます。
モチベーションを引き出す
それぞれのモチベーションの源泉がわかったら、今度はチームとしてモチベーションを共有していきます。共通の目標をもち、それぞれの価値観から自己のモチベーションと結びつけ、主体的に目標に向かう体制をつくります。
インセプションデッキでミッション、ビジョンを明らかにすることは向かう先を明確にする効果を持ちます。
ウィンセッションは行動に承認を与え、貢献できているという実感によるモチベーション向上を実現します。
1on1での深い対話は個人個人が抱える不安や葛藤、課題感を引き出し、達成に向けたポジティブな意識へ転換することに役立ちます。もちろん、そのためには課題を解決するアイデアの提案が必要です。
いきいきと開発できる環境を
いくらスキルが高くたって、いくらモチベーションが高くたって、荒れ地に花は咲きません。彼ら彼女らが最大限に生産性を発揮できるよう、開発環境の改善にも投資しましょう。
ここはプロダクト価値に直結するところではないため、マネージャーが強い意思をもってコミットメントしないと崩壊していくポイントです。
プロダクト価値に影響を与える改善ポイントを探そう
私たちは限られた人員、期間、スキルという制約条件を前提として開発を行っています。
そのため、リファクタリング、CI/CDの導入、テスト整備といった改善活動についてやりたいことを全部やることは難しい場合が少なくありません。それどころか、「プロダクト開発が忙しいから内部改善なんてビタ一文やる余裕ありません！」という意思決定がなされることさえあります。そんなことをしたら私達は廃墟に住み続けることになります。ではどうするか?レバレッジの効く改善ポイントを探り、想定する効果を言語化し、ステークホルダーの理解を得た上で進めましょう。
Value Stream Mappingで開発プロセス内のボトルネックを特定する
ボトルネックを解消する施策を考案する
その施策がもたらす効果について仮説を立て言語化する
ステークホルダーの承認が必要な規模であれば説明の場を設け合意形成する
実行する
効果測定する
実行結果からわかったことから学習し、2.に戻る。以下繰り返し
やるべきことを整理する
続いて、ステークホルダーからの期待(X)と自身がやるべきこと(Y)を整理します。
なぜやるかを明らかにする
XにせよYにせよ、まず大切なのは「なぜそれをやる必要があるか」という問いに対する答えを持つことです。そして、そのWhyは顧客価値に根ざしたものであることが望ましいです。
良いWhyの例
直接的顧客価値創出
2024年問題が目前に迫る中、ドライバー未経験者が安心して配送業務に従事できるようにしたい
交通量が増大するお盆の渋滞緩和に貢献したい
所要時間精度向上のため現在の精度ボトルネックになっている箇所を特定したい
間接的顧客価値創出(将来のデリバリーにいい影響を与える、という説明を添える必要あり)
今後も拡張が見込まれるクラスの複雑度が増大しているためリファクタリングしたい
開発工程での待ち時間を減らすためテストを並列化したい
改善したいWhyの例
事業から依頼があったのでやる
偉い人から指示を受けたのでやる
自分がほしいからやる
テストは整備したほうがいいらしいからやる
Whyが明確に言語化できていない場合
プロダクト価値創出に直接的に寄与するものであればValue Proposition CanvasやLean Canvasを作成してみましょう。
間接的に価値を創出するものである場合であれば「if-then」で考えてみます。
もし◯◯を実行しなかったら何が起こる?
それはいつ?
どれくらいの確率で?
それで困るのは誰?
たとえば以下のように問を立てます。
このクラスをリファクタリングしないまま半年が過ぎたら私達はどうなりますか?
この問いに対して「何も起こらない」という答えが返ってくるなら今はリファクタリングのタイミングではありませんし、「開発不能になる」という答えが返ってくるなら今すぐにでもリファクタリングしないとまずそうです。
そもそもリファクタリングは日常的に行うべき！
それはそう。日常的に行う習慣がついているのであればぜひそうしてください。また、新規に開発する場合はTDDなどリファクタリングを前提とする手法を取り入れるといいでしょう。やらない理由はないですから。ないよ。
でも、現実問題として目の前に技術的負債が横たわっている場合は話が別です。ここで紹介しているように取捨選択していくことが求められます。
優先順位を付ける
Whyが明らかになると、それを実施する意義が明らかになるため、優先順位を付けることが可能になります。オーソドックスな方法として、アイゼンハワーマトリクスの活用があげられます。重要度・緊急度でタスクを分類していきます。
https://asana.com/ja/resources/eisenhower-matrix
避けたいのは「全部最重要！」という状況です。人間はクラウドサービスとは異なり簡単にスケールすることはできません。最重要だからやりきってくれよ！といってもできないものはできない。さらに悪いことに、複数のタスクに優先順位をつけず全部渡すと、全部を少しずつ進めるような動き方になります。(だって、優先順位の整理がついてないから「他を優先してるので今は手を動かしてません」なんて言えませんからね）そうすると何が起こるか?なにも終わらないのです。そう、だからこそ優先順位を付けることは重要なのです。
WIPを絞る
チームとして仕掛るタスクの数を絞りましょう。チームメンバーの数より小さい数に絞っておくことを推奨します。これはさきほどの「優先順位をつける」とも関連するところで、一つ一つの仕事に集中して終わらせていくという狙いがあります。
おわりに
ステークホルダーからの期待と自分たちでやりたいことのバランスに苦しんでいるマネージャーをたくさん観測してきたので、自分なりのやり方をまとめてみました。どこかのだれかの役に立てれば幸いです。
参考文献
この記事が気に入ったらサポートをしてみませんか？