はてなブックマーク

プロジェクトマネジメントで欠かせないWBSを、AIと一緒にどう運用するかという話です。今回は私が普段使っているWBSスキル群について、それぞれの役割と、なぜそういう設計にしたのかを共有していきます。手動でWBSを更新し続けることに疲れている方には、ヒントになれば幸いです。 最後に、Skillsファイルも配布しておきます。 なぜExcelのWBSに戻したのかWBSの管理ツールって、本当に人によって違いますよね。Notionで管理する人もいれば、JiraやBacklog、GitHubのIssueで回している人もいます。 そんな中で私が最終的に行き着いたのが、ExcelやGoogleスプレッドシートでした。 理由はシンプルで、関係者が多くなるほど「ツールを使いこなせない人」や「使えても更新してくれない人」が出てくるからです。せっかく高機能なツールを導入しても、更新されないWBSはただのお飾りにな

2025年からAI駆動PMについて発信してきましたが、2026年4月時点の最適解をまとめきれていなかったので、整理しました。ツール構成からプロジェクト推進の進め方まで、私が実際にやっていることをよければどうぞ。 具体の内容までかくと一生書ききれないので、本日は仕組み編とさせていただきます。 CursorからClaude Codeへ2025年初旬、PMのAI活用といえばCursor一択でした。 ところが2025年秋頃から流れが大きく変わります。Claude Codeが注目され始め、2026年は空前のClaude Codeブームです。私のAI駆動PMの手法も、すべてClaude Codeで行うようになりました。 ちょっと前の記事で「組織活用にはNotion AIがいい」という話をしたのですが、これは前言撤回させてください。。。。すみません。 Notion AIは非エンジニアでも使いやすいという

Anthropicが公式に出している「Agent Skills」、全17種類を実際に試してみました。同じプロンプトをスキルあり・なしで投げて、出力を比較しています。「結局どれ使えばいいの？」という方の参考になれば嬉しいです。 スキルありとなしで何が変わるのかAgent Skillsは、Claudeに専門知識パッケージを読み込ませて、特定のタスクを高品質に実行させる仕組みです。Anthropicが公式で17種類を公開しています。 今回、このうち16個について同一プロンプトでスキルあり・なしの出力を比較しました。所要時間、トークン消費、ツール呼び出し回数の定量データと、成果物の品質を定性的に評価しています。 結果！！16個中5個しかスキルありの方が品質が高くないことがわかりました。必ずすもスキルを入れたら良くなるとは限らない、というのがこの検証の結果です。※1件未検証 検証の方法はシンプルで、

Google Stitch、話題になってますよね。 ただ、デザイナーじゃない自分からすると 「すごそうだけど、結局なにができるの？」 がよくわからなかった。触ってみたいけど、何から手をつければいいかもわからない。 同じように感じている人、けっこういるんじゃないかと思います。 なので、非デザイナーの私が実際に触りながら「こういうやれば、だいたいわかる」というハンズオンマニュアルを作りました。 あくまで"だいたい"です！！ この記事の通りに手を動かしてもらえれば、Google Stitch がどんなものか、なんとなーく掴めると思います。よければ使ってください。 そもそも Google Stitch って何が話題なの？Google Stitch のすごいところは、簡単にいうと3つだと私は思っています。 AIネイティブなデザインキャンバス: テキストや音声で指示するだけで、無限キャンバス上にUIデ

この記事は 期間限定で全文無料で閲覧できます。 前回の記事「PMはスキルエンジニアリングを極めるべし」では、PMが今やるべきはモデル競争を追いかけることではなく、自分の業務をSKills化する力を磨くことだという話をしました。 今回はその続きで、「じゃあ実際にどうやってスキルを作るの？」という具体的な方法を解説していきます。エンジニアではない方でも作れるように、考え方から手順まで丁寧に書いていきます。 そもそもSkillsとは？Skillsは、よくやる作業手順や知識をまとめた「スキルファイル群」を作っておくと、AIがそれを読み取って実行してくれる仕組みです。 今回はClaude Codeを使った作り方を解説しますが、SkillsはClaude Code固有の機能ではありません。CodexやCursorなど、他のAIコーディングツールでも同じ考え方で進められます。スキルの設計や構成の仕方は共

