ダメだなーと思うリーダーさんはスケジュールの作り方が下手。そしてタスクの分解が下手。正直それに尽きる。こんなの別に勉強すれば誰だってそこそこできるようになるのに、何故かエンジニア上がりのリーダーさんはこういうのもはググりもしないし、独学もしない。下手のまま。なんでだろと思う。

ソフトウェアエンジニアの人達はよく要件分析をして適切なドメイン、サブシステム、モジュールに分割していくというのが大事と言っているのになぜかリーダーとしては同じメソッドを適用しない。思うままにやった結果玉石混合のタスク分解とそれが直に反映された難解なスケジュールができる。

これらは遠目ではスケジュールぽく見えるんだけど、実際はどこがどうつながっているのか、何が大事で何が大事じゃないのかが分からない。タスクの分解粒度がでこぼこなのだ。なので稼働している時はまだいいけど機能不全になった時、外部からフォローが全くできない状態によくなる。

こういうプロジェクトはもはやリーダーさんは制御不能になっているので、外部に対して”大変だ”、”人よこせ”、”日程遅らせろ”としか言わなくなる。まあこれしか対策しようがないんだろうとは思うけど、結果ギャンブルにお金が吸い込まれるように今日もリソースが吸い込まれていく。とても辛い。

リーダーさんとかやる人はお願いだから大変な時に周りにお願いできる状態かどうかを考えて計画やそれを計画できる技術を身に着けて欲しい。対象が違ってもタスクを正しく粒度を分類して分解していける能力はソフトウェアエンジニアとしても大事な能力なので勉強しても無駄ないよ。マジで。

つーか、君らのプロジェクトが何を大事にしていて何が落としていいのか、何が日程を守る要素で何が遅延可能なのか、どのタスクがクリティカルなのかが全くわからない、リーダーさんが回答できない時点で外部からのフォローはほぼ不可能なんだよーとマジで言いたい。意地悪とかじゃなくてだよ。ホント。

ソフトウェアエンジニアの人でタスク分解がイマイチわからないって人は、エンタープライズアーキテクチャのヒエラルギー図をイメージすると分かりやすいと思う。要はああいう脳内の分解段階が必要。アーキテクチャは目的の実現のための図ではあるけど、あれは思考の分解図でもある。

アーキテクチャを構築していくのと基本的なステップは同じ。一番大事なのは技術の分解は一番最後って事。一番わかりやすいけど一番最後。イメージしやすいからって下ありきで分解を始めると上がいびつになる。結果的に上層で辻褄を合わそうとするのでさっき書いたダメな計画になる。

でも慣れてないと上からの分解は難しいとなるかもしれないけど、その場合は3つ手段がある。1つ目は脳内でプロジェクトを具体的に実作業をしているイメージで詳細に動かしてみて、その作業の流れをメモし、そこから分解粒度を整理して成形する。これは大変だけど後々楽になるので一番お勧め。

2つ目はあえて最初は分解をしない。【分解ポイントが見つかる】という大きなタスクを分解し、分解前、分解後で計画を立てる。これは思考の停滞を防ぎ。段階を組めるのはてんぱりやすい人はこっちの方が向いている。この場合最初の日程のブレが大きいのでCCPM的な技法で始めるとブレ粒度を減らせる。

3つ目は一番手っ取り早く、過去のかかわったプロジェクトの計画や作業を読み返してみてどんな粒度で進めた場合動いたかを自分の経験から思い出してその粒度をまねる。ようは成功実例のあるベストプラクティスの模倣である。これは材料がある時は一番効率がよい。

すべてにおいて大事なのはリーダーさんが自身の頭の中できちんと対象の作業を大、中、小の粒度でイメージができていて組みあがっている状態を作り出す事。これができていない状態で対面成形だけを考えて計画を立てると砂上の楼閣になる。結局ソフトウェア開発と同じで初手が大事。ホントそれに尽きる。

