これは「似ている人物がいたとしても、まったくの偶然です」という話であり、さらにいくつかの余計な話も含まれている。皆さん、自分に当てはめないでほしい。始めるぞ……

私は少し気まずい思いでコップを手にしていた。真正面には訪ねてきた王社長が座っている。彼は他所で頑張ってきた人物で、ここ数年はかなり成果を上げているらしい。モバイルインターネットが盛んになるのを見て、当然ここに参入して一勝負しようと考えているのだ。王社長の仕事もITに関係しているとはいえ、長い間技術に触れていなかったため、分からないこともあり、現場で十数年間開発に携わってきた私という老練プログラマーに相談しに来たのだ。十数年の開発経験にはいろいろな可能性があるが、それは重要ではないので、とりあえずこの細かいことは無視しよう。

私が気まずいのは、王社長の要求にどう答えてよいのか分からず、まるで習慣的な物思いに耽っているかのようだからだ。

王社長は立ち上がり、スマホを私の目の前に差し出して言った。「見てくれ、こういうAPPだ。」彼は慣れない手つきで画面を数回スワイプした。私はあまり真剣に見なかった。なぜなら、この質問が難しいことを知っていたからだ。すなわち、すべての開発者が必ず聞かれる、そして最も頻繁に聞かれるかもしれない質問、「こんなAPPの開発にどのくらい時間がかかるのか？」ということだ。私は「分からない」と言いたかった。それが最も率直で正確な答えかもしれない。しかし王社長は旧友なので、そう答えたら失礼になるだろう。そこで私は、彼が指しているAPPがおおよそどのようなものを含むかを大まかに考えるだけでなく、言葉を選んで、これは見積もれないと丁寧に伝えなければならなかった。「見てください、これだけシンプルなAPPですよ」と、王社長はまた画面を何度か操作し、少し期待を込めた目で私を見た。

私は慎重に言った。「率直に申し上げると、はっきりとは言えません。私もこの方面の経験はそれほど豊富ではなく、APP開発をやったことはありますが、これとはかなり違います。すべてのロジックを具体的に分析して初めて、時間を見積もることができます。」

王社長は私の言い分に納得していないようだった。彼はスマホを振りながら言った。「俺の要求は多くない、実はこれより簡単だ。」そして画面のあちこちを指さして、続けて言った。「これは、これも、これもいらない。こういうリストだけでいい。中に詳細があって、閲覧や修正ができればいい……」

私は心の中で、これはまさに典型的な「当然簡単だと思う」態度だと思った。彼にこの問題の複雑さを認識させなければならないと思い、私は逆に尋ねた。「ログインは必要ですか？」

王社長は少し間を置いてから言った。「それはもちろん。」

「どんなログインですか？ユーザー名＋パスワード方式、それとも携帯電話でのログイン、あるいはQQ、微博、微信のような第三者ログインを利用する形ですか？」

王社長は今回は少し考えたようだった。「モバイルインターネットとしては、携帯電話でのログインは絶対に必要だろう。QQ、微博、そうだ、微信、微信もできれば必要だ……ああ、さっき言ったユーザー名とパスワードも、これも必要だろうな。」

私はすらすらと続けて尋ねた。「それなら登録機能が必要ですよね。携帯電話でログインさせるなら、SMSプラットフォームを用意する必要があります。それに微信ログインには、まず企業身分認証を済ませる必要があります。そうそう、ログインとパスワードがあるなら、パスワード再設定機能も必要でしょう。」

「それは確かにそうだ。」

「同時に複数のログイン方法がある場合、それらを『統合』する合理的なロジックを考え出さなければなりません。最も一般的なのはもちろんアカウントの紐付けです。例えばアカウントに携帯電話番号を紐付ければ、その携帯電話番号で同じアカウントにログインできます。微信ログインも同様です。しかし現在のモバイルインターネットのユーザーは登録プロセスをかなり嫌がるので、携帯電話での直接ログインや微信での直接ログインを要求し、登録プロセスを自動的に完了させることがよく求められます。このような場合を考えると、ユーザーが先に微信でログインし、その後で携帯電話でログインしたとします。紐付けをしていなければ、2つの異なるアカウントが生成され、それを再び『統合』することはできません。私たちはより完全な方案を考え出す必要があります……」

