わんこPM

7,217 posts

わんこPM

@dx_saru

ビジネスとシステムをつなぐ。マネジメントとは、管理することではなく、うまくいくようになんとかすること

Amazonアソシエイトnote.com/dx_consul_saru…

Joined January 2024

6,289 Following

9,765 Followers

わんこPM’s posts

Pinned

わんこPM

@dx_saru

Dec 29, 2025

今年、効いた本。 ◆プロジェクトマネジメント『両利きのプロジェクトマネジメント』 ◆リーダーシップ『リーダーのためのストーリーテリング入門』 ◆チームビルディング『チームビルディングと組織開発の話』 ◆コミュニケーション『「わかってもらう」ということ』 ◆マネジメント

結局、図太い人は強いダメ元で「〇〇していい？」って聞いてみて、OKならラッキーだし、NGだったとしても断られたという言い訳を作ることができる。気遣いの人は自分の中で先にブレーキかけちゃうから損してる

「PMって指示するだけでラクそうでいいですね」って言われた。プロジェクトマネジメントは成功してるっぽい

前の席の人の足が臭くて作業に集中できないという訴えに対処したり、BPのおじさんが毎朝新人の女の子に「おはよう」のTeamsを送っているのを止めさせたりするのが、プロジェクトマネージャーの大切な仕事なんです

応用情報を合格した方へ。オススメの高度試験の順番。難易度や出題範囲など加味して以下の順番に受けるとスムーズです応用情報技術者試験 ↓ DBスペ、NWスペ、安全確保支援士 ↓ システムアーキテクト ↓ プロジェクトマネージャ ↓ ITサービスマネージャ ↓ システム監査技術者 ↓ ITストラテジスト

めっちゃ頭が良いし、面倒見もいいのだけれど、なぜだか周りのメンバーが疲弊してプロジェクトがうまくいかない人いませんか？例えばこんな人↓。下手するとパワハラにまでいくやつ　・とにかく話すスピードが速い・すべてを把握したがる・すべてに完璧を目指す

Replying to

奥さんへのプレゼントが家電とかなのもホント許せないのだが。

システム開発はなぜこんなに複雑なものをこんな素人ばかりで作っているのだろうか

求むクライアントに内緒でしれっと直したバグが原因でトラブルが起きた時の言い訳

頭はキレるし、面倒見も良いが、チームが疲弊するリーダーの特徴。まわりにもこんな人いませんか？すべて自分で考え抜いてから指示する。メンバーは意見を出す余地がないと感じてしまうメンバーのミスをすぐフォローする。一見優しいが自分で成長できない環境になる

PMOの難しさは「自分では決められない・動けない立場なのに、プロジェクトを動かさなければならない」こと。調整力が甘いと起きること・決まらないまま時間だけ過ぎる・依頼しても動いてくれない・結局PMOがこっそりやってしまう PMOとしてやるべきこと

Quote

わんこPM

@dx_saru

Jul 14, 2025

『自分ではなく相手が答えを見出す問い方と聴き方』これは…これこそが今の自分に必要なスキル。理論的に正しいだけじゃ人は動かないし、無理に進めてあとから反対されるのも悲惨だし。いかに腹落ちさせたうえで答えを出してもらうか。クライアントの問題をこちらで引き受けて解決するのではなく、クラ

ポートフォリオ出してって言われてもねえ業務系でマジメに自社の開発だけを頑張っている人は、表に公開できる実績なんてないんですよ…

PMにエンジニア経験は必要ないでしょどこまでPMに求めるんだよ

あなたはプロジェクトリーダー。いまはプロジェクトのピーク。あるメンバーに「この作業お願いしてもいいですか？」と聞いたら「嫌だって言ったらやらなくてもいいですか？」と言われました。なんて返しますか？？

いま相手しているベンダーさん。マジでこのレベルの障害分析しかしてこなくて、どこからツッコミ入れればいいか悩んでいる… 　 ■事象バグが発生しサービスが止まった　 ■原因個人の不注意によるプログラムミス　 ■対処プログラム修正　 ■今後の対策修正したソースをすべてレビューする

早めにリーダーを経験するのをオススメしたい理由リーダーシップとかマネジメントとかもあるけど、総じて言うと「自分で考えて決める」経験を多く積めることだと思う。小さなプロジェクトだったとしても、毎日何かしら決めて進めていく必要がある。リーダーの仕事は決めること

