その「やりましょう！」は大丈夫なの？
こんにちは。草食系妙齢プログラマ 野口おおすけです。関東は暑い日々が続きますが、いかがお過ごしでしょうか？ わたしはさっそく夏バテ気味でぐったりしています。先日、会社の後輩たちに会う機会があったのですが、仕事が忙しいらしく疲れきった表情をしていて、ちょっと心配しています。仕事を頑張るのも大事ですが、やはり体調管理をおろそかにしてはいけません。無理しない程度に仕事に取り組んでほしいものです。
■勉強会夏祭り2010に登壇します
いよいよ今週末7月17日に開催される「勉強会夏祭り2010」に、「それは一枚の不思議な仕様書でした……」というテーマで登壇することになりました。LightningTalksでは何度か「マジカル仕様書」についてお話ししたことがありますが、今回はたっぷり50分間ということで、「マジカル仕様書」を通して「ITエンジニアがユーザーに提供しているバリューとは何か」ということを考えてみようかと思います。わたし以外にも、学生からOSSエンジニアまで、さまざまなジャンルの方が登壇します。詳細・参加申し込みは、こちらのサイト（http://atnd.org/events/6067）をご覧ください。
さて、前回に引き続き、今回も不思議なマネジメント「エキセントリックマネジメント」についてお送りします。前回は、主にプロジェクトにまつわる「数字」の話をお送りしました。今回は、よくある危ないマネジメントについてお送りします。
■なんでもかんでも「やりましょう！」
Twitterで大人気の某携帯電話ベンダの社長の「やりましょう！」はすばらしい、と評価する声をよく聞きます。中にはこの社長を目標とされている方も多いと聞きます。この「やりましょう！」をプロジェクトに持ち込むとどうなるでしょうか。
ユーザーの声から新たな要件を抽出し実装するという「やりましょう！」は、ユーザーのサービスに対する満足度を上げるという側面では評価できます。しかし、前回もご紹介したとおり、プロジェクトに費やせるリソースには制限があります。その制限の中で、すべての作業を終えリリースを行わなくてはなりません。サービスを完成させリリースすることが対外的なミッションなのです。つまり、「やりましょう！」といってできることには限界があります。
「スケジュールを○○日までお願いします」「やりましょう！」「この機能を追加してください！」「やりましょう！」「この画面を変えてください！」「やりましょう！」となんでも「やりましょう！」ということを繰り返していると、チームの生産可能な成果物の限界を超えてしまいます。
「やりましょう！」と返事をすることは、お断りするよりとても簡単です。しかし、無策に「やりましょう！」を繰り返すとチームは破綻します。マネジメントに必要なのは、最近話題の「仕分け」なのです。必要な機能にリソースを集中させることや、不必要な要件は優先度を下げたり実装を見送ったりすることが、マネジメントの基本になります。
何でもかんでも「やりましょう！」を続けた先には、メンバーが疲弊したチームしか残りません。そのような状態では、顧客とコミットメントした最初の要件を満たすのも難しい状態すら、招く結果となります。本当に必要な要件を選択すること、それに対しリソースを集中すること、これを適切に行うことが重要なのです。
■その工数はだれもの？
ソフトウェア開発にかかる工数は誰が負担しているものでしょうか。いいかえると、ソフトウェア開発に必要なコストは誰が負担するものでしょうか。それは顧客が負担しています。自社の社内システムであれば自社が顧客となりますし、新しいWebサービスのローンチであればステークホルダーが負担します。
プロジェクトにかかるコストが、果たして顧客のためになっているでしょうか。ここで、システム運用や維持作業を行うプロジェクトで運用しているシステム上のバグにより、システムに不具合が生じてしまったというケースを考えてみましょう。このような場合、システムを復旧させることが第1のミッションとなります。原因追及やバグの修正が第2のミッションになります。
年に一度や二度しか起こらないうえに、復旧にかかる工数もほとんどかからないし、冗長化によるシステムへの影響度はないと判断するのであれば、施策をとらないこともあるでしょう。しかし、これが月に数回や週に数回になると、いくら復旧に時間がかからずシステムも見た目上は影響を受けないとはいえ、何かしら施策をとらなければなりません。
ここで考えたいのは、「復旧に関するコストは、本来顧客が負担すべきものであったのかどうか」ということです。本来であれば、バグがなく安定して稼働することが、システムのあるべき姿なのです。つまり、本来発生すべきでないコストなのです。短期的に見たら大したことがないコストでも、長期的な観点で見ると大きなコストとなるわけです。
顧客がコストを負担するということは、プロジェクトとしてはバリューとなります。しかし、このような場合は、本来発生しないコストからバリューを生む仕組みとなってしまっています。このバリューと、顧客に対してサービスを提供して得られた本来のバリューを混同してはなりません。本来発生すべきでないバリューだけを積み重ねることを続けていると、真に求めるべきバリューを失うことになります。
さて、2回にわたって「エキセントリックマネジメント」についてお送りしてきました。このようなマネジメントは、短期的にはプロジェクトをなんとか運営できても、長期的に見るとメンバーは疲弊して、最悪の結果を招くことになるでしょう。プロジェクトメンバーは、いま所属しているプロジェクトがカットオーバーを迎えると、次のプロジェクトへアサインされます。次のプロジェクトでも同じようなマネジメントを繰り返せば、メンバーは会社そのものに疲弊していきます。その先は……いうまでもありませんね。
さて次回は、ソフトウェア開発に関する四方山話をお送りいたします。それではまた次回。