小さく分ける
プロジェクトが大きくなると、ネックになるのがメンバーの増加である。その最も興味深い理由の1つが、コミュニケーションチャンネルの数の増加だ。お互いの話が可能なのは2人の場合だけ。コミュニケーションの道が１つだけだからである。しかし、これが3人になると道は３つ。4人だと６つ…事実上リンクは指数関数的だ。1日仕事をするはずが、メモとミーティングに埋まってしまうことになる。
解決策ははっきりしている：チームを小さくし、独立して動ける規模まで小さくし、コミュニケーションのリンクを減らすのだ。
同じ様に、プログラムも小さな単位に分ける。問題の多くは多くの要素の混在（大きな変更、機能同士のデータ接続エラー、ハードウェアの共有…）から起こるため、要素同士の依存を取り除く、_または最小限にする_様プログラムを分ける方法を考えるのだ。
Getting Real by 37signals
ビジネスに必要な掛算
* ひどいアイディア = -1
* イマイチのアイディア = 1
* まぁまぁのアイディア = 5
* 良いアイディア = 10
* 素晴らしいアイディア = 15
* 最高のアイディア = 20
* 実行しない = $1
* ほとんど実行しない = $1000
* まぁまぁ実行した = $10,000
* 結構実行した = $100,000
* かなり実行した = $1,000,000
* 最も実行した = $10,000,000
ビジネスを行うには、この２つの掛け算が必要になる。
最高のアイディアでも、実行が伴わなければ、$20の価値しかない。最高のアイディアを最もよく実行に移せば、その価値は$20,000,000になる。
私が人のアイディアを聞きたくない理由が分かっただろうか。実現していないものには、何の興味も持てないのだ。
—
デレック・シヴァーズ、「CD Baby」・「HostBaby」社長・プログラマー
Getting Real by 37signals
PM : 僕たちには1000のアイディアはいらない
スティーヴ・ジョブスが何人かの独立系レコード会社の人にiTunes Music Storeのちょっとしたプレゼンテーションを行いました。その日の私のお気に入りの台詞は、彼らが手を上げて「それはxはできるの？」、「あなたはyを追加する予定ですか？」と尋ねたときのこと。ついにジョブスは言いました、「待ってくれ、待ってくれ — 手を下ろしてくれ。いいかい。君たちがiTunesに入れることができる1000のクールなアイディアを持っているるのは分かっている。もちろん僕たちもだ。でも、僕たちには100のアイディアはいらない。 それはみっともないよ。イノベーションは全てのこと̆に対してイエスと言うことじゃない。それは最も重大な機能を除いて、全てにノーと言うことだよ。
Getting Real by 37signals
Team Work
チームは可能な限り小さく保ちなさい。メトカーフの法則、『コミュニケーションシステムの価値はそのシステムのユーザー数の約二乗で増加する』はプロジェクトチームにおいてもそうです。 チームの効率性はチーム内のメンバーの数の約二乗に反比例します。私は1.0の製品のリリースには３名が最適だと考え始めています・・・あなたがチームに加えようとした人々の数を減らすことから始めなさい。それからさらに何人か減らします。
Getting Real by 37signals
Career : CSA（Chief Software Architect）
過去に感心したソフト（製品）を挙げてください。また、そのソフトをあなたが改良するとしたら、どのような部分を変更しますか？
【連載】新時代のITキャリア 第18回 トップ・マネジメント編「CSA」 : キャリアアップ - Computerworld.jp
SI業界に明日はあるか
現在SI業界は、構造上の問題、人材の不足、ユーザーの要求の高度化、雇用流動化という4つの問題を抱えている。この問題を解決するためには、どうしたらいいのかについて考えてみる。
- 構造上の問題
SI業界の多重請負構造が、システムの品質の低下、高コスト化をもたらしているのではないかという説。
多重請負構造とは、クライアントからシステム開発を請負う元請けがいて、さらにその下に1次請け、2次請け、、といった下請け会社に外注するという構造のこと。当然、各社マージンを積んだ上で見積もるので、階層が重なるにつれ、コストはかさみ、下に行くほどマージンは低くなる。
また、元請けと下請けの間の溝は深く、最悪ドキュメント、メールなどインダイレクトなコミュニケーションとなる。ゆえに仕様がうまく伝わらず、バグの温床となる。
最近では、この構造が世界規模で拡がっている。オフショア開発である。下請けがインド、中国にまわる。言語的な壁、文化的な壁がさらに状況を悪化させているという話も聞く。
- 人材の不足
上記のような構造のため、元請けは管理タスク、下請けは開発タスクがメインとなりやすい。したがって、元請けに技術の分かる人間が社内にいなくなる。（かといって、下請けから人材を登用するという考えはあまりない。）
また、IT業界を希望する学生も減っているようだ。それは、上記の構造によってもたらされた悲劇を皆が知ってしまったからだ。長時間労働、低賃金、技術者の地位の低さ、、努力しても報われない世界を希望する人間はいない。（もっとも環境ビジネスやナノテク、遺伝子工学など他の魅力的な業界に奪われているというのもあるだろうが。）
当のこの業界にいる人間たちは、耐えに耐えた結果、疲弊して業界を去っていく。
- ユーザーの要求の高度化
一方、ユーザーの要求は、変化するビジネスに迅速に対応するシステムを求めている。より短期間で、より低コストなシステムが今まで以上に求められている。結果、無理に受注したプロジェクトは、燃える。燃えるプロジェクトの多くは、あまりにも限られた期間、予算の中でスタートすることが多く、始まる前に勝負がついていると感じる。
- 雇用流動化
システム開発はプロジェクトという有期のスタイルであるため、必要な時に、必要なスキルを持った人間を、必要なだけ確保するという特徴がある。したがって、人材は他業界と比べても流動的である。必要であれば、社外から人を確保するし、逆にプロジェクトがなければ、社内に留保するしかなくコストになるだけだ。かくして、SIerの人件費は、変動費となり、雇用流動性が生まれる。また、育てるという文化も生まれにくくなる。
以上、SI業界の多重請負構造、ユーザーの要求の高度化により、プロジェクトは燃えやすくなる。わらの家の周りで子供が火遊びをしているようなものだ。そして、実際に燃え尽きてしまったいくつもの失敗例が、SI業界を敬遠する理由、去る理由となり、人材が不足していく。さらにプロジェクトというスタイル上、雇用流動性が高く社内に人が残りにくいく、また人が育ちにくい（育てない）。その人材の不足が、またプロジェクトを悪化させるというデフレスパイラル構造である。
- SI業界に明日はあるか
このような状況を打開するためには、どうしたらいいのだろうか。今、僕は、新しい技術と新しいマネジメントの両面が欠かせないのではないかと思っている。
新しい技術とは、ビジネスの変化に追随可能な、より柔軟で、俊敏で、再利用性の高いシステムを実現する技術である。それは、生産性、品質の向上、スピードアップをもたらす。具体的には、フレームワークの活用、サービス化（コンポーネント化）がポイントだと思っている。また、Agileなどの新たな方法論の活用も欠かせない。
何よりも重要なのは、このようなアーキテクチャの重要性を理解し、それをリードできる存在である（ここでは、ITアーキテクトと呼ぶ）。彼らには、新しい技術の重要性を啓蒙し、皆をキャッチアップさせ、プロジェクトに定着させる力が求められる。
次に、新しいマネジメント。プロジェクトの成否は、始まる前に分かっていることが多い。スケジュール、スコープ、コストこれらをしっかりと顧客と交渉し、勝算のあるプロジェクトをスタートさせられる存在。そして、いざプロジェクトがスタートした後は、その制約条件の中で、チームをモチベートし、ひとつの目標の達成に導いていく存在。ここまでは、従来のリーダー像。
今必要だと思うのは、リーダーがいなくてもまわる組織、日々学習し進化し続ける組織、メンバーが自立的に動ける組織、こんなを作れる存在である。
一人がすべての存在になる必要なんてない。チームの中にこれらの役割を果たす人間が少しでもいれば、プロジェクトの成功確率は上がる。SIも疲弊せず、楽しくやれる。そんな人材のひとりになりたい。そして、そんな世界を作っていきたい。
