優先順位付けの重要性、あるいは戦略的思考（の1つ）
★バグは優先順位をつけて対応する
24年前という大昔に、ケンブリッジの面接を受けたときの話。
当時SE／プログラマーだったので、「なにか質問ありますか？」と言われた時に「システム構築する時に、どうやって品質を上げていますか？」と聞いた。
そもそもケンブリッジってミドルネームが「テクノロジー」なので、コンサルティング会社だと思っていなかったんですよね。もし入社したら、これまでやってきたようなシステム構築をやるんだと思っていた。実際に当時のケンブリッジは今よりも随分システム構築色が強かったし。
入社後に認識したのだが、聞いた相手はマーケティングダイレクターだったので、かなりズレた質問だった。その人は「いやあ、あんまよく知らないけど、多分バグを見つけたら優先順位をつけながら対応していると思いますよ」みたいな回答だった。
話はもちろん盛り上がらずにそこで終わったのだが、彼の回答を聞いた僕はたちどころにあることを理解し、面接の場で一人静かに感動していた。
それは箇条書きにすると以下のようなことだった。
・バグにはクリティカルなものと、どうでもいいものがある
・すべてのバグを根絶することはプロジェクトの目的ではない
（バグをすべて潰すよりも、納期やコストなど、優先すべきものはある）
・したがってバグには優先順位をつけ、優先順位が高いものからやっつける
この考え方は今では当たり前だと思う。ほとんどのプロジェクトでこのような対応をしているだろうし、消費者として使うアプリで、軽微なバグが放置されているのにも僕らは慣れた。
しかし転職前の僕は「バグを出してしまうのはプログラマーとして恥。すべての仕事を放り出してでも、真っ先にバグ修正を行う」というメンタルモデルで仕事をしていた。だから面接相手の何気ない一言は衝撃だった。大げさではなく、当時の僕にとってパラダイムシフトだったのだ。
転職前の僕が感じていたプライドは、1人の職人としては尊いかもしれない（実際にその時の僕は、慣れた環境ではバグというかコンパイルエラーすらほとんど出さなくなっていた）。
でも経営目線（システム投資の費用対効果を考える立場）からすると、それってどうでもいいことなんだよね・・。
※この話、どっかで書いた気がしないでもない。ブログだけでも350くらいアップしたので、もはや書いたか書いてないか覚えていない・・。
★優先順位付けが大事なのは、バグ改修に限らない
入社してみると、「たくさんある"やったほうがいいこと"の中から、優先順位をつけ、順位が高いものから取り組む」という仕事の姿勢は、システム構築に限らず、全てに及んでいた。
・現状調査をやる時は、優先順位が高いところから調査し、低いものには目をつぶる
・改革施策は筋が良さそうなものを選んで、深掘りする
・要望が上がったシステム機能をすべて作るのではなく、優先順位付けする
・ベンダー選定の際、コンタクトするベンダーさんも優先順位による
などなど。すべてこの調子だ。
この「たくさん候補をリストアップ⇒基準により優先順位付け⇒優先度の高いものから着手」という考え方があまりに大事なので、初期の頃に、いくつもこの考え方についてのブログを書いた。（このブログの最後にいくつかリンクを貼った）
★しかし人間は、優先順位付けが苦手
ということで、僕自身は「優先順位付け」が仕事のOSとして染み付いているのだが、一緒にお仕事をする方々は必ずしもそうではない、と観察している。
もう少しはっきり言うと、普通の人は優先順位付けという頭の使い方が苦手だ。
なぜ苦手？①部分しか見えないから
優先順位付けの前提は「全体最適」だ。
プロジェクトでいえば「プロジェクト全体として成し遂げたいこと（プロジェクトゴール）」があり、それにインパクトがあるものの優先順位が高く、インパクトがないものは低い。
だがプロジェクトに参加する人の中には、部分しか担当していない人が多い（業務の一部、プロジェクトタスクの一部）。そういう人に「あなたが担当しているのは、全体からすると優先順位が低いんですよ」と言ってもまあ、納得できないですよね。
それは投資戦略であっても同じだ。
自分の立場や経験から離れて、全体最適で考えるというのは、難しい。
なぜ苦手？②戦略思考だから
これは①の続きなのだが、そもそも戦略思考って、
・全体を俯瞰して
・優先順位を付け、
・資源を投入する先を決める
という思考形態のことなので、今話していることとほぼ同じなのだ。
そして戦略思考ができる人材はとても少ない。「人事戦略」みたいなタイトルのパワーポイントを書けるひとではなくて、仕事や人生の様々な局面で上記の思考をさらりとできる人のことだ。
元々少ないんだから、普通の人が出来ないのはしょうがないよね。
なぜ苦手？③ものづくりマインドと相性が悪い
日本の製造業には「品質をとことん上げる」という組織文化がある。品質を上げることは、経営視点では何かを達成するための手段でしかないのだが、そんな話はとっくにどこかにいき、行動規範というか信仰というか、そういう神々しいものになっている。
更に「自工程完結」も根付いている。自分の持ち場は完璧にこなして、次の人に引き継ぐ、という責任感を体現したワークスタイルだ。トータルでの品質を上げるためには有効だし、「立つ鳥跡を濁さず」的な日本人マインドとも相性がいい。
で、これらの組織文化と「優先順位付け」という考え方の相性が悪いのだ。
品質向上はやり切ることに意味がある。歩留り率90%と99.98%とでは世界が違う。
でも優先順位付けは「優先でないものには目をつぶろう」という精神だ。やり切らない。そこがいい。
でも品質向上精神が染み込んだ人はそれを許容できない。
冒頭で紹介した、転職前の僕のように。
このように優先順位付けは日本組織と相性が悪いが、本質的にとても大事なので、組織OSに組み込まないとデメリットが大きいものだ。
ところで、「システムを作らせる技術」のコアな部分は、システム機能の洗い出し＋洗い出した機能の優先順位付けだ。プロジェクト参加者が本来苦手な優先順位付けに乗っかれるように自然にリードする方法論を説明している。
大型プロジェクトには様々な利害関係者が参加し、「アレを作れ」「コレを作らないなんてとんでもない」と主張をする。でも予算は限られている。だからここで話している、全体最適観点で優先順位をつけることが本当に大事。でもみんな苦手。だから洗練された方法論が必要なんだよね・・。
（そして、人々が優先順位付けを苦手すぎて、そういう方法論を使ってもうまくいかなかった苦い経験談をコラムにいくつか書いた）
★時に、大胆に目をつぶることも
経営視点で優先順位を考え尽くすと、プロジェクトメンバーが違和感を覚えるような意思決定をすることもある。
・経営の重要なマイルストーンを守るために、品質に目をつぶったプロジェクトにした
・プロジェクトを2つに割り、半分だけを速やかに実行
・局地的にユーザーが不便になるシステムを構築
・時間をかけてでも、プロジェクト参加者の成長を重視したプロジェクト
みたいな感じだ。
全ては全体最適、経営目線で優先順位を熟考した上でのことだ。
皆さんは仕事の隅々でも優先順位を考える癖がついているだろうか。
****************
関連する過去ブログ
二流のリーダーには決して言えないこと、あるいは品質管理の奥深さ
プロジェクトを成功させる魔法？あるいはブレようのない要件定義
システム構築の失敗はFMで防ぐ、あるいはなぜ僕らは要求定義でこのツールを愛用し続けるのか？