ITちびまる子ちゃん
Twitterで「#ITちびまる子ちゃん」というタグが流行ってて、これがなかなか面白い。
「まるちゃん、今はサーバよりクラウドなのよ」 #ITちびまる子ちゃん pic.twitter.com/yJ6GdgWntk
— Lucifer-Alpha (@LuciferAlpha) 2020年6月11日
こんな時事ネタもw
いろいろ眺めてたんだけど、目についたのが次のツイート：
なんで納期直前になっていろんな部門から要求が降ってくるのかね全く…。全部の要求聞いて仕様変更するあたしの身にもなってくれよ、トホホ…。#ITちびまる子ちゃん pic.twitter.com/CYsk5SBt5I
— ミノ駆動 (@MinoDriven) 2020年6月10日
まさにあるあるネタw
「水の上を歩くことと、仕様書からソフトウェアを開発することは簡単だ。どちらも凍結してさえいれば」というジョークが示す通り、ソフトウェア開発が大変なのは仕様が固まってないからとも言える。
仕様変更のタイミングの謎
さて、これを単なるあるあるネタで済ましてしまうのもいいんだけど、あるあるネタということは、みんな同じ悩みを持っているということ。
なので、ちょっと冷静に考えてみたい。
なんで仕様変更は納期直前にやってくるんだろう？
ここでポイントになるのは、「納期直前に」というところ。
これがせめてもっと早い時期にやってきたのなら、まだ対処のしようもあったかもしれない。
けど、現実はそうではないので、凄惨なデスマーチへと進むことになったりする。
はてさて、なんで納期直前にこんなことになるのか。
プログラマならここで、原因を突き止めるために「差分は何なのか」を考えるはず。
何か差分があるからこそ、違いは生まれてくる。
では、納期直前とそうでないときとの差分は何なのか？
動くソフトウェア
そう、差分を考えると、それは「動くソフトウェアがあるかどうか」。
要件定義や設計のときは、当然動くソフトウェアはない。
実装中も、ソフトウェアはまだユーザが使える状態ではない。
システムテストに入って、ようやく動くソフトウェアに触れることが出来るようになって、不具合なのかどうかもあやしい挙動が見つかったり、お客さんが実際に触ってみて感触を確かめることが出来るようになる。
で、そうやって動くソフトウェアに触れるようになって初めて「想定してなかったこと」が見つかったり、「使い勝手がいまいちだね」ということが分かったりする。
すると、システムテストも終盤で、いよいよリリースだねという納期直前になって、「ここは想定してなかったけどこういう動きにして」とか「ここは使い勝手がいまいちだから仕様を変えて」という仕様変更が襲いかかってくることになる。。。
よくよく考えれば、動くソフトウェアがなければ仕様変更なんか基本的にはないし、あったとしてもまだ作ってないんだから手間は変わらない。
動くソフトウェアが実際にあるからこそ、仕様変更は生まれてくる。
そして、動くソフトウェアが出来上がるのがシステムテストに入ってからなら、仕様変更が納期直前になるのは必然とも言える。
どうすべきなのか
しかし、そう考えると、仕様変更が納期直前になるのは必然であり、避けようがないようにも思える。
何か対策はないのか？
まず考えられる対策は、「上流工程をよりしっかりやる」こと。
「凍結してさえいれば」という通り、もうどう考えても抜け漏れのない完璧な仕様を作れさえすれば、たしかに仕様変更もなく楽に開発ができる。
けど、じゃあ上流工程をしっかりやろうとしてないプロジェクトがあったかというと、そんなことはないわけで。
どのプロジェクトも上流工程をしっかりとやろうとしてきたはず。
それでも現実には抜け漏れがあったりするんだから、正直これは理想論でしかない。
凍結してりゃ、そりゃ水の上も歩けるかもしれないけど、現にどんなに頑張っても凍結しないんだから、「凍結してさえいれば」なんて真にならない命題には何の意味もない。
じゃあ、どうすればいいかというと、もうこれは「動くソフトウェア」を早く作るしない。
もちろん、全部入りのソフトウェアを早く作るなんていうのは無理だから、一部の機能に限定したソフトウェアを作ることになる。
そして、実際に触れてみれば、想定してなかったことや、実際の使い勝手が見えてくる。
それを踏まえてプロジェクトの早い段階で仕様変更を受容するようにすれば、余裕をもって対応できるようになる。
まぁ、とどのつまり、アジャイル開発になるわけだけど。
面白いのは、これはソフトウェアだからできる対処法だということで、たとえば家を作るときにこんな芸当はできない。
リビングだけまず作って、次にダイニングを作って、みたいなことは不可能で、まずはちゃんと全体を設計して、土台を作って、骨組みを作って、壁を作って、と順番に作っていくしかない。
けど、ソフトウェア開発はそんな制約に縛られる必要性はない。
プロジェクトのすべての成果物を同期させることには累積効果があるので、先へ進むほど変更のコストが飛躍的に上昇します。
（中略）
少し調べてみると、その曲線が土木工学に端を発することがわかります。
（中略）
しかし、これらのルールがソフトウェア開発に当てはまるのは、私たちがそうさせたからにほかなりません。
ソフトウェアは、ソフトと呼ばれるだけあって、柔軟にできています。
ソフトウェアは容易に変更できるはずなので、正しい手法とよい道具さえあれば、非常に融通の利くものとなります。
ですから、土木工学のたとえを用いてソフトウェアを鉄筋とコンクリートになぞらえると、自分で自分の首を絞めることになります。
（『The RSpec Book』より引用）
この指摘は非常に面白くて、つまりソフトは他にも柔軟な開発方法があるだろうに、わざわざ後になるほど変更のコストが高くなる建築と同じように作れば、そりゃ後工程の変更コストがバカ高くなるのは当然よね、と。
なので、やっぱりいにしえの開発手法に縛られているのではなく、より柔軟な開発手法にシフトしていかないといけないんだろうなぁ。
今日はここまで！