王社長は私の話に少し苛立ちを見せた。「そんなに複雑にする必要があるのか？このAPPを見てくれ、これらは全部あるじゃないか？」

「私がさっき説明したような問題が起きるかどうか、試してみたことはありますか？」

しかし王社長はそのような問題には関心がないようだった。彼はただ、こんなAPPを作るのにどれだけの時間がかかるのか知りたかった。もちろん、いくらかかるのかも、これも彼が気にする問題だ。彼は自信満々の口調で言った。「問題があるのが怖いのか？困難なんて何だ？これらは全部解決できると信じている。だが時間が重要だ、早くしないと。競合他社は俺たちを待ってくれない。これだけのものだ、どう思う、どのくらいかかる？」

彼の様子は、まさに順風満帆で成功している人物そのものだった。一方、私のような立場の低いプログラマーは、彼の前では確かに弁解の余地もなかった。私は引き続き細部の重要性を伝えようと思ったが、彼に遮られた。「いや、そこまで正確でなくていい。範囲を推定してくれればいい。2週間か？それとも2ヶ月か？」

私はもう何も隠す必要はないと思った。「本当に分かりません。優秀なチームなら2週間でできるかもしれません（ただ、私自身はそんなすごいチームがいるとは思いませんが）。しかし、私がそんな奇跡を起こせる人間でないことは明らかです。」心の中では、たとえ「2週間から2年」という冗談めいた範囲を言ったとしても、それすら間違っているかもしれないと思った。

王社長は私の答えにかなり失望したようだった。しかし彼は実行力の非常に強い人物で、何かをやりたいと思ったら必ず行動する。行動は必ず速く、必ず結果を出す。この迅速果断な行動スタイルは、確かに私はとても評価している。だが彼のこのプロジェクトには、私は本当に手助けできない。それでも礼儀として、私は言った。「技術的な問題があれば、いつでも私に聞いてください。」

====================== あまり華麗ではない区切り線 ======================

「APPを作るのにどのくらいの時間がかかるのか？」という問題は、人の余命があと何日あるかを測るよりも難しいかもしれない。これほど条件が不十分な問題に、どう答えればいいのだろうか？

全体的に見て、要件が明確であればあるほど、チームが成熟していればいるほど、見積もられる時間は正確になる。しかしソフトウェア開発というものは、何年発展しても、どのような方法論が提唱されても、伝統的な製造業のように「工数」をそれほど正確に計算することはできない。その内部の複雑に絡み合う論理的関係によるものであり、ソフトウェア工学は量産が絶対に不可能なのだ。

ユーザーが見るのは単なるAPPだけだ。もし彼がiOSを使っていれば、おそらくAndroidに触れることすらなく、開発者がiOS版のほかにAndroid版も作らなければならないことを知らないだろう。（Windows版の可能性もある？そうなれば作業量は間違いなくさらに増える）あるいは、Web版で全部済ませる？実際にやってみれば、そうは思わなくなるだろう。ましてや微信小店のようなモデルが本当にあらゆる場面に適用できるだろうか？また、ネットワークに異常が起きなければ、一般のユーザーはサーバーの存在に気づくこともない。サーバーはいつも黙々とユーザーのために24時間働いている。その開発難度はAPP自体に劣らないだろう。そしてAPPの運用保守には人手も必要で、規模が大きくなれば専門チームを組む必要さえ出てくる。彼らは「バックエンド」が必要で、いつでもデータを閲覧・処理できるようにしなければならない。いつでもどこでもデータを閲覧・処理する必要があるなら、バックエンド専用のAPPまで作らなければならなくなるかもしれない。

