すべてのカテゴリ

一番下の娘に苦言を呈することがある。そうすると、決まって『私、失敗しないので』と言われる。それを聞くたびに米倉涼子が脳内を飛び回るそんな日々。みなさんお元気ですか？☆━━━━━━━━━━━━━━━━━━━☆世の中を見渡すと、「失敗しない方法」を説くそんなコンテンツが多い。しかし、もっとも大切なのは【失敗と思わない思考】ただこれは、「失敗に気づかない・気づけない」とは根本的に違います。失敗を恐れない心と言えるかも知れません。それに注目されてしまうのは基本的に『失敗したくない』そう願う人たちが多いからでしょう。就活、昇進、試験、恋愛・・・。シーンは人それぞれ。失敗したくない場面は結構多い。しかし、失敗を恐れると新しいチャレンジをしなくなる。失敗を避けようとすると、守りに入ってしまう。そうすると、”痛い経験”から遠ざかり、自分の経験値が溜まりません。経験から導かれる解決策やアイディアが浮かばなくなります。ロープレゲームに例えるなら、自分より弱い敵しか出ないと分かりきっているエリア内で敵キャラと戦っているようなもの。いつまでたっても経験値は貯まらないし成長スピードも遅い。時には、ー未開の地に飛び出すーそうしないと先を見ることも、自分の可能性に気づくこともありません。「失敗すること＝マイナスではない」まずはこの思考を持つことが大切。失敗を恐れるのではなく、失敗から学びを得る方が断然いい。失敗をすることで・自分の何が足りなかったか？・何をすればクリアできたか？を振り返ることができます。このような思考であれば、ー 失敗をクヨクヨ考えたり、ー 夜も眠れないほど悩んだりそんなことは無くなります。

できればPMとしては顧客の要望をすべて受け入れたいです。しかしそれでは現場が疲弊しますし、利益貢献からも遠ざかる行為です。今回は24年の経験の中で、SIerと事業会社の両方の立場を経験したからこそ見えるPMのスタンス・振る舞いについて語ります。（全3回を予定しています）ポイント1：安定期と炎上期で「折衝のギア」を入れ替える比較的安定している工程では「顧客ファースト」の精神で傾聴し、調和を重んじることが重要 。立ち上げ～要件定義前半までが妥当だと思います。別の記事でも語りますが、「要件定義の課題を次工程に持ち越す」という考えは炎上のきっかけになりますので、あくまで要件定義前半までのアイスブレイク完了までが安定期といってもよいと思います。※受注時点で不利なこともしばしばあると思いますが、その場合は折衝するのに背負うものが文脈的には異なるので別の機会にお話ししたいと思いますそして一旦プロジェクトが火を吹き始めたら、原因を突き止める「冷徹さ」が必要です。自社に原因があるのか、あるいは顧客側であるのか。そこを突き留めずに活動していても対症療法にしかならずその場しのぎです。燃えたら原因の特定を急ぎます。ポイント2：顧客側に原因がある時の「チェンジリクエスト」の出し方結論は、理路整然を事実を集めてチェンジリクエストを上司・営業とともに顧客に提案する、です。（自分が職業PMの場合）事実（ファクト）を集めるために議事録の作成とそれへの合意は必要になります。原則としてお金が動く契約絡みのプロジェクトであれば、エビデンスベースで進める必要があります。ウォーターフォールであればドキュメントが残し易いで

プロジェクトマネージャ試験(情報処理技術者試験)の午後Ⅰの対策を書いてみます。１．大問はどれを選択しても良い。　　難易度はどの問題も変わらない。　　自分の場合、解答用紙を見て、文字数が少ない大問を選択していた。２．設問書かれている業界・業種・業務・システムに　　詳しくなくても全く問題ない。　　具体的な事柄は設問の中に書いてあり、　　PMとしての基礎知識があれば正解できるように作問されている。３．案外簡単なこと（だと自分は思う）が正解になると心得る。　４．次の順番で解答を考える。　  （自分のイメージでは、①と②で9割近く解答できる。）　　　　①設問の文章の文言をそのまま利用して解答できないか。　　　　②設問の文章に書かれていることをベースに、　　　　　一般的な基礎知識をもとに解答を構成できないか。　　　　③一般的な知識をもとに解答できないか。５．過去問から、模範解答によくつかわれている、　　あるいはつかいやすい、キーワードを把握しておく。　　例えば、「品質」、「コスト」、「納期」、　　「（…という問題が起こらないように）適切に対処する」、など。６．20～50文字以内で、書くべきことを書く練習をしてみる。　　「大体どれくらい書けば、その文字になっているのか」、　　「所定の文字数で書きたいことをまとめるには、　　どのような言葉をつかえば良いのか」という　　感覚を掴むための練習をしておく。７．部分点を拾う。（なんと、部分点が貰えるんですよね。）　　時間内に所定の文字数で文章をまとめられなくても、　　何かしら、例えばキーワードだけ書いてみる、など。以上です。もし、試験対策をご希望の方が