AIでスライド作ったけど、実務では使えない おしゃれなスライド作れたけど流石に定例報告会では使えない スライドガチャに疲れた 多くのビジネスパーソンがそう思っていると思います。 実際に、NotebookLMやClaudeで作るAIのレベルはものすごく高くなってきていて、スライド作成の経験がない人よりも良い構成でおしゃれなスライドを作れるようになってきていると感じます。 ただし、日常の仕事ではAIが作った資料をそのまま使えるケースは意外と少ないです。 要は使い分けが大事です。 社内勉強会やnote記事の挿絵など、カジュアルな場面ではAIスライドの表現力が活きます。一方、顧客向けの報告資料や提案書のように正確さと型が求められる場面では、自社テンプレートに沿ったシンプルなスライドの方が適しています。 本記事では、自社テンプレートを活かしたシンプルなスライド生成スキルの作り方をお伝えします。 作る

話題のClaudeCodeで新機能「Agent Teams」が登場しました。 非エンジニアの私は理屈はわかっていても実際どう使うのか全然わからなかったので、AIにデモを作ってもらったのでそのままシェアします。同じ気持ちの方がいれば参考にしてください。 Agent TeamsとはClaude Code 内で複数の Claude セッションを チームとして並列に協調させる仕組み です。複数の AI インスタンスを分業・並行処理させることで、大規模なタスクや複雑なワークフローを効率的に進められます。 「自分でSubAgent作らなくてもClaudeCodeが勝手にSubAgentっぽいものを作ってくれて実行してくれる」みたいな理解で一旦いい気がしています。 ※厳密には違うと思いますが。。。悪しからず 考えるより体験するべしAgent Teamsを一回体験してみるためのデモ手順になります。この手順

タイトルの通り、「Obsidian」を引退しました。 以前はObsidianに関する記事をよく書いていましたが、ついにObsidianを完全に引退しました。勘違いしてほしくはないのですが、これはObsidianがダメなツールだという話ではなく、私の作業環境が変化した結果です。同じようにツール選びで悩んでいる方の参考になればと思い、経緯をまとめました。 参考：過去のObsidianの記事 Obsidian引退の背景Obsidianはプラグインも豊富で、非常に使いやすい素晴らしいツールです。この点は今でも変わりません。 今回の引退は、あくまで「私が使いこなせなかった」、あるいは「私の求めていた環境が、他のアプリですべて完結できるようになったため、ツールを集約した」という、個人のワークフローの変化によるものです。 今までの課題今までは、アイデアなどをObsidianで蓄積していき、それをCurs

NotebookLMによるスライド作成の品質が本当にやばいですね。 少し前まではAIスライドは実際のビジネスの場では使えないものばかりでしたが、Nano Banana Proの登場とNotebookLMでの活用で普通に使えるレベルになっていますね。 素晴らしいスライド作成プロンプトは多くの方が紹介していますので、そっちをみてもらい、この記事では そもそもスライドのレイアウトパターンってどんなものがあるのか。 レイアウトをどうAIに伝えるべきか を言語化して整理しました。 あくまでレイアウトパターンなので、デザインについてはFIJIさんの記事などを参考にすると良きかと思います。 この記事では全部で32パターンのスライドレイアウトを言語化しました。自分でAIスライドで指示をする際の参考にしてください。 ※新しいレイアウトがあれば順次追加していきます。 早速いきましょー。 補足：各レイアウトパタ

『7つの習慣』は昔に一度読んだことがあるのですが、正直なところほとんど覚えていない状態でした。そんな時に、PMコミュニティの座談会でこの本が話題になり、「改めて読む価値がありそうだ」と思って手に取ってみました。すると、昔は気づかなかった大切な考え方、特にプロジェクトマネジメントにおける重要性を再認識することができました。今回は、その気づきを紹介させてください。 『7つの習慣』って、意識高い人が読む「ザ・自己啓発本」だと思っていました。w　それは間違いではないのですが、プロジェクトマネジメントをする上で重要な考え方がかなり言語化されているので、固定概念を捨てて一度この記事を読んでほしいです。 人格主義がPMの土台になるこの本で学んだのは、「人格主義」という考え方です。簡単に言うと、テクニックやツールよりも、まずは自分自身の人格を磨くことが大事ということです。誠実さ、謙虚さ、勇気といった内面的

Cursorがよくわからない。 難しすぎます。。。 全然、Cursor使ってくれない 約半年前、「AI駆動PM」というnote記事を公開し、多くの方から反響をいただきました。以来、AI駆動PMをテーマに発信を続けてきましたが、現在、組織的な活用という大きな壁に直面しています。 前回の記事では主にCursorを使った手法について書きましたが、チームメンバーへの導入を進める中で、非エンジニアやAI初心がCursorをいきなり使うのはハードルが高いという課題が見えてきました。 そんな中、Notionのアップデートが発表されNotionAIが思った以上にCursorと近いことができてきたと感じ、Notion完結のAI駆動PMの手法を試した結果をまとめさせていただきます。 Notionで完結させるAI駆動PMが現実的になってきた ・Cursor利用率0% ・メンバーはNotionAIのみでOK ・組

