小規模なシステム変更でも時間がかかることを説明するときに納得してもらいやすかった例え話
ITシステムを利用していると改善したいことが出てきます。「こことここは同時に指定したい」「この順番が入れ替わると作業しやすい」といったこと要望を感じることは誰にでもあるのではないでしょうか。ご自身が開発に携わっていれば、変更することもできますが、社内のIT部門が管理していたり、開発会社にお願いしていたりすると、このブログエントリのタイトルのように思うことがあるかもしれません。
「ちょっとした変更なのに、なぜ時間がかかると言うのだろう。本当はそれほど時間がかからないのに、ひょっとして仕事が増えるのがいやなだけで、体よく断っているのではないか」と思ってしまうかもしれません。その可能性はゼロではありませんが、一般には次のような理由があるからです。
変更が他の部分に悪影響を与えたり、不整合を起こしたりしないかを確認する調査に時間がかかるからためです。変更自体はそれほど難しくなさそうに見えても、その変更が他のところにも影響するときがあります。それは実際に調べてみないとわからないときもあります。調べなくても大丈夫なときももちろんありますが、調べてみてから、はじめて影響ないのですぐに変更できたり、大丈夫とわかったりします。
これまで、ソフトウェア開発を委託している会社の経営陣の方に「IT部門や開発ベンダーが変更のために多くの時間と費用を必要とするのはおかしい。必要以上のことをしているのではないか？」という質問をもらって、回答してきたときに納得してもらいやすかったものが電車の時刻表の変更です。これを紹介します。私は鉄道の運行やダイヤに特段の専門知識を持っていないので、この例で挙げる制約が厳密には違うものかもしれません。これまで特段の専門知識を持っていない者どうしでは、この問題を理解するための適切なたとえになっているようです。
下の図のような、ある駅を発車する時刻があるとします。0:23がこの駅の終発電車だとします。この駅には別の路線が乗り入れていて、0:28だと、そこからの最終接続がよりスムーズになります。この時刻表の23という数字を書き換えて28にするというのが、簡単に見える変更です。これを28に書き換えるだけで電車のダイヤが変更されるわけではないことはわかりやすいと思います。
この路線の最終電車の発車時刻をすべて5分遅らせるというだけで済む場合には、変更はそれほど難しないかもしれません。しかし、乗務員、駅員、整備士の労務管理上、これ以上遅くすると基準を守れなくなってしまうかもしれません。近隣住民の騒音苦情があり、列車を車庫に戻す時刻に申し合わせがあり、23分よりも遅くできないかもしれません。この最終電車も別の駅で最終電車に接続していれば、その最終電車のことも考える必要があるかもしれません。難しいのは、時刻表の23という数字だけからでは、そのことがわからないことにあります。
こうした制約を調べるのに時間がかかる、調べた結果、他との調整が必要であることがわかった場合を想定すると、変更を頼むほうからは「こんなに小さな変更なのに...」、頼まれるほうからは「小さな変更であっても、できるかどうかはそんなすぐにはわからない」という齟齬が起きています。
これと同じようなことがシステムの改善や変更でも起こるということを理解してもらえれば、誤解が減っていきます。お願いされるほうやそこを管理する方々むけに、ではどうすればよいかを以下で説明します。短時間で終わってミスがなくなるという万能な方法はないのですが、次善策としての方法は大きくわけて3種類あります。
1つめの方法は、改善を依頼する側と受ける側の双方に「簡単だと思ったけれど、やっぱり難しかったから時間がかかる。」という回答があることを合意することです。本記事で促進したいと思っている方法です。双方に理解がないと、変更する側がバッファをとっておいて期待外れにならないようにしがちです。つまり、簡単に変更できる場合でも、変更が難しいときを想定した手間と時間をあらかじめ宣言しておいて、問題となりにくくするのです。安全側に倒しているとも言えます。
ただし、ITシステムを請負契約で外部委託しているなど、費用に影響するような場合には、ゆるやかな基準を決めておかないとトラブルになりやすくなります。その典型は、振り返って見ると調査ばかりで何も変更できなかったというものです。
アジャイル開発に変更した、請負から委任契約に変更して、スピードが変わったというときには、この方法による効果があてはまることが多いでしょう。
2つめの方法は、システムをよく理解した人を確保することです。システムだけで閉じるような変更であれば、ほとんどの制約を理解しているのでこの人に聞けば大丈夫という人です。ただし、システムの内側以外にも制約はありますので、カバーできる範囲は限られています。上の時刻表の例でも、電車の運行以外の制約で時刻が決まっているものがおわかりいただけると思います。システムにもそうした制約はあり得ます。
リリースのたびに、開発担当者が入れ替わるような開発をやめて、同じ開発チームがシステムを維持するように変えたときや、プロダクトオーナーのような役割の人を置いたというときには、この方法による効果があてはまることが多いでしょう。
3つめの方法は、制約に関わる情報をドキュメントとして残しておいたり、問題があれば不合格となるようなテストをプログラムとして書いておきます。テスト用のプログラムを実行したり読んだりすると制約がわかります。この方法の弱点は、ドキュメントを作る時点やテストプログラムを書く時点では、将来必要となる制約やテストを考えることが難しいことです。改善や変更によって、これまでには問題にならなかった制約がドキュメントやテストプログラムに書かれているとは限らないからです。
私の研究グループでは、有償の共同研究としてこうした課題に対応するための方法や仕組みを作ることをご一緒しています。