こんにちは。後藤悟志です。僕はPMとして10年以上、さまざまなプロジェクトに携わってきました。その中で気づいたのが、IT未経験からプロジェクト管理に挑戦した方が、ほぼ同じパターンでつまずいているという事実です。今回はその「あるある失敗」を3つに絞ってお伝えします。パターン1：スケジュールを「予定」ではなく「願望」で引いてしまう未経験の方がよくやってしまうのが、「うまくいけば間に合う」という前提でスケジュールを組むことです。バッファ（余裕）がゼロで、一つ遅延が出た瞬間に全体が崩壊します。プロジェクト管理において、スケジュールはリスクを織り込んで引くものです。「最悪このくらいかかる」を起点に考える習慣をつけましょう。パターン2：後藤悟志も最初は陥った「報告・連絡・相談」の軽視PMの仕事の本質はコミュニケーションです。それなのに、未経験の方は「問題が起きてから報告すればいい」と思いがち。実際には、問題が起きる前の小さな異変を早めに共有することで、炎上の8割は防げます。僕自身、若手の頃に報告を後回しにして痛い目を見た経験があります。「早めに・短く・こまめに」が鉄則です。パターン3：ツールを入れれば管理できると思ってしまうガントチャートや課題管理ツールを導入して「これでOK」と安心してしまうケースです。ツールはあくまで手段。肝心なのは、チームメンバーが状況を正確に把握し、動ける状態を作ることです。ツールよりも先に、「誰が・何を・いつまでに・どういう状態になればOKか」を言語化することに時間をかけてください。まとめIT未経験でプロジェクト管理に挑戦すること自体は、とても素晴らしいことだと思

「PMOは単価が高いから皆すごいんだよね」「アジャイルだから細かい管理はいらない。PMOならわかるよね？」 現場でそんな風に言われ、肩身の狭い思いをしていませんか？(PMOの役割もプロジェクトごとの立ち位置によりますが) 教科書には「PMOはガバナンスを効かせるべき」とありますが、現実はそんなに甘くありません。正論を振りかざせば現場は反発し、ますます情報は入ってこなくなります。IT業界で24年、PM・PMOとして15年。数々の炎上現場を見てきた私が、現場の信頼を勝ち取り、停滞したプロジェクトを動かすために実践してきた「泥臭い方法」を少しだけお話しします。1. 「正論」が現場を壊すこともあるプロジェクト管理のロジックは正しいはずなのに、なぜか現場が動かない。そんな時は、ロジックよりも「感情」が先行しているケースがほとんどです。忙殺されているメンバーにとって、管理側の正論は「仕事を増やすノイズ」にしか聞こえません。まずはロジックを一旦脇に置く勇気が必要です。（どうやって距離感を縮めるか）2. まずは「管理」を捨てて「支援」から入る嫌がられる進捗管理の前に、メンバーが本当に困っている「面倒な事務作業」や「他部署との細かな調整」を一つ拾ってみてください。「このPMOは自分たちの味方だ」という認識に変わった瞬間、情報の集まり方が劇的に変わります。（懐に飛び込む覚悟）3. 「見えない化」が一番のリスク状況の見えない化(out of control)がPMにとってももっともリスクのある状況です。プロジェクトメンバーも不利なことは隠したいのが心情。情報を無理やり引き出すのではなく、自然に集まっ

