原則

すべてを抱え込んだら、チームが受け身になった ― リーダーシップの原則は「役職」ではなく「行動」

炎上気味の案件を任され、「自分がなんとかしなければ」と重要な判断をすべて自分に集めた。責任感の表れのつもりだった——のに、気づけばメンバーは指示待ちになり、判断は私の返事待ちの行列に。この記事では、この悪循環をどう断ち切ったかから始めて…
原則

自動テストを増やしたら、リリースはかえって遅くなった ― システム思考が教える部分最適の罠

テスト工程を効率化しようと自動テストを導入し、実行時間は目に見えて短くなった。「成功だ」と思っていたら、リリースのサイクル全体はかえって遅くなっていた——私の苦い実体験です。この記事では、この「もぐら叩き」がなぜ起きたのかから始めて、P…
原則

一つの漏れもなく実装したのに「これじゃない」と言われた ― 「価値」の原則が教える本当の成功基準

要件定義書のとおりに、一つの漏れもなく実装した。テストも通り、品質は文句のつけようがない。それなのに利用部門の反応が鈍い——私が実際に経験した「完璧な的外れ」の話です。この記事では、その案件で何がズレていたのかから始めて、PMBOK第7…
原則

案件担当者の要求に応え続けたら、決裁者は別を見ていた ― ステークホルダーの原則が教える「誰と握るか」

熱心な案件担当者の要望に、ていねいに応え続けていた。信頼されている手応えもあった。それなのに後工程で、決裁権を持つ役員がまったく別の優先順位を持っていたことが判明する——ステークホルダー対応でいちばん切ない失敗を、私は実際にやりました。…
原則

キックオフで作ったリスク管理表を、そのまま放置していた ― 「リスク」の原則は評価し「続ける」こと

キックオフで、我ながら良い出来のリスク管理表を作った。想定される脅威を洗い出し、対応方針も書き込んだ。そして——そこで満足して、二度と開かなかった。数ヶ月後、表に載っていないリスクが顕在化して後手に回る——正直に告白すると、私の実体験で…
原則

本番障害でチームが沈んだとき、最初にやめたのは犯人探しだった ― 「適応力と回復力」の原則

基幹システムの本番リリース直後、想定外の障害。対応は深夜に及び、「あれだけ準備したのに」という落胆と「誰のミスだ」という空気がじわりと広がっていく——リーダーを任されて間もない頃、私はこの場面でチームの立て直しを迫られました。この記事で…
原則

システムは刷新されたのに、現場は旧システムのまま動いていた ― 「変革」の原則が言う本当のゴール

新システムへの移行は問題なく完了。データも移り、動作も安定。プロジェクトとしては「成功」のはず——なのに現場を見ると、業務フローは旧システム時代のままで、せっかくの新機能はほとんど使われていない。私が実際に目にした光景です。この記事では…
パフォーマンスドメイン

序盤に作った関係者図のまま進めたら、主役の交代を見逃した ― ステークホルダー・パフォーマンスドメイン

キックオフで影響度×関心度の相関図を作り、決裁者も押さえ、月次の個別報告枠まで用意した。我ながら良い立ち上がり——のはずが、フェーズが進むと関係者の主役が静かに入れ替わっていて、気づくのが遅れた私は「聞いていない」という不満を浴びかけま…
パフォーマンスドメイン

私が席を外すと、チームが止まった ― チーム・パフォーマンスドメインは「任せ方」の仕組み化

タスクの割り振りを全部自分で握り、一つひとつ指示を出す。丁寧に管理しているつもりだった——でも実態は、私が指示を出さないとチームが止まる状態。会議で席を外すと、手が空いたメンバーが「次、何をすれば?」と待っている。私自身がボトルネックで…
パフォーマンスドメイン

「いつものウォーターフォール」で受け入れが荒れた ― 開発アプローチとライフサイクルは案件で選ぶ

深く考えず「今回もウォーターフォールで」と決めた案件。ところが画面まわりの要望が最後まで揺れる性質のもので、受け入れテストの段階になって「思っていた操作感と違う」が一気に噴き出した——アプローチの選択そのものがズレていた、私の実体験です…