この道理は少し似ている。私たちは戦闘機が空で見事に敵を撃破する任務を遂行するのを見て、戦闘機自体がすごいだけだと思いがちで、戦闘機に関連する付帯設備を見落としがちだ。熟練したパイロット、作戦指揮センター、地上レーダー、早期警戒機、補給、空港や空母、地上要員などがなければ、戦闘機は戦闘力を失ってしまう。APPも同じで、動きさえすれば終わりというものではない。それを支える付帯設備やメンテナンス作業は、APP自体に少しも劣らず複雑なのだ。

こうした大きな側面はさておき、細部にも多くの不確実性がある。だからこそ成熟したチームが特に重要なのだ。経験豊富な開発者なら、この開発プロセスでどのような問題に直面するか、少なくともおおよそは分かっている。どの問題が比較的簡単で、どの問題が大量の時間を費やす可能性があるか。これは経験に依存する。私がいつも口にする言葉がある、それは「やったことのないものを簡単だと言うな。」というものだ。「当然簡単だ」という態度はプロジェクトにとって何の利益もない。もし自分が確信が持てないなら、この方面に経験のある人に相談しに行くべきだ。具体的な答えが得られなくても、おおよその方向性は得られる。その方向に沿って調べていけば、直面するであろう問題が分かる。もちろん、往々にしてそれらは全体ではないが。

「難易度を過小評価する」ことについて、以前の会社で有名な話がある。当時小さなプロジェクトがあって、すでに機器で使用されている英語のみ対応のプログラムに多言語サポートを追加するというものだった。プログラムはそれほど大きくなく、関わる内容もあまり多くなかった。エンジニアは最初、これは単純な翻訳作業で、長くても2週間で完了するだろうと考えていた。しかしやり始めると簡単ではないことが分かった。まず翻訳は専門家に頼まなければならず、自分たちではうまくできなかった。私たちの誰もヨーロッパ各国の言語に精通していなかった。次に単位換算がある。メートル法を使う国もあれば、ヤード・ポンド法を使う国もある。これは考慮しなければならない。日付表示形式も考慮する必要がある。一気にどれだけの作業が増えたか分からなかった。これらがほぼ終わった頃、今度はドイツ語の単語が長すぎて、私たちの機器の画面に表示しきれず、範囲を超えてしまった。そこでまたフォントを調整し、簡素化を行い、前後で何度も会議を開いて議論した。最後にリリースしようとしたとき、この変更によってプログラムのSizeがかなり大きくなり、一部の機器のストレージに入りきらないことが分かった。これには皆呆然とした。最適化だ、簡素化だ、とやっているうちにプログラムはかなり乱雑になってしまった。最後に何とか品質管理部の検査を通り、ようやくリリースできたが、なんと丸半年かかっていた。今振り返ってみると、これほど時間がかかった重要な理由の一つは経験不足だった。多言語や国際化に不慣れで、遠回りをたくさんした。だから前に述べたように、成熟したチームが特に重要なのだ。

私たちはプロジェクトの時間を見積もる際に、往々にして「コードを書く時間」だけを計算し、上司や客との押し問答、要件分析、設計、テスト、バグ修正にかかる時間を考慮に入れていない。そしてこれらの時間を合計すると、通常、コードを書く時間よりもかなり多くなる。私は上司に気に入られるために、安易に完了時間を短く言うことはしない。なぜか？——そもそも達成できないのだから、なぜ嘘をつく必要がある？1週間かかる新機能の開発であれば、私は通常この時間を2倍にする。これでも比較的「控えめではない」方だ。

