原則 「テスト工程を削れませんか」と言われた日 ― スチュワードシップはきれいごとではなかった
顧客からの「コスト削減のために、テスト工程を圧縮できないか」という相談。受け入れれば予算はきれいに収まり、機嫌も損ねません。でも、そのテストは過去に本番障害を何度も食い止めてきた工程でした——この記事では、私がこの場面でどう動いたかから…
原則
原則 
原則 個々の進捗は「順調」なのに、全体が読めなくなった ― 「複雑さ」の原則が示す相互作用の罠
各社が担当する機能は、単体で見ればどれもシンプル。個々の進捗表は「おおむね順調」。それなのに、全体としては予測困難な遅延が積み上がっていく——複数の協力会社が並行開発する案件で、私が実際に味わった不気味さです。この記事では、この「読めな…
原則 障害ゼロでリリースしたのに「思っていたものと違う」と言われた ― 「品質」の原則はプロセスの質まで含む
リリース時点で障害件数はゼロ。テストも入念に回し、チームも「今回はうまくいった」と手応えを感じていた。それなのに、リリース後にじわじわと「思っていたものと違う」という声が上がり始める——私が実際に経験した、いちばんやっかいな品質問題です…
原則 レビュー工数が本体の工数を圧迫した ― テーラリングの原則は標準を「使える形」に仕立て直すこと
数人月の小さな保守案件に、大規模案件と同じ多段階レビューをそのまま回したら、手続きだけで工数がふくらみ、品質のための仕組みがスケジュールを苦しめ始めた——完全な本末転倒を、私は実際にやりました。この記事では、その顛末から始めて、PMBO…
原則 すべてを抱え込んだら、チームが受け身になった ― リーダーシップの原則は「役職」ではなく「行動」
炎上気味の案件を任され、「自分がなんとかしなければ」と重要な判断をすべて自分に集めた。責任感の表れのつもりだった——のに、気づけばメンバーは指示待ちになり、判断は私の返事待ちの行列に。この記事では、この悪循環をどう断ち切ったかから始めて…
原則 自動テストを増やしたら、リリースはかえって遅くなった ― システム思考が教える部分最適の罠
テスト工程を効率化しようと自動テストを導入し、実行時間は目に見えて短くなった。「成功だ」と思っていたら、リリースのサイクル全体はかえって遅くなっていた——私の苦い実体験です。この記事では、この「もぐら叩き」がなぜ起きたのかから始めて、P…
原則 一つの漏れもなく実装したのに「これじゃない」と言われた ― 「価値」の原則が教える本当の成功基準
要件定義書のとおりに、一つの漏れもなく実装した。テストも通り、品質は文句のつけようがない。それなのに利用部門の反応が鈍い——私が実際に経験した「完璧な的外れ」の話です。この記事では、その案件で何がズレていたのかから始めて、PMBOK第7…
原則 案件担当者の要求に応え続けたら、決裁者は別を見ていた ― ステークホルダーの原則が教える「誰と握るか」
熱心な案件担当者の要望に、ていねいに応え続けていた。信頼されている手応えもあった。それなのに後工程で、決裁権を持つ役員がまったく別の優先順位を持っていたことが判明する——ステークホルダー対応でいちばん切ない失敗を、私は実際にやりました。…
原則 キックオフで作ったリスク管理表を、そのまま放置していた ― 「リスク」の原則は評価し「続ける」こと
キックオフで、我ながら良い出来のリスク管理表を作った。想定される脅威を洗い出し、対応方針も書き込んだ。そして——そこで満足して、二度と開かなかった。数ヶ月後、表に載っていないリスクが顕在化して後手に回る——正直に告白すると、私の実体験で…
原則 本番障害でチームが沈んだとき、最初にやめたのは犯人探しだった ― 「適応力と回復力」の原則
基幹システムの本番リリース直後、想定外の障害。対応は深夜に及び、「あれだけ準備したのに」という落胆と「誰のミスだ」という空気がじわりと広がっていく——リーダーを任されて間もない頃、私はこの場面でチームの立て直しを迫られました。この記事で…