世の中には知りすぎているから決断ができなくなる、という状況がある。

そもそも何も知らない無知な人であれば、決断に迷うこともない。

たとえば、先日行われた情報処理試験でも、しっかりと勉強している人ほど、試験をナメていない。
過去問題には難しいものが含まれていることも、自分の得点圏も知っている。だからこそ、慎重に、かつ確実に合格できるための方策を練るのである。

しかしあまり勉強していない人は、そんなに試験が難しいと思っていない。ちょっと勉強すればなんとかなると思っている人もいる。そういった人は、何度か受験に落ちることで、試験の奥深さを知って行くのであろう。

これに類似することを先日システム開発の現場で感じた。その時の話をしたいと思う。

●欠陥修正における、スコープ・マネジメント

現在私たちのチームでは、スコープ・マネジメントを強化しようと活動をしている。

本プロジェクトは改良開発がメインなので、摘出した欠陥修正や機能改善を短サイクルで繰り返すのが特徴だ。

みなさんにも経験がおありと思うが、欠陥修正を行う際に、欠陥が発生したその事象だけを修正しようとすると、実は類似する原因によって、他の個所にも欠陥が潜んでいることがある。通常は、同種の欠陥が潜んでいないのかを、水平展開して調査する必要がある。そうしないと、同種の原因によって後から後から欠陥が摘出されてしまう。

特に欠陥修正は、欠陥が引き起こす現象は目に見えやすいので、ひとまず目に見える事象が改善されてしまうと、安心してしまうことが多い。そのため、水平展開の漏れが発生しやすい。また、欠陥への対処が急がれているときに、悠長に水平展開などやっていられない、というプレッシャーがかかることもある。

水平展開を適切に行うには、次のステップが必要だと考えている。

（１）問題事象の原因を調査する

まず個別具体的な目に見える問題の直接原因をしっかり分析して把握することが重要だ。

（２）問題の影響範囲（スコープ）を客観視して
　　「どんな問題だったのか」を一言で表現してみる

水平展開をするには、個別具体的な問題をそのまま扱ったのでは都合が悪い。一歩引いて客観視することでその問題が持つ影響の本質をつかむ必要がある。

客観視するには、問題の影響範囲（スコープ）を広げて考える必要がある。

たとえば過去にこんな欠陥があった。
冗長化されたシステムの現用系（動作中の系）のＯＳ（Linux）がカーネル・パニックを引き起こし、急に動作が停止してしまった。本来ならデュプレックスシステムであるため、予備系がすぐに現用系に切り替わり、処理を継続しなければならない。しかし、予備系が現用系のカーネルパニックをすぐに検知する仕組みがなかったために、長い時間、システムに現用系が存在しない状況が発生してしまった。その間、システムは稼働できない状態となり、それが問題となった。

この問題に対して、問題の本質を「カーネルパニックを予備系でも検知する仕組みがないから」と判断してしまっては、この問題の影響範囲（スコープ）を適切に捉えられていない。

この問題の影響範囲（スコープ）の本質は、「デュプレックスシステムにおいて、現用系が存在しない状態を作ってはいけない」ということである。

今回はカーネルパニックという１つの個別具体的な事象によって、「デュプレックスシステムにおいて、現用系が存在しない状態」を作ってしまったが、それはあくまで契機の１つである。もっとしっかり問題の影響範囲を把握していれば、カーネルパニックに限らず「デュプレックスシステムにおいて、現用系が存在しない状態」を作ってしまっている契機があることに気が付ける。

このように、問題の原因が判明した時点ですぐに対処を検討するのではなく、問題の影響範囲を一歩引いて見極めることで、同じ原因の問題を引き起こさずに済む。

●スコープの不備は見えども・・・

とまあこのような経緯から、改良開発において欠陥への対応をすぐにおこなうのではなく、いったん問題の影響範囲を見極めてから、対処検討のスコープを定めるようにプロセスを変えてみた。

すると、確かに当初の問題原因の捉え方だけではスコープが小さくなりすぎ、同種の欠陥を見逃してしまうという事象を、上流工程で発見することができた。

これは効果があったと感じた。上流工程でスコープを適切に定義しさえすれば、水平展開の漏れを防ぐことができる。

しかし、ここで問題が発生した。欠陥対応というのは、そもそもここまでやればよい、という線引きが難しいものである。水平展開のスコープを広げれば広げるほど、品質を保証できる範囲も広がる。それは良いことだが、それに伴って水平展開に必要となる工数もどんどん増えていってしまう。

