00:05
はい、7月7日、金曜日ですね。すごく朝9時33分になりました。
昨日は、とある非公開というか、完全招待制のエンジニアのイベントがありまして、
これも言っていいのかわかんないですけど、赤舞さんが主催されたイベントだったんですけど、
そこに呼ばれましてですね、ありがたく参加させていただきましたと。
CTOの方もいらっしゃったり、バイトダンスのCTOの方も来られたりとか、
結構著名な方っていうか、業界で活躍された方ばっかりのイベントですね。
どうでも貴重なイベントだったと思いますし、とても刺激になりましたね。
改めて、すごいクラウドの世界にコミットしたくなったなっていうような感じがありますし、
僕やっぱりプラットフォーマーがすごく好きらしくてですね、
そういうクラウドを作っている会社とか、提供サービスを展開している会社さんって、
すごく興味あるなっていうのが改めて感じた次第ですね。
はい、おはようございます。みやみの技術孤独はるはるです。
では、本日も朝から始めていきたいなと思います。
では、今日は昨日、一昨日の引き続き、タイトルにあります
How to plan as an engineering executiveっていう記事ですね。
読んでいこうと思います。
タイトルにあります通り、エグゼクティブってあるんですけど、
経営層というか経営視点でのエンジニアリングですね。
技術者、もしくは技術に関するいろんなもののプランのやり方っていうのを、
この人なりにまとめたっていうような記事になります。
昨日、一昨日でどこまで読んだかっていうのを、今ちょっと思い出そうとしてるんですけども、
昨日なんかリクルーティングまでのお話をちょっと読んでた気がしてて、
いろんなポートフォリオとか、リソースのアロケーションをどうとかこうとか
みたいな話を昨日読んでて、途中で止まったと思ってますね。
今日はその続きからで、多分ここからだと思うみたいなところですね。
もし昨日と被ってたらごめんなさい。
読んでいきたいと思います。
Don't over-index on early resultsですね。
初期の結果を過大評価しないっていうところからちょっと入っていこうかなと思ってます。
今日の参加者は鹿内さんと松本幸太郎さんですね。
じゃあいきましょう。初期の結果を過大評価しない。
エンジニアリングポートフォリオのアロケーションで最も頻繁に見られる具体的な誤りというものは、
初期の結果に基づいてインパクトを過大評価したり、もしくはコストを過小評価したりすることになります。
いくつか例をちょっと挙げてみましょうというので、2点挙げてみます。
1点目は、2人のエンジニアがビルドパフォーマンスの改善に取り組み、
2ヶ月でビルド時間を50%短縮しました。
彼らはこの結果から、理論的にはエンジニアの能力の50%を開発者の生産性に投資すべきであり、
50%とはいかなくても、少なくともチームの規模を3倍にすべきだというふうに主張しています。
ここにもっと投資するのは簡単ではありますが、彼らはすでに初期のリターンを獲得しているかもしれない、
あるいはそうでないかもしれないというところですね。これが1点目で。
2点目は、2人のエンジニアが全てのフロントエンドのコードを共有のフロントエンドモノレポに移行する作業をしています。
3ヶ月の作業の後、あなたは概念実証を行い、4つのフロントエンドエンジニアリングチームに迷惑をかけ、改善を示すメトリクスがありません。
03:09
このプロジェクトをキャンセルするのはもちろん簡単ですけど、このプロジェクトで得られたものを統合することで将来の成果がより高くなることも意味します。
良い結果も悪い結果も課題評価をして、じゃあやめますとか、じゃあどんどん投資するって、一概にパッと言うのは想定だなという話ですね。
このような失敗を防ぐには、インパクト曲線が少なくとも1回返局するまでプロジェクトへの固定投資を確立するということをお勧めします。
要は一定の評価が結果が出るまではデカい変化をするんじゃなくて、粛々と作業とか計画通り進めていくということですね。
例えば2人のエンジニアのインパクトが過方にシフトするのを確認するまでビルドパフォーマンスに取り組ませ続け、その後で初めて適切な長期投資レベルを見積もりましょう。
これが遅すぎると感じる場合は、より早い段階で返局点を示すようなプロジェクトの設計に時間をかけましょうと。
いわゆるアラートじゃないですけど、アラートかもしくはチャンスみたいなところを返局点というところに軸を置いておいて、
それが見えるような、早い段階で見えるようにそもそものプロジェクトの設計を見直しましょうという話ですね。
ポートフォリオの良し悪しとか結果ってなかなか評価判断しづらいので、それは確かに最初の設計の仕組みでやるしかないなというのは満足感じますね。
クラウドウォッチで自動でアラート出るようになったらすごく楽なんですけど、とはいえ人の行いなのでそうはいかないという感じなんですよね。
では続きまして、アグリングオンザロードマップですね。ロードマップの合意というセクションに入ります。
私が強く信じる決定的な解決策を見つけた分野というのはたくさんあります。ロードマップはその一つでしかありません。
4列のスプレッドシート、例えばプロジェクトだったりチャンス、導入コスト、所有チームとかを使えばそこにたどり着くことができます。
ロードマップを作成する方法は他にも数え切れないほどありまして、ロードマップが失敗する原因はフォーマットにはほとんどありませんと。
フォーマットについて議論することに時間を費やすよりも、既に提案されているものには何でも使うことをお勧めします。
むしろロードマップが失敗するには、ロードマップ作成と予算や機能ポートフォリオの配分の変更が連動していたりするとか、
プロダクト、エンジニアリング及びそれらの利害関係者の間の緊張であったりとか、
ロードマップに具体的なプロジェクトとスコープのないプロジェクトが混在しているとか、
あとは計画を深く練りすぎることによるチームの無力化だったりなどなど、本当にいろんな理由があります。
カップリングの問題については既に時間を費やしたので、他の問題についても少し掘り下げていきましょうというので、
一応このセクションの冒頭はこんな感じがありました。
セクションの中身ですね、詳細の一つ目ですけど、ディスコネクティブプランナーズですね。
バラバラのプランナーズというところからいきましょう。
効果的なロードマップの作成には、プロダクト、エンジニアリング、そしてデザインが協力的に働くということが必要になります。
ある部門がプランニングをリードすることが多いが、他の2部門は積極的なパートナーであるべきであります。
06:03
そうでない場合は、合理的に見えるロードマップが作成されることになりますが、計画された作業の実際の基礎となる地形を説明することができません。
同様に、プロダクト、エンジニアリング、デザインが密接に連携しているにも関わらず、
提案された作業がステークホルダーの要望、一般的にはセールスだったりマーケティングからの要望ってあることが多いですよね。
そういうものを考慮していないロードマップをよく見かけます。
このような場合、適切にスコープされたロードマップはまとまりますが、一般的に会社の課題を最適に解決する一例の作業にはなりません。
このようなことが起こっているかどうかは、他部門の人々が提案された計画に概ね同意しているかどうかを確認することで、すぐに判断することができます。
そうでない場合は、異なる機能のプランナーを部屋に集め、議論をします。
私がここでよく目にする間違いというのは、幹部が一対一のディスカッションで解決しようとすることです。
一対一で討論するのはうまくいきますが、解決にはオープンなグループ討論というのが不可欠です。
私はグループが議論を始める前に、各自が1、2分間中断されることなく自分の見解を述べるという構造化されたグループディスカッションで特に良い成功を収めてきたと。
はい。これはその通りですよね。
結局やることはスコープの中にある人全体に渡ってくるので、なるべくグループ討論をしてみんなの意見を得て、その中で落としどころを決めていくという集合地ですね。
という当たり前の動きをするのが良いですね。
続きまして、ロードマッピング・アンスコープト・ワークですね。
スコープのない仕事をロードマップしましょう。
ケラン・エリオット、もしくはマック・レアのどのように計画を立てるかという素晴らしい投稿の中で、彼は計画プロセスがしばしば新しいアイディアを積極的に招き入れるという重要な見解を示しています。
実際は、How to Planという別の記事のリンクも貼られているので、興味があれば見てみてください。
プランニングの沈黙のあるいは明示的な問いかけというのは、しばしばあなたのエキサイティングな新しいアイディアを全て教えてください。
目標を成功するためにはあなたの想像性が不可欠です。
大きな石を投げてください。大きな石を投げなさい。これは待つというような問いかけがあるんですけど、これは間違いです。
課題は新しいアイディアがスコープがなく実証されていないということになります。
そしてあなたは結局スコープがないアイディアの未加工の可能性と既存のアイディアの実証済みの可能性を比較することになります。
実績のないアイディアをどのように割り引くかは、実際の可能性よりむしろ経営人の真理を反映するのが普通であり、これでは計画が気まぐれに感じられてしまいます。
また、新しいアイディアがすぐに否定されるような場合には計画プロセスが短命な計画を生み出すことになります。
それはもはや計画と言えない気がしますね。
このシナリオを避けるための効果的なテクニックというのが2つあります。
1つ目にスコープを設定したイニシアチブと設定していないイニシアチブの配分に合意し、その配分の中で類比優先順位をつけましょう。
09:02
例えば製品エンジニアリングの時間の20%を人気プロジェクトの検証に当てるべきだというかもしれませんし、
そしてその20%をどの未検証プロジェクトに割るべきかみたいな議論が行われたり、
その後に80%の時間を検証済みプロジェクトに投資することについてまた別の議論を行います。
もしくは例えばですね、プロダクトエンジニアリングの時間の10%を検証プロジェクトに長期的にも割り当てちゃいましょうとか、
これらのアプローチのいずれかを正式に採用できなかったとしても、
多くの場合はスコープ付きプロジェクトとスコープなしプロジェクトを別々に議論するように、
非公式に議論を誘導することもできます。
この辺なかなか難しいですね。
決定権もありますし、実際にリソースの話もありますし、
今どこまでできているか、もしくはここからが青写真かという、
しっかり線引きができているかというですね、
その今プロジェクトの中がどうなっているかというのがありますけど、
それすらできないならまずは今の自分たちの状況を把握するところからスタートという感じがしますね。
それができた上でどう割り当てるかというのは、
やっぱりリーダーの方の手腕に関わりますけど、
リーダーだけにそれを考えさせるというのは僕はちょっと違う気がしていて、
しっかりメンバーの人の意見も、メンバーの人たちがどんな思いだったり、
実際能力がどれくらいかというので、
誰にどのタスクを割り当てるかというのを考えて、
リソース配分を考えればいいんじゃないかなと思ったりしますね。
これはしっかりビジネス側の意見だったり考えたんですけど、
とはいえ現場の人たちの意見をしっかり反映しないと、
現場が苦しむだけの配分になってしまうので、
しっかりそこはお互いに協力していきましょうという感じですね。
続いて、ロードマッピングintoMuchDetailですね。
詳細すぎるロードマップの話です。
ロードマップ作成の最後の課題というのは、
あまりに具体的になりすぎると、
実際の作業を担当するチームの権限を誤って奪ってしまうという可能性があります。
メリッサ・ペリーという方は、
Escaping the Build Trapというビルドの罠からの脱出みたいな、
これもまた記事ですかね、が貼られてますけども、
この中でこの考えを雄弁に語っております。
あ、これ本ですね。失礼しました。
この本では、ロードマップを望ましい成果ではなく、
やるべきプロジェクトに絞り込みすぎると、
チームの思考を制約することになるというふうに述べています。
これまた難しい話ですね。
新任のリーダーは、この懸念を少し文字通りに捉えすぎて、
チームの自主性を奪うので、
幹部は特定のプロジェクトについて議論することを許されるべきではないと主張することもあります。
エグゼクティブチームが純粋な資源配分の決定者になってしまうからになります。
マイクロマネジメントをする経営人がチームに嫌われるのと同様に、
資源配分しかしない経営人はもっと嫌われます。
それもそうだよね。
あくまで経営人は経営をするので、会社の未来についてコミットしたり話をするべきではあるので、
資源配分しかしないだと、さすがに嫌われるでしょうね。
ビジョンとかファッション的なところを示すのが割と経営人には求められたりしますね。
その上でしっかり計画的に何かどうだっていう具体性のところまで落とし込めるのが大事だと思うんだけど。
なので、資源配分だけ、リソースの配分しかしないっていうのは、
12:01
それも経営かどうかもちょっと怪しいとかはありますけど。
そうではなくて、信頼度の高い目標成果を強調し、
次に信頼度の低い具体的なプロジェクトについて議論するということを目指すべきであります。
しかし具体的なプロジェクトを掘り下げることで、目標に関する抽象的な議論よりも、
実行に関する遥かな議論が鏡面化するでしょうということですね。
これまたバランスのお話になる気もしますけど、とはいえ、
やるべきことばっかりやる、つまり今にフォーカスをし続けると、
結果、思考は確かに制約することになりますよね。
淡々とチケットベースでやることをやっていくので、
そのチケットのゴールが何ですかっていうところで、今にしかフォーカスをしなくなるので、
じゃあこの先どうなるみたいな新しい発想とかアイディアみたいなところが生まれるチャンスがほぼなくなるんですよね。
もちろんそういうことを考えながら各メンバーがやってるっていう可能性ももちろんあるので、
一概には言い切れないですけど、確率はやっぱり高いと思いますし、
やっぱりチケット駆動でずっとやってる方が未来を語るって、僕あんま経験したことないんですよ実は。
なので、そういう未来について考えるチケットを最初に用意しておくっていうテクニックもあったりはしますけどね。
では続いて、ロードマップの話は今ので以上ですね。
続いては、プランニングプロセスの話かなこれは、に入っていきたいと思います。
タイムライン for Planning Processesですね。計画プロセスのタイムラインの話です。
上記の計画プロセスっていうのはカレンダーにマッピングをすると通常は次のようになります。
いくつか例ありますけど、年間予算っていうのは前年度末に作成をします。
機能計画というのは年間を通じて計画的に行いましょう。
市販機計画というのは各市販機の数週間前に行います。
市販機でなく、販機であれば各販機の前の週に準備をします。
このような典型的な実施例を一つに示します。
ざっくりとした図が示されてますけど、市販機もしくは販機は年間の目標というのは、
その前期の最後の方にやるは当然だと思ってますし、むしろそれが正しいと僕も思ってました。
ここでの特定の詳細というのは企業によって合理的に異なるでしょうし、
私は詳細が一方的にあまり重要であることを発見していない。
詳細が一方的にあまり重要であることを発見していない。
私が警戒を怠らないことをお勧めする最大のポイントは、
ストライプという会社でプランニングを始めた頃、クレアヒューズ・ジョンソンがよく口にしていたことになります。
計画のために1週間を確保すれば1週間かかります。
プランニングに1ヶ月を避けばもちろん1ヶ月かかります。
プランニングは無限のゲームなので、有限のステップに多くの時間を費やすのはなるべく避けた方が良いと。
プランニングは無限のゲームなんですよね。
一生やろうと思ったら一生やれるし、ずっと続けようとしたらいくらでもやれるので、
プランニングはどこかで区切ったり、どこかエイヤーでここまでやってみましょうというようなサイクルに
いかに落とし込めるかというのが結構大事ですよね。
ではそれについてもう1個詳細の話ですけど、
プランニングはシャドウプランニングプロセスです。
シャドウプランニングプロセスの実行をしましょう。
15:01
ある時点で予算・機能・優先順位・ロードマップというのを独自に解決しようとしない人が
運営する計画プロセスに身を置くことになるかもしれません。
同様に会社のあらゆる問題を解決することに固執する計画プロセスで働くことになるかもしれません。
幹部としてあなたはオーナーと協力して計画プロセスを改善すべきですが、
自分の部門内でシャドウプランニングプロセスを実行する必要もあるかもしれません。
予算と機能的リソース配分の両方について行うのが最も簡単です。
例えば、通常エンジニアリング部門の年間人員計画を保守的に設定し、
他の部門が年間を通してより多くの人員を確保するために争ったとしても、
エンジニアリング部門をその人員計画に向けて運営することができます。
一方、シャドウロードマッププロセスを実行することは、
たとえロードマッププロセスが難しいことであったとしても、正直無理があります。
私はシャドウロードマッピングプロセスがうまく機能するのを見たことが実はありません。
プラットフォームエンジニアリングだったり、デベロッパープロダクティビティだったり、
インフラストアクションエンジニアリングのような、
エンジニアリングのみを顧客とするチームの場合は除きますけどねって話でした。
なるほどなるほど。
テックの人たちばっかりをフォーカスしたような顧客だったり、
そういうチームだったら意外とうまくいくけど、
そうじゃない場合はシャドウロードマッププロセスを実行しても基本的にはうまくいかないらしいですね。
とはいえ、でもそれを必要とするケースもどっかであるよって可能性はあるんですけど、
ただまあうまくいかないので、
まあじゃあどうしたらいいんだろうなって話は気がしますけど。
はい、まあ続きまして。
要は撃破が必要な時っていう時でしょうね。
シャドウロードマッピングするしかないっていう。
もうどうにもニッチも立ち向かない時にエリアでガンと、
何かを変えなきゃいけない時に使ってみるのかもしれない。
でも使っていれば多分うまくいかないところまで一回ぶつかって走っていっちゃうと思うんで、
そこでもう一回まあリプランニングするっていうのはいい話かもしれないですね。
はい、まあそうならないようにいろんなものをしっかりチームで議論しながら進めましょうって感じはしました。
では続いて、Ways that planning process failですね。
計画プロセスが失敗する理由の話ですと、
有能なエグゼキティブチームであったとしても、
プランニングプロセスがうまくいかないことはよくあります。
その原因は、相入れない目標だったり、
チーム目標から個人目標への微妙な逸脱であったり、
大きな結果をもたらす小さな戦術的ミスの長いリストというのが混在してたりします。
で、プランニングの課題を診断するために、
私が遭遇したプランニングの課題の中で最も頻度の高いものと、
どの課題がプランニングプロセスに影響を及ぼしているかというのを特定するために
使える症状をちょっとまとめてみましたよっていうので、
今から入っていきたいと思いますけど。
そのうちの一つ目が、
Planning as ticking checkboxesですね。
チェックボックスにチェックを入れるようなプランニングをしましょう。
結果志向ではなくて、プロセス志向の人物だったり、
プロセス志向の変更を要求する他者を押し留めることができないような人物ですね。
に、プランニングを委任しているような兆候がある場合ですね。
その場合は、チームは計画プロセスをサポートするために、
何十もの計画成果物をまとめ、幹部は必要な作業の深さを称賛します。
18:01
計画が終了すると、次の計画サイクルが始まるまで、
その計画が再び参照されることはほとんどありません。
これは純粋に価値のある仕事ではなくて、
見かけ上価値のある仕事に集中するよう個人を借り立ててしまいます。
見かけ価値って結構落とし穴ですよね。
難しいですね。
これ、振り返りする時じゃないと意外と見えなかったりするので、
仕方ないというか、僕の中で経験値としてはどうしようもないと思います。
ただ、見えないようには見えた方がいいので、
しっかり振り返りの時に、実はあんまり価値がなかったなというのが
反省点として出ればいいなと思いますけどね。
そして、走っている途中で見えるんだったら、
それは一番いいと思いますので、
そういうリファインメントするようなタイミングがあればいいと思いますけどね。
じゃあ続いて、計画の質よりも形式が重視されるという話ですね。
経営幹部というのは、計画プロセスを重視していることを示すために
計画に意見を提供する義務があるというふうに感じています。
価値あるフィードバックがない場合でも、
彼らはフィードバックを見つけようとしますが、
それは多くの場合、計画文書のフォーマットや
計画プロセスに正しく従うことに関連しています。
これでは、計画決定そのものの質の評価から正直外れてしまいますよ。
難しいですね。
フィードバックをしなきゃいけないというのが
使命感に苛まれている可能性があります。
効果的なプランニングプロセスには、
その中核となる目標に集中させることができる
権限を与えられたエグゼクティブスポンサーと
少なくとも明確なプロセスの実行と同じくらい
有用なプランの作成に情熱を燃やすプランニング実施者
というのが必要になります。
しっかり専任でプランニングする人を立てるというのは
いい話かもしれないですね、これは。
では続きまして、
多くのエグゼクティブチームは
予算策定プロセスで機能横断的なリソース配分を設定しますが、
その後、その配分に反する人員要求というのを行います。
これは会社の目標との成功性ではなく
二次元的な要因だったり、
多くの場合、個人の要求や興味によって
要求が評価されることにつながります。
計画は最も効率の悪い組織に報います。
リーダーはしばしば組織の能力をサンドバックにし、
現在のレベルで業務を遂行するためには
さらに大幅な人員が必要だというふうに主張します。
その結果、最も効率的でないリーダーや
組織に最も多くのリソースが割かれてしまいます。
このパターンの変種というのは、
エグゼクティブが自分たちの人員要求が全て満たされない限り、
自分たちの機能の成果に対して責任を持てないと
好めかすことになります。
これは一貫して高い人員要請と相まって、
エグゼクティブが義務を果たさず、責任を負えないと主張するという
有害なサイクルももたらしてしまいます。
人員計画は万能役として扱ったりするという
ケースもあります。
人員計画を重視するエグゼクティブチームでは、計画立案が
最も重要な仕事を決定するのではなく、
人員要求を合理化することに集中しがちになります。
優先順位付けやプランニングの議論において、
ベロシティが固定され、その仕事が行われなければならないと
仮定し、その代わりにヘッドカウントに軸足を置くとき、
このようなことが起こっているのは明らかになります。
これは自分の職務がどのように機能しているかを理解している
21:02
想像的なリーダーを罰することになります。
そのようなリーダーは、その職務の運営方法についての
知識があるため、ヘッドカウントを重視する同僚よりも
戦略的に劣っているように見えてしまいます。
エグゼクティブチームはメンバーに対して、より大きな利益のために
最適化するよう社会的圧力をかけることはできますが、
最終的にエグゼクティブの行動に責任を持たせることが
できるのはCEOだけになります。
こうした問題を定長に提起することは
価値がありますが、それに対処できるのはCEOだけになります。
問題を解決しようと強引に働きかけても
逆効果になるだけですよというお話でした。
ちょっと難しいしセンシティブな話だなと感じましたね。
ちょっとミスると一気にメンバーの不満を買ってしまいますからね。
続きまして、
プランニングアースリドローイングシャイニープロジェクトですね。
ピカピカのプロジェクトに報酬を与えるようなプランニングだそうです。
プランニングプロセスが本来のリソース配分や
機能調整の問題を解決することよりも
経営人を書き付けていることに重点を置いているような兆候ですよと。
経営人が最も興味深いと思う仕事に
プランニングの軸足を置いているというようなケースが1つ目ですね。
特定のプロジェクトは常に任意の経営人が議論する方が活力になっていたりします。
例えばほとんどのエグゼクティブチームは
販売数や新製品開発について議論することに
興奮をしますが、コンプライアンスについて議論することに
興奮する人は少ない。
エグゼクティブが楽しいと感じる仕事によって
計画プロセスが推進されるのであれば
それはしばしば計画の成果を低下させることになりますし
いわゆるゴマ擦りの社員がどんどん増えるんだろうなと感じますね。
計画立案が部門横断的な要求しか考慮しなくなるみたいな話もあって
多くの計画立案プロセスは
実施すべき業務全体を計画するのではなく
部門横断的なコミットメントを満たすことに重点を置いています。
ロードマップが機能横断的な要求だけを
深く考慮するのは合理的ではありますが
機能的な配分も計画されていることが不可欠であり
そうすることでたまたま単一機能の責任とみなされる
重要な仕事について経営人が議論できるようになります。
例えば顧客満足、セキュリティ、コンプライアンス
安定性用単一機能の責任とみなす企業もあります。
インパクトのあるプランニングの成果を生み出すには
目の前のビジネス上の問題や機能上の問題を
解決することにかかっています。
エグゼクティブチームに活力を与えることは重要ですが
この目標に向かって計画を散漫にすることは
本当にかつ不当に高いコストを伴いますよというのに注意してください。
続いてプランニングアズ
オーナーシップの低下としてのプランニングだそうです。
エグゼクティブチームが
より広いチーム内の自立性とオーナーシップを
低下させるような方法でプランニングに取り組んでいる
状況だと。
自立性とオーナーシップを低下させる時点でわりと我解している気がします。
1つ目に効果的な計画プロセスは
社内の各チームが業務を遂行するためのガイダンスとしての
役割を果たします。
24:01
エグゼクティブチームは必要な成果や投資分野ではなく
特定のプロジェクトの優先順位付けに焦点を絞りすぎることが
たまにあります。その結果最もコンテクトのあるチームだったり
つまりプロジェクトを実施するチーム自身が
より効果的なアプローチを調整できなくなる
みたいなこともあります。その結果チームの指揮は低下しますし
会社の実行に緊急性がないことを不満を抱く幹部も
出てきたりします。2つ目に
計画立案が新たなプロジェクトを生み出すみたいなケースですね。
計画立案プロセスにおいて
あるエグゼクティブがある領域について考えるのはその時だけだ
というような場合もあります。例えば最高財務責任者
CFOがカスタマーサクセス組織の
ロードマップについてプランニング以外で考える時間を
あまり取らないかもしれません。これは本質的には問題では
ないんですけど、時にはそのような遠方の幹部が
計画を機会にスコープ外の重要な
新規業務を提案することがあります。これは
ほとんどの場合計画プロセスの遅延または失敗に
つながります。なぜなら十分に計画された作業と
計画されていない作業の優先順位を付けようとすることになり
それは非常に困難だからです。エグゼクティブは
プランニングを通じて幅広いチームをコーチする
ということが優先すべきであります。時には
自分の領域で計画を立てられないリーダーを特定し
トップダウンで計画に変更を加える必要があるかもしれませんが
それは日常的なことではなく例外的にある
べきではあります。エグゼクティブはしっかり
組織内の今をしっかり把握しなきゃいけないなってことですよね
進んでいるかっていう具体の話も
しなきゃいけないけど、ちゃんとゴールに向かって今どういう状態ですか
何が問題ですかっていうのもしっかり見ていくっていうのは
とても重要なので、これ難しいですね。マクロとミクロ
両方見なきゃいけないって感じですね。当たり前かもしれないですけど
最後、サマリーですね。概要というかまとめになります
この投稿を通じてあなたは経営人の
年間予算策定プロセスだったり、エンジニアリングの
目標機能の割当ての維持であったり、その2つを組み合わせた
具体的なロードマップの策定というのを扱ってきました
また、エンジニアリングの成長を会社全体の
成長のリミッターとすべきかどうか、機能配分における
流度の検討、シャドウプランニングプロセスを実行するなど
トレードオフなど、小さなトピックも数多く扱ってきました
これらのアイディアを次のプランニングプロセスに
反映させるあたり、私が最も期待するのは
最初のセクションを思い出していただくことだけになります
重要なのは、少しずつ改善し続けることだということで
この記事は締められておりました。はい、いかがだったでしょうか
いろんな経験、考えだったり
この人もいろんな立場でお仕事されてきて
最終的には小さく改善をひたすら続けるという
そのサイクルを回すというところに落ち着いたというのが
やっぱり何ですかね、当たり前のことって
やっぱり人類の英知だったりするので
本当そこにたどり着くのはいい話だと思いますけど
一回そこに自分たちも周り回ってみるっていうのもいいかもしれないですね
組織的に。最初からその人類の英知に
ガッと飛びつくのは僕は別に構わないと思いますし
一番それが効果的かもしれないですけど
チームの情勢だったり組織の成長というところを考えると
27:02
一度はペインをもう一回自分たちにも歩んでみるというのは
僕はできるんだなと思いますね。お金とかリソースの余裕があるんだったら
やってみるのもあるかもしれないですけど
メンバーはそれを歩みたいかというのはまた別の話ですね
とはいえ、どこまで効率的にやるかというのと
どこまで組織の成長と会社の成長するかというのはすごく重要な観点ではあるので
経営手話にかかっている気がしますね
とはいえ、いろんなトピックがあって本当に面白かったですし
なんか経営層で
僕は一応経営層でお仕事させていただくことはあるんですけど
やってない方でもこういうのを読んで経営人ってどういうことを考えたり
どういう目線で仕事をしているかっていうのをインストールするだけでも
割と会社の見え方が変わってきたりすると思うので
ぜひ読んでいただければなと思ったりはしました
とはいえ、経営人も現場のことをしっかり考えてプランニングしたりとか
いろんなものを進めるっていうのも大切ですので
やっぱりお互い悩みより大事だよなっていうのを読んでいただきたいですね
はい、じゃあ長々と語りましたけどこれで以上にしたいと思います
本記事もですね3日に渡りましたけど
ちょっと難しい話も多かったんですけどね
明日からまた別の記事を読んでいきたいと思うので興味があれば参加してみてください
改めまして今日の参加者は赤神さんと鹿内さんと
しちゆうせんさんとあと見えてないけどスーさんですね
ご参加いただきありがとうございました
ということでですねまたなばたというところもありまして
仕事をしっかり締めていただいて夜と土日はゆっくり休んでいただければなと思います
じゃあ終了したいと思いますお疲れ様でした