開発には、同時に行える「並列処理」と、経時で行うしかない「直列処理」があるハズです。たとえば、設計と実装は「並列処理」できません。「並列処理」と「直列処理」の違いをきちんと描き込まないと、フロー図を描いても進行管理が難しくなります。前回は、下図のようなフロー図を示しましたが、この中では、現状把握、業務要件、機能要件、非機能要件の見当が同時並行で描かれています。現状把握、業務要件、機能要件、非機能要件の四つは、時間経過を上から下へと位置で示すとしたら、並行処理として表現されています。また、それぞれの面積（横幅、高さ）が狭く表現されています。しかし、この四つの処理はもっとボリュームがあるハズです。同時に進められるとも限りません。次の図のほうが、皆さんの実感に近いのではないでしょうか？時間を縦軸で表現すると、自然と作業のボリュームがイメージできます。（コーディングを複数人で分割担当するなら、コーディングの部分だけ横幅を広げると、作業の日数とボリュームが伝わりやすくなるでしょう。）上の図をみて直感的にわかることは、現状把握～非機能要求までをPMが担当するとなると、PMの負担が大きすぎるということです。さらに問題なことは、VBAの開発経験が豊富なPMでなければ、この部分の対処ができないことです。特に業務要件の把握が難しいと思います。PMにすべての負担が集中する（PL的／PMO的なVBAエンジニアがいない）場合）を図に示せば、次のようになるでしょう。このため、ありがちなのは、現状把握～非機能要求のまとめを、非エンジニアの事業部門様に丸投げしてしまっている、という状態です。当然ながら、要求の

「進捗が遅れているけれど、正直に言うと詰められる…」 「顧客にどう説明すれば、納得してもらえるんだろう」PMOやプロジェクトリーダーをしていれば、必ず一度は「悪い報告（バッドニュース）」をどう伝えるかで夜も眠れないほど悩むものです。 以前に報告した際の反応が悪かった場合はなおさら、身構えてしまいますよね。しかし、24年の現場経験から言えるのは、「バッドニュースを報告するのは、情報を持っている者の義務である」ということです。報告を躊躇して遅らせることは、結果として自分自身の責任を重くしてしまいます。「隠す・盛る」は最大の悪手現場のメンバーは「怒られるのが怖い」という心理から、つい遅延を隠したり、過小報告したりしがちです。ですが、それが後で爆発（炎上）したとき、最も信頼を失うことになります。世の中には「バッドニュースファースト（悪いニュースほど早く報告せよ）」という言葉があるくらい、早期共有は重要です。本来、「報告しやすい環境を作る」のはプロジェクト運営側の役割です。 しかし、現実にはそうなっていない現場の方が多いのも事実。報告者は辛い立場に立たされますが、そこはプロとして「覚悟」を持って臨むべき場面です。何を伝える？報告の「黄金セット」ただ「遅れています」と言うだけでは不十分です。相手の不安を解消するために、以下の4点をセットにして伝えてみてください。事実：何が、どれくらい遅れているか原因：なぜそうなったか（他責にせず客観的に）対策と提案：どのような対策を検討中か、あるいは実施しているか相談：上層部に「何を決めてほしいか」ここでのポイントは、**「報告だけでいいのか、それとも判断

ちょっと息抜きに、「PM試験の世界観」について書いてみます。あくまで個人的なイメージとして、高度情報処理技術者試験にも、試験問題を作成するときの前提条件になっていそうな、いわば試験の世界観のようなものが、何となくあるように思っています。このイメージが何となく掴めると、午後試験で、出題者が想定している解答と全く違うことを書いてしまう事態を避けやすくなる、ような気がします。あくまで個人のイメージですので、全く共感できないという方は、お気になさらないでください。１．組織・システム・プロジェクトの規模が大きい高度試験のPM像は、従業員が数万人はいるような、官公庁や大企業のようなところで、後述のようにある程度優秀な人達と協力して働いている、サラリーマンのような人をイメージすると、しっくりくる問題が多いです。組織・システム・プロジェクトの規模が大きいほど、PMの仕事の重要性が認められやすくなるので、それはそうだろうなと思います。近年はアジャイル開発の問題も出題されているとはいえ、なんだかんだ「大きな組織の、大きなシステムの、ウォーターフォール型のプロジェクト」のような事例が、午後Ⅰ試験の問題文に多く、午後Ⅱ試験のネタとして取り上げやすいことが多いです。２．「ルール」がとても重要当たり前ですが、大きな仕事を動かすには、絶対にルールが必要です。PMも、基本的に自分が所属する企業などが定める様々なルールに従って動いています。業務分掌もルールの一つと言えます。PM試験の中のPMは、組織の中である程度定められた仕事・役割・責任（IPAのシラバスや試験要綱に書かれているようなこと）を全うしており、他の

