人間のわがままには疲れた...
最終更新日: 2009-11-17
WEB+DB PRESS Vol. 54 に向けて書いた記事の元の原稿です。
ソフトウェア開発における危険信号「バッドシグナル」についての本連載、5回目の今回はソフトウェア開発のスムーズな進行を妨げるボトルネックついて考察してみたいと思います。
ボトルネックとは文字通り、瓶の首のように細くなっている部分、つまり流れが妨げられる部分を指す言葉です。ソフトウェアの世界では、ソフトウェアの実行速度を低下させる要因を指す言葉として通常使われますが、ソフトウェアの開発速度を低下させるボトルネックも大きな問題です。
ここでは開発のボトルネックにどのようなものがあるか、人間的な要因を中心に見ていきたいと思います。
英語の 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週間伸ばす価値はあるか」と反論した方がよかったかもしれません。最初から数パターンの案を持っていいって、思いつき系の提案を防ぐという戦略も考えられます。
人間のわがままには疲れた...
今回はソフトウェアの開発速度を低下させるボトルネックについて考察しました。人間的な問題は技術的な問題よりも解決が難しいことが多く、場合によっては解決が不可能なケースもあります。せめて自分がボトルネックにならないよう気をつけたいものです。