第1章 イントロダクション 読者、著者、そしてこの本について
この本に書かれているのは、ソフトウェアはどう作られるのか、どういう人が作っているのかということ、特にソフトウェアを作るプロセスがいかに奇妙で特異性のあるものか、いかに気まぐれで失敗しやすいものかということです。信じてほしいのですが、ソフトウェアプロジェクトというのは失敗しやすいものなのです。
大規模組織におけるITプロジェクトについての調査で、ソフトウェア作成を含むプロジェクトでは、ソフトウェアを含まないものより予算超過額の割合が平均で5 割高く、スケジュール遅延期間の割合が平均で10倍になることがわかっています。ソフトウェアの作成は誰の予想よりも長くかかり、高くつくだけではありません。その予測が外れ失望させる度合いが驚くほどなのです。
このあとの章の前提となるのは、そんな風である必要はないということです。ソフトウェア開発の失敗は通常そのプロセスの奇妙さや特異性が理解されず無視されていて、ソフトウェアの構築を建築事業のように扱う傾向のために起きています。この点については繰り返し強調することになるでしょう。
ソフトウェアの構築は家を建てることとは全然違う
この本はソフトウェア開発者の解剖学と心理学を含むソフトウェア開発プロセスのガイドツアーであり、ソフトウェアプロジェクトを駄目にしてしまう誤解や誤認識を避けられるように意図したものです。私が想定する「読者」はいろいろな値を取り得るので、まずはその点について述べましょう。
1.1 読者は誰か
読者はソフトウェアを作る必要があるが自分では書かない人です。もう少し詳しく言いましょう。読者像の簡単な描写を3つあげます。どれか近いものがあれば、この本は自分向きだと思ってください。
プロジェクトマネージャー
PRINCE2認定を取得していて、会社で最初に手がけた2、3のプロジェクトで理論を実践することに自信をつけました。コーヒーでも淹れるようにガントチャートを作り、バナナサンデーでも食べるようにリスク評価できます。会計ソフトのアップデート版リリースの成功では、月例の全社集会でCOOから名前をあげて褒められ、この調子で続けていけば将来は約束されていると直属の上司にも言われています。
しかしその後大きな社内システムの改修に当たることになりました。以前のプロジェクトとは違って、今回は新しいソフトウェアを構築してリリースするというものです。下の階の開発者が何人か割り当てられ、みんなごく友好的ですが、上級Javaエンジニアはプロジェクト計画段階で手助けを求めても、あまり助けにはなりませんでした。システムをまるごと「車輪の再発明」しようとするのではなく、既存のシステムを適切に手直しすることに時間をかけるのが正しいやり方だと繰り返すばかりなのです。それでは役に立ちません。
そもそもこのプロジェクトは、既存のシステムに手を入れることにみんなうんざりしていていたので、もっとマシなものを作ろうと予算を調達したものです。ほぼ同じものを出すことになれば関係者の合意は得られませんが、そのエンジニアはそこのところの重要性がわかっていないようです。
加えて彼女は新しいシステムを作るのにどれくらいかかるかは、入念に書かれたこちらの仕様書が「ユーザーストーリー」として書き直されなければ何とも言えないと言い張っていますが、それは文章が「ユーザーとして」で始まる以外には違いがないように思えます。彼女はまたリソースが不足していると不満を言い続け、作業を外注するか、契約社員を入れるかする必要があると言いながら、どれほどの作業量になるかははっきり言えないと言うのです。一方でプロジェクトの開始は近づきつつあります。
CEO
やりました。チャンスを掴んで変化を起こし、今やエキサイティングなスタートアップの世界の創業者となりました。ウェブアプリのすごいアイデアを思い付いて投資家向けのかっこいいプレゼン資料を用意し、9か月やっていけるだけのシード投資を得られたので、エリック・リースの本で学んだすべてを実践したくてうずうずしています。1人目となる社員も採用し、CTOに据えました。少し若いですが、なかなか目を見張る経歴の持ち主で、面接ではとても知識を持っているようすに感心したものです。
しかし若干気にかかることがあります。そのCTOが言うには、前に作らせたプロトタイプは目的に合っておらず、それを作った契約の開発者はPHPとか言うものを使っていたけど、それは「ちゃんとした」言語ではないので、Nodeなるもので1から作り直す必要があるということですが、基本的には同じもののように見えます。加えて彼はアセンブラとかいうものに大枚を払うことを望んでいますが、それが何のためなのかちゃんと説明していません。
それから再構築が完了した後に新機能を開発するのにどれくらいかかるか見積るのは、ユーザーストーリーを「機能仕様書」に書き直さないとできないと言っていますが、自分にわかる限りでは妙な文体を使う以外は同じものに思えます。技術的な問題については彼のことを信頼していますが、彼が入ってから万事が少し難しくなったように思え、ミーティングの後にいつも何か理解し合えていないような感じが残ります。
クライアント
このところ事業が好調です。何年かの不景気の後、地元でそれなりの評判を築き上げました。口コミとネットでの好意的なレビューのお陰で、かなりの仕事が来るようになりました。ある業界の賞にノミネートさえされています。正直に言うとノミネートされている人はたくさんいて、授賞式の参加費が高いので、事情通の人は価値がないと言っていますが、何にせよ注目してもらえるのはありがたいことです。
もう少し改善したいことを1つあげるなら、それはウェブサイトです。もともと知り合いの知り合いに作ってもらったものですが、当時はホームページと電話番号さえあれば基本的に良かったのです。その後何年かの間にいろいろ追加しました。
ブログの「連絡先」のページに始まって、最近ではオンライン予約システムも加えました。知り合いの知り合いが引っ越すことになったので、代わりに地元の業者を紹介されました。しばらく前からウェブサイトの表示が遅くなっているのが気になっていて、その業者には遅いことを指摘していますが、彼らは見てみますと言うだけで何も改善されていないように思えます。
それからページの表示が壊れる問題が繰り返し起きていますが、直してくれと言うと、「再現できなかった」とか、「たぶんキャッシュの問題なので、サイトの新規訪問者には影響しない」と言うばかりで、信じていいのかわかりません。ウェブサイトで直接製品を売れるように拡張する予算を用意しましたが、業者に言うと、要領を得ず、「技術的負債」がどうのと言い始めます。
こちらで想定している新しいページについて詳しく説明すると、彼らは「アジャイル」なやり方でやりたいと言い、それはどうも前もって計画する代わりに、進みながら考え出していくということのようです。彼らのことは気に入っているし、彼らもこちらを好きなクライアントだと言っていますが、ときどき何か騙されているような気がしています。
1.2 身に覚えがありますか？
このうちのどれかに少しでも合うところがあれば、この本はあなた向きです。そうでない場合でも、この本から何か得られるものがあるでしょう。自分はソフトウェア開発者ではないけれど、一緒に作業している相手や、部下や、あるいは（まれですが）上司がソフトウェア開発者で、彼らがどのように仕事するものなのか理解したいなら、この本を読んでください。
ソフトウェア開発者の仕事に影響を与える、あるいは影響を受けるというなら、この本を読んでください。ソフトウェア開発者であって、自分の仕事が非技術系の同僚の仕事にどう関わるのか知りたいなら、この本を読んでください。ここまでで多少とも当てはまるものが何もないなら……、まあ、ここまで読んだことだし、あとほんの300ページです。別に失うものもないことですし。
ここで読者の知識についていくつか仮定をしておきます。コンピュータープログラムのコードについては何も知らないものとします。たとえばHTMLとHTTPの違いをうまく説明できないし、そのような違いについて知っていることが自分の仕事を早くうまくやるのに役立つのでもない限り、気にかけないものと仮定します。これで読者については済んだので、私のことを話しましょう。
著者について
私もかつては読者の皆さんと似たようなものでした。以前はHTMLとHTTPの違いや、そういったつまらない技術的なことについては、知りもしなければ気にもかけませんでした。シンプルな時代でした。より幸せな時代だったかって？ そうかもしれません。
それからソフトウェア開発者の仕事を得ました。ありがたいことに、最初の雇い主は前提知識や経験を何も要求せず、私の「哲学と古典」の学位が障害になることもありませんでした。その後10年の間に、私はさまざまな役割をこなしてきました。
ソフトウェア開発者、ソフトウェア開発者のマネージャー、プロジェクトマネージャー、プロダクトオーナー、大工。幸いなことに私は、スタートアップ企業から大企業、コンサルタントからフリーランスまで、さまざまな組織や立場で働く機会に恵まれました。
今日までの経歴の中で、私は幾多のひどい失敗をしてきました。大失態です。その多くは純粋に技術的なもので、ありがたいことにこの本とは無関係なので話さずに済みますが、特にソフトウェア開発者やソフトウェアプロジェクトを管理していたときの私の決断による失敗は、ソフトウェアを作り上げる上で何がうまくいき、何がうまくいかないのか、多くのことを痛みと共に教えてくれました。
それからまた、私のものに劣らずひどい失敗を同僚や上司が犯すのを観察する機会もあり、密かに慰められました。マネージャーがみんな経験する、暗い午前3時の魂の危機の中にあって思うのは、私が犯し、観察してきた過ちには、いくつか共通点があることです。もし私や同僚たちが前もってわかっていたなら多くの過ちを避けられたであろう知恵があることに思い当たったのです。そうしてこの本ができました。
1.3 この本は何か
この本は非技術系の人にソフトウェア開発がどういうものか少しでもわかるようにし、より良い決断を下せるようにしようというものです。ソフトウェア開発は一般に組織の中でサポート的な役割を果たすため、ソフトウェア開発者が開発者よりは開発者でない人の下で働くことが多いのは驚くまでもない事実でしょう。
CTOはCEOの下で、上級エンジニアはプロジェクトマネージャーの下で働き、ソフトハウスはクライアントからの依頼で仕事をします。いずれの場合でも、非技術系の人が決断をし、技術系の人に指示をします。純粋に技術的な問題については非技術系の人には決断が下せないので、決定権は技術系の人に委ねられます。非技術系の人が責任を持つのは、非技術的な部分――商業的、ロジスティクス、美的な部分などです。
しかしここに難しい問題があって、非技術的なものすべてが技術的な部分に影響を与え、また影響を受けるのです。そのため正しい決断をするためには、非技術系の人は、技術についてそんなに知らなくとも、論理や直感やよく知っている分野との類比によって、どんな影響があるものか合理的な仮定をする必要があります。
それはいいのですが、問題はその技術的な部分というのが非論理的で直感に反し、他のことと比較し難いということです。これはこの本の中心をなすことなので繰り返しましょう。
ソフトウェア開発というのは非論理的で直感に反し、他のことと比較し難い
そうであれば、ソフトウェア開発が関わるプロジェクトを納期と予算を守って遂行するのが極めて難しいのもうなずけるでしょう。複雑なプロジェクトの一環として何年もコードを書いてきた経験のない人が滅多に持ち合わせない、ソフトウェア開発というものの奇妙さや謎についての理解が必要なのです。
これは別にソフトウェアプロジェクトはみんなプログラマーを責任者にすればスムーズに進むと言っているわけではありません。そうではなく、どんなプロジェクトであれ、責任者に最適なのは、管理という高等な技術について具体的な経験とスキルがありトレーニングを受けている人です。
この本を通して繰り返し示そうとしているのは、ソフトウェア開発については、責任者は通常最適な決断を下すのに必要な情報を持っていないということです。ソフトウェアという興味深い野獣を何年にも渡って研究し、その謎について学ぶ余裕などないのが普通だからです。
この本はその情報への近道を提供することで、ソフトウェア開発者としての実務経験がなくともソフトウェアプロジェクトの良きリーダーとなれるようにしようというものです。これは難解で見通しがたいプログラマーの世界への入門書であり、プログラマーではない読者が正しい決断を下し、私や私の同僚は学ぶのが遅すぎて犯してしまったような間違いを犯さないようにするためのものです。
大体において、本書は何か非常に深い、革新的な、あるいは飛び抜けたことを言おうとする書籍ではなく、一部には知られているけれど、その知識からもっとも恩恵を受ける人（すなわち本書の読者）が知らないことの多いさまざまなことについて、要約を伝えるものです。
第2章と第3章では、プロジェクトの計画と遂行のための従来の直感的な方法とソフトウェア開発プロセスが相容れない点に触れ、そのような衝突を避ける方法をいくつか評価します。特にアジャイル開発に焦点を当て、ソフトウェアプロジェクトの管理がどう発展してきたか説明します。アジャイル開発が何か知らなくとも大丈夫です。その基本については解説します。またその利点と欠点を評価します。
第4章から第6章では、ソフトウェア開発者が何をどのようにやっているのかについて解説します。ソフトウェア開発プロセス、関連する用語、コードを書く以外にソフトウェア開発者が行っているさまざまなことにも触れます。
第7章から第9章では、ソフトウェアプロジェクトの管理とは別の話として、ソフトウェア開発者の管理に焦点を当てます。これはソフトウェア開発者をどう採用するかといった具体的なことについてのアドバイスを含むほか、一般的なプログラマーの心理学について探り、開発者の心を占めているプレッシャーや優先度に目を向けます。
最終章では少々落胆する問題、失敗にどう対処するかに焦点を当てます。私が示したいのは、この不完全な世界にあって物事は決して計画通りに進まないものですが、優れたリーダーの特徴は不利な状況にあっても勝てるということです。
第10章ではまずくなったときにどう進めたら良いかアドバイスし、どんな災難も、それがいかに大きかろうと、見た目ほどひどくはないものだという肯定的なメッセージで締めくくりたいと思います。
