私が清水吉男さんに教わった色々・その2

私が清水吉男さんに教わった色々」の続きです。まだまだ、いっぱいあるなぁ…

日本語の「危機管理」には Risk - Crisis - Emergency がごっちゃに含まれている。この違いを認識しなければ「リスク管理」はうまくいかない。そして、リスク管理をまともにできない組織は、未成熟な組織である

「有事後」の管理は「危機管理」であって「リスク管理」ではない。のに、日本ではその辺が曖昧。

組織には「ファイヤーマン」と呼ばれる“ベテラン”が居ることがある。問題が表面化してから登場して活躍するため、社内では「英雄」として扱われるが、そもそも他人の失敗なので原因も発見しやすいしノウハウもある。

火消しが成功しても、失った顧客の信頼回復は難しい。ならばリスク管理をしっかりして、問題を表面化させないほうが得策という教えでした。

テストは品質を織り込むプロセスではない。テストが開始される”その時までに織り込まれた品質”のレベルにうまくいけば到達できるのであって「テストをガンガンやって品質が上がる」のは大きな勘違いである。

今となっては当たり前の概念ですが10年ほど前の開発部隊は、自分たちはろくにテストもせず後工程のQA部隊にテストを丸投げし「品質が上がる」と本気で思ってる人が多い時代でした。

まともな「計画」もないままにプロジェクトの開始が承認されていることで多くの被害を出してしまう。 混乱の中で多くの人が疲弊し脱落していく。殆どの組織では、こうした問題の背後に「計画」が関与していることに気付いていない。

計画がない事による弊害は、アジャイルだろうがウォーターフォールだろうが関係ありません。インセプションデッキだけでも立案してあるのと、無いのとではその後のプロジェクトの展開が全然違います。

計画書は考えたときに書かないと書けなくなる。 “思い出して”書くことの出来る成果物ではない

ほんとに。

開発期間が短いと「間に合わないモンスター」を自分の中に作ってしまう。”ソースの修正を急がねば間に合わない”と自分を追い詰めるので、見積り、計画書、リスクリスト、変更仕様書などが尽く省かれてしまい、本当に間に合わなくなる

相対見積もりすら出来ない組織にも、このモンスターが現れます。

仕事は約束である。本物のプロとは”約束を守る”人のことを指す。プロは約束を実現するための鍛錬を怠らない。

はい、肝に命じて。

プロセス改善は、うまく出来た部分を積み重ねることが必要。そのためには、どこがうまく行っているかを知る必要がある。「良いものを素直に認める文化」を推進し組織内での発表の機会を作るべき

スマホ版「どうぶつの森」のお披露目会が目に浮かびます。

“分かった”というのは、その人が“分かった”と思った範囲だけ“分かった”に過ぎない

とても清水さんらしい言い回しで好きでした。そもそも要求仕様書やユーザーストーリーが書かれないことでこの問題が大きく牙を向きます。

日本社会の悪いところは、うまく出来ている箇所があるにも関わらず出来ていない箇所がひとつでもあれば評価されないことである。特にプロジェクト終了後の「反省会」文化は、うまく行かなかったことの説明ばかりになることが多い。「ポストモーテム」で組織に”褒める文化”を取り込むべき。

これと似た文脈で「落穂拾い」の反省会化も憂いてらっしゃいました。偉い人の前で「うまく行かなかった」ことの説明ばかり。褒める文化がなければ人は育たないはずと。
ところで「ポストモーテム」というタイトルのセミナーでこの聞きなれない言葉を日本に広めたのは清水さんだと思っています。書籍「チームソフトウェア開発ガイド」(TSPiの解説書)では「事後分析」と訳されてしまった”ポストモーテム”をあえてそのまま使ってらっしゃいました。

「死を目前にしたとき、それまでの半生を振り返ってニコッと微笑むことができるような人生を送りたい」
ある大学の入試問題でみたこの文章を、私は人生の最終ゴールに据えることにした。

セミナー等で良く仰っていました。
ニコッと微笑んでる清水さんの顔が思い浮かびます。

この記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。

たかぼー

デスマーチに花束を

ソフトウェア開発、IT業界の地位向上を目指します。発注先の能力は、発注元の能力を超えられないのよ?
コメントを投稿するには、 ログイン または 会員登録 をする必要があります。