00:02
はい、7月2日日曜日ですね。
時刻が昨時34分になりました。
えー、ちょっと今日は、声小さめでやっていきたいと思います。
というのも、ちょっと隣でですね、うちの嫁が別のなんか収録、配信をちょっとしていてですね、
はい、まあその音声、邪魔しちゃいけないなと思ってので、今日は小さめな音声でやっていきたいと思います。
はい、おはようございます。ひめみどきーすことふわはらです。
では、本日もあさかつ、始めていきたいなと思います。
本日はですけども、まあタイトルあります。
「進捗をやめるとうまくいく」っていうタイトルの記事なんですけど、
そんなに長くないノートブログになりますが、
なんかまあタイトル的に面白そうだったっていうところで、
なんか読んでみたかったので、読んでみようと思います。
なかなか、進捗確認ってすごく大事だろっていう、
なんか、いやむしろやめたほうがいいよっていうのは、タイトル的にですね、目を引くと言います。
なんかインパクトあったのでね、うだうだ言っちゃいそうなので、早速入っていきたいと思います。
ではでは、いきましょう。
進捗確認をやめるとうまくいく、というタイトルです。
プロジェクトマネジメントといえば進捗確認と思っている人もたくさんいると思いますが、
私は進捗確認という行為そのものに否定的ですと。
このエントリーでは進捗確認という行為がいかに無意味であるかという話、
および進捗管理として行うべきことっていうものを書いていきたいと思います。
誰かのプロジェクトマネジメントの参考になれば幸いだと思っております。
もちろん進捗管理が不要という話をしたいわけではないよってところだけ注意してください。
進捗確認のまず定義からいきたいと思います。
このエントリーでは進捗確認ということを以下の定義という風にしていきたいと思います。
複数人が関わるプロジェクト等においてプロジェクト等をマネジメントするべき立場にある人間が
プロジェクトの所属メンバーに対してタスクの進捗状況を口頭およびテキストなどで
直接確認をする行為のことを言いますと。
もう一回言いますね。
複数人が関わるプロジェクト等においてプロジェクト等を
マネジメントするべき立場にある人間がプロジェクトの所属メンバーに対して
タスクの進捗状況を口頭もしくはテキストなどで直接確認する行為のことを言います。
少し難しい言葉で書きましたが、
いわゆる進捗等といった質問およびその回答からなる一連の流れだという風に思っていただければ良いと思います。
定義とか言葉的には難しく書いてしまうんですけど、
いつも通り僕らがよく感覚として感じている進捗等というところの質問および回答だと思ってもらえれば良いと。
ではなぜ進捗を確認したくなるのかという次の話ですね。
プロジェクトマネージャー、いわゆるPMの仕事の一つに納期の管理というものがあります。
この納期を守るために進捗管理というものが必要になります。
そしてその手段の一つに進捗確認を取り入れる人も多いと思います。
ではそもそもなぜ進捗確認が必要だと感じるのでしょうか。
その理由の多くはPMの不安からになります。
納期に間に合わないのではないかという不安を払拭するために逐一進捗状況を共有させるわけです。
ただ本当にその行為には意味があるのでしょうかというところですね。
PMの不安だけではないと思いますし、クライアントだったりとかステークホルダーだったりとかの方、もしくは発注元とかいろんなこと言えますけど、
03:00
進捗を管理するマネージャーの人ではなくてそれを届ける先、もしくは依頼先の人にも不安を払拭させるために報告をするというのが必要だと思いますし、
ある意味でリスクヘッジになりますよね。
なんか進捗が良くなかったりとか、実はこういう問題が起きてますよっていうのを共有確認をするためにやるっていうのもそういう側面もあるかなと思いました。
では続いて、進捗確認には時間がかかる上、精神的負担が大きく、さらには何も生み出さないというところですね。
進捗確認で忘れがちなのは、それそのものにもかかるコストがあるよというお話です。
メンバーだったりPM、それぞれの時間が取られるのは当然のこと。
PMとしては気軽に聞いたつもりの進捗どうですかという質問は、実はメンバーにとってはかなりの精神的負担を伴います。
そうだよね。
タスクなんて遅れるのが通常ですし、とはいえ遅れていることを素直に報告すると怒られてしまいます。
つまり進捗どう?という単純な言葉を投げかけるだけでメンバーの生産性を大きく下げる上、その質問に対して回答している間の作業は全て止まってしまいます。
さらには進捗状況が悪い時に、なぜ進捗が悪いのかといった質問を投げかけるPMも数多く見てきましたが、この質問は本当に無意味です。
普通に仕事に取り組んだ結果として進捗が悪いわけで詰めるような質問を投げかけられたところで答えようはありません。
PMが満足できる答えにたどり着くまでにその問答が続くことはよくありますが、これは本当に時間の無駄です。
全てストップして、メンタルも下げて、その上何も解決しないみたいなことにもなりかねないですから、本当に無駄でしかない。
その時間に少しでも多くの作業を進めた方が、プロジェクトは確実に前に進みます。
さらにはこの進捗どう?という質問は下記のような事象を引き起こします。
1つ目に正確な進捗を隠すようになる。
2つ目に作業の見積もりに嘘が増える。
3つ目に作業そのものの質が下がるという可能性がある。
詰まるところ進捗確認に対しての恐怖ゆえに進捗を隠したり、よりバッファーを積んだ見積もりにしたり、見た目の進捗を間に合わせるために質の悪い作業になったりと、本当に良いことはありません。
一応補足がありまして、進捗率という意味のわからないものを使っているプロジェクトがあったとしたら、即刻廃止してください。
無駄です。進捗率の定義ができているのであるならまだしも、その定義すらなく間隔でN%と会話しているチームもよく見かけますが、
本当に意味がありません。定量的な数値として90%という風に出せるようなタスク、
例えば100個のネジを作る意味で90個を作り終わった状態などですね。それぐらいはっきりとしているものであるんだったらまだしも、
そうではない場合は進捗率という言葉は何ら意味を持ちません。
訂正的な言葉はブレが多く、具体的な状態は何も示さないからです。
また進捗率の定義があったとしても、あまり意味をなさないことには変わりありません。
せめて全体で10個のタスクのうち7個終わりましたといった形で会話する方がまだ良いですよと。
いやーこれ本当に進捗どうですかっていう質問は正直言うと僕もマネジメントしたことあるんですけど、
06:03
やってしまいがちというかやっぱり流したくなりますねこの質問は。
それは別に冷たいわけではないし、なぜ遅れているかっていうのの原因が特定できたりとか原因はわかっていて、
そこに対してマネジメントの立場でやれることがあるとか、
もちろん自分がコミュニケーションしたら何か解決するものがあるんだったら聞いておきたいし、
それはぜひ自分が動きたいっていうそういう側面もあるので、
なぜ遅れているっていう質問は正直やってしまうと言いますかね。
やるのが普通だと思ってますね。
ただ僕もエンジニアですし、マネジメントされる側にいたこともあるので、
正直言うと進捗どうという質問とそれがなぜ遅れてるのっていう質問は正直言うと
詰められているような質問って感じちゃうんですよね。
ほんと仕方なくて、チームビルディングとかプロジェクトやチームの発足の時に
しっかり関係性を作るとか、この質問はそういう意図ではなくて、
単純に何か解決手段があるんだったら僕手伝うよっていうような、
そういう態度だっていうのを示していくことが大事かもしれないですね。
あとはそれを言葉を単純に書いてもいいかもしれないですね。
なぜ進捗悪いのっていう、
なぜ悪いのっていう悪いというワードが使われているから結構怖いのかもしれないですけどね。
言い方はさておき、そういう態度っていうのを示すのもプロジェクトマネージャーとしては大事かもしれないですけどね。
はいすいません、脱線したので戻ります。
では続いて、進捗確認をしなければならない状況をいかにして避けるかっていう話ですね。
常述のように進捗確認にはマイナスの効果が正直大きいです。
ではどのように進捗を管理していけばよいんでしょうか。
一つ目ですね、タスクの流度を変えましょうと。
まず大切なのがここです。
進捗確認が必要なほどタスクの流度が大きいということがまず一番の問題です。
一つ一つのタスクの流度は長くても1日、通常であれば半日程度に終わる量に分割すべきです。
タスクの流度がどうしても大きくなってしまう場合は、そのタスクを細分化した小タスクの常述の流度で作るようにしましょう。
そうすることでそもそも進捗状況を確認するという状況がほとんどなくなります。
タスク表を見れば状態がわかるようになるためです。
これあれですね、タスクっていうこともそうですけど、エンジニアリングの立場からするとプルリクと言ってもいいかもしれないですね。
1日1つ1つのプルリクの量とかサイズをいかに小さくするかですね。
小さくすることでプルリクエストを出す個数が増えていって、それからレビューの数も増えるんですけど、
プルリクエストって数が小さければよいかってそういうわけじゃないんですよね。
数大きくても一個一個のサイズが小さければ一瞬でプルリクのレビューが終わるんですよね。
プルリクのレビューが終わってすぐにマージされたら、
マネジメントする側もそうですし、プルリクを出す側、開発者の方もそうですけど、
少なくともタスクが終わって進んでいるっていう実感が得られるんですよね。
そうするとその実感とかリズムができて好循環が生まれるんですよね。
結構定性的というかメンタルの話になるかもしれないですけど、
これやっぱり僕の感覚もそうなんですけど、このリズムを体感しているときってすごく気持ちよく仕事を進められるし、
どんどんどんどんコミュニケーションを取ったりとか進捗が良くなっていくっていうのは正直あるんですよね。
09:04
なのでプルリクエストがデカすぎると、一つのプルリクがデカすぎるとやっぱりレビューってめちゃくちゃ時間かかるし、
一人のレビューだとやっぱり不安なのでやっぱり二人以上誰かレビューくださいってなって、
マージまで時間がかかっちゃうんですよね。
結果的にはリードタイムが遅くなるので、できればプルリクエストは下げて、
かつ、例えばプルリクエストを一日に三つ以上投げましょうみたいなルールとかにしてみると、
三つ作らなきゃいけないとなると絶対にプルリクエストのサイズが小さくなるんですよね。
その結果実はリズムも上げれるみたいな負荷価値が出てきたりするので、これと同じような感じだと思います。
という風に今のタスクの流度を下げるとか変えるっていうところはプルリクエストのサイズを変えると、
ほぼほぼリンクするなって感じたってお話でした。
すみません、脱線ばっかりで戻ります。
続いてはタスクの進め方を変えるというお話です。
進捗確認ばかりしているPMを観察していると、タスクを丸投げしているというケースが目につきます。
しっかり丸投げをせず、きちんとタスクを分割した上で、
さらにはその内容や背景をメンバーに共有した上でタスクを進めるようにしましょう。
これもよくある話ですけど、タスクを振るときはしっかりフレーミングをしてメンバーにタスクを振るようにしてみてください。
フレーミングの説明が長くなるので端折りますけど、
誰に何のタスクを投げるかというのをしっかり定義してメンバーにタスクを振りましょうみたいなお話です。
続きまして、リスクを正しく管理するというのが次のお話ですね。
進捗が遅れるケースの多くの理由はリスクの読み間違いです。
にもかかわらず、プロジェクトを開始当初にリスクの洗い出しをきちんと行うPMというのは結構稀です。
Pinbook、PMVOKですね。
Pinbookというドキュメントがあるんですけど、ここにも書いてあるのにやらないと。
リスクが正しく管理されていれば、リスクとして想定された状況が出てきた場合でもきちんと対処できるようになります。
実現が難しかったA案ではなく、B案を採用するなどなどもリスクへの対処の一つです。
リスクヘッジというのはどこまでプロジェクト最初の開始時に予想できるかというのは結構PMの良し悪しというか能力の差は出るかもしれないですけど、
もちろん想像できなかったリスクとか何か問題が起きたときはどうするか常に協議しながらというのはあると思いますけど、
それをいかに減らすかですね。
いかに想定しておくかというのは結構大事かもしれないですね。
これはPMだけじゃなくてエンジニアも一緒です。
PMは想像できないですから、結局開発をやらないのでPMは。
現場で起きていることはやっぱり現場しか分からない。
なので現場の人間こそしっかりこうやったらこうなるかもねとか、ここで進めていくと問題が生じる可能性があるなみたいなところを、
なるべくプロジェクト最初のうち、もしくは早い時期に想定しているものをしっかりPMにも共有しておくというのはすごく大事なことですね。
これなんか優秀なエンジニアの人は多分されていると思いますけど。
なので実装力があるエンジニアというのも優秀かもしれないですけど、
ビジネス観点でしっかりリスクヘッジとかそういう情報共有するっていうのも優秀なエンジニアの一つかなと思いました。
何見せんやねんって感じでごめんなさい。
続きまして、進捗ではなくて困り事を聞くというのが次の話です。
成熟のリスクの話と近しいんですけど、メンバーには困り事を聞くようにしましょう。
12:01
困っている状態というのは目に見えなかったリスクが顕在化した状態ですねと言い換えることができます。
適切にリスク管理ができて、前もって全てに対処できていればそもそも困ることはないですからねと。
当然そんな完璧にリスク管理ができている状態なんてありえないわけで、だからこそ早めに困り事を確認しておく必要があります。
困り事への対処、支援によって結果的にプロジェクトを前に進めることができます。
続きまして、ツールを活用して一時情報を取るという話です。
スプレッドシートのようなものでもプロジェクト管理をするのは限界があります。
WBS等は全体の概要把握には役立ちますが、日々の進捗の管理には不向きです。
その理由は具体的なタスクの状態とWBS等がリンクしないからです。
例えば何か開発をする、WBSを更新するといった流れがあった場合、更新忘れや更新までに時間がかかる等の状況が多々発生します。
つまりその間は正確にプロジェクトの状況を把握できていないという矛盾点が発生する時間帯が生じるということですね。
そうではなく、ソフトウェア開発であればGitHubのプロリクエストの状態を見たり、チケット上でなされる質問のやり取りを見たり、一時情報に当たるべきです。
そうすることで、より正確な状況が誰かに質問しなくても把握できるというようになります。
また余談なんですけど、とある会社さんでは、営業もPMも経営サイドもみんなプロリクエスト、GitHubベースで進捗確認をしたり、タスク管理をしていると言ってましたね。
例えば営業からエンジニアサイドの人にやり取りするときは、イシューを立てたりして、全部プロリクエストとかで管理をしているという話ですね。
例えばこういうことをしたりとか、ビジネスサイド側の提案でこういう風な方向を変えたいと言ったら、そういうプロリクエストを投げるみたいなことを言っていて、すごく面白いエンジニアライクな組織設計になっているなと思ったりしましたね。
これはなかなか参考になるというか、でも実際に真似できるかというとすごく難しいので、そういう文化が変わるのがすごく素晴らしいなと思いました。
続きまして、他にもいろいろな手段があります。
他にも何かを聞きたい場合は個別にご連絡ください。チーム状況やメンバーのスキル等によって取るべき手段は当然に変わるため、そこを見させていただいた後、何かお伝えできればいいなと思っております。
いいので、一旦この記事自体は締められていたんですけど、記事公開後の追記で思ったより反響があったので追記をしていきたいと思います。
この内容はどちらかといえば初心者向きですとか、どちらかといえば小規模プロジェクト向けで書かれていますとか、大規模プロジェクトでは無理だよねーみたいな話は当然です。
管理手法がそもそも違いますとか、自社プロダクト、クライアントワークでも管理手法異なります。タイトルは多少の煽りが入っています。
前半の例は、私が見てきた残念なPMの人たちを元にして書かれた空想物語です。良くない例として参考にしてください。
追記2ですけども、残念なプロジェクトにいた残念なPMみたいなコメントをいくつかいただいたんですけど、そもそもこれはこの筆者の方の話ではなくて、良くない例を元にした空想物語ですよみたいなところですね。
なんか本当にいろんなコメントがあったらしいですね。
PS、どうやっても二日酔いを防ぐプロジェクト管理ができません。
15:00
何ですか。
二日酔いを防ぐプロジェクト管理ができません。
僕もそうなので、なかなか面白いですね。
というところで、この追記の文号があっただけで、この記事自体はこれで締められておりました。
はい、いかがだったでしょうか。
まあ進捗確認をやめる、うまくいくっていうタイトルだったんですけど、厳密に言うと進捗管理自体はやるって話ですね。
やるんだけど、単に進捗どうですかみたいな質問だったり、なんで進捗悪いのっていうお決まりのパターンの質問だったりとか、
あとタスクをしっかり分割とか分けたり、フォーカスしないまま丸投げして結果どうですかって聞くっていうもう最悪な話ですね。
なので、プロジェクトのマネジメントのスキルというかコツと言いますか。
なかなかこう、いわゆるハウツーボンとかノウハウが固まった、いわゆる体系化したような書籍で語られていないようなソフトスキルみたいなところの話が
僕なんかフォーカスされたんだろうなと思っていますね。
でもこれはやっぱりプロジェクトマネジメントをする人だけの話じゃなくて、プロジェクトマネジメントされる側もしっかりする側とのコミュニケーションとか関係値だったりとか、
情報の出し方だったりとかっていうのを考える必要があって、やっぱりお互いに考えた結果プロジェクトはうまくいくっていう風に僕は聞こえましたね。
というところで、皆さんの環境だったり、いろんな現場によって状況が違ったり、ツールももちろん違いますしあれですけど、結構この中で僕コアだったのはやっぱりタスクを分割をしていない、いわゆる丸投げしているっていうのが一つ大きな話だったんですけど、
もう一個は進捗管理のツールですよね。WBSと例えばGitHubのプルリクエストっていうところがリンクしないっていうのはこれ結構本当はある話だと思いますね。
開発時代終わってますよって言うけど、チケット時代更新されてなかったりとか、そのチケットに紐づいた他のチケットだったり、質疑応答のチケットとか生まれると思うんですけど、
これがリンクしないので、結果矛盾点が発生する時間帯っていうところですね。これが割とでかいと思っているので、だから結局PMは確認しなきゃいけないですよね、メンバーに。
でもそれもしっかりしなきゃいけないので、ツールの管理とか運用の仕方とか、プロジェクトによってチケット管理は例えばバックログです。
ソースコード管理はGitHubですとか。進捗管理はWBSとかGanttチャートはSpreadsheetですみたいな、全部バラバラになる可能性が大いにあるので、タスクを管理するためなのにツールが2、3分かられた瞬間どれがどれみたいな話が絶対あるし、
人間はミスをする、ヒューマンエラーは起きるので、そういうことを加味した上で一時情報にツールをまとめていくっていうのが結構大事かなと思ったりはしましたね。
はい、というところでいかがでしょうか。個人的には当たり前と言いますか、正しいことと言いますかね。よくある話を持ってきこられたというふうには聞こえますけど、でもよくある話っていうのは歴史を繰り返すからね、人は。
なかなかできているようでできていなかったりするんですよね。僕らは当たり前と思ってるけど、できていないことってたくさんあったりするので、そういう自分の振る舞いとか行動をもう一回見直すとか、
振り返るという意味でもこの記事はすごく問題提起されていいなと思ったので、後ほどこの記事シェアします。皆さんの方でも改めて見ていただければなと思います。
本当に良い開発現場はマネジメントの人が先導するんですけど、本当に環境を作るのは一人一人の意識の話だと思うので、マネジメントに全部丸投げをするんじゃなくて、開発側の方も意識していろんなものを変えていくっていうことを常にブラッシュアップしていくってことを意識していけたらなと思いました。
18:11
はい、というところで今日の朝活は終了したいと思います。本日の参加者はしちゅうせんさんとみはるんさんとしかないさんとしきもおじさんですね。
はい、というところで日曜日の朝からご参加いただきありがとうございました。
明日ものんびり入力何か読んでいきたいと思いますので、興味があれば参加してみてください。
ではでは、日曜日ですね。ゆっくり休んでいただいて、また明日月曜日からお仕事頑張っていけたらなと思います。
じゃあ終了したいと思います。お疲れ様でした。
