【52】「その場しのぎ」が長生きしてしまう

クラウス・マルカルド（Klaus Marquardt）

　プロジェクトの中で「暫定ソリューション（その場しのぎ）」を作ったことがある人は多いのではないかと思います。なぜ暫定ソリューションが必要になるのでしょうか？

　おそらくその理由は「一刻も早く解決しなくてはならない問題があるから」でしょう。その問題は開発チーム内部に閉じたものということもあります。たとえばツール間の差異を埋めるために早急に何かツールが必要になったのかもしれません。あるいは問題は外部、つまりエンドユーザから見える問題かもしれません。ユーザの求める機能が不足しているので、取り急ぎ何らかのかたちでその機能を提供する必要があったのかもしれません。時間が無いときに、その場しのぎに作られる。それが「暫定ソリューション」です。

　どの開発チームでも、暫定ソリューションは、開発中のシステムに属さないものとして作られることが多いはずです。作った当初はあくまで「ドラフト」と考えられており、時間がなくて本来守るべき規約やガイドラインに従うことができないため、あとで修正することが前提です。必然的に、チームの内部からは「そういうものを作るべきではないのでは？」という異論が出ることになります。暫定ソリューションを作る理由は色々とあるでしょうが、いずれにしろ、その成否を分ける条件は単純です。有用であれば使い続けられ、そうではなければすぐに使われなくなります。

　暫定ソリューションで問題なのは「慣性の法則がはたらく」ことです。いったん暫定ソリューションができてしまうと、既成事実化するのです。すでに存在していて、一応役に立っていて、皆に一応受け入れられている。もしそうだとすれば、その状況を今すぐ変える必要性を誰もあまり感じません。本当は暫定ソリューションも早くシステムに統合すべきなのですが、重要な仕事は他にもたくさんあるので、どうしても後回しになります。動いていて、皆に受け入れられているのだから、とりあえずはそのままで良いじゃないか、ということになりやすいのです。規約やガイドラインに従っていないということは良くないと皆思っているのですが、よほど特殊なシステムでない限り、それを即どうにかしなくてはと考える人は多くありません。

　そういう理由から、暫定ソリューションは「暫定」と言いながら、いつまでも修正されずに残ることになります。

　また仮に、暫定ソリューションに何か放置できない問題が起きたとしましょう。修正の際に、システム本体のコードと同等の品質にまで高めることは難しいでしょう。結局は暫定の対策でその場を切り抜けることになります。少し新しくなったというだけで、本質は何も変わらないのですが、目的は果たしているのでそれでよしとされてしまいます。

　暫定ソリューションの最大の問題は何でしょうか。

　その答えは、プロジェクトごとに違うでしょう。また、この質問を投げかけられた人が、規約やガイドラインを個人的にどの程度重視しているかによっても答えは違ってきます。暫定ソリューションの数があまりに増えれば、システムのエントロピーは増大し、複雑になってしまい、保守が難しくなります。しかし、本当の問題は暫定ソリューションの存在や多寡ではないのではないでしょうか。ソリューションというのは、存在するからには必要なもののはずです。利用する人たちがそれを気に入っていようがいまいが、存在するからには必要なのです。ただ困るのは、ソリューションをいったん暫定ソリューションにしてしまうと、後で修正するのは難しくなるということです。

　では、一体どうすればいいのでしょうか。対応は大きく次の 3 つに分かれると思います。

  1. 暫定ソリューションをはじめから一切作らない。
  2. 暫定ソリューション修正の優先度が上がる体制作りをする。プロジェクトマネージャが自然に暫定ソリューションの修正を他より優先するような体制にする。
  3. 現状のまま何も変えない。

　では、1 、2、3 について個々にどういうことが言えるか検討してみましょう。

  1. 暫定ソリューションを一切作らない、というのは現実には非常に難しいと考えられます。目の前に即座に解決すべき問題があって、システムの規約やガイドラインを厳密に守っていたのでは間に合わないということは現実に起きるからです。「規約の方を変更すればいい」という考え方もあるでしょう。それも意義あることですが、多くの場合、規約を変更しようとしても、苦労するばかりでなかなか前には進みません。変更を待っていたら、おそらく問題解決には間に合わないでしょう。
  2. 「体制」というのは、プロジェクトの文化に根ざしたものです。文化を意図的に変えるのは容易ではありません。小規模なプロジェクト（特にプログラマ 1 人だけのプロジェクト）ならば、根回しなしに独断で修正をしてしまうことが可能な場合もあります。規模が大きいプロジェクトでも、暫定ソリューションのせいで混乱し完全に行き詰まれば、多くの人が修正に賛同してくれる可能性はあります。
  3. 1 と 2 が不可能な場合は選択しなくても、自動的に 3 を選ぶことになるでしょう。

　プロジェクトを進めていく間には、ソリューションを多数作ることになります。おそらく、そのうちの少なくとも一部は暫定ソリューションになるでしょう。暫定であっても有用なソリューションならそのまま残ってしまいます。その状況を変える最善の方法は、暫定ソリューションに修正を加えるのではなく、不要にしてしまうことです。後から改めて、より優れたソリューション、より有用性の高いソリューションを作るのです。大事なのは、自分に変えられることと、変えられないことを冷静に見極めることです。そして変えられることは勇気を持って変える。その姿勢で臨めば成果はあがるでしょう。