ソフトウェア開発における危険信号「バッドシグナル」についての本連載、5回めの今回はソフトウェア開発のスムーズな進行を妨げるボトルネックについて考察してみたいと思います。
開発のボトルネック
ボトルネックとは文字通り、瓶の首のように細くなっている部分、つまり流れが妨げられる部分を指す言葉です。ソフトウェアの世界では、ソフトウェアの実行速度を低下させる要因を指す言葉として通常使われますが、ソフトウェアの開発速度を低下させるボトルネックも大きな問題です。
ここでは開発のボトルネックにどのようなものがあるか、人間的な要因を中心に見ていきたいと思います。
Go-To Person
英語のGo-To Personは「困ったらあいつのところに行け、と頼りにされる人物」という意味の言葉です。Go-To Personと認識されることはグループの中で一目置かれる存在になるということであり、基本的には好ましいことと考えられます。しかし、Go-To Personはボトルネックになりやすいという危険性を秘めています。
「このフレームワーク、中でなんか微妙にデータ変換が行われてるっぽいんですけど」
「んー、そこはよくわかんないなあ。使い方を間違えるとすぐデータ壊れちゃうんだよね。作ったのNさんだから、Nさんしかその辺わかんないんじゃないかな。ドキュメントあんまないし。捕まえて聞いてみたら」
「とりあえず今、見当たらないので後から捕まえてみます。げ、Nさん出張中ですか。2週間かー、結構長いっすねー。とりあえずメールしてみます」
（3日後）
「ぜんぜん返事来ねー！ やっぱ出張中は忙しいのかなあ。と思ったら、うわ、twitterに書き込みしまくってるじゃん。しかもマジックテープの財布を使ってるかどうかとか、内輪でどうでもいいことで盛り上がってるし。そんなことよりオレの質問に答えてよ...」
これは、Go-To Personがボトルネックとなっている典型的なパターンです。Go-To Person本人は、質問の返答を少しくらい後回しにしてもいいやと気軽に考えているかもしれませんが、質問者のほうは返事がこないおかげで、作業が滞ってしまっています。
このような場合は、困っているから早く返事が欲しいとの旨を最初のメールに明記しておくとか、1日経過したくらいですぐに催促のメールを出すといった対処法が考えられます。
とはいえ、そもそもの問題は、Go-To Personだけがノウハウを握っているという状況なので、Go-To Personさんにドキュメントを書いてもらってGo-To Personを卒業してもらうのが長期的に正しい解決方法です。
無用な作り込み
ソフトウェア開発において、開発者のこだわりは良い方向にも悪い方向にも作用します。良い方向のこだわりはソフトウェアの品質を上げますが、悪い方向のこだわりはただの時間の浪費につながります。
「あれ、何、作ってるんですか。あ、開発用のツールですか。へえ、いまどきは開発用のちょっとしたツールも、ブラウザで動くように作るんですねー。ん、何なんですかこれ」
「ISO 3166の国コードを国名に変換するツールですか。ああ、jpをJapanにするとかですね」
「わ、世界地図が出てきた。もしかして、jpって入力すると日本にピンが立つとか？ わ、やっぱり」
「しかもこのUIのグラデーションとか回転とかはなんですか。へえ、CSS3でできるんですか」
「って、めちゃめちゃ作り込んでるじゃないですか。こんなことに時間使わないでくださいよ！」
この例では自分しか使わないような開発ツールを無用に作り込んで時間を浪費しています。JavaScriptとCSS3の勉強を兼ねて、と理由をつけることもできますが、無用な作り込みはほどほどにしておきたいところです。
無用な作り込みと似た問題としては「無用な全部書き直し」という問題があります。よく言われることですが、「こんな汚いコードいじるくらいなら、全部書き直したほうが早い」と思っても、ほぼ確実に予想以上に時間がかかります。
独裁者タイプ
開発者の中には、自分でプロジェクトのすべてをコントロールしたいという独裁者タイプの人がいます。よくあるのは、自分のやり方に徹底的にこだわって、他のメンバーのやり方を認めないパターンです。
「バグ見つけたので、直したんですけど」
「なんだこの直し方は！ こんな直し方は認めん！ 直すといったらこうやるだろ。まったくわかってないな」
「はあ、そうですか（やれやれ。どっちのやり方も大差ないのに。次からはバグ見つけても、もう直さないよ...）」
同様に、他の人の意見を認めないケースもあります。
「こういうアイディアはどうですかね」
「ダメだダメだ。お前はどうして今の仕様になっているのか知らんから、そういうことを言うんだろう。まったくわかってないな」
「はあ、そうですか（もう意見なんて出さないよ...）」
こういう独裁者タイプの人は、自分のやり方にこだわるあまり、他のメンバーによる貢献を制限してしまいます。こういう人に限って「他のメンバーからの貢献が少ない。みんなどうしてもっとアイディアを出さないんだ」
などと不平を言ったりするので困りものです。オープンソースの世界では、このようなリーダーが原因でプロジェクトが分裂する例をたまに見かけます。
やるやる詐欺
やるやると言っておきながら、なかなかやってくれない人というのはどこにでもいます。どうせやらないなら、そうはっきり言ってくれたほうが助かるのですが、本人は一応やる気があるらしく、催促しても「やるやる」という返事しか返ってきません。
「この部分の実装、全然動いてないみたいだけど」
「ちょっと見てみるわ」
（1週間後）
「もうそろそろ直った？」
「ごめん、まだやってない。今見るから、ちょっと待って」
（さらに1週間後）
「あのー、まだ壊れているっぽいよ。直してくれたの？」
「おっと、まだだけど。そもそもこれって、動かないのが正しいじゃないの？」
「（こいつ、あほか...）いや、そんなことはない。スペック見てみてくださいよ」
「たしかにスペック見ると、書いてあるね。今度こそ今週中に直すわ」
（さらにさらに1週間後）
「やれやれ、まだ直ってないね。こっちで直しとくから、もういいよ」
こうした、やるやる詐欺を信じると時間ばかりが経過して作業は何も進みません。同じチーム内のメンバーなら強く要求できますが、別のチームのメンバーだったりするとそうもいかないことがあり、厄介です。無駄に失望しないよう、はじめから期待し過ぎないことが肝要です。
思いつき系の提案
ソフトウェア開発において、アイディアを出し合って議論することは重要なプロセスです。しかし、強い権限を持っている人が思いつきでアイディアを出してきた場合、開発をスローダウンさせる要因となることがあります。
「これがほぼ最終のバージョンです」
「ほうほう。いいんじゃないの。で、これ、何でメニューこの順序で並んでいるの？ こことここ、逆にしたほうがいいんじゃない？」
「いや、とくに理由はないですけど。逆にするのは簡単ですよ。逆にしたほうがいいのはなぜですか？」
「なんとなく。とにかく、逆にしたバージョンを持ってきてよ。来週のこのミーティングでまた見るから」
「はい。ではそうします（なんとなくで提案するなよ...これでまた1週間、リリースが延びた...）」
この例の場合、思いつきの提案のおかげで1週間、リリースがずれ込んでしまいました。この場合、おとなしく引き下がらないで「逆にするのはいいが、リリースを1週間延ばす価値はあるか」と反論したほうがよかったかもしれません。最初から数パターンの案を持っていって、思いつき系の提案を防ぐという戦略も考えられます。
まとめ
今回は、ソフトウェアの開発速度を低下させるボトルネックについて考察しました。人間的な問題は技術的な問題よりも解決が難しいことが多く、場合によっては解決が不可能なケースもあります。せめて、自分がボトルネックにならないよう気をつけたいものです。
