00:04
8月2日、火曜日ですね。
地獄あさくじを回りました。
今日もめちゃくちゃ暑くなりそうな日ですね。
はい、おはようございます。
ひめめのkeeth家族の原です。
本日も朝活を始めていきたいと思います。
めちゃくちゃ暑いんですけど、
全然蝉が鳴かない感がすごくてですね。
まあ、僕の住んでいるところなんですけど。
なので、今年の夏どうしたっていう感じはちょっとありますね。
はい、ということです。おはようございます。
いつも皆さんご参加いただいてありがとうございます。
ナイチさんとネブさんとヘイリンクさんですね。
はい、ありがとうございます。
今日はタイトルにある通りですけど、
Learn the weekly rituals you should master as a software project managerということで、
プロジェクトマネジメントに関するブログを見つけたので、
ちょっと技術的な記事を読もうと思ったんですけど、
心が入れてしまったので、
こっちを今日は読んでいこうかなと思います。
何かしらソフトウェア業界でマネジメントする仕事をしている方って結構多いと思いますし、
キャリアが重なるにつれて何かしらやることにはなると思うので、
損はないでしょうみたいなところもありつつ読んでいこうかなと思いました。
では早速入っていきたいなと思います。
今日はプロジェクトマネージャーの1週間の生活を取り上げたいと思います。
私がプロジェクト管理をするときに毎週やっていることだということですね。
へー、なるほど。
次のマイルストーンを特定するっていうのが1つ目ですね。
1ヶ月以内のゴールはありますか?
ない場合はできるだけ早く作りましょう。
チームとのミーティングの度に次のマイルストーンについてはしっかり話しましょう。
というのが1つ目です。
2つ目はプロジェクト計画を更新しましょうということですね。
毎週金曜日に1時間ぐらいプロジェクト計画を見直し、更新する時間を設けましょう。
3つ目はリスクレジストリというのも更新しましょう。
これはプロジェクトの計画期間中にリスクレジストリというのがあって、
それを更新していきましょうということですね。
常に見直しをしましょうということです。
最後4つ目です。
4つ目は毎週プロジェクトの最新情報を送信しましょうと言ってます。
プロジェクト計画とリスク登録の更新後、
私は自分が担当しているすべてのプロジェクトの状況をまとめた最新情報を送ってますよと言ってますね。
素晴らしいですね。
特に4つ目は素晴らしいなと思います。
PMの方々って結構忙しいことが多くて、
いろんなコミュニケーションとかやり取りしなきゃいけなくて、
とにかくそういう情報を送ることを忘れてしまったりするので、
今プロジェクトどうなってんのっていうのが、
1プレイヤーからすると不安になることもあるので、
この4つ目は素晴らしいですね。
これらのことをまとめるにはしばしば会議とかコミュニケーションが必要になります。
しかし毎週何を提供するのかを具体的に把握することで、
何に注力すべきかがより明確になるので、
冒頭は一旦そこにして実際に入っていこうかなと思います。
はい。
じゃあいきましょう。
1つ目のセクションは、
Identify the Next Milestoneですね。
次のマイルストーンを明確にしましょうというところです。
03:00
人は近くて分かりやすい目標に向かっているときに、
最も効果的に働くものです。
1ヶ月以内のマイルストーンに取り組むと、
より生産的で効果的な仕事ができます。
また複雑な作業を管理しやすい大きさに分割することもできます。
人々はその程度の仕事であれば、
理性的に考えることができます。
そしてその目標に向かって、
より効果的に働くことができるのです。
ほとんどの州は、
次のマイルストーンがすでに特定されているはずです。
それは特に素晴らしいことですよと言っています。
しかしそのマイルストーンがもうすぐ終わる、
あるいはプロジェクトで状況が変化することはよくあることで、
あるいはプロジェクトが十分に分解されていないため、
マイルストーンがすぐに設定できないみたいなことも
よくありますよと言っていますね。
はい。
まあまあこの辺は絵手して、
状況によりますしコンテキストによるかもしれないですけど、
常にその辺のマイルストーンとかその辺は
明確にするのは大事だし、見直すことも大事ですよね。
はい。
戻りますね。
なぜ1ヶ月なんでしょうかと。
簡単に言うと、
私自身の経験と限られたデータから得られた証拠から
このように考えているからですと。
この点についてはプロジェクトではなく、
マイルストーンの記事を書いているので
そこを詳しく見てみてくださいと言いました。
マイルストーンのプロジェクトという記事のタイトルがあるので
そこも見てみてくださいと言いましたね。
長そうなのでこれは後ほどツイートします。
はい。
私はプロダクトマネージャー、デザイナー、
そしてプロジェクトの技術的な輪郭について
最もよく考える人たちを部屋に集め、
マイルストーンを特定したい旨を伝えることを
お勧めしますと。
はい。
1ヶ月以内に達成できるマイルストーンは何がいいでしょうか。
いくつかの候補を挙げて一番気に入ったものを選びましょうと。
はいはい。
なんかすごいスクラム的な考えですよね。
MVPを決めましょうってことですよね。
はい。
必ず1ヶ月以内のマイルストーンが必要だという制約から始めましょう。
マイルストーンがない場合、またはマイルストーンが終わりそうな場合は
次のマイルストーンを確認します。
プロジェクトを分割する技術については
マイルストーンの記事を参照してくださいと。
はい。
そしてこれは本当に必要なスキルであることを忘れないでください
というところですね。
はいはいはいはい。
なるほど。
まず先にこのセクションに入るってことは
本当にちゃんとマイルストーンを切るっていうのが
今この人にとってまず最優先というか
第一にやるべきことなんだろうなっていう風な
風に僕は受け取りました。
はい。
やっぱりこの技術を身に付けるには
やはり時間と練習っていうのがやっぱり必要であり
でもそれぐらい本物のスキルであるってことを忘れないでください
っていうのが念を押されて書かれてるので
とても大事なんだろうなと思いますね。
しっかり細かく分割をして
マイルストーンをしっかり切って
それをしたら見直しをするというところですね。
はい。
今のが一つ目でした。
次のセクションですね。
次はアップデートやプロジェクトプランですね。
プロジェクト計画の更新っていうところです。
はい。
私は毎週自分のプロジェクトを更新する時間というのを予約しています。
06:01
ほうほうほう。
プロジェクトプランを見直し
それが現在の私の考えを反映しているかどうかというのを確認します。
そしてそれがまだ現実的であるかどうかを自問します。
そしてプロジェクトの残りの時間について考え
遅延やリスクの原因になりそうなことというのも考えます。
希望的観測はあなたの敵になります。
会議的な視点で全てを見ましょう。
これが自然な人もいれば練習が必要な人もいます。
これは多分練習必要だと思いますね。
プロジェクトプランを更新するために
他の人からの情報が必要になることというのもあります。
私は通常チームごとあるいはプロジェクトごとに
週1回のビーティングを予定しています。
プロジェクトごと、チームごとにですね。
でも週1回なんですね。
毎日やるもんじゃなくてデイリーやるんじゃないんだと思いました。
デイリーとかはチーム内で完結してくださいということで
その辺で出てきた情報だったりアラートを書き集める感じですかね。
このミーティングでは主要なリーダーに出席してもらい
今後2週間を詳細に説明し、私の現在のプロジェクトプランの考え方を示し
批評してもらいますと。
その後さらに次の未来について説明しますが
先に行くほど忠実度は少し下がりますと。
通常プロダクト、テクニカルリーダーシップ、デザインの各担当者を
とりあえず招いてそういう話をしますと。
これも結構いいことですね。
ちゃんとしっかり批判をしてもらうというところが重要ですね。
だから本当に言ったんだからやれよっていう
上から目線のわけではないところですね。
プロジェクトごとに週1回のミーティングというのは
ただのリーダー陣を集めてどうなのという
大枠的なところの話をしたいという感じですね。
細かいところとか具体的な話は各チームに完結してもらってということですね。
どうでもいいと思いました。
これらのミーティングはかなりハイレベルに保つようにしていますと。
ハイレベル?
参加者にとって時間の無駄にはならないようにしたいものです。
私はこの活動をより大きな目的を持った会議に参加させるのがベストだと考えています。
例えばローカルチームのリーダーシップミーティングでは
毎週5分から10分程度この活動をカバーするかもしれませんと。
ああ、なるほどね。
ローカルチームのリーダーシップミーティングでその5分から10分ぐらいで
この活動、今やろうとしている活動をカバーできるかもしれませんと。
しかし時間の大半は他の事柄、例えば自分たちが懸念していることや
改善すべきことを話し合うかもしれませんと言っています。
それもありますよね。
結果なんだかんだ課題点問題を話し始めると
ボロボロ影響するものだったり関連するものが出てきて
それについて議論しちゃいますからね。
しちゃいがちか。
プロジェクトマネージャーのアンチパターンの一つは
常に情報を求めて人にプッシュする癖がついてしまうことだと。
これは迷惑けやまりない。
プロジェクトマネージャーが情報を得るために安価で済むようにしましょう。
また、自分が観察していることを表に出すように促すことで
あなたが情報を更新する必要がなくなることもありますと。
09:01
メンバーが勝手に情報を出してくれたり更新してくれるかもしれません。
コミュニケーションはプル型からプッシュ型に
切り替えるのが望ましいと思いますと言っています。
いいと思いますね。プッシュ型になるというのは本当にいいと思いました。
それぞれの担当とか責務を持っている人たちが
自分たちの情報をプッシュ型でどんどん出していくというところですね。
問題はそれが情報を流れていったり
情報が煩雑になってしまう可能性があるので
そこをしっかり使者選択してまとめあげるのが
プロジェクトマネージャーとしての
腕の見せ所みたいなところがあると思いますけど。
でもプル型よりもプッシュ型の方が僕もいいと思いましたね。
結局聞けばこの人持ってたんだけど後から知ったので
みたいなことはよくある話なので
メンバーが自発的にプッシュ型で出せるようなチームを作るのも結構
難しいけどとてもいい話だなと思いましたね。
以上2つ目。今のがUpdate Your Projectsプランですね。
やっぱりプロジェクトマネジメントの
記事ってだいたいそうだよねとか
共感味あるなっていうことばっかりなんですけど
やっぱりこの記事もそんな感じしますね。
これは世界共通同じような波にみんなぶち当たるんだろうな
という気はしました。余談ですけど。
じゃあ次行きましょう。続いて
What should the project plan look like?
プロジェクトプランはどのようなものにすべきでしょうか?
すべき論を語るのはむずいと思うんですけどちょっと読んでいきましょうか。
私はプロジェクトプランを週単位で作成しています。
ということはこの人はスプリントは基本的には
1週間単位でやっているということですね。
各週にはいくつかの箇条書きがあります。箇条書きは
その週のデモを予定する内容だと言っています。
デモには技術なものも含まれます。
提供するものの説明はできるだけ顧客に焦点を当てたものに
でもしたいなと思っています。
またプロジェクトのデリバリーに関する時間を
関連する時間ベースのイベントももちろん追加しています。
例えば休暇、オンコールスケジュール、オフサイトなど
みたいなことも全部箇条書きで書き連れています。
今僕の画面を開いているので
見えているんですけど
トップにプロジェクトプランって書いてあって
そこに赤線が引いています。その下に
Week of 何月何週みたいなところですね。
ここに青いラインが入っていて
その下に箇条書きで書いてあります。
次にまたWeek of 何月何週みたいなので
青いラインで何月何週というのが
一つのブロックになっていて
その下に箇条書きでバババって書いてあるのが
ずっと連なっているという感じですね。
こんな開発はただ単にメモなんですね。ざっくりと。
でもないよりはあった方がいいと思いますし。
赤と青というところが結構面白いですよね。
赤は危険だけどここが重要だというところを示していて
青のところで
人間って青い色を見ると心が落ち着くみたいな心理的
なんかあったはずなので
色の使い方も個人的にはいいなと思いました。
12:00
本文戻ります。
プロジェクトプランの目標というのは
いくつかの箇条書きよりも具体的でないことです。
プロジェクトプランの目的はいくつかの箇条書きよりも具体的でないことです。
not specific the couple of bullet pointsですね。
ちょっとわからん。
簡単に変更できる計画であることが望ましいよと言っていました。
要は具体的に書いておいて
簡単に書きかけられる方が望ましいと言っています。
プロジェクトが具体的であればあるほど
それを変更するためのコストが高くなります。
良いプロジェクト計画とは議論のための道具であり
変更を阻止するのではなくむしろ変更を促すものであるべきだ。
と私は見ています。
ってことはあまり具体的にしない方がいいってことかな。
私はプロジェクトの成果物がたくさんあり
更新が必要なものを見ると疑心暗鬼になります。
これはみんなそうだと思います。
ガンドチャートっていうのは効果的なコミュニケーションツールではあるんですけど
その根底にあるデータが変更しにくいことを示しているというのはよくあります。
と言っています。
ガンドチャートはそうかもしれないな。
変更はしづらいしその裏にちゃんとデータがあるみたいなことは
ガンドにはまず見えないですからね。
気をつけなければいけないのは
多くのエンジニアリングチームが一つのプロジェクトにつき一人で作業していることです。
そんなのは怖いですけどね。
チームをプロジェクトの納品単位として利用できればより良いですけどね。
これは深い話なので今はあまり触れませんが
一般的に各人が何をするのかが明記されているプロジェクト計画を見ると
そのプロジェクトは不必要に脆いというような
サインだと捉えています。
そして過度に専門化し
知識の共有が十分に行われないチームになってしまいます。
まあまあ依存度が高くなってしまうし
職人をどんどん生み出すことになってしまうので
それは確かにチームとしては脆いですよね。
冗長化できないということですからね。
これは小さな会社では適切かもしれませんが
そうでなければ私はお勧めしない傾向になります。
リソースの分布層の配分を見たら
私は通常叫び声を上げバッグからライターを取り出して
壁に火をつけ部屋から飛び出してしまいます。
意外と海外の方の
この辺の言い回しは特に面白いな。
そんなことをするんですね。
管理するプロジェクトの数が少なければ少ないほどより良い仕事ができるようになります。
ですからチームがより少ないプロジェクトに集中するための
もう一つの主張が今の話だよと言っていますね。
あともう一個ですね。
2週間のスプリントを行うチームでは1週間ごとのプロジェクトプランが必要なのかと聞かれることもあります。
もちろんそれはあなた次第ですが
私なら週単位で行います。
2週間スプリントであっても1週間単位でプランニングします。
そうでないと物事が順調に進んでいるかどうかがほとんど見えません。
もし私が2週間のスプリントベースでやっていたら
チームにこれは最終金曜日までにデモができるかどうかを示す計画ですと
伝えますと言っていますね。
やっぱり事細かに見ていくというのが重要ですし
15:00
チームというのは水ものなのでどんどん状況とか環境が変化していくので
そこをしっかり見ていきたいというところですね。
この方は。
でも2週間って確かに結構大きいですからね。
2週間全体のしっかり進捗だったり振り返りとかしないまま走るって結構怖いと思います。
はい。
また1週間単位でやることによってやっぱりリズムも生まれると思うんでね。
人はあと時間があればちょっとぐだって
だらだらやってしまう傾向も正直あるのでね。
これはブーメランですけど。
続いてWhat should your risk registry look like?
という最後のやつですね。
次のセクションに行きたいと思います。
リスク登録はどのようなものにすべきでしょうかというところですね。
プロジェクト計画を更新するときには何がうまくいかない可能性があるか
というのを自問自答する必要があります。
以下は自分自身や他の人に質問することで
良い計画を立てるための方法になります。
この方法は4つ書かれてますね。
1つ目はこのプロジェクトで最も失敗しそうなことは何でしょうかと。
2つ目は過去に似たようなプロジェクトがあったか
その際にどのような問題があったか。
3つ目このプロジェクトで起こりうる最悪のケースで
実際に起こりうるようなことは何でしょうかと。
最後4つ目ですね。
このプロジェクトがうまくいくかどうか今月の給料をかけるとしたら
どんなことを心配するだろうかと。
4つ目の観点は面白いですね。
今月の自分の給料をこのプロジェクトにかけるとしたら
今どんなことを心配しますかと。
これは自分視点にさせるという問いとしてかなり面白いですね。
なるほど、自分の給料をこのプロジェクトにかけたら
何を心配するかってことですよね。
いやーでもこれ本質的だというか
みんなガチな話を出してくれるんでこれいい話ですね。
なかなか新しい発想だと思いましたね。
リスクマネジメントとはバランスを取ることに
他ならないと言っています。
多くのリスクに対して過剰な投資をすべきではありません。
しかしリスクは考え抜かなければなりません。
新しいリスクを思いついたら
登録リストがあるのでそこに過剰を書いて
どんどんリストアップしましょうと。
そういうプロジェクトマネジメントのやり方を教えるんですね。
リスクレジストリという壁に項目があって
そこに各人が勝手に書けるような
リスクのリストバーで用意しているんですね。
今は僕には画像を見ているんですけど
いろんな人たちがいろんなリスクを
過剰書きでひたすら書いていますね。
タイトルとざっくり概要とそれに起きる影響だったりとか
どれぐらいのビジネス的なコストからみたいなことですね。
これ確かに大事ですね。
プロジェクトの開発をやっている途中でも
こういうリスクがあるとかこの辺やっぱり懸念事項があるなっていうのを
リストアップしておくのがすごく大事だと思いましたね。
今だとノーションとかジラのツールとかあるので
その辺にリスクレジストリ
日本語にするとなんか分からないですけど
っていうところを書いて一覧にしておくと
18:00
そこをマネジメントする側としては
ここにリスクがあったりするのでっていうのを把握できるんで
プロジェクトは普通はやるのか分からないですけど
僕は今までそんなにやったことなかったなっていうのがあるので
なんかもやもやリストみたいなのを一応作っていて
各プロジェクトに今この辺にもやってるんだよね
リスクっていうことじゃないけどなんか起きるかもしれないとか
ここちょっと不安だなみたいなそのもやもやリストっていうのを
僕はこのプロジェクトをマネジメントするときに書かせてたので
これ結構いいと思ってたんですよね。
これをもうちょっと明確にリスクがあったようにしたのが
リスクレジストリっていうやり方なんだろうなと思いました。
余談ばっかりですね。すみません戻ります。
各リスクについてあなたまたは他のリーダーグループっていうのは
そのリスクを経験するために何か行動を起こすかどうかというのを
決定してください。リスク登録ですね。
リスクレジストリの次にそれぞれの計画を列挙してください。
あるいはリスクを受け入れるかどうかっていうのも書いておいてください。
これも大事ですね。そのリスクは今回は飲むのか
っていうのは確かにプロジェクトとかビジネス的観点で重要ですし
全部を解決できることが、もちろんできれば
それが理想なんですけどできないこともあるので
飲み込んだ代わりにどう対処するかみたいなのが次のアクションが出てくるので
確かにそこを表明しておくのもすごく大事ですね。
なるほどなぁ。学びになりますね。
またリーダーシップグループがうまく機能していれば
そのリスクとそのリスクを軽減するためのコストについて
合理的な議論もできますと。そのリスクレジストリを
導入する際にはそのリスクを軽減するためのコストについて
話し合い、どのようにリスクを軽減するかだけではなく
軽減したいかどうかについても必ず話し合うことを
お勧めしておきますと。
人によってそのリスクの軽減するかどうかみたいなところの
重みだったり優先順位が結構変わったりするってことですね。
さすが。はい。
以上、今のガイドリスクレジストリのお話でした。
続いて、これ次ラストかな。
次のセクションはプロジェクト、
Writer Weekly Project Updateですね。
プロジェクトの終時更新を書きましょうってやつですね。
プロジェクトプランとリスク管理表を更新した後、私は
プロジェクトの現状をよく理解しますと。そこで今度は
その状態をできるだけ簡潔なフォーマットで共有することで
周りの人たちを助けていますと。
Weekly Updateの目的っていうのはプロジェクトの全てを
共有することではありません。また自分のチームがいかに
プロジェクトアップデートに取り組むと文章が読むのに
絶えないようなものになってしまいがちですと。
そうではなく、読み手のニーズっていうのを重視して
必要になるあなたのところに来て、もっと長い話ができるように
ちょうどいい情報を提供するんですと。
質問があればいつでも投げられるようなウェルカムの
情報にしておきます。ただ、簡潔に概要とか状況の
言いたいことはまとめておいて、読み手のコストを
かけないようにするっていうのはすごく重要ですよね。
かつまた、みんなが欲しいと思っている情報をちゃんと
この人も考えて多分流しているのかなというところで。
21:00
ここ結構すごい時間かかりそうだと思いますけど
大事なことなんですが、素晴らしいなと思いました。
次のツイート。このツイートは、
簡潔で読みやすい更新文を書くことについて
私が長年に渡って学んできた多くのことをまとめています。
また素晴らしい例も紹介しますので、ぜひ一度目は
お勧めしますと。ここでツイートのリンクが
貼られていますね。たぶんここのツイート
はいはいはい、1 N分の1って書いてあるんで
スレッドでずっとひたすら書き継がれているんでしょうね。
どんなことになるかわからないし、僕もまだ見たことないんですけど
後ほどこのツイート内容自体はリツイートしておきますね。
参考になればなと思いながら後でリツイートしておきます。
ただ、Likeが9200とかあるので
かなりすごいですね。投稿自体も
今年の6月27日で
1万近く9000ツイート、Like来ているので
すごく大事な話をしているなと思いました。
では戻ります。
1つ強調しておきたいのは、あなたが中立的な
立場の人間であるべきだということです。客観的で
リスクについて率直で偏見なく物事を明らかにすることです。
プロジェクトプラン、リスク登録
そしてプロジェクトの現状を示すリンクなど
情報源へのリンクなどが含まれている必要もあります。
アップデートを書いたらそれをステークホルダーに送りましょう。
メーリングリストとかスラックのチャンネルを利用すると良いでしょう。
新しい人が簡単に情報を追えるようにしたいものです。
おそらく誰がそれを有用だと思うのか驚くことでしょう。
あなたのアップデートを有用だと思う人が
社内の他の部門にいるかもしれません。
これらの更新はあなたの周りの人たちが効果的に活動できるようにします。
あなたの上司はプロジェクトの状況を知ることができ
あなたの仕事を代表して会議に参加することができます。
もしくはあなたはこのことが彼らにとって
どれほど役に立つか想像もつかないでしょうと言っています。
あなたに依存している他のチームは
最新情報を得るためにあなたに連絡する必要もなくなります。
これは非常に素晴らしいコミュニケーションの足場となります。
お礼の手紙もらえるかもしれません。
これは場合によりますね。
私自身に問い合わせをするのではなく
情報はここにあるのでここを見てくださいということが一つにまとめられているのであれば
それは素晴らしいことですね。
ちなみにこれらのアップデートはプロジェクトの管理能力を示すのにも役立ちます。
私はプロジェクトの更新というのは他のプロジェクトマネジメントを行うための
良い強制機能だと思っています。
毎週更新しなければならないことを知ることで
他のすべてのことをする時間を取らざるを得なくなります。
そういうケツを叩くみたいな環境を作っておくということですね。
理想的に更新は1,2ツイート程度の長さにすることです。
なるほどね。
Twitterのツイートというのが一つの基準なんですね。
なかなか面白いですね。
みなさんがツイッターしているという前提ですよね。
そういうコンテキストがないと通用しないと思うので面白かったです。
更新は1,2ツイート程度の長さにすることです。
すごく簡潔にまとめるということですね。
280文字以内か。
詳細な情報は必要ありません。
24:01
質問がある人はあなたに相談するだけでいいのです。
では最後、サンキューのところで。
私はプロジェクトマネジメントとは長い付き合いで、
過去にはプロジェクトマネジメントソフトウェアというのを
ブログで書いたこともあります。
しかし、誰だ。
ブジョン・フリーマン・ベンソンという方がいらっしゃるそうです。
この方が良いアップデートを書くための
詳細な情報を私に叩き込んでくれたのです。
彼は編集者として毎週どうすればより良いものになるか
というのを教えてくれました。
表紙の画像はガード・アルトマンにお願いして作っていただきましたよ
みたいなことで謝辞を述べて終了しています。
というところです。
当たり前のこともあれば、
新しい視点というかアイディアをもらえたので
結構僕としては勉強になって良かったなと思いました。
皆さんの情報になれば幸いですし、
いくつか貼ってあったリンクで
一緒にこの後ツイートしていこうと思いますので
もし興味ある方は見てみてください。
ではちょっと短いですが、
今日の朝活は以上にしようかなと思います。
今日もたくさんの方ご参加いただきありがとうございました。
また明日も何か僕が学びたいものをどんどん読んできていますので
興味あれば聞いていただけると幸いです。
では火曜日ですね。本日もお仕事一日頑張っていきましょう。
お疲れ様です。