「あれ？思っていたものと全然違うな……」 「あの要件もあった！完全に忘れてた...」 「このツール、今の会社では使えないんだよな。APIが使えないじゃん。」 最近、ツール開発する機会が増えてきてよくこの問題に出会して、大きな手戻りが発生することがあります。特に非エンジニアの方が自分で使うツールをAIに開発してもらう場合、要件定義の段階で機能や仕様、目的が固められていないまま開発が進み、後から「思っていたものと違う」という事態が頻繁に発生していました。 例えば、Google Apps Scriptで日々の業務を自動化したいという要望があったとします。最初は「Excelの集計を自動化したい」というざっくりとした要望から始まるのですが、いざAIに開発してもらう過程で「集計のタイミングはいつ？」「エラーが起きたらどうする？」「誰に通知するの？」といった質問が次々と出てきます。そして、AIに開発して

「営業から来る“要望メモ”の粒度がバラバラで、結局エンジニアが聞き直している」 「テンプレートを配っても、項目が埋まっていなかったり、書き方が統一されない」 「会議のたびに前提や非機能要件が抜けていて、見積もりがブレる」 私もプロジェクト現場で、同じ悩みに何度も直面してきましたし、テンプレート配布や教育を繰り返してもなかなか揃わないという壁にぶつかってきました。 そうした中で、Notionのボタン一発でAIレビューを回し、所定のテンプレートに自動整形したうえで不足点を赤ペン指摘まで返す仕組みを試作してみたところ、粒度のバラつきやレビューの遅延を減らせる可能性があると感じています。 今回は、その仕組みと実装手順を、非エンジニアでも実務で回せるレベルまで分解してお伝えします。 もし「運用負荷を抑えながら、書き手の経験差を補正したい」と思っているなら、この記事は参考になるはずです。 AI要件定義

「またObsidianで挫折しそう...」 「前回も途中で諦めちゃったし、今度も同じかな」 もしこんな風に思っているならこの記事は少しは役に立つかもしれません。 私も実は、Obsidianで挫折した経験があります。最初は「難しすぎる」、次は「何をどう使えばいいかわからない」、最後は「結局続かない」という理由で。 でも、ある日気づいたことがあります。挫折の原因は、Obsidianが難しいからじゃなかったです。 Obsidianはアイデア次第でなんでもできますが、あくまでWant（欲求）です。まずはMust（必須）の課題解決に集中することです。 今回は、今度こそ絶対に挫折しないObsidianの始め方を、ステップバイステップでお伝えします。 「もう諦めよう」と思っている方は最後にぜひ読んでいただければ嬉しいです。 ちなみに、Xで拡散されているようなかっこいい使い方やデザインは一切ありません。シ

PDFファイルをマークダウンに変換する作業って、地味だけど本当に大切な作業ですよね。 「また手作業でコピペか...」 「レイアウトが崩れてる...」 「表がめちゃくちゃになってる...」 私もさまざまな文書管理の現場で同じような課題に直面してきました。特に、既存のPDF資料をObisidianやNotionなどのマークダウン形式で管理したい場面って、本当に多いですよね。 手作業でやると、一つの文書だけで数時間かかることもあります。表や画像の配置を調整して、リンクを張り直して、フォーマットを整えて...。骨が折れる作業です。 「もっと効率的な方法はないだろうか？」 そう思っていた矢先、いくつかの優秀な手法を発見しました。今回は、スキルレベル別に4つのアプローチをご紹介したいと思います。 【各レベルの概要】まず、それぞれのアプローチの特徴を簡単にご紹介しておきますね。 レベル1：GPT-5でシ

「あれ、このプロジェクト、結局何を目指してるんだっけ？」 「この資料、結局何が言いたいのか、さっぱりわからない…」 「もっと主体的に考えて動いてほしいんだけど、どう指導すればいいんだろう…」 プロジェクトマネージャーやチームリーダーとして、メンバーとのやり取りの中でよく聞く話。 私はこれまで、事業会社やコンサルティングファームで、数多くのプロジェクトマネジメントとプロダクトマネジントに携わってきました。多くのプロジェクト推進する中で、ずっと感じていた一つの大きな課題があります。 それは「仕事の進め方の『OS』が、メンバー間でバラバラである」ということです。 優秀なメンバーは、無意識のうちに効率的な思考法やコミュニケーションの型を実践しています。しかし、それを言語化してチーム全体に共有するのは、驚くほど難しい。結果として、仕事の品質は個人のスキルに依存し、チームとしてのパフォーマンスが安定し