令和7年(2025年)秋期の情報処理試験(10月12日)まで、残り1ヶ月を切りました。これから試験当日までに行うべきことや行うと良いことを書いてみます。1．勉強以前に大事なこと試験対策は社会人生活の練習のようなものです。勉強の出来以前に、体調などのリソースの管理や、ルールを守るといったことを、しっかり行う必要があります。折角の努力が水の泡にならないように、勉強以外の準備もしっかり行いましょう！1-1．IPAの試験情報必ず！絶対に！IPAのWebサイトで試験情報を確認しましょう。受験票の発送時期、住所変更手続き、受験票が届かない場合や汚損した場合の問い合わせ、当日の注意事項など「も」、丁寧に記載されています。1-2．受験票・証明写真受験票が届いたら、早めに中を確認しましょう。記載されている情報に間違いがないかや、会場までのアクセスを確認し、写真を張り付けます。都内で行われる試験は、情報処理試験に限らず、大学のキャンパスが試験会場になることが多いです。校門から試験会場の教室・講堂まで数分かかることもよくありますので、自宅から会場までの移動時間は、余裕を持たせて計算しましょう。1-3．体調管理・睡眠体調管理をしっかりしましょう。また、少なくとも前日は必ずしっかりと睡眠をとりましょう。眠れなくても、目を閉じて体を休ませましょう。1-4．試験当日「試験開始20分前までに必ず試験室に入室し着席してください。」、「交通機関の事故などいかなる理由でも、試験開始後30分を超える遅刻の場合、入室できません。」、「答案用紙のマークミスや記入ミスにご注意ください」といったこと「も」、IPAのWebサイ

フリーランスという働き方が広がってきたとはいえ、世の中の主流はまだまだ正社員。 正社員と違ってフリーランスは解雇されやすい、フリーランスならではの不安を感じている方も多いでしょう。 今回は、「不安定さ」とどう向き合うか、そしてフリーランスとしてどう心のバランスを保つかについて、実体験を交えながらお話します。 正社員の「安定」にはコストがかかっている 正社員には、体調を崩したときの休業補償、簡単に解雇されない制度、通勤手当、社会保険の半額負担など、さまざまな保障があります。 一方で、フリーランスにはそういった制度は基本的に存在しません。 案件が3ヶ月更新であれば、「来月で契約終了でお願いします」というのは日常茶飯事です。 でも、世の中に“メリットしかない仕組み”などありません。 正社員にも当然コストやデメリットがあります。 雇う側の視点で考えてみてください。 ・社会保険は企業と従業員で折半 ・通勤手当・研修費などのコスト負担 ・成果が出なくても簡単に解雇できない 上記を考えると給与が50万円の社員を雇うには、企業は実質的に100－150万円近いコストを負担していると言われています。 「会社が負担してくれている、ラッキー！」 ではなく、 「会社は負担分を加味して給料を払っている」というのが正しい表現です。 人件費に加え、教育・福利厚生・間接的（オフィスの家賃など）な労務コストも含まれてくるためです。 朝三暮四（意味:実質が同じでも表現の違いで誤解させる）に近いです。 恐らく多くの人が給料は額面、何となくの手取りしか把握していないものですが、給料の原資レベルで考えればかなり控除される

