00:05
はい、11月16日水曜日ですね。 時刻は昨日もありました。
えーとですね、今日はですね、「How to plan?」 って記事ですけど、何日か前に読んだんですけど、
この記事、続きますって言っておきながら、 次の日全然別の記事を読み始めてしまってですね、
途中で読むのをやめてしまったので、 今日はその記事を読んでいこうと思います。
はい、えーと、昨日リミックスのブログを読んで、 なんかその周辺ブログだったりとか、
その記事内に書かれていた別のリンクの 記事を読もうと思っていたんですけど、
昨日の夜ですね、朝活のデータを編集していたときに、 このHow to plan?っていう記事を全然読みきってなかったってことを思い出したので、
今早速読んでいこうかなと思っています。 はい、では前後しましたけど、はい、おはようございます。
ひめみきーすことくわはらです。 では改めて始めていきたいと思います。
で、この記事ですけど、どうやってプランニングするか、 計画とてるかっていうと、
それがどれほど難しいかというところを、 この筆者の方がですね、走り書きしたっていうことですね。
4Kワードいったらしいですね、 4000ワードくらいに連なったブログらしいですけど、
それをガーッと書き下したものだったんですね。
それと、最近のインタビューの質問と、 25年間のいろいろ様々ですね、苦しい計画、
プランニングのプロセスっていうところで、 前読んだところでいくと、
ちなみに1から9じゃなくて0から8番目なんですけど、 その0番目のDo Fear Thingsと
1つ目のボトムアッププロセッシング Doesn't Workですね。
まず物事をしっかり小さくしていきましょうっていうものと、 ボトムアッププロセスは基本的に
うまくいかないよって話をしてましたね。 っていうところですね。
そこまで読んだので、2個目の項目から 今日は入っていこうと思っております。
では早速いきましょう。2つ目ですね。
2つ目は、計画は新しいものを導入する時期としては 不適切であるというところから
入っていきたいと思います。ほとんどの組織では、 毎年もしくは市販機ごと、
あ、これ読んだな。読みましたね。 13週間ごとに計画を立てるっていうのが
正式な期間を設けられている。 結構よく聞く話ですね。市販機ごとに
計画を向けるとか、OKRって大体その3ヶ月で 振り返りすることが多いので、
そのOKRの見直しを図るのも大体できましょう。 フレームワークと制約条件を
提供するということは、マイクロマネジメントを 行わずにトップダウンの
プランニングを行う方法ですよと。 弁紙の投稿では、チームが運営しなければ
ならない予算を伝えること、そしてチームの 創造性や野心を刺激し、オプション性を
維持するためにバッファー、20%を確保することの 重要性に触れています。
これらは有用な制約にはなりますけど、チームには 他にも必要なものがたくさんあります。
このアプローチというのは、より良い結果と 控えにリーダーシップに多くの仕事を
与えるものですよというふうに語られています。 ちなみに弁さんが投げられている
投稿、そのブログのリンクも貼られていますので、 後ほどこの記事をシェアするので
見てみてください。
メトリクスもしくはOKRというものは、 長年にわたって人気のある制約には
03:04
なります。収益解約、サインアップ、稼働率などは 多くの企業の計画プロセスの基礎となる
ものです。このような指標とあなたが重要だと 考えていることについての物語、
ストーリーテーリング指標を形成する指標を 組み合わせることを検討してみてください。
例えばデスクトップとモバイルの両方で当社の 製品を使用した顧客、製品が利用可能になると
それを採用する会社の割合などなどです。 フレームワークというのは
制約を導入するのに有用なかつ有効な方法です。
イーブンオーバーズというのは有用なフレームワーク となり得ます。
イーブンオーバーズというフレームワークが あったんですね。
これちょっと僕知りませんでした。
私たちの目標は多品種少量生産の企業になる ことです。
そうだよね。たくさんの選択肢種類がありつつ、 でもそれら1個1個の売り上げとか
生産率が高くて、少なく作ったとしてもすぐに 売れると。在庫を持たなくていいということで
素晴らしい話です。つまり新規顧客よりも 純増数を優先することになります。
ニューカマーではなくて今のものをどんどん 売れるようにしていくことが大事だということですね。
マルチプラットフォームの一貫性よりも 新機能を出荷するというところですね。
投資ポートフォリオというのは、 投資のポートフォリオアプローチというのがあって
そのアプローチというのは1つのフレームワークです。
ハイリスク、ハイリターンである新規事業には 全体の20%の労力を割くべきと考えます。
成熟した製品の運用に必要な人数というのは、 使用量が増えても前年比20%減でなければならない。
使用量が増えても前年比20%減に必要な人数が、 人的コストをそれだけ下げたいということですね。
また次に能力モデルですね。 能力モデルというのも1つのフレームワークですよ。
XができればYの機械が生まれるのということですね。
1と2で説明したのと同じ理由で、 これらの制約条件というのは計画プロセスでは発見できず
計画に入る前に人々が知っている制約条件である必要があります。
例えばよくある制約として、今年の新機能を祝うために マーケティングイベントを行いたいというものがあります。
チームからいつまでに準備ができているかというのを教えていただいて、 それからイベントを計画するのは魅力的ではありますけど、
それは結構回りくどいやり方です。
彼らはイベントがいつ行われるかというのを知って、 初めて何が準備されるかというのを伝えることができます。
イベントがいつなのかを知ることで、 私たちが作る実装が迅速で汚いものなのか、
それとも徹底的で資料深いものなのかを知ることもできます。
計画を立てる際に最も重要な制約というのは、 私たちがすでにコミットしている仕事のコストはどれくらいかというところですね。
また私たちのKTLOというのは何でしょうか。
すみません、僕が知らないものだったので、 ちょっと不勉強で申し訳ないです。
あとは現在進行中のマイグレーションを完了させるために 必要なものは何でしょうかとか、
顧客に約束したことは何だったかとか、
機能していないシステムの一部を水上とするために 必要なコストはどれくらいありますかと。
06:03
あとは一般的に現状維持するために 必要なコストは何かというところですね。
これらのことというのを年間を通じて 追跡調査すべきことではありますが、
もしそうでなければ計画を立てる前にこれらの答えを得るための 時間を確することがもちろん重要ですと。
これは年間計画の前にむしろ知っておいた方が いいことじゃないですかね。
結局コストの端になると思うので。
リーダーとしてトップダウンの計画には 実際のコストだけでなくてリスクも伴います。
少なくともいくつかの点で あなたは間違っている可能性が高いですよと。
そしてそのことを教えてくれる人が 必要なんですということでした。
いろんなフレームワークと制約条件というところが いろんなものを解決してくれますけど、
事前に知っておくこともすごく大事だったりするし、
この辺は加味しなきゃいけないことが たくさんあるよねということでした。
いろんなフレームワークがあるんですね。
全然知らないフレームワークがたくさん出てきたので。
たくさん2つ3つですけどね。
EVEN OVERSというものと、能力モデルというものと、
投資ポートフォリューアプローチというものですね。
こんないろんなフレームワークがあったんですね。
後ほどこれはそれぞれで調べてみたいと思います。
調べてまとめたら、改めてブログを書いてみたいですね。
別に誰かがブログを書いている気はするんですけども。
今のが3つ目の話ですね。
続いて4つ目です。
4つ目の観点は、プロジェクト計画には 返却点があるというお話ですね。
多くの企業の人生には一本調子、あるいはそれに近い時期があります。
全員が一つの重要なことに向かって仕事をしているか、
全員が一つの重要なことに取り組んでいるか、
あるいは重要でないことに取り組んでいるのか、
どちらかですよということですね。
この段階ではプランニングで解決しようとしている重要な調整問題のほとんどは、
それ自体で解決されます。
マイルストーン、障害物、リスク、立ち上げ計画、
大きなもの、小さなものに分解して、
段階的に価値を提供できるか、などです。
これはプロジェクトプランニングであり、
企業の人生のこの段階で行うのには完全に合理的なことでもありますよと。
達成しようとすることが複雑化し、
プランニングが調整とコミュニケーションに重きを置くようになってしまうと、
プロジェクトプランニングはもはや企業レベルで行うには来た季節ではありません。
粒子が細かすぎるのですと。
さらに重要なことはチーム外の人たちに対して、
問題解決の方法を過度に細かく約束することですと。
問題を解決したときのインパクトにコミットすべきなのです。
問題解決へのアプローチをチーム外の人に監視してもらうと、
新しいことを学んだときに計画を変更するのが非常に難しくなりますと言っています。
マーティ・カガンという方がいて、
このことについて頻繁に話をしています。
例えば製品ロードマップの問題点についての投稿になりますと。
その投稿についてまた記事のリンクを貼られています。
ソフトウェア、特に製品を作っているときに新しいことを学んでいないのであれば、
何かひどく間違ったことをしていることになりますが、
それは別の投稿でまた説明をしますと。
作っている中でも新しいことを学びが絶対に必要だと。
ないんだったら間違ったことをしているということですね。
昔の繰り返しだったりとか、何も改善をしないということになると思うので、
09:04
それはビジネス的には確かに大きい話だと思いますね。
何かしら新しいことをやっている、
新しい何かを築き学びがないことをやっているというのが
一つの間違った方向に行っていますよということの指標になるかもしれないですね。
多くの組織がこの重要な変局点を見逃して、
プロジェクト計画への期待を抱いたまま、
戦略的な計画へと舵を切ってしまうのです。
このような状況にある企業というのは、
期待した戦略的成果というのが得られないことにフラストレーションを感じ、
その解読剤としてよりきめ細やかな計画を推し進め、
予測可能性を最適化することで、
偉大さを達成しようとするのですというふうに言っています。
よくも悪くも、
それはそれできめ細かい計画を進めていくというのは、
よくも悪くもいいと思いますけどね。
ただ大きい対局家に立つと細かいところばっかり言って、
枝端の話ばっかりしてしまうと、
本来やりたい方向に行かないという話はずれ出てくると思うので、
それはよくないと思いますけどね。
ただこの返局点というのをとりあえず見逃すのは確かに大きいことだし、
何も新しいことがないというところが一つの観点として、
なかなか面白いなと思いました。
では続いて5項目ですね。
5つ目の観点ですけど、
Don't Walk to Kill Bad Ideasですね。
Don't Walkじゃない、Don't Waitですね。
悪いアイディアを潰すのを待たないでくださいということですね。
あらゆる計画プロセスにおいて、
何を始めるかという質問と、
何をやめるかという質問は対になっています。
より集中しましょうということですけど、
より少ない矢の後ろに、
より多くの木を置くとかですね。
しかし、
何をやめるかの計画は、
何を始めるかの計画ほどには時間をかけられず、
注目されていません。
されません。でもこれは理にかなっていると。
何をやめるかって結構大事だと思いますし、
何をやらないかの定義を最初にやることってすごく重要だと思いますけどね。
やらないかとやめる、
そうか、別の話ですね。
やらないかっていうのは最初の話で、
やめるっていうのは途中、ランニングしている途中で意思決定をすることですもんね。
物事をやめるっていうことは、
物事を始めることよりもずっと楽しくないっていうのが既定路線です。
かつ、やめるほうがエネルギーがいるっていう可能性が高いだと思いますよね。
やめるっていうことは、
何かを試してみてうまくいかなかったっていうことですよね。
最近の記憶では、
誰もが最も重要なことだと同意していたことがあります。
あまりにも重要なことなので、
これをするために他のことをやめてしまったのかもしれません。
マネージャーとしてやめるっていうことは、
これがあなたにとって最も重要な仕事だと言ったときに、
私はおそらく間違っていて、
これはちょっと間抜けに見えるかもしれないということです。
そんな見方をされることもありますし、
そういう観点はあると思いますけど、
やめることは重要だと思います。
またこの新しいことを始めるために、
急いでいますと、
エキサイティングだし重要だし、
来年の財務計画には、
既にその成功を織り込んである。
早く始めないと、
古いものなど始末や廃棄は後回しだということですね。
このサイクルを何度か繰り返すと、
技術的不採が爆発的に増えて、
技術的不採というものは存在しませんが、
そこは十分です。
12:00
それに伴い、チームの例書も見られるようになるでしょう。
やめるならきっちりやめないと、
不採が貯まるというのは確かに、
本当おっしゃる通りだと思いました。
その代わり、各チームに、
彼らの計画は仮説であり、
彼らの仕事はその仮説を検証することだと考えているように、
強調してください。
そしてその検証作業がどのように行われるかを
尋ねるために定期的な会話を設定します。
彼らは何を学んだのか、
何を否定したのか、
どこで考えを変えたのか、
悪いアイディアを簡単に潰すことが目標だと言いたいのですが、
残念ながらそれは無理なお話です。
アイディアの50%は失敗し、
残りの49.9%は成功するまで、
何度も繰り返す必要があります。
あと0.01%なんだ。
ですから、
アイディアを簡単に潰せるようにし、
悪いアイディアを早く潰せるような話を
簡単にできるようにしましょう。
基準であったりとか、
やめるところのお話を最初に決めておいて、
そこの基準に達したからやめましょうというのが、
合意形成できていると良いのかな、
という風には聞こえましたね。
最初に想像していないようなケースも起きると思うので、
その時その時、
みんなでしっかり話し合って、
やめることはしっかりスパッとやめるというような
意思決定をするのが大事だと思います。
なかなかでも後ほどのカジキをした後、
それをまたリカバリーするというエネルギーコストも
かかるので、
そんな簡単にやめるというのは難しい話ですし、
ビジネス的な話だと、
マネージャーとして意思決定しづらいとは思いますよね。
お金とコストがかかって、
かつ、
もう一回その手順を別の方法で
歩まなきゃいけないので、
納期だったり時間的なところが
すごく制約にかかると思いますけど、
とはいえ、やめることはちゃんとやめないと
後でかかる、後で失うお金を
どんどんどんどん
重ねていくことになるので、
やめる意思決定はやっぱり、
どっかエイヤーでやるしかないんだろうなと思いました。
続いて6個目のアイディアです。
6個目は依存関係を最小化しましょう
というお話です。
依存関係はまたプランニングが
多くの目標に対応しようとすることで
問題が生じる領域にはなります。
これまで述べてきたように
プランニングではしばしば
大きく考えリスクをとって
大きなインパクトを与えるような賭けをすることが
求められます。
また合理的に正確でなければならない
ファイナンシャルプランに貢献することも
求められています。
この相反する2つの欲求が
ディペンテーシーズで出会うということですね。
私は来年
数十億ドルの新企業を
立ち上げるための妥当な説明ができています。
数十億ドルってすごいな。
私が必要とするのは
会社の全員が今やっていることをやめて
私の計画に取り組み
つまり私の依存関係に同意して
さらに私が計画に入れた
1000人ほどの追加雇用
そういえば採用に関する依存関係を
掻き溜めておこうということですね。
そのうちの何人かを
説得して私の依存関係の
1つに取り組むことに同意させることは
できるかもしれません。
これはバカバカしいと思われるかもしれませんが
プランニングでは何度も何度も見られることですよ
ということでした。
仲間に引き入れるみたいなことですね。
チーム間にかなりの
依存関係があることの問題点とか
特に戦略的計画にとって
15:00
重要なチームというのは
機能的に同じチームであるかのように
それらのチームを緊密に結合しているんです。
少なくともこのプロジェクト
計画取り組みなどの
期間中というのは同じチームにするか
クリティカルパス上の依存関係を
計画を設計するものとして
既に動作して出荷されているものを
基礎として計画を構築するよう
人々に奨励すること。
新しい機能そしてそれに対するサポートと
興奮の構築というのは
このプロセス外の資金調達
プロポーザルで行うべきでありますよと。
この計画は新しいものを導入する時期として
不適切であるという
同じブログの項目があるので
そこを参照してくださいということですね。
うーん。資金調達プロポーザルで
行うべきであると。
依存関係を最小化。
依存関係というのが人に関する依存関係
だということですね。これを最小限とどめる
ということでそうですね。
そうするとチームが小さくなるのかなと思ったけど
意外とメンバーを大きくするみたいな話が
出てきたので
ちょっとバックボーンが
ここまで読んできたんですけどバックボーンがちょっと分からないので
これは不運しか思えなかったですね。
皆さんの方でもし解釈できたら
ありがたいと思いますけど。
続いて7個目の項目ですね。
7個目はヘッドカウントの
プランディングがあなたのプランと一致しない
みたいなところですね。
計画、プランディングが
人員計画、ヘッドカウントプランディング
に反映されるのは当然のことで
多くの場合両者は緊密に連携していますと。
プロジェクトそのものの計画と
人員計画というところですね。
結局のところ来年
最もインパクトのある仕事が何であるか
ということが分かればその仕事を遂行する
ためにもおそらく最もコストのかかる
リソースである人員を調整する必要が
ありますと。このアプローチでは
必然的に利害が一致することになります。
チームを成長させようとする人は
しばしば帝国の建設者
のように言われますけど、成長と雇用は
健全なチームの一部なのですよと。
私たちは今チームを
健全に保つためにプランニングを
ナビゲートとゲーム化することの意欲に燃えています。
ゲーム化
多分後で出てくるのかな。
私たちはそのプランニングの持つ高いリスク
っていうのをオフサイクルの資金
調達の提案に移行することで
シフトすることができますと。そうすれば
チームの成長、チームメンバーの成長
プロジェクトは既に処理されていて
会社にとって最善の
全体的な計画を作成するという
共通の目標を持ってプランニングに取り組むことができますと。
さらにポイント3
制約条件とフレームワークで
述べたように既にコミットしている
仕事のコストを低量化する必要もあります。
これによってチームの資金を
維持するためだけに新しいプロジェクトを
立ち上げなければならないというよくある
プレッシャーを回避することができますと。
依存関係を減らすことで誰が依存関係に
必要な人員を要求し、それを
どのように配分するか、その人員は
現在働いている人の数か、
6ヶ月後に採用する人の数かは分からないですけど
という3カード問題というのを
単純化することができます。3カード問題
というワードがあるんですね。
で、最後に
ヘッドカウントというのは
曖昧さを受け入れる必要がある
分野にはなります。性格を
競うとする計画プロセスというのは逆に
混乱と不安を生み出し
18:00
私はかつて年度内の
キャッシュフローを非常に気にしている
企業にいました。そして何週目に
人を雇えるかというのを綿密にモデル化した
人位計画プロセスというのを導入しました。
その年の26週目に誰かが入社すると
給与コストの半分しか年度内に
着服できないからですよと。
スプレッドシートにはチームの人数に対して
何%の権利が確定しているか
が表示されており
将来の人数に対して借り入れが
できるようになっていましたと。借り入れコストの
計算式が十分に複雑で
Windows版のExcelが必要だったため
上級エンジニアのリーダーを全員
採用のためだけに2代目のノートPCを
用意しなければなりませんでした。
無駄じゃね。この高価なリソースを
正確に管理しようとするのは理解できますが
だからこそシニアリーダーであることの意味の定義に
曖昧さに対する
心地よさが何度も現れてくるんですよと。
まあそうだよね。あまりにも厳密にすると
なんかお金とコストかかるんで
逆に言うと多少の曖昧さは
やっぱり心地いいとそれは思うかもしれないですね。
計画プロセスから
人員削減のプレッシャーをできるだけ
取り除いたら次の目標というのは
常に曖昧で不正確であることを
承知の上でシンプルなものを
展開することになります。
なぜこのプロセスが曖昧で不正確なのか
っていうことで言うと
原因というか理由は人なんだよってことですね。
多くの企業では人とチームの
関係、採用済みで入社していない人の
数、インターンの数などを正確に
把握することに苦労しています。
簡単な方法としては
各チームに年度末の
Not to exceed
年度末にこれだけの人数を
チームに揃えることという数字を
与えるというものがあります。
年度末にNot to exceedという
数字を与えるんですね。
やったことないです。
こうすることで年度内に予測される
複雑な人員削減目標を達成しようと
する際に採用を中断することなく
柔軟に対応することができます。
採用中断することは
優れた採用プロセスには候補者の
健全なパイプラインが必要であって
構築に時間がかかってしまい
採用中断すると
日上がってしまうという問題です。
人員削減のお話は
日本だとあまり聞かないから
あれかもしれないですけど
海外は普通にレイオフとか当たり前に
ありますからね。
しかし健全なチームが
プランニング時にコミットしたこととは
別に成長する必要がある場合
どのように解決すれば良いでしょうか。
健全なチームがプランニング時に
コミットしたこととは別に
成長する必要がある場合
またなぜそれを
気にする必要があるのでしょうか。
それは新しい人がチームに
加わることで、新しいアイディア
新しいスキル、経歴、指導を
受ける新しい機会、新鮮な
エネルギー、そして誰かがあるいは
複数の人が抜けた時の
チームの継続性が生まれる可能性があるからです。
ゲームプランニングにプレッシャーを
かけることなくチームの成長を
実現するためには
予算の20%のチームがオフサイクルで
プランニングすることを提案できるよう
かなりの割合を予備として確保することが重要です。
ボトムアップの提案を見ると
すでに割り当てられた予算の
200%に達している場合
かなりの割合を保留することは
21:00
苦痛になることがあります。
しかし今回説明する経験則で基づいた
プランニングを実施すれば
選択肢は広がります。
新規事業のための資金調達の提案だったり
一般的な成長のための計画プロセス
そしてチームを健全に保つための
臨機応変で有機的な雇用のための
例外的プロセスですよと言っていました。
プランニングが一致しないのは当然ですし
プロジェクトを走っていったら
どんどんどんどん実際の
お話はかなり変わってくるので
最初から予算20%をオフサイクルで
適用できるように提案するのは確かにいい話ですけど
20%で足りるかどうかは
ちょっとわからないですね。
またボトムアップの提案だけを
判断にするとそれはやっぱり危険な気がしますので
難しいですねこれはでも
採用の話が結局どうしたって
加わってくると思います。
プランニングするからには。
最初からプランとか
計画した人数だけで走り切るのは
もちろんできるかもしれないですけど
ビジネス加速させるとか大きいチャレンジを
するためには必ず人を採用しなきゃいけないなと
もちろんその通りなので
そのためのプランニングを
するっていうのはまたそれをそれで大変ですよね
採用中断すると
なかなかビジネス加速するのは
大変ですけど加速させるからには
いろんなものを整備しなきゃいけない
っていうところはかなり難しいですね。
また海外ではチームごとに
Not to Exceedってさっきやったとおりですけど
どれだけ人が必要だったらどれだけの
利益の話っていうのを結構考えてるんですかね
日本だとあんまりそういうのを考えてる
印象がないというか日本って大きい主語だ
しましたけど日本的にお金回りは
営業とかプロジェクトマネージャーの方が
考えてて現場の人はあんまり
意識をしないというかどっちかというと生産性を
上げたりとかいかに早く
デプロイまでするかということを考えることが
多いと思うんですけど
これが結構意識の差があるのかもしれない
ちょっと思いましたね。その上で
現場の人からの
意見が出てくるっていうのはいい話だと思いますけど
続いて
ラストですね9個目です
お金が目的ではない場合どうすればいいか
というところです。技術系
ではお金に射止めをつけない会社があります
リソースは今のところ制約されていない
成功の確率を
考えて経営額を評価
する必要なものがないと。このような
会社の人たちと話すと
私は超成長企業に14ヶ月
ついで私のチームは毎日
100%成長したと
レイオフされるまでというようなことを言うそうです
ちょっと面白いですね
レイオフされるまでってなかなか面白いですね
このような会社ではそのボトムアップのアプローチが一般的
ですよと予想はつきます
超成長企業っていうのは超成長後に
成功しようとしている企業での
私の経験から
すべての行動、すべての製品、すべてのマーケティング資料
すべての成果物には
たとえ削除するコストだけでも
長期的なコストがかかるということを忘れてはならない
まあそうかもしれないですね
駆け上がって成長した企業
っていうのは多分いろんなものを抱えて
今でも成長したっていうのはあるので
後ほど削除するコストっていうのが
意外と長くかかるということは忘れちゃならないよということですね
ほとんどの人が驚くほど
難しいことだと思いますけどもね
これはそうと思います
特にハイパーグロス環境において
あるいはお金や人数が目的ではない場合
より良いプランニングが必要です
24:00
まずなら唯一の制約はあなたの思考の質だけだからです
これは本当におっしゃるとおりですね
だからやっぱりボトムアップアプローチ
は一般的
こういう企業には一般的でしょうけど
ちゃんとトップダウンで縛るところは
縛っていかないと危険だなって感じがします
やっぱり人依存な
お仕事をするっていうのはやっぱり危険が
すごく伴うなっていうふうには聞こえました
はいじゃあラストですね
ではなぜ私たちは計画を立てるんでしょうかと
今までこんないろんな考えることだったり
制約だったりリスクだったり
わちゃわちゃっていうのがある中
なぜ私たちが計画を立てるのかっていうのは最後結論っぽいですね
これから取り組む新しいプロジェクトの多くや
その仕事の影響
予算の大半をすでに配分し
何も新しいものを導入しないことを目標に
計画に入るんだとしたら
そもそもなんで計画する必要があるんでしょうかってことですけど
このモデルにおいてはプランニングには
2つの重要な目的があると
1つ目はマルチスレッドな会社を
同期化させるためのポイントとして
機能することです
私たちは1年中さまざまなチームや機能が
緩やかに結合して活動しています
そのため自分たちがやっていることをできる限り
包括的に把握するための時間を設けることは
私たちがバラバラになりすぎないための
重要な投資なんですよと
それがプランニングなんですと
これは分かりやすいですね
自分たちがやっていることとか
それがどういう効果があったりとか他のチームとの影響とかっていうのを
包括的に把握するってのがすごく大事なことで
それのために時間を設けるっていうのは
投資だとして
でもその投資は必要な投資だと
それがプランニングの1つだと言ってます
2つ目ですね
もう1つは強制的な機能になりますと
自分たちはみんな忙しく
時には期限と人が求めなければ
求めなければ物事が進まないことがありますと
そうですね期限を設けないと
結構ダラダラしてしまいがちな時もあったりするので
必要はありますよねってことです
計画を立てることってのはすごく重要で
これまでに吸引する必要はないんですけども
そのためには計画プロセスの複雑さというのを
やはり減らしてやることを少なくして
その上でプロセスを動かしている
ハードウェアである人間のことを考慮する必要があるんですよ
っていうことでした
はいっていうので結論でした
以上ちょっと長かったですね
やっぱりこの記事長かったし
ちょっと抽象的なお話だったりビジネス観点の話が
かなり多くてですね
僕もこれ記事読みながら
50%くらいしか多分理解できないです
不運と思いつつもなるほどと思いつつも
どういうことを言ってるのかちょっと意図が
読めないみたいな感じがよくあると思うので
これは改めて皆さんの方にも
原文をちゃんと英語で読む方がいいかもしれないです
一応僕ディープエールで翻訳したものを
バッと読んでますけど
なかなか読んでてわからないことも多かったし
ディープエールの限界ももちろんあると思うので
ここは原文読むのが多分良さそうですね
ただこういう
ソフトスキルバンバンのところの
お話っていうのはすごく大事なことであって
かなり経営観点での
お話がすごく多かったので
これはすごくビジネスマンとして
良い教材になるんじゃないかと
僕は思いました
改めてこれはちょっと自分の方でもチャレンジしてみたいなと思いますし
このブログの中でもいろんな記事の
リンクを貼られているのでその辺
とても参考になりそうなので読んでみていただければと思います
ではですね
時間過ぎてしまいましたけど朝カツはこれで終了したいと思います
はい明日はまた
予定通り戻りまして
27:00
昨日読んでたリミックスの
ブログですねに貼られてあった別のブログを
ちょっと読んでみたいのでちょっとテクノロジーな
ブログ記事じゃないです朝カツになると思いますけど
応用していただければ幸いです
ではですね今日も
たくさんの方朝からですねご参加いただき大変にありがとうございました
はい水曜日
中日ですね折り返しですけども
頑張っていけたらなと思いますそれでは終了したいと思います
ありがとうございました