上流工程でミスって記載した１行のせいで、下流工程でリカバリするのに１か月かかるの、罪が重いな… この痛みが分からずに上流やったらあかんな

問題が起きたときのヒアリングの仕方。うまいこと整理しながら引き出していこう。責任追及は要らないですよ～「いつ、どこで、何が起きた？」「実害出てる？誰に影響が出ている？」「原因ハッキリしてる？再現性ある？」「原因ハッキリしてないなら、なんとなくあたりついてる？」

Quote

わんこPM

@dx_saru

Sep 30, 2025

問題が起きた際、とにかく１次情報を捉えて分析、調査すること。人から聞いた情報を鵜呑みにしてはいけない。人は意識せずに「事実」と「解釈」と「感想」をごちゃ混ぜに話すものだから

SIerのエンジニアだと「自分のやりたいこと」なんてそもそも無いのが普通じゃないかな　案件はお客様が決め、技術選定も制約だらけ。「やりたいこと」より「やらなきゃいけないこと」が溢れていて考える時間も全然ない

参考までにシステムを作ってもらう側のガイドブック・プロジェクトの管理・予算及び執行・サービス・業務企画・要件定義・調達・設計・開発・サービス・業務の運営と改善・運用及び保守・システム監査デジタル・ガバメント推進標準ガイドライン実践ガイドブック

digital.go.jp

デジタル社会推進標準ガイドライン｜デジタル庁

デジタル庁は、デジタル社会形成の司令塔として、未来志向のDX（デジタル・トランスフォーメーション）を大胆に推進し、デジタル時代の官民のインフラを一気呵成に作り上げることを目指します。

PMが潰れないために気をつけること完璧な計画より、修正しやすい計画を立てる。最初から崩れる前提でスケジュールを組む。守るより臨機応変に。誰が悪いかより何が起きたかで話す。トラブル時は感情を切り離して事実ベース。犯人探しはチームを壊す。

定期的にかみしめたい「システムは要件通りには動かない。設計通りに動く」

炎上案件にぶっこまれたときの初手　プロジェクトの目的を把握。全社の中でのプロジェクトの位置付けを確認。並行しているプロジェクトの状況確認。ステークホルダーの把握。プロジェクト計画書、課題表、進捗報告書など既存の管理ドキュメント確認。そして、諦めて、自分事として責任持つ決意！

炎上案件にぶっこまれたときの初手・プロジェクトの目的を把握・全社の中でのプロジェクトの位置付けを確認・並行しているプロジェクトの状況確認・ステークホルダーの把握・プロジェクト計画書、課題表、進捗報告書など既存ドキュメント確認・最後に、自分事として責任持つ覚悟を持つ！

システムの立ち上げなんてだいたいこんな三段落ちでできている AsIs：問題だらけで、どこから手をつければいいのか分からない現実。泥臭くて、矛盾していて、それでも誰かがなんとか支えてきた世界。 ToBe：

引き継いだシステムがとんでもなくバグだらけだったとして、自分事として謝ったり真摯に対応できるかどうか PMとしての度量が試される

だいぶ古いけど基本は大事　 IPA-SEC「超上流から攻めるIT化の原理原則17ヶ条」

業務システムなんだから業務を理解するのが当たり前だと思うけれど、業務理解するために現場で確認するとか首を突っ込んでいく人がほぼいないんだよな要件定義の数ヶ月、現場に行くもんじゃないのかな

プロジェクトマネージャーの「代打、オレ」は禁止。自分でやっちゃダメ

ITエンジニアさん。自分の開発環境が重くて動作が遅かったら、「こんなんじゃ仕事にならん！」って思うでしょ？それなのに、業務システムの検索に30秒かかるのは「仕方ない」って言うんですか？

「PMは謝ったら負け、つけ込まれるぞ」と教わってきて、一時期はツッパっていたのですが、やっぱり悪いときはごめんなさいしよう。素直になれるように普段から信頼関係を築いておく

ついに、PMOを支援する、PMO支援チームが発足しました。支援の輪が広がっています

リーダーの仕事は決めること。決められないってことが一番信頼をなくす。まわりも変化していくんだし、多少間違ってもいいんだよ　・できる限り１次情報を素早く集める・方向性決める・間違ってたら謝って見直す　この繰り返し