※本記事はdrawioバージョンです。 miroによる出力を希望される方は以下の別記事ををご覧ください。 プロジェクトの関係者全員が納得する「業務フロー図」。それはプロジェクトを円滑に進めるための"共通言語"であり、重要な存在です。 しかし、その作成は本当に骨が折れる作業です。一つ一つの箱を作り、線でつなぎ、色を分け…。手戻りが発生するたびに、あのコネクタを一本一本修正する虚しさ。初期のたたき台を作るだけで半日が終わってしまい、肝心の"中身の議論"に時間を使えないなんてこともザラです。 「この作る手間さえなければ、もっと本質的な議論に集中できるのに…！」 そう思っていた矢先、ある方法を試したところ、この長年の悩みが劇的に改善しました。それは、AIコーディングツール「Cursor」を使って、業務フロー図の作成を自動化するというアプローチです。 実際にCursorで実行して出力された業務フロー

プロジェクトの状況を関係者に正確に伝え、議論を促進させるための「スライド作成」。これは私たちの業務において極めて重要なタスクの一つです。 しかし、このスライド作成に多くの時間を費やしてしまい、より本質的な課題解決や戦略策定といった業務への集中を妨げている、と感じることが多いです。 近年、GensparkやGmmaやFeloなど優秀なAIスライド作成ツールが登場し、資料作成の自動化に大きな期待が寄せられています。キーワードを入力するだけで、デザイン性の高いスライドが生成されるのは、確かに画期的な技術です。 しかし、結論から言うと、私はこれらのAIスライドツールを実務では採用していません。 その理由は、現状のAIスライドツールが、PMの実務における速度と品質の要求に、必ずしも応えられていないと感じるからです。本日はその理由と、私が最適解だと考えている「CursorとMarpを組み合わせた爆速ス

日々、プロジェクトマネジメント業務において、AI駆動PMをおこなっています。 私は思考の整理からタスク管理、ナレッジベースの構築までこなせるObsidianと、AIがコーディングや文章作成をサポートしてくれるCursorを愛用しています。この2つのツールを導入してから、PMとしての日々の仕事のレベルが格段に上がったと実感しています。 詳細はこちらの記事をご覧ください。 私はWindowsのデスクトップPCとMacbookの2台持ち。そのため、作成したメモやドキュメントは、どちらのデバイスからでも常に最新の状態でアクセスできる環境が不可欠です。 当初は、手軽さからGoogleドライブをデータの保管場所にしていました。これで、どのデバイスからでも同じデータにアクセスできる環境は実現できていました。しかし、長く使っていると、いくつかの課題も見えてきました。 過去のバージョンに戻せない…！ Pyt

この記事で伝えたいこと ・属人化業務のマニュアル化は「面倒」で後回しにしがち ・音声入力を活用すれば、通常業務をしながら自然にマニュアル化できる ・たった1時間で20個の属人化業務をマニュアル化した実体験を紹介 属人化業務のマニュアル化、なぜ進まないのか？多くの組織で課題となっている「属人化業務」。 誰もが「マニュアル化すべき」と分かっていながら、なかなか着手できない、あるいは着手しても中途半端なマニュアルで終わってしまうことが多いのではないかなと思います。 私自身、多くの属人化業務を抱えており、「マニュアルを作ろう」と思いつつも、以下のような理由で進まない状況が続いていました。 マニュアル作成の優先度が常に下がってしまう 面倒くさくて着手する気が起きない 作っても基礎的な内容しか書けず、重要な暗黙知が抜け落ちてしまう 結果として、引き継いだ人が苦労することになる しかし最近、「音声入力」

PM：「この施策、どうやって進めていけばいいんだろう...」 チーム：「要件が曖昧で、何から手をつければ...」 経営層：「もっと早くプロジェクトを進められないの？」 ・・・ ・・・ 「また同じような課題で躓いてる...」 「手戻りばかりで進まない...」 「プロジェクトの期限に間に合わない...」 私も非エンジニアのPMとして、長年プロジェクトマネジメントの現場で、同じような課題に直面してきました。特に非エンジニアのPMの方々は、技術的な判断も求められる場面で不安を感じることも多いはずです。 でも、大丈夫です。今、私たちには心強い味方がいます。そう、AIという最強のプロジェクトパートナーです！ ChatGPTの登場以降、多くのビジネスシーンでAIの活用が進んでいますが、実はプロジェクトマネジメントこそ、AIの力を最大限活用できる分野です。 なぜ今、AI駆動プロジェクトマネジメントなのか？

