00:00
国脇さん、今日はですね、プロジェクトマネジメントについて話を聞いていきたいなと思うんですけど、
仕事でプロジェクトをリードする立場になったときに、最初はやる気があるんで意気込んで、勢いで進められたりするんですけど、
後々ですね、後の方になってくればくるほど、ちょっとテンションも下がってきてグタグタになるみたいなことが結構あったりするんですけど、
国脇さんはどうなんですかね、ここらへん。
最近PMになったんで、この辺りの事情がだいぶ分かってきました。
中盤とか終盤とかでグタグタになるのは、おそらく自分たちの位置を見失って不安になってるんじゃないかなと思ってます。
位置を見失うと、本当に期日までにできるのかなとか、次何やればいいのか分かんなくなっちゃったなとかってなっちゃうんですよね。
なので、じゃあ自分たちはどこに行きたくて、自分たちはそこからスタート地点とゴールの間のどこにいるのかっていうのを見失うなにすることがすごく大事なわけです。
それ聞いてるとあれなんですかね、進捗をちゃんと確認して自分たちの立ち位置を明確にしておくってことが重要ってことなんですかね。
その通りです。進捗を確認するっていうのもすごく大事なんですけど、実はもう一個だけ大事なことがあって、
進捗って100%に対して今自分たちは何パーセントかっていうことを知るってわけですから、
100%はどんな状態なのかってことをよく知らないといけないんですよ。
なので、このゴールっていうのとあった日々の自分たちはゴールに対してどれくらいの距離があるのかっていう、
この2つっていうのがとても大事なポイントですね。
なるほど、じゃあゴール設定というか、期日もそうだし、ゴール設定をちゃんと目標設定をしっかりした上で、
そこまでのマイルストーンを置きつつ、現在位置をちゃんと明確にしていくっていうのが非常に重要なんだよねっていうプロジェクトマネジメントにおいてってことですかね。
プロジェクトマネジメントにおいてはもうちょっといくつかその革新的な部分があって、
自分たちがゴールしたときにどういう状態になってるかっていう、ある程度経営的なコミットメントが求められてるわけですよ。
つまりお金はどれくらいかかって、期日はいくらぐらいで、
実際どういう品質のもの、ユーザーにどれくらいフィットしたものが出てくるのか、
この3点、QCDですねっていうのが結構大事なわけで、
このQCDっていうのがどれくらいになってるというのが予測される、この幅に収まりますよっていうのが、
プロマネが常に目を光らせなきゃいけないということですね。
じゃああれなんですかね、その観点でいうと、期日がスケジュール上だったらこの日までっていう感じになってたんだけど、
現実ちょっとプロジェクトを進めていく中で伸びてしまうってことはあるかなと思うんですよ、現実的に。
そうなってきたらコストの面でどんどん増えていくよねとか、
みたいなそういう金感情みたいなところ、若干のコスト感みたいなところもちゃんとプロジェクトをリードする立場の人は、
リードするマネジメントする立場の人はちゃんと目を光らせないといけないっていう。
その通りですね。これはトレードオフスライダーになっていって、
どのトレードオフをどっち側に動かしやすいかっていうのは結構プロジェクトごとによって違うんですよ。
例えば前者の命運をかけたようなプロジェクトっていうのは比較的コストはどうにでもなりやすい。
03:04
コスト、要するに投下する資源とかは比較的どうにでもなりやすいんだけど、
だいたいデリバリーがカチカチで、クオリティもあんまり下げることができない。
なのでCは動かしやすいっていうタイプのプロジェクトになりやすいですね。
確かに、そのプロジェクトの特性というか目標によるって感じでしたね。
その会社の経営状況だったりとか、そもそもの会社の目標みたいなところもあったりするのかな、
経営者がコミットメントするところみたいなところもあったりするのかなと思うので、
そこら辺に結構引きずられるというか、かなり依存するっていうところなんですかね、
やっぱりプロジェクトの目的みたいなところは。
本当にその通りで、ちょっとこれは少し見積もり、デリバリーの見積もりの詳細に踏み込むんですけど、
デリバリー見積もりするときって、我々いつもだいたい1点で、
この期日までは多分できると思いますっていうふうに1点で見積もっちゃうことが多いんですけど、
実際は2点とか3点で見積もったほうがいいってよく、これはもう鉄則なんですね、プロジェクトマネジメントの。
悲観と楽観で決める。1点で人間見積もると、楽観側にすごく寄って見積もっちゃうっていう性質が知られてるんですよ。
なので必ず楽観と悲観、最低でも2点で見積もってバンドを出すんですね。
楽観の場合は、例えば明日にはできてます。悲観の場合は1週間かかります。こういうバンドがあるわけですよ。
で、多分この楽観と悲観の間にどこかの1点に落ちるんですよ。
それを悲観側に寄せるか楽観側に寄せるかっていうのは選択の余地があるんですね。
これがさっき言った経営的な判断なんですよ。
例えばCMを打ちたるこの期日までにっていうふうになったときに、そのCMを打つってなったら、
CMってすごい数億円とかかかったりするんで、失敗できないわけですよね。
失敗できないのに楽観側に寄せるのはおかしいわけですよ。
これはどっちかというと悲観側に寄せたほうがいいってことが分かるわけです。
CMとか打つって決めたときには、見積もった後に楽観、悲観の悲観側でなるべくやりましょうっていうふうなことが経営的な判断。
大抵はなるんじゃないかなと思っている。
そうじゃなくて、例えば別に楽観とかじゃないんだけど、
ただとにかく競合たちが似たようなことをやろうとしている気配があるから、
早く出さなきゃいけないんだっていうときは、どっちかというと楽観側。
これ品質とかをちょっと妥協したりとかしてとかっていうふうなことを考えたりする。
これも経営的な判断ですよね。
なのでこのバンドの中でどこを選んでいくのか、
現実的にはここのバンドになるってことが分かった上で、
コストとかもバンドがあって、クオリティにもバンドがある。
それの中で自分たちはどこの位置づけを狙ったらいいのかっていう、
このできるラインとここが望ましいっていうラインのちょうどいいところを探すっていうのが、
この経営者のとかプロマネの革新的な部分になってくるわけですね。
なるほど。今のお話聞いてるともうプロマネっていうか経営者なんじゃないと思ったんですけど。
そうですね。経営者はもうちょっと大事な要素がいっぱいあって、
経営者っていうのは競合他社とか、あとは従業員がどう考えてるかとか、
2つのことをやらなきゃいけないんですよね。従業員をよりよく動かすってこともやらなきゃいけないし、
あとは経営プランとかってなって、自分たちがどの位置に一丸となって向かっていくのかっていうこと、
06:03
そのビジョンをぶち上げてそこに向かっていくってことをやらなきゃいけなくて、
そこの扱ってるプロジェクトの範囲がめちゃくちゃでかいんですよ。
中につくプロジェクトはいっぱいあるんですけど。
中小度合いが高いってことですね。
中小度合いが高いです。めちゃくちゃ高いです。
なので個別の意思決定とかってのはなかなかできないんだけど、
だけど全体的な方針とかを示してそのルールを作るっていうのが経営者の役割だと私は思っています。
スコープがどんどん狭まっていくって感じですね。経営者をもっとでかいところから見ていくけど、
プロジェクトマネージメントマネージャーはそのプロジェクト単体での意思決定というか経営みたいなところ、
経営っていうのかちょっと分かんないですけど、プロジェクトのコストとか品質とかそういったところをマネージメントしていくよっていうところなんですね。
そうですね。もう一点だけ大きな違いがあって、プロジェクトには終わりがあるんですけど、
会社には明示的な終わりってなかなか想定しないですよねっていうのがあって。
まあ確かに。
これはちょっと結構大きな違いで、プロジェクトは成功したか失敗したかっていうのがそのプロジェクトの終了時点で分かるものなんですよ。
だけど経営っていうのは常に問われ続けるんですよね。そこはちょっと結構意思決定のモデルとかが異なるかなと思うんですね。
確かになんか根本から少し違いそうですよね。そこに関しては。
永続的にというか、その会社の成り立ちとか、どこ目指してるのか、上場目指してたりとか、何十年も続けていくぞみたいないうのとか、
そういうのに結構よるかなと思いますけど、そういう中での経営に関してはもうちょっと長期スパンみたいな視点が入ってくるけど、
プロジェクトはどちらかというとそれと比べたら短期スパン。
そうですね。終わりがちゃんとある有機能って言い方をしますね。
なるほど。じゃあそういったところで経営者目線も入れつつもプロジェクトをちゃんとマネジメントしていかないといけないっていうのがプロジェクトマネージャーのお仕事っていうことなんですけど、
さっき言ってた見積もりを2点で取る。悲観と楽観で取るっていうのでちょっと引っかかったのが、
大体タスクの見積もりとかってプランニングポーカーとかやるわけじゃないですか。いろんな手法あるかなと思うんですけど、
そういうのって大体今まで聞いてた話だと1個しか出さないかなと思うんですけど、悲観と楽観いつ出すんですか。
このプランニングポーカーって悲観と楽観両方出すといいと思います。
なるほど。普通に。
そうですね。ただ実際はプランニングポーカーっていうのは見積もりをするための道具っていうよりかは認識のずれを可視化するための道具っていうことのほうやっぱり側面が強いんですよ。
何でかっていうと、まずプランニングポーカーの説明をするんですけど、プランニングポーカーは複数人で集まって、じゃあAってタスクがあるね。
例えばA何にしようかな。じゃあToDoアプリを作るっていうタスクがある。そのToDoアプリを作るっていうタスク。
じゃあこれどれぐらいかかるかねっていうのをフィボナッチ数かなんかで1,2,3,5みたいな感じのやつでそのポイントで、
09:04
じゃあこれは何日かかかると思うみたいなことをみんなで出して、みんなが一斉のせいで出すんでずれることがあるんですね。
例えばこの人は3日って言ったんだけど、この人は何と7日かかると言っている。2倍の差がある。なんでだって。
そうするとここで話すわけですよ。一番低い人と一番高い人が、あなたはどうしてこんなに短くしたの。あなたはどうしてこんなに長くしたのって聞くと認識のずれが分かる。
例えば実はこのファイルいじったときにすげー苦労したんですよみたいなこととか言われたりして、なるほどってなったりして、そうするとこれは長いほうが変わっていくでしょうね。
短い人は、実は最近ある会社がこういうことやってて、この会社の製品使えば多分これ一発できるんですよみたいなこと言ったら、それは短いほうができますねってなって、
こういうふうになってみんなの認識が揃うっていうのがプラニング効果のいいところなんですね。これは楽観、悲観でやるとより精度が高くなるんですよ。
楽観の場合こう、分かんないことはみんなあるんですよ。だから何日でできるって言われたら3日かもしれない。
まあ大体3日で終わると思うけど、でもちょっとドツボにはまったらいつかかかるかもねみたいな。
なのでプラニング効果一緒に出したいですね、その意味では楽観と悲観を。
なんか結構前なんですよね、社会人になる前かな、そういうタスクの見積もりをするときは大体エンジニアだったら自分が思う3倍を出せみたいな。
2倍、3倍を出すことで最終的にはいい感じになるっていう。バッファーを持つみたいなそういうことだったんですけど、タスクに対して。
そこの話も入ってくるのかなと思ってて、悲観はその3倍で出して、楽観の方は当初自分が思ってたところを出して。そんな感じなんですかね。
あってますあってます、まさしくそのとおりで。ただ私は固定にしないことを説明してます。この3倍とかっていうのを固定にしないことを説明してて。
なぜかというと、例えば不確実性が高いタスクと小さいタスクがあるわけですよ。
例えば小さいタスクっていうのはTUDOアプリ作るっていうのはすごく小さいタスクで、なぜかっていうと要件もはっきりしてるし分からないことは少ないわけですね。
だけど例えばTUDOアプリを爆売して100万ドル稼げるようなアプリにするって言われたら、分からないことが多すぎるわけですよ。
世の中の人たちはどんなTUDOアプリを求めてるんだみたいなことは全く分からない。分からなければ意思決定ができないわけで。
こういうふうに不確実なものっていうのは大抵、さっき言った不確実のバンドが広いわけです。
そのバンドが広いっていうのがどれだけ不確実なってことをちゃんと表してるわけなので、機械的に3倍とか決めちゃうってこれが分からなくなっちゃうんですよ。
これは不確実なタスクだな、これは不確実じゃないなとかっていうのは。
なので、なるべくバンド2次元のデータとして出してあげる方がいいですよっていうふうに思ってます。
なるほど。そこの固定値ではなくて、不確実性があるかどうかでちょっと係数とかを変えつつ、自分の中でだと思うんですけど、
各々の中で変えつつ、悲観と楽観で1個ずつ出していってもらうみたいな感じ。
結果的にそのタスクの見積もりのミーティング中に多分やるかなと思うんですけど、
それを見た上でプロジェクトマネージャーはじゃあ今回どっちに転がしていこうかなみたいないうのを考えていくわけなんですかね。
12:02
そうですね。ただプロジェクトマネージャーがどっちに転がしていこうかなって考えるってもうほとんど選択の位置なくなっちゃうんですよ、そう考えちゃうと。
だって楽観と悲観がバッて出てきて、うーんってなってじゃあ楽観側かなとかっていうふうにリスク選択ができるんですけど、
実際そこで何かアクションを打てるかって言ったらほとんど打てないわけじゃないですか。
なのでここから実はいろいろなアクティビティが始まるんですね。
なるほど、どういうのが。
どういうことかっていうと、プロジェクトには賞味期限が大抵あるんですね。
例えばさっき言ったクーレする2Dアプリ作るみたいなのがあったときに、
2Dアプリは他の競合がめっちゃありすぎるんで、もうちょっとあるプロジェクトやる、まだ誰も世界の人に気づいていない。
これは誰も気づいてないうちにリリースをすると、それがもし当たれば開拓者利益、先行者利益を得ることができるわけですね。
競合がそれに気づいてしまって実装されてしまう、そっちが競合の開拓者利益を取られてしまうと、
それは結構丸存なわけですね。
なのでプロジェクトっていうのは、なるべく短く出したほうがいいっていうのはある。
つまり賞味期限があるっていうのが現実だと思っています。
なのでなるべく早く出さなきゃいけないんだけど、とはいえ現実的にはこれぐらいかかっちゃうっていうのもあるわけじゃないですか。
そのとはいえ現実的にかかるのこの部分を何とかしなきゃいけなくなってるわけですね。
そこで大体4つぐらいの回線を入れることになります。
一つは直列でやることになってたんだけど並列でできないっていう並列化とか、
あとはこれ一人でやるってなってるからめっちゃ時間かかりになってるけど手分けできないっていうタスクの分配とか、
あとはこれ全部作るってことになってるけどありもの使っちゃったらもっと早くなるんじゃないとか、
あとはこれ複数人で手分けすればするほど早くなるからプロジェクト100人ぐらい追加すればあっという間にできるんじゃないっていう資源の追加。
大体この4つの方法でこのデリバリーを何としてでも短くしてるぞっていうふうにやって短くしていくっていうのがプロマネのできることなんですね。
なのでこのデリバリーがダメだ楽観でさえ賞味期限切れになっちゃってるっていうのが分かった瞬間に今言ったプロセスの改善っていうのに入っていってやっていくっていうのがプロマネのやらなきゃいけないことですね。
なるほど。じゃあリソースの調整ですね。すごい雑に言うと。
あとはプロセスの調整やり方って調整って感じですね。
なるほど。ひかんとらっかんっていう材料をもらってじゃあどう進めていこうかっていうことをプロマネは考えて、
じゃああとこの期日までにどうしても出したいってか市場的に出さないといけなさそうだから賞味期限があるからそこまでに出すためにはじゃあどうするのか。
リソースの調整、プロセスの調整をどうしていくのかっていうところに頭をひねっていくっていうのがプロジェクトマネージャー。
そうです。だからもう本当に私が実際PMOでプロマネ的なことやってたときにはずっとそのプロセスをホワイトボードに書いてどこを短縮できるんだとかっていうのことを考えてずっとううんうん言ってたのを覚えてますね。
なんか実際にどうしました。具体的ななんかいい事例出せたら聞きたいんですけど。
さっきの4つの改善のパターンっていうのはやっぱりすごく意識して作る必要があって。
15:07
今回やったもののうちのいくつかは、まず土台としてプロセスって何で書くのか、過剰書きで書くのかみたいな話がまずあって、
今回私はプロセスフローダイドラムPFDって呼ばれてる図で書いたんですね。
このPFDって図はちょっとこれ言葉で説明するの少し難しいんですけど、
プロセスっていうのはある入力をするとある出力が出てくるっていう成果物の変換だっていうことをちょっとまず捉える立場があって。
それで例えば仕様書をインプットにすると実装が出てくる。これはプログラミングですよね。
あと要求とかをヒアリングするとそこからこんな感じだったら解決できるんじゃないかって仕様が出てくる。
これが要求分析とか仕様記述とかって書いてあるのと。
こんな感じでプロセスがいっぱいあってこれをつなげていくと最終的に目当ての成果物ができるようになつを作れるんですね。
ここから実はGanttチャートを自動生成することができるんですよ。
この一個一個のプロセスにどれくらい時間がかかる。
こいつとこいつは並列できるとかっていうことは全部図の中に表現されているので、
ここからGanttチャートを引いて消滅期限切りしてないか見て、消滅期限切りしてたらそのPFDの図をここを直立から並列にしよう。
ちょっと危なくなるけど仕方ないとか。そういうことを決めながらいじっていくんですね。
いじっていってこれで大丈夫になったっていうのを確認できたんですよ。
楽観が届くようになったって確認できて、それでそのプロセスでいきましょうってことを承認を得てやっていくってことを実際にはやっていました。
今ちょっと疑問に思ったのが最初からGanttチャート書けばいいんじゃないと思ったんですけど。
いい質問ですね。これが実は難しいんですよ。
なぜかというとGanttチャートってプロセスって普通依存関係があるんですよね。
さっき言った通り使用ができてなければ実装を始めることはできないわけですよ。
っていう風になるのがあって、このGanttチャートの棒の端っことこの棒の端っことは連動するっていう情報と連動しないやつもいるんですよ。
っていうのがあって、どこが連動するのかっていう情報がGanttチャートには見えないんですね。
Ganttチャートツールによってはその部分が連動できるようなリンクを貼ることができるんですけど、
大抵の人たちはそんなリンクなんて貼ってないっていうのがあって、それが私は直接Ganttチャートを使わない理由なんですね。
なるほど。じゃあツール側の問題というか。
ツール側の問題と情報量の問題ですね。
Ganttチャートという表現手法だと、一般的な表現手法だと依存が書きづらいから、
PFDでしたっけ、PFDというような形式で一旦書いてから依存関係も書き切ってからGanttチャートに変換するという手法を今回取って、
計画を作ってみたいな感じなんですね。
やってること、さっきのPFDの説明からそうなんですけど、完全なるエンジニアリングかなと思ってるんですけど。
まさしくエンジニアリングで、プロマネってエンジニアリング的な側面もすごく多いのと、エンジニアリングじゃない側面もいっぱいあるんですけど、
18:01
やっぱり多くのことはエンジニアリングで解決できるし、何なら昔結構軍事的な分野で研究されてきたものでもあるんですね。
Precious Researchって呼ばれてるような分野になっていて、なので結構いろんな問題の解き方が知られてるんですよ。
なのでそれはもう利用しない手はないんですね。なのでそういうのを利用して、なるべくエンジニアリングにできることは要するに退屈なことはプログラムにやらせようということですね。
退屈じゃない部分、例えばこの人とこの人組み合わせるとプロジェクトの進捗が死ぬから辞めようとだっていうそういう判断とかもあるわけですよ。
そういうプロマネ的な、要するに人間の感情とか機微に配慮したマネジメントみたいなのがプロマネの中に入っているので、そういうところとかっていうのはもうちょっとエモーションがあるな、仕事になるでしょうね。
もうちょっと人と人が対話していって、なんとか寝ごってみたいなお話ですよね。
あとはあれですね、つい最近もあった話なんですけど、なんかこのままだと期日までに終わらないかもしれない、1ヶ月後に終わらないかもしれないっていうのがあって、
じゃあ休日残業すれば間に合うかもなみたいな。
休日出勤か、休日出勤。この時にどう伝えるかによって人間の動き方が変わるんですよ。
3週間後に間に合わなかったんで休日出勤しますっていうふうに言うと、ブーブーブーってなるんだけど、このまま行くと間に合わないんで、最後の週に休日出勤するかもしれないですっていうふうに最初に言っておくと、やべえ、休日出勤嫌だと思ってみんな頑張るんですよ。
なるほど。
っていうのがあって、これがやっぱり人間の上手い動かし方っていうのがあるっていう話で、そういうふうな部分とかっていうのも結構経営者寄りな視点ではありながら、プロマネーとしては重要な支出だろうなと思ってます。
人にどう動いてもらえるかってことですよね。
そうですね。
しかもその時にどう気持ちよく動いてもらえるかっていう観点も非常に重要になってきそう。
そうですね。
かなり難しいところだと思います。
難しい、そう難しいです。
人間関係のこととかトラブルがあったら本当にめんどくさいと思うんで、かなり難しいかなと。
私がちょっと最近トラブル関連で面白いなって、システマチックな再発防止策として面白いなって思ったのは、スラックとかから人間の特徴をAIとかに抽出させて、自分の手元にあるこの人はこういう人っていうキャラクターみたいなのを成長させていくみたいな。
なるほど。
これはなるほどだったことを覚えてます。
なるほど。自分だけ見れるプロフィール帳みたいなのを作っていくみたいな。
そうそうそう。作ってっていうのはなるほどなったのと思いましたね。
それやってるんですか?
私はまだやろうかなと思い始めた段階でまだやってないです。
なるほど。誰かやってる人がいたっていう。
そうなんですよ。やってる人がいてちょっと面白そうだなって。
すごいな。その人のキャラクターブック見たいっすね。
見たいですね。
見たいですね。多分開示できないと思うんですけど。
開示できない。そうですね。
いろんなやばいこと書かれてそうな気もするんで。
そういうキャラクターブックが一度できてしまえば、そしてなるべくリモートみたいな企業でほとんど例えばスラックとかに現れるようであれば、
21:03
このリソースとこのリソースを一緒にすると破滅が起こるみたいなことって予測しやすくなるじゃないですか。
そういう意味で人のアサインっていうのもエンジニアリングしていく余地が広がってきていると思っていて、
それは結構いい流れだなと思ってますね。
あれですよね。パワープロードームのキャラクターみたいな感じで、センス×とかセンス○とかバッジが付いていって。
×とか付けられたらマジで最悪だけど。
そういう感じでちゃんとキャラクターが出来上がっていって、
プロジェクトを立ち上げ、メンバー募集みたいな感じになった時に、この人たちで組むといいよみたいな感じの推薦が来たりとか。
そういう感じですよね。未来的には。
でも確かにこれは本質的にはピープルマネジメントする人は絶対やってなきゃいけないことで、
それをAIに肩代わりさせたっていう意味で過ぎないんですよね。
いや確かに。単純に頭の中にありますよね。
普段関わってる人があったらこういうキャラクターだからこういう言い方したらスムーズにいくよねとか。
ここの人は頭固いそうだから先に行っとかないといけないなとか、そういう細かいやつとか。
やっぱりよくあるのが、この人喋りすぎちゃって周りの人たちが遠慮しちゃうから、その人が独断状になっちゃう。これもやっぱり悪いサインですよね。
確かに。そういうのはHR系のサービスでありそうですけど。
ありそうですけどちょっと人間性がないと思いませんか。
それはちょっと難しいなって思うところで、若干ディストピア入ってるなって。
ちょっとディストピア入りかけてる。
なので従業員が嫌がりそうなという気はちょっとしてます。
多分全体に公開されてると嫌だけど、多分経営者だけが見えるとか、あとは人事とかプロマネー以上が見れるとか、そういう感じになってくるんじゃないかなって感じですよね。
そう思いますね。そうなったら、目的はやっぱり人々が気持ちよく成果を出せることだと思ってるんで。
その目的何に使われるんだったら、私はちょっとディストピア味があるけど意味があることだと思うんですよ。
そこは私がもし従業員だったら受け入れたいなとは思いますね。
でもよく考えたらスラックもそうだし、あとはZoomとかMeetとかTeamsとかの履歴とかも全部読み込まれててっていうことですもんね。
そうです。
行き着く先はディストピアだ。
そう、ディストピアだってなるんですけども。
絶対に嫌がる人はいますね。
そうですね。
そこはちゃんと受け入れないといけないかなってところですけど。
ありがとうございます。今までの話って結構プロジェクトを立ち上げて、計画して、よっしゃ進めるぞみたいなところの話かなと思うんですけど、
途中のお話、プロジェクトをやっていく中で、例えば計画が変わってくるなんて往々にしてあると思うんですよ。
その時に再計画しないといけないとか。
あとは進捗確認していって、ずれそうだという最初の計画の見込みからずれそうだという時の切り直しとか、その時も多分プロジェクト再計画するのかなと思うんですけど、そこら辺で何かあったりしますか。
24:09
実はプロジェクトの再計画ってほとんど変わらないんですよ、プロジェクトの計画と。
さっき言ったPFDで言うと、結構最初の方に書いてあるプロセスが終わったことになってて、もう手元に成果物が手に入ってるよみたいな状況になってて、PFDがどんどんちっちゃくなっていくイメージなんですね。
どんどん成果物ができて、プロセスは終わっていらなくなってっていう風になっていくんで、そこからまた時間のチャートを引いてってことで何も変わりがないんですよ。
だから不確実性が減っていくっていうのはプロセスの数が減って、中身に含まれているプロセスの数が減っていくので、どんどん不確実性が減っていくんですよ。
楽観と非観のバンドが小さくなっていくっていうのがあって、これが不確実性コーンと呼ばれてるやつになっていて、最初はプロジェクトが分からないことがめちゃくちゃ多いから不確実がすごくバンドが広いとか1年とかのバンドがあったりするんですけど、
だんだんとプロジェクトが進むにつれて分かれてることが増えてきて、半分ぐらい経てばだいたいもうその不確実性も半分ぐらいあって半年ぐらいの部分でもう誤差が分かってるみたいな状態になってくるんで、
っていうのが自然と表現されてるんですね。PFDが小さくなっていくことによってこれが自然と表現されるっていうのがよく流れて、
これは再計画の考え方です。つまり再計画は単に小さくなったPFDで同じことをやるだけなんだよっていう。
ただもう一個大事なのが本当にそのプロセス本当に終わってんのっていうのは結構大事なんですよ。この成果物ができてることになってる。
なってるんだが本当にフォーマット通りにできてるのかなとか、そういうところが分からなくなってきて、ここで読み間違えると死ぬんですね。
できたことになってるがこの仕様はほとんど意味がないものになっていたとか。
あれですよね。後になってちょっと変えないといけない、結構変えないといけないことがあったみたいなことですよね。
そうです。つまりできたことになってたけど本当はできてなかったっていうことがすごく怖いので、なので私がそのプロセスを設計するときには必ずその人の自己申告じゃなくて、
他の人による申告。この品質はこうだったよ。ちゃんとその後の仕様に耐えられるよっていう品質基準っていうのを定めて、
それに対して合格か不合格かっていうことを決めるようにしています。そうすることでまずいものが上がってくるってことを防ぐってことですね。
そういうことをなるべくやるってことをやっていますね。
それはタスク単位でやるんですか?それともなんかチェックポイントというかマイルストーン単位でやったりするんですか?
現実的にはマイルストーン単位になることはやっぱり多いです。なぜかというと、ある程度バルクでやらないと小っちゃな変更ばっかりやってると結構大変だからですね。
後でその変更いらなくなっちゃったってことが明らかに出してレビュー無駄だったかってことが出てくるんで、ある程度はバルクでやるっていう感じですね。
品質基準定められるものばっかりだったらいいんですけど、定められないものもいくつかあります。
例えばよくあるのが実装の品質基準って何ですか?っていうのが結構あって、実装の品質基準って実装完了段階だとほぼ分かんないんですよ。
カバレッジとかは分かるけど、カバレッジが一体何を表してるかって言われたら指す意味がある数値ではないんですよね。
27:02
だから実装とかすごく難しい。検証フェーズまでいかないとその品質が分からないっていう。計測にすごく時間がかかるっていうタイプのものですね。
っていう風になっちゃってる。これはでもリントとか使うと最低限の品質は分かるんですよ。
さすがにフォーマットみんな守ったやろ。いや守ってねえぞやべえぞみたいなのは分かるんだけど、でも実際のところちゃんとお客様の役に立てるのかとかっていうことはまだ分からない。
そういう意味では品質を十分に測定できないものがある。なのでこの大事なのはこのPFDっていうの中には絶対成果物が可視化されるんですよ。
それは最初は今手元にこれがあるとか中間成果物はこんなものがあるとか最終的にはこれが作りたいみたいな。
全部のその成果物が可視化されるので、その一つ一つに成果物の品質基準を決めて、それが計測できるんだったら計測をして、
それでやべえできてなかった、実際できてなかったみたいなことを防ぐっていうのがこの進捗を把握する上ではすごく重要なプロセスです。
最初の計画時点でもうすでに計測できるというか、見て判断できるチェックポイントを用意しておくことが重要そうですね。
すごく簡単な考え方は、それを成果物を使う人たちにレビューしてもらうのが一番いいんですよ。
例えば仕様書ってあるじゃないですか。仕様書って前に第4回とか第3回で伝えたと思うんですけど、仕様書を使う人たちは結構はっきりしていて、
エンジニアが実装するために使いますよね。検証するためにそのテストケースのデータソースとして使いますよね。
だったらCAXとかの人たちがお客様からの質問に回答するために使う。
なんでこれらの人々に、あなたたちの業務でこの仕様書使えますかねって聞くと、速攻で品質基準が分かるっていうのがあって、それが結構お勧めの方ですね。
なるほど。ちょっとできたプロダクトとかだったら実際にユーザーに見せるだったりとか、そういうことですよね。
途中の再計画は一番最初のプロセスとほぼほぼ一緒だし、その中ですでにプロジェクト走っていく中で見えてきたことがあるので、情報量としては増えてるから、より確実度は高くなってるみたいなところがあるって話だったんですけど。
じゃあ次はですね、終わった時ですね、プロジェクトが終わった時の振り返りみたいなのって振り返りも結構次のプロジェクトのために必要になってくるかなと思うんですけど、そこら辺どうしてますか。
振り返りの成果物って私は代表的には2つあると思ってるんですね。1つは走り切ったプロセスです。
つまり現実的にいろいろ直接あって、ちょっといろいろやったんだけど、こういうプロセスでこの最終成果が作れたんだっていう、その取説に近いかな、なんていうのかな。
これを作るための手順書っていうのが残るわけですね。この手順書っていうのはすごくいい性質を持っていて、フィージブルなんですよ確実に。
もう一回やれって言われたら多分できるんですよ。同じプロセスで。もうちょっと洗練させてやることはできると思うんですけどね。
なのでこういうものをいっぱい積み重ねていくと、過去作ったものに近いものは何でも作れるっていう組織に成長していけるわけですね。
なのでこのプロセスのカタログを集めてるっていうのがまず第一に大事なことですね。
30:04
そして第二に大事なのはそのプロセスの中で、このプロセスにはどれくらい時間がかかったみたいな統計データが残ってるわけですよ。
例えば当初我々はこれに3日間かかるといった。実際にかかったのは4日間だった。ずれてますねと。
それがずれてますねっていうずれをちゃんと分布とかヒストグラムとかにして、我々が3日っていうふうに見積もったときが大体この範囲に分布するっていうのを見て、
そうするとさっき言った見積もりっていうのがより科学的なプロセスになったわけですよ。
過去のデータによればこのプロセスはこれに似てるからじゃあ3日ぐらいかかるんだよっていうのがわかる。
こういうふうに見積もりの精度を上げるためのものにする。この2つですね。つまりプロセスのカタログを育てていくっていうのと、
見積もりに使えるデータの引き出しを増やしていく。この2つっていうのが振り返るにおいてはすごく重要です。
なるほど。すごいあったらいいなと思う2つのデータなんですけど、それをまとめるのって結構手間というかめちゃくちゃ難しいなと思ってて、
フォーマットって揃えられないなと思ってるんですよ。こうやってやってきたよっていうプロセスのフォーマットにしろ、
意味あるフォーマットをどう作るのかっていうのに毎回悩むんですけど、どうしてますかね。
私がお勧めなのは、Jiraとかの、よく皆さんチケットトラッキングシステムを使って大抵仕事をするんじゃないかなと思うんですけど、
そのチケットトラッキングシステムに見積もりの数値を必ず紐付ける。ストーリーポイントとかちゃんと記入して、
それで見積もりと実際にかかった時間は自動的に記録されるので、その記録された時間っていうのがどうだったかってことをある程度機械的に集計できるようにすることがすごく重要です。
なので基本的にはそのチケットトラッキングシステムにべったりくっついちゃったシステムにした方が良くて、っていう感じです。
ただ欠点もやっぱりあって、皆さんチケットの進捗変更忘れしたみたいなことよくありませんか。
あれはツールによるアシストが必要なんだろうと私は思っていて、私は今それでちょっと定期的にこのチケット実は着手してるんじゃないのとかっていうことを指摘したりとか、
あなたは次着手するって言うのこれだよみたいな必勝的なパソナルアシストさんと実装していて、
そのあたりとかでちょっとうまくそういうところをケアできないかなと思って試行錯誤してるところですね。
なるほど。そういったチケットシステム、タスク管理ツールで得られるような情報を元にしていくっていうようなところなんですかね。
そうです。
その中で一番重要になってくるのが、たぶん国明さんがプロジェクトリードして、いろんなプロジェクトのプロセスのカタログを貯めていきますと。
それが他の人も使えるとは限らないみたいなところが結構重要かなと思ってて、その人しか使えないんじゃないって思っちゃうんですけど、そこら辺どうですか。
そこら辺は最近はですね、昔だったら本当にその通りだったと思います。
なんだけど今はすごく良くて、AIのスキルにしちゃえば難しいコマとか全部AIが叩いてくれるわけですよ。
人間はわからないところだけAIの補助を受けながらやるってことができるようになったので、だいぶハードルが下がったと思っています。
33:06
私は実際PFDとかを使うスキルっていうのを2つほど作っていて、その2つっていうのを使えば大体私のやったことが再現できるようにっていうふうにしているってことをやってますね。
エンジニアリング、スキルは自然言語かもしれないんですけど、そういった形でプロセス自体自動化して、できる限り自動化していって再現性可能な形で残していくっていうのが組織にとって良さそうって感じですね、最終的には。
実際そのプロセスがどう変わっていったのかとかを見ると、プロセスをどう変えていけば一緒に賞味期限に間に合うかとか、あるいは品質を上げれるかとかっていうこともだんだん分かってくるんですよね。
Aとかに分析させられるようになるんで、そこを分析した結果、私がさっき言った4類型だったんですよね。ありものを使うとかいろんな4類型の話をしましたけど、こういうふうなことをためていくってことが私はすごく腕のいいPMになっていく、プロジェクトをリードする人たちになっていくためにスキルだと思っていて、なるべくこうやって構造化してなるべくエンジニアリングとして捉えてやっていくってことが大事なんじゃないかなと思ってますね。
なるほど、じゃあやっぱり考え方としてエンジニアリングの素養というか、構造化して抽象化して応用可能にする、次のプロジェクトでも応用可能にするみたいなところは普遍的に必要ですね。
そうですね。
結構全てにおいて。
ただやりすぎると人間の心がないって言われるんで、私はよく言われることがあります。
なるほど、お前は人間の心がないぞみたいなことを。
そうですね。
なるほどね。ちょっとやりすぎ注意だけども、できる限りまとめて再現可能にしていくっていうのがやっぱり重要そうですね。
そうですね。私が人間の心がないをどう捉えているかっていうと、人間の心がない人たちっていうのは大抵感情っていうのを計算の外に置くんですよ。
なるほど。
この人はそう。
見積もりから度外視するみたいなそんな感じなんですかね。
そうそう。システムのモデリングから外しちゃうわけですよね。だから感情がないロボットみたいなものとして使う。
だから人間の心がないようなディストピア社会みたいになっちゃうけど、でも実際は人間は何かされたら嫌だなとか思ったりとか嬉しいなと思ったりすることがあって、
そういうものを計算に入れてあげると人間の心があるエンジニアリングができると思っているんですよ。私はそう信じていて。
なるほど。
なんでそこまで踏み込めたらいいなって思ってます。
感情を注入してほしいってことですね。
そうですね。モデルに入れてほしいということです。
あとロボットに感情を注入したらアトムになったみたいな。
いいじゃないですか。アトム。
アトムになりたいと。
ありがとうございます。
じゃあ最後にちょっと聞きたかったのが、タスクの見積もりの話とか散々してきたかなと思うんですけど、
その中で今AIによってタスクの速度感みたいなのが結構ガラッと変わってきたかなと思うんですけど、
36:00
どんどん速まってる感じします?
そうですね。私の直感的な感覚だと、AIは確かに人間よりは速いんだけど、
あっという間みたいな100倍ぐらい速いっていうほどではないなと思っていて、
おそらくAIの一番優れてるところは並列数を稼ぎやすいことにあるというふうに個人的には思っています。
つまり一個一個は多分人間の2倍か3倍ぐらいしか速くないんだけど、
ただ100並列とかでそれを動かすことができるっていうのがAIの強みだと思っていて、
その意味でリソース最適化の考え方が変わってくるんだろうと個人的に思っています。
今までは3人でできるタスクっていうのは、さっき言った通り3倍ぐらいしか速くならないので、
3分の1の脳機で何かを出していくってことはできるかもしれない。
それ以上縮まらない。なのでその3分の1の脳機で100個出すと。
そういう世界に変わってくるんだろうなっていうのが今のAIの速度を見てて私が思うことです。
なるほど。並列度を上げられるですね。
単純にエンジニアの脳、人間だったら1個だけど、パソコンにマシンにしたらCPUいっぱい詰めればいいよねっていうことですね。
何が起こるかっていうと、私は今まで実現された、欲しいなって思う人はいたんだけど、
実現されてこなかったものってたくさんあると思ってるんですよ。
例えばこれは私は海面に出てる島のようなものだと思っていて、
今までは実装コストがすごく高かったんで、島っていうのは少なかった。
すごく海底火山がめっちゃ出っ張らないと、ようやく作るかって本腰を上げるみたいなことはならなかったと思ってるんですけど、
この海面がだいぶ下がってきてる。
いろいろと簡単に作るようになってきたか故に、
これも欲しい、これも欲しい、あれも欲しいみたいな感じで、
ポコポコポコポコ海底火山が頭を出すっていうことになってるなって思ってるんですね。
なんでそういうものが並列していろいろ実装されて、
世の中にたくさんあふれてくるって世界になると私は想像していて、
薄利多倍じゃないですけど、1個が爆当たりするみたいな世界観というよりかは、
複数がニッチのところを取りまくって、そのニッチで世界を埋めていくみたいな、
そういうふうな製造のされ方になっていくんじゃないかなっていうふうに私は予測しています。
なんとなく言いたいことは分かりますね。
すごい細かいものがいっぱいできてきて、その中で自分に合うもの、
もしくは自分が使いたいものを作るかもしれないんですけどね。
用途に合えば他の人もそれを使うみたいな。
本当にちっちゃいところ、ニッチなところのものがすごい増えてくるかなとは自分的にも思いますね、確かに。
その並列度がめちゃめちゃ上がってくるっていう。
そうですね。私もつい最近はスライド作りながらソフトウェアを実装しながら、
自分のプロセスを改善するツールを作りながらレビューを受けてみたいなことを4並列とか5並列ぐらいでやっていて、
大体そういう世界になってくるんだろうなと思います。
ありがとうございます。じゃあいい感じの時間になったので、最後ですね、プロジェクトマネジメント、
39:03
最近PMOになった国明さんなんですけど、プロジェクトマネジメントの言いたいことがあったらお願いします。
そうですね。最近はアジャイルでだいぶ計画が流行ってきちゃって、計画をするってことがすごく軽視されるようになってきちゃったと思うんですけど、
私は依然として計画は大事だと思っているので、皆さんいい計画を立てて、いいプロジェクトマネジメントをしていきましょう。
ありがとうございます。では今回はここまでにしたいと思います。
もっと詳しく教えてください。ラジオ略称クアラジでは、スーパーエンジニアである国明さんに一般エンジニアである僕が技術的な質問をしていく番組になっています。
今後もいろいろなことを聞いていきたいなと思っていますので、お聞きのプラットフォームで高評価やフォローのほうをお願いします。
またこんなことを国明さんに聞いてほしいっていうことがありましたらコメントいただけると取り上げたいと思いますのでよろしくお願いします。
Xなどでハッシュタグクアラジで呟いてください。感想をぜひお願いします。
それでは今回もありがとうございました。
ありがとうございました。