PMBOKとか、PMBOK関連本とか、あんなのは最初に読むものじゃないからね。アレでプロジェクトマネジメントを始めちゃだめよ。まずは現場で手を動かして、失敗と失敗と失敗と成功を体験してから読むもの。

エンジニアとして開発工程をひと通り経験しましたというのは、要件定義〜導入あたりで良さそうだけど、PMでそれだと足りないかな。システムの企画から入って、如何にシステムを活用するかから考えて、導入後に運用保守まわしたり効果測定するところまでは見ておきたい。ユーザー会社側になるつもりはな

要件定義３つ・業務要件定義・システム機能要件定義・システム非機能要件定義特に「業務要件定義」が重要。業務フローや業務ルールをキチッと固めないと、最後の最後の受け入れで崩壊する。発注側がメインで動く作業ですが、データが絡むので、システム側としてもきっちりおさえておくべき

たまには勉強しないとな… ITエンジニアは１年目：基本情報３年目：応用情報５年目以降、高度試験くらいが求められるイメージだけれど、３年目の応用情報が一番しんどい

PMとしては「自分で出来ないからやらせる」ではなくて、「自分で出来るけどやらない」であるべきなんだよな〜

WBSはスケジュールでなはい。大事なのは、スコープ決めて詳細にタスク出しすること。そのあとに、工数や前後関係を意識してスケジュール引く

え…進捗が遅れたときのリカバリ案て、PMが考えなきゃいけないの…？もちろん最後に責任持って対処するのはPMなんだけど、まずは個人で考えるべきじゃないのか。言われたことだけやって、遅れたら報告上げるだけじゃどうにもスキル付かないと思うけど… ちょっと驚きだった

どうせやるんだ前のめりで動いてコントロールしていこう！能動的アクション（言われる前にやろう！ほかの人を巻き込んで進めよう！）問題意識（与えられたものだけじゃなくて、自分ごととして問題をとらえよう！）業務理解（システムだけじゃなくて業務にも首を突っ込もう！）

マネージャーが周りの人に作業を渡して、自分の身を空けておかなければならないのは、未来のことを考えるため。自分で手を動かしているうちは、目の前の課題解決で精一杯になる。メンバーと同じ時間軸で活動してはならない。

こんなPMは嫌だ詳細な報告を頻繁に求めるくせに内容が理解できずに何も判断できない

PMとしてのコンプレックス。自分は技術にそこまで強くないし、業務知識もその場その場でかじった程度で、いろいろと中途半端。一緒のプロジェクトで作業するメンバーみなさんは、技術や業務のプロなので、ほんとリスペクトしてる。何とか皆さんの力を１つにできるようにすることが自分の仕事

スケジュールの作り方。ザックリやること（タスク）洗い出し ↓ 優先順位付け ↓ どこまでやるか決める ↓ WBSできあがり ↓ タスクの階層分け。粒度そろえる ↓ 作業時間の見積もり ↓ 依存関係みて作業順序の整理 ↓ スケジュールできあがり

みんなが考えすぎて複雑になったことを、シンプルに整理して見える化して、全員の認識を合わせる。それが自分の仕事のひとつ。それをやると、初めから分かっている一部の人からはこう言われる。「そんなの当たり前でしょ」「もう分かってるから」「時間の無駄、早く先に進もう」

プロジェクトのキックオフで「ストーリー」を語っていますか？数値目標だけになってないですか？？ロジックや正論だけではなく共感が求められる時代。論理的な正しさよりも、感情的な意味づけが重要になります

Replying to

こんな方がプロジェクトマネージャーとして仕切っていたので、一見カンペキそうに見えたのですが、中に入り込むとメンバーの疲弊がすごいのと、念の為の作業がとても多くてコスパは圧倒的に悪かったですねやりすぎ…

自分がここから学んだのは、ちょっと飛躍しますが、「お客に振り回されるな、先手を打って自分でコントロールしろ」ということと「要件を全部詰め込むのではなく、最も価値の高いものから着手しよう」ということでした

Quote

うめめ

@beConjuror

Oct 5, 2025

新社会人にもベテランにもおすすめなのがエッセンシャル思考。仕事をしているのに大事なことは前に進まない、徒労のような状態になりがち。本当に大事なこと、睡眠や遊び、重要な仕事だけにフォーカスし、不要なものは断るべきなのです。

26K