あれ、削減できたはずなのに忙しさが減らない？ 「業務の効率化が大事だから」と経営陣からDX推進や業務改善のプロジェクトを任され、意気込んでスタートしたものの、いざ蓋を開けてみると現場からはこんな声が出てきます。 ・「作業時間は減ったはずなのに、なぜか忙しさは変わらない…」 ・「ツール導入で1時間かかっていた作業が10分になったのに、そのぶん空いた時間の実感がない」 ・「数値上は効率が上がっているはずなのに、あまり成果が感じられない」 思い当たる人も多いのではないでしょうか。これは決して珍しいケースではありません。どの企業でも「生産性向上」を旗印に業務改善に取り組みますが、期待通りの効果を実感できずにモヤモヤしていることがとても多いです。 なぜ、こんなギャップが生まれてしまうのか？ その原因の一つは、「業務改善の本来の目的」を取り違えてしまっていることにあります。業務改善と聞くと、「時間削減

新人PL「はじめてプロジェクトリーダーをするけど不安だ….」 MGR「メンバーにプロジェクトリーダーを任せたいけど、大丈夫かな….」 春になると新しい環境で新しい挑戦をする季節です。 プロジェクトリーダーを初めて担当する方向けのハードルの低い教科書をイメージして執筆しました。よって、 プロジェクトマネジメントにおける前提となる考え方に焦点を当てた内容です はじめてのプロジェクトマネジメントで不安がある方にぜひご覧いただきたい内容です。後輩メンバーや部下がはじめてPM業務を担うという方にも、この記事をシェアして読んでいただければ嬉しいです。 本記事では、プロジェクトマネジメントにおいて特に重要だと感じる4つのスキルを中心に解説します。PMBOKなどの体系的な知識ももちろん大切ですが、「あれはちょっと分厚いし、あまりに難しくて数ページで挫折しそう…」という方も少なくないと思います。そこで、10

役員「新しいプロジェクトに新卒入ってもらうから、よろしく！」 PM「新卒って育成もしないといけないのか。。。」 PMがメンバー育成もしている組織は非常に多いです。その場合、プロジェクトも育成も両方うまくいかない確率が増えると思っています。 今日はそんな話。 私もよく「PMだから、人の教育や評価をしているんですよね？」と聞かれます。これって「マネージャー」という言葉のイメージによる誤解なんだろうな、と思います。「マネージャー」と聞くと、どうしても「部下の教育やモチベーション管理をする人」ってイメージしませんか？ さらに、日本企業の多くは「課長」「部長」といった役職があって、その役職者が人の評価権限を持ちますよね。つまり、マネージャー＝組織マネージャー、という構図が頭にこびりついているわけです。でも「プロジェクトマネージャー」はそうではなくて、組織というより“プロジェクト”単位のマネージメント

「あれ？思っていたものと全然違うな……」 「すみません。そもそもこの機能がないと業務が回りません。」 「・・・今言われても・・・」 こういった言葉は、プロジェクト後半やリリース後にたびたび聞かれるものです。一番テンション下がる瞬間ですね。笑 こうした状況になる原因のほとんどは、要件定義の過程でしっかりと機能や仕様、目的が固められていなかったからです。 特に非エンジニアの方であれば、用語や技術面でつまづくことも多く、開発サイドとのコミュニケーションの齟齬が起こりやすくなります。そうならないようにするためにも、要求定義と要件定義の流れと進め方、さらに注意点をしっかり押さえておきましょう。 この記事を読んでほしい人 ・初めてシステム開発やツール導入のプロジェクトを担当する方 ・非エンジニアで、ITプロジェクトの進め方に不安を感じている方 ・要件定義や要求定義の違いがよくわからない方 ・ベンダーに

この記事をご覧になっているということは、業務フロー作成について関心がある、または「そもそも業務フローってどう作ればいいの？」と悩んでいる方が多いのではないでしょうか。 私自身、これまで10年以上で1,000枚以上の業務フローを作ってきました。DX推進や業務改善、新規事業の立ち上げなどに携わり、たくさんの成功例と同時に、失敗例も目の当たりにしてきました。 その中で痛感したのは、業務フローは単なる「手順書」ではないということ。適当に作った業務フローでは、いざプロジェクトが動き出したときに想定外の問題が発生し、最悪の場合、事業の撤退にまで追い込まれることもあります。一方、しっかりと設計された業務フローは、現場に安心感をもたらし、プロジェクトをスムーズに進める土台となります。 この記事では、私が実際の現場で培った経験をもとに、実践で使える業務フロー作成のコツをお伝えします。専門用語は最小限にしつつ