昔いた会社での話なんですが、プロジェクトの振り返りが「良かった探し」になっていることに軽くブチ切れて、当時の先輩と二人で
「何故当社のプロジェクト振り返りは何の役にも立たない無駄な時間なのか」
というテーマで色々と話し合ったことがありました。
その時、副次的に生まれたのが「失敗を糧にする組織である為には一体どんな条件が必要なのか」という議論でして、単なる数名によるブレストなんですが、ちょっと思い出したので書いてみます。
本記事の要点として先に書いてしまうと、当時、自社の状況と照らして抽出した「「失敗」から何かを学べる組織である為に必要な5つの条件」は下記のようなものです。
・負け/失敗の条件を明確に定義・言語化出来ているか
・遠慮なく「失敗」を指摘出来る空気があるか。または、失敗を指摘出来る人間が発言力を持っているか
・一方で、責任者がきちんと説明責任や遂行責任を果たす風土があるか
・魔女狩りではなく、組織の問題として失敗の原因を言語化、課題化出来ているか
・課題解決と、それに関するフィードバックがきちんと機能しているか
今から振り返っても、それなりに妥当な条件なんじゃないかなーと思っています。
***
ということで、書きたいことは最初に全部書いてしまったので、あとはざっくばらんにいきましょう。
以前にも書いたことがあるんですが、私は昔、あんまり大きくないシステム開発会社に勤めていました。
社員は4桁に届かないくらいで、SI案件とSES案件が大体半々くらい、自社業務と客先常駐も大体半々くらいという、よくある「昔ながらのシステム開発会社」でした。仮に名前をA社としておきます。
で、当時色んなプロジェクトに参加したんですが、会社の慣例として、プロジェクト完了後の振り返りをやっていたんです。
皆さんKPT法ってご存じですか？
現状を「Keep（このまま継続するべきこと）」「Problem（解決すべき課題）」「Try（課題を解決する為に実施すること）」の三つに分けて書き出していって、皆で認識を共有して、課題を協力して解決していく、という手法です。
これ自体はすごーく有用なメソッドでして、その時のA社でも、プロジェクトが終わる度にそういうことやってたんですよ。
何故か妙なところでオリジナリティにこだわる会社でして、KPTではなくそれを置き換えた別の言葉でやってたんですが、まあ中身はKPTのパクリです。
ただ、振り返るのはいいんですが、やればやる程「この振り返りに意味はあるんだろうか？」と思うことが増えていったんですよ。
一言でいうと、単なる「良かった探し」になっていたんです。
・そもそも殆どのプロジェクトが「成功」した体で議論されて、結果「Keep」ばかりが大量にピックアップされる
・「Try」が挙げられてもそのフィードバックが求められない為、殆どは実施もされずに放置されて、いつの間にかフェードアウトする
・「Problem」が挙げられても、それは個人の問題に帰せられて、組織や仕組みの問題に帰着しない
なんでやねんと。
いや、何度か問題も指摘したし、席上で言ったりもしたんですよ？
ぺーぺーだったんで一顧だにされませんでしたけど。
プロジェクトが完了したといえば聞こえはいいですが、工数も大幅に超過して納期も何度も延期されて、コスト的には完全に赤字になっているのに何故か「成功」として捉えられている。
結果として「成功要因はこれこれなのでこのあとも続けましょう」という話ばかりになる。
それじゃ振り返りの意味がないやろ、と、当時色んなプロジェクトで一緒にやっていた先輩と議論しました。
株主さん相手に「成功しました」と言い張るのは構いませんけど、内部の振り返りでまでそれやってどーすんだ、と。
これは第一に、「どういう状態になればプロジェクトは失敗とみなされるのか」ということが定義されていないことに起因している、と、私や先輩は考えました。
プロジェクトが完全崩壊してシステムリリース自体が失敗していればまだ分かりやすいんですが、そうでなくても「これは成功とは言えんだろ」というプロジェクトは幾らでもあります。
それに対して、「失敗」というラベリング自体が存在しなければ、どんなに炎上しても何故か「成功」とみなされる。
ルール上「負け」が設定されていないゲームみたいなもんです。
ただ、たとえ「これこれこういう条件を満たしたプロジェクトは失敗とみなす」という明確な定義が存在したとしても、それだけでは意味はないだろうな、とも考えました。
第二に、「「このプロジェクト失敗ですよね」ということを指摘することに、何故か滅茶苦茶なコストがかかる」という問題があったんです。
プロジェクトに対して冷静に問題を指摘する人が煙たがられて、何故か「ネガティブなヤツ」「みんなが頑張っているのに水を差すヤツ」として認識されてしまう。
「あいつ後ろ向きだな」という低評価を受けてしまう。
これがあるが為に、「失敗」を受け入れ、失敗を糧にする風土が醸成されないし、サンクコストに縛られて会社が適切な損切りを判断出来ない。
これ、ポジティブ指向の悪しき側面の一つだと思います。
ポジティブなのは結構なことですが、結果損切りが遅れに遅れて、会社が大きなダメージを負ってしまえば意味がない。
「必ず上がる！！」と自分の豪運を信仰しているFX戦士かよって感じです。
プロジェクトを「失敗」だと指摘することが、何故か「責任者に喧嘩を売っている」というような扱いをされてしまうことも問題でした。
会社の風土なのかなんなのか、「失敗」という言葉が過大にとられ過ぎるが為に、責任者に気を使って「失敗」を言い出せない、というような側面もあったんです。
「あいつに恥をかかせるわけにいかない」とか、なんでやねんって思うんですけど、なんかそういう言い方されるんですよ。
これはある程度主語を大きくしてしまっても問題ないと思うんですが、旧来型の日本組織って、どうも「責任」を取り扱うのが凄く苦手みたいなんですね。
責任を取ると言うと「降級」とか「辞職」のことだと考えている。
「責任を取る」って別に「辞める」ということではなく、むしろその遥か前に遂行責任とか説明責任とか色々あるんですが、何故かそういうまともな責任の取り方はされなくって、即進退責任に結びついちゃうんです。
失敗を指摘することが、ダイレクトに「お前辞めろ」という意味になってしまうと、色々と面倒なことになって失敗の指摘自体しにくいじゃないですか。
結果、たとえ「失敗」を定義したとしても、それを言い出す為のコストがでかすぎて誰にも言い出せない。
それら複数の条件が重なり合って、失敗を「今後の糧」として取り扱うことが出来る状態にない、と。
その会社はそういう状況でもあるように思いました。
あとは、「失敗」からきちんと「組織の改善に繋げる施策」を取り出すことが出来るか、というのも重要な話ですよね。
責任者の話とは別の問題として、「失敗」の要因探しが魔女狩りになってしまっては意味がありません。
人間はミスをするし失敗をするもので、それは指摘しやすいですが本質的な問題ではありません。
そういうミスや失敗をフォローする為に組織というものがあるのですから、失敗の原因は組織の仕組みに求めるべきですし、組織の改善に結びつけるべきです。
これが何故か逆になっちゃってる組織も多いんですよね。
仕組みややり方については、それを構築した前任者の仕事が聖域化されていて、そこに対して文句を言えない。
だから指摘しやすい「人的なミス」とか「遂行者の能力不足」ばかりが追求されてしまう。そういうケースも何度も見ました。
もちろん、ただ「課題が挙げられるだけ」で、そこから具体的に改善が動かないと何の意味もありません。
ですから課題はきちんと施策化されて、その施策の進捗状況がフィードバックされる必要があります。
そこから、「失敗の原因を組織の課題として言語化出来ること」「更に、その課題から改善の為の施策を抽出して、そのフィードバックが可視化されること」が、失敗を糧にする組織である為には必要だ、と、私も先輩も考えました。
これらをまとめて「プロジェクト振り返りについての根本的な問題」として偉い人にプレゼンしたりもしたんですが、基本「何言ってるんだこいつらは」みたいな顔されちゃって、それからしばらくしてその会社潰れちゃったんですけど。ある種の寓話です。
***
手前味噌なんですが、以前こんなことを書きました。
貴重なノウハウの宝庫である「失敗談」を語ってくれる人に、わざわざマウントしに行く、残念な人たち。
これは断言していいと思うんですが、「ノウハウとしての失敗談」は非常に貴重です。個人的な所感としては、成功談の255倍くらい貴重です。
「勝ちに不思議の勝ちあり、負けに不思議の負けなし」という言葉がありますが、基本的に敗因って勝因よりも分析しやすいんです。
それは、「失敗」という状況が、マイナス点として評価しやすいということに由来しています。貶すのは褒めるよりも簡単、という現象と同じ話で、物事のマイナス側面はプラス側面よりも明確に見えやすいし、他と比較しやすい分指摘もしやすいというわけです。
失敗体験はノウハウの塊であって、成功体験より遥かに重要。失敗体験こそ参考にするべき、という話です。
これは個人だけではなく組織にとっても同じであって、組織がきちんと「失敗」を認めて、それを改善に繋げることが出来ると、その組織って滅茶苦茶強くなります。
強い組織の必須要件の一つ、と言ってしまってもいいと思います。
一方で、「失敗」を上手く扱うことが出来ないと、ノウハウが組織に蓄積されず、何度も同じ失敗を繰り返し、更にそれが次の失敗に対する備えを甘くしてしまうという、負のスパイラルに陥ってしまいます。
勇気をもって失敗を認めて、そこから次へ向かう為の課題と施策を見出すべきだ、と。
その為の条件が整っているかどうかは、時には自己分析してみてもいいかも知れませんよね、と。
そういう話でした。
今日書きたいことはそれくらいです。
生成AIの運用を軸としたコンサルティング事業、メディア事業を行っているワークワンダース株式会社からウェビナーのお知らせです
＜2025年1月21日実施セミナー＞生産性を爆上げする、「生成AI導入」と「AI人材育成」のコツ
【内容】
1. 生産性を爆上げするAI活用術（安達裕哉：ワークワンダース株式会社 代表取締役CEO）
2. 成功事例の紹介：他業種からAI人材への転身（梅田悟司：ワークワンダース株式会社CPO）
3. 生成AI導入推進・人材育成プログラム「Q&Ai」の全貌（元田宇亮：生成AI研修プログラム「Q&Ai」事業責任者）
4. 質疑応答
日時：
2025/1/21（火） 16:00-17:30
参加費：無料
Zoomビデオ会議（ログイン不要）を介してストリーミング配信となります。
お申込み・詳細 こちらウェビナーお申込みページをご覧ください
(2024/12/6更新）
【著者プロフィール】
著者名：しんざき
SE、ケーナ奏者、キャベツ太郎ソムリエ。三児の父。
レトロゲームブログ「不倒城」を2004年に開設。以下、レトロゲーム、漫画、駄菓子、育児、ダライアス外伝などについて書き綴る日々を送る。好きな敵ボスはシャコ。
ブログ：不倒城
Photo by Markus Spiske
