本記事は『プログラマーとお仕事をするということ 折れないプロジェクトは異文化コミュニケーションから』から抜粋したものです。
著者紹介：パトリック・グリーゾン
過去10年に渡りプログラマーとして、またプログラマーのマネージャーとして働いてきました。受託開発するコンサルタント会社や多国籍企業からスタートアップまでさまざまな組織で仕事をし、現在は若い人々がより良い職業選択をできるよう助けるツールを提供するシンクスマート社でCTOを務めています。
ケンブリッジ大学で哲学および古典の学位を取得し、ロンドン音楽演劇アカデミーで舞台技術の学位を取得しています。また映画や演劇のための作曲も手がけ、木琴を奏でる機械仕掛けのタコを含むロボットサーカスのためのアニマトロニクス人形作成に1年間取り組みました。
はじめに
2年ほど前、私は東ロンドンのせわしいコワーキングスペースにあるスタートアップ企業の面接を受けました。創業者のアリは、押しの強い元金融トレーダータイプで、まずクレジット・デリバティブ、それから不動産とキャリアを積んできた人でした。
彼には不動産貸付業界を変革するアイデアがあって、アプリケーションのプロトタイプを作成するプログラマーの小さなチームを雇えるだけの資金をかき集めました。私のこれまでの経歴について根掘り葉掘り聞いたあと、私の返答に満足したらしい彼は、私の方から質問する機会を与えてくれました。私がそのプロトタイプの進み具合について聞くと、彼は大いに進展していると請け合いました。
「俺に言わせりゃね、ソフトウェアを作るのは家を建てるようなもんだよ」。そう話しながら自分で頷いていました。「まず設計して、構築の計画を立てる。その時点でどれくらいの期間がかかるかわかるから、あとはただ作りゃいいだけさ。簡単な話だよ。もう設計とプロジェクト計画はできていて、ベータ版を6月に出す予定だ。現在少し遅れが出ているのは認めるけど、開発者をもう1人探していて――それは君になるかもね――それでオンスケに戻せるだろう」
満足げにくつろいで座る彼を見て、たった今奇妙なことが起きたことに気が付きました。私には彼の話してくれた情報しかありませんでしたが、アリの会社について、アリ自身が知らないことを私は知ったのです。つまり、6月にベータ版を出せる見込みはまずないということです。現在の状況についての彼の説明には赤信号が山ほどあって、毛沢東主義集会にでも出ている気がしました。しかし私が何か言う前に、彼は出口戦略や新規採用者に与えるストックオプションのことに話を変え、その後スケジュールについて話す機会はありませんでした。
結局は、採用すると言われましたが辞退しました（既存のチームメンバーと話して、アリが一緒にやりやすい雇用者でないのではという疑いが裏付けられました）。それでも、その会社の動向については定期的にチェックしていました。案の定、6月がやってきて過ぎ去りましたが、リリースはありませんでした。7月が過ぎ、8月も過ぎました。何かをリリースできたのは10月のことだったと思います。
彼らが予定を守れないだろうことに自分にはどうしてそれほど確信があったのかと、考えるようになりました。そして私が苦い経験を通して学んだソフトウェアの厳しい現実にアリが通じていなかったことに気が付きました。プログラマーと仕事をした経験がないなんてどういうことでしょう？
たとえば、ソフトウェア開発は家の建築とはまるで違うことを私は知っています。消費者向けアプリケーションでプロトタイプを作る前に設計を完成させるなら、リリース前のどこかの時点で設計し直すことになるのはほぼ間違いないと知っています。遅れているソフトウェアプロジェクトで一番やってはいけないことが、チームに開発者を増員することだと知っています。でも、あいにくと彼はそういったことを何ひとつわかっていなかったのです。
そのことを考えるにつけ、すごく不当なことに思えてきました。世界にはアリのような人たちがたくさんいて、仕事上の成功がソフトウェアプロジェクトにかかっていて、そのプロジェクトの成否がその人の決断にかかっているというのに、ソフトウェア開発の奇妙さや特異性のために正しい決断は時にすごく直感に反したものになるということを知らないのです。ソフトウェア開発がどういうものか、誰かが彼らに教えるべきだと思いました。
それから、その誰かは自分でもいいのだと気付き、この本を書くことにしたのです。
第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章ではまずくなったときにどう進めたら良いかアドバイスし、どんな災難も、それがいかに大きかろうと、見た目ほどひどくはないものだという肯定的なメッセージで締めくくりたいと思います。
1.4 この本は何ではないか
これは若い白人オタク男性についての本ではありません
ステレオタイプの話をしましょう。西欧社会では、ソフトウェア開発者に対する、根強く、時にいくぶん侮蔑的なステレオタイプがあるのはご存じでしょう。開発者はギーク（geek）ないしはナード（nerd）だと決めつけるのは簡単なことです。
「ギーク文化」などと言うとギークが復権する助けになっていますが、私の経験ではビジネスの文脈における一般的な感覚は、ギークにはさまざまな好ましくない性質が伴っているというものです。さらに、ソフトウェア開発者のステレオタイプには人種や年代についてのある仮定が付随しています。その仮定とは、開発者というのは男性で、白人で、おそらく35歳未満だということです。
本当のことを言うと、ヨーロッパや北米におけるプログラマーについては、これらの仮定やステレオタイプには一定の根拠があります。現在西欧における開発者の多くは男性であり、白人であり、35歳未満です。それを示す調査や統計があります。ギーク度を測る統計を見付けるのは難しいことですが、広範囲なソフトウェア開発者と仕事してきた誇りあるギークとして言わせてもらうと、平均的な開発者は平均的な人と比べてずっとギーク度か高いというのは断言できます。
そうするとこう思うかもしれません。これはソフトウェア開発者とどう仕事をするかという本であり、ソフトウェア開発者が若い白人男性でギーク的な傾向があるなら、この本は若い白人男性のギークとどう付き合うかという話になるのではないか。これに対する答えははっきりと「ノー」です。これには3つの大きな理由があります。
第1に多数派だけに向けて提供するというのは当てにならないやり方だということ。レストランの客の大多数は致命的なピーナッツアレルギーを持ってはいませんが、だからといってすべての料理にナッツをたっぷり振りかけて差し支えないということにはなりません。教室の生徒の大半は成績が下位3分の2に属しますが、だからといって教師が上位3分の1の生徒を惹き付け、挑戦させるような努力をしないのは馬鹿げています。
同様に、ソフトウェア開発者の大半が特定の層に属していて、他の層を犠牲にしてその層の人に特に合ったやり方を考案することは可能だとしても、そのようなやり方はその層と合わないチームではたぶんうまくいかないだろうし、そういうやり方を選んで推奨するというのは無責任で見当違いでしょう。
第2の理由は、時代遅れの仮定をしている文章ほど古く感じさせるものはないことです。現時点においてプログラマーは白人で男性で若く非社交的という傾向があるのだとしても、それがずっと続くと仮定すべき理由はありません。実際それは変わるだろうと仮定すべき理由があります。
ソフトウェアを作る上で若い白人男性のナードだけが向いているような、何か本質的なものがあるわけではありません。何より、初めて公開されたコンピュータープログラムを書いたのが女性だったことを忘れないようにしましょう。
バイロン卿の娘にして聡明で狂っていたとも言われるエイダ・ラブレスが、チャールズ・バベッジの発明になる、まったく理論上のハードウェアのために書いたソフトウェアがそれであり、ソフトウェアという概念自体彼女によるところが大きいのです。
さらに、性別の偏りは世界的な現象ではないということ。ヴィクラム・チャンドラはその素晴らしい本『Geek Sublime』（Graywolf Press、2014年）で、2003年のインドにおいてコンピューターサイエンスの学位を取得した人の55%が女性だったことを記しています。
米国においても変化が起きつつあります。学生を増やそうとする試みとして、大学は女性を惹き付けようとしており、中には極めて上手くいっているケースもあります。男女の偏りをなくそうという努力の甲斐もあり、カリフォルニア州にあるハーベイ・マッド大学では2016年のコンピューターサイエンス専攻の学生の過半数が女性でした。
同様にソフトウェア開発者における人種的多様性も、わずかずつではありますが増えています。テクノロジーで億万長者になる現代の神話のおかげで、プログラミングに惹かれる20代でやる気満々の人々はどうでしょう？ 彼らは年々年を取って年代の偏りを減らしています。多様性の増加で性格についての単純なステレオタイプが合いにくくなるのは言うまでもありません。
開発者がどういう人間かというある種の仮定が現在この場所で統計的におおよそ合っていたとしても、その仮定に依存するのは私たちの住む変化し続ける世界においては近視眼的でしょう。
3つ目の理由は、どういう人がソフトウェア開発者になるかというステレオタイプには自己強化的なところがあるためです。そういうステレオタイプを信じ、仮定することは、それに合わない人がソフトウェアの世界に来にくくなるような環境を作ることに繋がります。
多様性と包括性は、それ自体も、それがもたらすものも価値があると主張することに異論はないでしょう。この2つを促進するために私にできる最善のことは、その妨げとなる狭いステレオタイプを受け売りし強化するのを避けることだと思います。
そのため、この本ではソフトウェア開発者を戯画的に描くことはしません。ナード型の人と付き合うためのマニュアルを望んでいる人は失望することになるでしょう。プログラマーの心理学に目を向け、プログラマーがどのように考え、振る舞う傾向があるか、実用的な一般化は行いますが、その一般化はソフトウェア開発を生業とするのがどういうことかに基づいたもので、ステレオタイプに合うかどうかということではありません。
これはプログラミングの本ではありません
この本ではプログラムを書いたり読んだりする方法を教えようとはしないし、学ぶべきだと説得しようともしないことを明記しておくべきでしょう。私はこの職業のエバンジェリストではありません。
本書の内容は読者がソフトウェア開発者として働くことではなく、ソフトウェア開発者と一緒に仕事する助けになることに焦点を当てており、技術的な話に深入りするのは、その話題について専門家と生産的な会話をしやすくするためであって、自分で専門家になってもらうためではありません。
とはいえ但し書きとして、この本では多くのことを単純化することになると言っておくべきでしょう。技術用語の定義やプロセスの解説をいろいろしますが、それは完全なものでも正確なものでもありません。技術やプロセスに関しては、どんな定義にも但し書きや例外があるもので、私はいちいち細部へと下りてはいきません。
これには2つの理由があります。第1に、細かな議論をしているとそれだけですぐ本が埋まってしまうこと。たとえばポストSQL時代のデータベースの構成要素が何かとか、BDDでは上位レベルの機能や統合テストですでに網羅されているのと同じ実行経路を単に通すユニットテストを書くべきなのかとか。そんなことをしていたらこの本で本当に伝えたい部分にたどり着けないでしょう。
第2のさらに重要な理由は、読者はそういう詳細を気にかける必要はないということです。必要なのは仕事を成し遂げる上で役に立つ、とりあえずの定義です。だから私が「データベースは……」とか「BDDでは……」などと言ったときには、頭の中で「（ただし例外もある）」と文末に付いているものと思ってください。
これは非技術系の人を批判するものではありません
最後に、この本は過去50年のソフトウェアプロジェクトにおけるひどい実績について、ソフトウェア開発者を赦免しようとするものではありません。たしかにこの本の前提は非技術系の人の行動を変えることでソフトウェア構築プロセスの苦痛を減らすということですが、それは悪いのがすべて非技術系の人間だということではありません。
むしろ私は、非技術系の人（つまり読者）がソフトウェア開発の問題に対してもっとも大きな貢献ができると思っています。たとえその問題の元々の原因が非技術系の人の行動や態度によるものであろうとなかろうとです。