たとえコードを書く時間だけを計算しても、過小評価されることが多い。上司や客は、あなたが開発したものに満足しない可能性が高い。もしかすると彼の機能要件を誤解したのかもしれないし、UIが少しカクつくのかもしれないし、アイコンの色が気に入らないのかもしれない。あなたは開発者であって、デザイナーではない。間に合わせでデザイナーの代わりはできても、やはり専門のではない。さらに重要なのは、UIデザインをしたり、画像を作ったりする作業も、かなりの時間を費やすということだ。「1ピクセル」に頭を悩ませているとき、チームにデザイナーが一人いてくれたらと強く思うのではないだろうか？こういう時は上司に注意を促さなければならない。時間と機能の間で、何かを取捨選択しなければならないと。上司はもちろん非常に不機嫌になるが、それでも機能の一部で妥協せざるを得ない。こうすることで難産のプロジェクトを早くリリースできるかもしれないが、将来のプロジェクト失敗の際に、上司に絶好の言い訳をとえることになる。すなわち「うちのエンジニアはあまりにも劣っていて、私の言う通りにやらなかった」と。

ボスやクライアントは、あなたが作ったものが見た目に美しくないと文句を言うだけでなく、さらに多くのものを要求してきます：このインターフェースを複数選択に変更できるか、通知機能を追加できるか、既読・未読の状態を設けてほしい、インターフェースをもっと滑らかにできないか、昨夜プログラムがなぜか「クラッシュ」した……要件はただ機能を挙げるだけで、具体的にこのUIがどれほど美しいべきかは言わず、プログラムの安定性が優れているべきとも言わず、さらに達成すべきスループットの規模にも触れず、もちろん、おそらくもっと重要な——安全性も言わない。あなたはハッと気づく：そうだ、もしハッカーが、いや、ほんの少し技術を知っている悪意のあるユーザーでも、私たちのサーバーを攻撃してダウンさせるのはあまりにも簡単だ。そしてこれらの防御策は何一つやっていない！幸いなことにプロジェクトの知名度が低すぎて、当面これを考慮する必要はない。（どうやらほとんどのアプリはこれを考慮する必要がある段階まで生き残れないらしい。）

これらすべては、機能と言おうが、細部と言おうが、堅牢性と言おうが、どれも自動的に土から生えてくるものではなく、時間をかけて考え、実行する必要がある。中には「システムエンジニアリング」とすら言えるものもある。頭が痛ければ頭を、足が痛ければ足を治すようなやり方をすれば、システムのあちこちに「飛び回る配線」が溢れ、将来のメンテナンスに多くの危険を残すことは間違いない。エンジニアの君は、すべて考慮しただろうか？ましてや、コスト削減のためにボスが買ってくれた低性能なパソコンで毎日イライラさせられる、といった「取るに足らない」ことは言うまでもない。

====================== あまり華麗ではない仕切り線 ======================

さて、王社長は私に別れを告げた後、電光石火の勢いで会社を登録し、ドメインを登録し、オフィスを手に入れ、さらに一気に大勢の人を呼び寄せて勢いよくやり始めた。この発展の勢い、この情熱には、ただただ自分が及ばないと感心するばかりだ。心の底では本当に彼と一緒に事業をやらなかったことを後悔した。しかしそれは感情的な一瞬にすぎず、理性が次の数百ミリ秒のうちに私を引き戻した：やはり行かないほうがいい、彼とはコミュニケーションが取れないから。

王社長のプロジェクトは後に文字通り天を突く勢いで急速に発展し、彼は今や評価額数億の会社のCEOだ。私はというと、ますます自分が「負け犬」だと感じ、オフィスに一人座り、あいかわらずあの水筒を持って、悔やんでばかりいる——待てよ！こうすると結構ドラマチックじゃないか？しかし最初にこの物語は「もし似た人物がいても、まったくの偶然です」と宣言したとはいえ、いい加減にでっち上げるわけにもいかない。本当の結末はこうだ：確かに数か月間は勢いよくやっていたが、その後突然ぱったりと音沙汰がなくなった。もともと王社長に電話して一体どうなったのか聞こうと思ったが、彼は別の超多忙な人になり、私と世間話をする気などもうなかった。うん、結末はやはり似たようなものだ。私は相変わらず苦しい思いをしながらオフィスに座り続けるプログラマーだ。ああ、考えるのはやめて、仕事を始めよう！

出典：http://www.cnblogs.com/guogangj/p/4676836.html