そして通常、水平展開によって摘出された欠陥を修正しなくてもよいという理屈も働きにくい。特に本システムはミッションクリティカルなシステムであったので、スケジュールを若干犠牲にしても、品質を確保することが必要だと考えられていた。

水平展開をして調査しても、まだスコープが狭いように感じ、スコープを広げてまた調査する、の繰り返しをするうちに、本当にキリがなくなってきてしまったのだ。

我々は、たしかにスコープの不備を検知することはできた。

しかし、適切なスコープを定めるためのマネジメントを持っていなかった。

この状態になって私は、チーム・メンバに、

「スコープを適切に管理しようとしていろいろ施策を打ってるけど、スコープがどんどん広がってしまって、逆にスコープが管理できないよ」

と愚痴をこぼした。

するとメンバは一瞬考えてから、次のように答えた。

「それって、逆にスコープを意識しているからじゃないですか？」

「え、どういうこと？」

「スコープを適切に管理しようと意識すればするほど、今のスコープの漏れに気づくから、さらにスコープが広がるんじゃないですか。今までみたいにスコープについてあまり意識しないでザルの管理をしていたら、逆にスコープはすぐに決まったと思います」

私はその言葉を聞いてすぐになるほどと感心した。

たしかにその通りである。

問題対処でもスコープでも、スケジュール策定でもなんでも、あまり知識やノウハウがない人が、いけいけドンドンでやっていれば、問題対処に漏れがあろうが、スコープに漏れがあろうが、スケジュールに無理があろうが、決めることはできる。

これは、無知であるがゆえにスムーズに決まる、ということだろう。

しかし、今我々は目の前の問題についてしっかり考えられるだけの知恵がある。すると、どうなるか。

目の前の問題について様々な観点からの分析ができすぎて、すべての観点から満足できる対処を検討しなければならなくなり、問題解決が急に難しく感じてしまう。

無知であれば１つか２つの観点にしか気がつかないから、あまり悩まずに問題対処もできるだろう。

●世の中に「知らないほうが良いこと」はあるのか？

知恵があるからこそ悩むのであれば、いっそのこと「知らないほうがまし」なのだろうか。

いや、そうではない。
そもそも私は世の中に「知らないほうが良い」ことなどないと思っている。

これは知恵がある者に課せられたワン・ランク上の課題なのだと思うようにしている。今回の事例に当てはめて言えば、スコープの不備を検知はできるが、スコープを適切にマネジメントするすべがない、という課題である。

その「悩ましい」状況にきちんと対処ができれば、次回からは「悩ましい」問題ではなくなる。

こうして１つ１つの悩みを前向きに解消することが、成長なのだろうと思う。

スポーツなどでスランプに陥った人に対して、よく、

「あまり考えすぎると何もできなくなるよ」

などと気軽に声掛けするシーンを見かける。

しかし私に言わせれば、「もっと考えなければならない。考えが足りない」とアドバイスしたいところだ。

そもそもスランプとは、今までやっていたことが急にできなくなってしまう状態のことである。つまり、いままで「なぜできていたのか」を意識してこなかったということである。無意識のうちにできてしまっていたものだから、何かの拍子に調子が狂ってしまい、今までできていたことができなくなる。

もし私がスランプに落ちいたら、まず第一に「今までなぜできていたのか」を徹底的に分析し、理論的にしっかりと理解をするだろう。

そして今と過去のギャップを探り、何の差分があってうまくいかないのかを頭で理解する。

頭で理解できれば原因がわかるのだから、あとはそれに従って体を動かし、体を理論に近づけていく。

それがしっかりできていないから「スランプ」が続くのである。

スランプから抜け出したいのであれば、「あまり気にしない」のではなく、「もっと徹底的に考えることが必要」なのであり、スランプになっている人は、そこから抜け出せる状態になるまでに考え抜いていないのだと思う。

つまりスランプとは「もっと考えなさいよ」という天からのおつげであり、ワンランク上の課題に挑戦するためのチャンスでさえあると思う。

同様に、今回の問題対処においても、もし仮にスコープの不備に気付かないまま開発をしていれば、結合テストか何かで同種の欠陥が見つかったはずであり、大きな手戻りが発生したであろう。最悪はテストをすり抜け、フィールド問題として発見されてしまっていた可能性もある。

やはり上流工程でスコープを適切に管理することは、本当にプロジェクトを守るのだ、ということを肌で改めて感じた次第である。