スケジュールには当人の脳内がそのまま可視化される。上手くいかないって事は自身の中でゴールまでのイメージができてないって事。できてないならできるまで考えるしかない。時間がないならそこまで開始を延ばすしかない。でも下手な人はそこで遅れますと言えないのでなんとなくでも開始してしまう。

一度何となくで始めてしまうと、チームのメンバーは常に巣の中でタスクという食事を欲しがる。リーダーはリソースが無駄に消費されるのを恐れる為にわかるタスクをどんどん積んでいく。結果的にプロジェクトは動いているように見えるけど、それはただ先がない作業をさせているだけである。

そのような形でできたスケジュールはもうスケジュールではなく、やった事、やれる事リストでしかない。こういうパターンに陥って機能不全になるリーダーさんとプロジェクトは多いけど、書いたようにこれはそうなる原因がクリアなので対策すれば改善できる。だから勉強してそういうの防ごうよという話。

ソフトウェアの言語覚える時もそうでしょ。まず文法呼んでその後は良質なコードを読んだり、サンプルコードを書いたり、今あるコードの拡張をしたりして使い方と適切な利用を学ぶ。みんなできてんじゃん。それをスケジュールや計画つくりでもやればいいんだよーって話でした。おしまい。

リーディング研修で書こうと思ってる内容をTwitterに書くくらいならちゃんと研修資料で書けばよかった。非効率だなぁ。

もっと詳細知りたかったら、この辺の資料読むと良いよ、みたいなのありますか？

背中から胸に貫通して死にそうです いろいろ読んで実践しているのですが、どんな書籍や、Googleさんに教えてもらうワードがいいのでしょうか プロジェクト関連資格でComptia Project+は持ってます スケジュール作りが下手って、メンバーに思われてそうで

金さえ貰えば良いから 日本のサラリーマンは勉強しないしアメリカの統計ではやる気のある人は6パしかいないとされるわ

勉強してもしなくても対して給与変わらないしゴルフやってる方が偉くなるしね

そりゃだって工数やコスト抑えても大して評価変わらないもの、、、

エンジニアは実務の数値に慣れてて、予測とか曖昧さとか、後でなんとか調整するからの適当な見積もりとかが苦手なんだよなあ。 自分の仕事でそれをやると地獄を見るので。 経験長く、下手に真面目すぎるとリーダーには向かないことが多い気がする。 そこそこは誰でもできるだろけど…

あと、クソリーダーによる炎上案件とか何度も経験してる人は、なかなかリーダー脳に切り替え出来なかったりするという悲しい話もw

調べたらやり方が存在する事である 技術として身につけられるものである ということを知らない人や事ってあると思う そういう人や事があることを知ろうとしてあげたり、伝えるためにどうすればよいか調べることもまたできるかも 自分だったら指摘して欲しいし、直接伝えてほしいのに、 なんでせんの

PMがスケジュールを組み立てるときはタスク分解とそれらのリレーションはもちろん必要だと思うけど以外と見落としがちなのはタスクの長さと確認頻度。 特に単納期PJや既に遅延しているPJだと致命的になる。 例えば3日のWBSに対して確認頻度が週一だと実質意味ないよね。。

この長さの愚痴ツイートを見るとたぶんツイ主にも問題あるか状況を正しく把握できてない可能性ある

へぇ、すごい

他社員のスケジュール管理できて、設計とかもできるんだけど、自分が作業する分のスケジュールだけ連日朝までコースの自分に厳しいハードエンジニアを知っています。

普通ガントチャートぐらい作るだろ？ プロジェクト管理の基本やで

機械イジりの方が好きだから。

そのような人をリーダーにした会社が悪いだけです

耳が痛いです。

技術力じゃなくて地位でリーダーを決めるから。 大半の人は評価、判断できない。 いつもの行動とポジショントークを繰返す。 時代遅れな日本🇯🇵😅