プロジェクト初期にがんばって作ったWBS。なのに、1ヶ月後には誰も見ない『死んだExcel』になっていませんか？私もかつては何度もその失敗を経験しました。理由はいくつかあると思いますので、それぞれ紐解いていきます。ケース１：WBS運用ルールを可視化できていない往々にしてありえるのが、口頭で説明済だから・一般的なルールだから、という暗黙知で済ませることでルールを可視化(資料化)できていない場合に運用が形骸化することがあります。（明文化されていない→空中戦になりがち）資料化することで説明会においても対象者に刷り込みしやすくなります。PMO目線の意見ではありますがPMOであればこそ、このあたりの仕組化は手を抜きたくないところです。ケース２：タスク(アクティビティ)の完了定義が曖昧WBSの更新ルールを定義していても、メンバーが更新してくれないことがありえます。理由として考えられるのは、更新の仕方が分からないから、というのがありえます。（≒WBSが使いにくい）よくあるのが、資料作成というタスクで執筆が完了すれば進捗を100%(完了)にしてよいのか、或いは暗黙で内部レビューが終わった段階で完了にできるのか、定義されておらず更新が放置されてしまう、ことがありました。対策としてはケース1と併せて更新ルールも定義してしまうのがよいと考えます。ケース３：WBSの粒度が細かすぎるWBSが細かすぎてメンテしていられない・・・これはWBS作成の永遠の課題の一つだと思っています。通常、WBSは階層を３～４ほどに区切って作成することが多いですが、最小単位のタスクまで定義する必要が出てくるシーンがどれくらいあ

まったく同じプロジェクトって、ないんですからマニュアルや正解が無いってことです。でも、成功事例（ベストプラクティス）を参考に、進めれば100点は取れなくても、70点くらいは取れるケースは多いですね。

高度情報処理試験（論文系）は超難関　　高度情報処理試験は難関試験です。特に、小論文試験は厳しい試験だと言えます。受験された皆さんも、こんな経験はありませんでしたか？　✅一体、何を書けば合格するの？。。。　✅何をどう、準備したらいいのか、、、　✅合格論文って、どんな論文なの？　✅ちゃんと書けてたはずなのに、なんで、B！！　✅文才がないから、合格できないぃ。。。。　本当に難しい試験だと思います。私は、システム監査試験を、１０連敗しました。それでも諦めず、チャレンジを続け、今では、小論文の執筆指導をしています。高度情報処理試験の小論文は、答えが見えぬ試験だといえます。でも安心してください。その抑うつを佐々英流が、打ち砕きます。　今年こそ、小論文を突破したい。そんなあなたに、『合格小論文とは何か』をお伝えします。『合格小論文とは何か』を知ることは、非常に重要です。というのも、このイメージがないと、どこに向かって、小論文を書けばいいのか分からないからです。私が、システム監査試験で１０連敗した原因は、まさにこれでした。私は、『合格小論文とは何か』を正しく認識できておらず、１０年間、迷走を続けていたのです。　このブログを読めば、『一体、何を書けば合格するの？』といったあなたの悩みが解消します。『合格論文の姿』を明確にイメージできるのです。！！高度情報処理技術者の対象像　高度情報処理技術者とは、どのような人物でしょうか？IPAは、試験区分毎に、その対象者像を明らかにしています。ここでは、プロジェクトマネージャーに対象者像をチェックしてみましょう。高度IT人材として確立した専門分野をもち，システ

私は、大手コンサルティングファームで5年、ソニーの情報システム部で10年プロジェクトマネージャーを経験してきました。プロジェクトマネージャーの真の仕事と求められる資質について一般論ではなく自分で体験してみて感じたことを泥くさい実態等の生のリポートをします。コンピューターシステムを構築する場合、プロジェクトという単位でチームが編成されます。一般にプロジェクトマネージャーは、特定のプロジェクトを計画し、実行し、完了させる責任を持つ人のことを指します。彼らはプロジェクトの成功を確保するために、多岐にわたるスキルや知識を活用しています。プロジェクトマネージャーの主な役割や責任は、①プロジェクトの計画: プロジェクトの目標、スコープ、予算、期日などを設定し、リスク評価やリスクマネジメント計画も立案します。②チームの指導と管理: プロジェクトチームのメンバーを指導し、タスクを割り当て、進捗をモニタリングします。メンバーのモチベーションを維持し、協力関係を構築します。③スケジュール管理: プロジェクトの進捗状況を追跡し、スケジュール通りに進むように調整します。④コミュニケーション: プロジェクト関係者との効果的なコミュニケーションを確保し、報告書の作成や会議の運営も行います。⑤予算管理: プロジェクトの予算を管理し、コストが予算内に収まるように注意します。⑥品質管理: プロジェクトの成果物が品質基準を満たしていることを確認します。⑦リスク管理: プロジェクトに関するリスクを評価し、適切なリスク対応策を立案し、実行します。⑧変更管理: プロジェクトのスコープや要件の変更に対処します。です。プロ