さーて、（ようやく今になって）iPhoneアプリ開発でも始めるか。といった次第なんですが、我ながら「やっと始めるのか！」という感じです。じゃあ今まで何をやってたかというと、作ろうとしているiPhoneアプリの技術的要件（？）を調べていました。
具体的に言うと、ベクター画像(2D/3Dは未定)が変形する様子を描画する方法を調べていて、それってOpenGLでやった方がいいのか、Quartz Composerを使った方がいいのか、はたまた別の方法でやった方がいいのか、といったことをウェブで調べたりしてました。もっとも、NDAが解禁になったとはいえ、iPhoneアプリ開発の情報は日本語ではまだまだ少ないのが現状ですし、ウェブで調べるといっても、そもそも目的の情報が存在するのかどうか不明なわけですから、あまり賢くない「調べもの」だったことは間違いありません。
「じゃあ一体どうすれば良かったの？」という話をする前に。
ちょっと今の状況は何だか覚えがあるぞ、と。
僕が新人プログラマ時代に、ろくに先輩や上司やらから支援を得られずにVisual C++でコーディングしていた案件があったのですが、その頃はVC++で「どんな事ができるかわからない」、「どうやったらできるかわからない」、「目的を達成させるための適切な手段がわからない」という悲惨な状態で無理矢理仕事を与えられました。
その結果、どうなったかというと、「使おうとしている技術」のことがろくに分からないので時間・納期の見積もりなんかできるわけがなく、納期に間に合わせるために徹夜の連続だったりしました。それでも結局は納期を大幅にオーバーし、徹夜も連続するという最悪の事態でした。
そうです。システム/アプリ開発で、プログラマがこれから使おうとしている技術への理解がおぼつかないまま実装を担当すると、間違いなくプロジェクトは破綻します。これは昨今のプロジェクトが破綻する理由の一つになっているのではないでしょうか。実装に使用する言語をろくに理解していない新人プログラマに実装を担当させて、「このプロジェクトで君の担当はx人月だから…」なんて期限が決められても、ろくに完成しないまま大幅に納期が遅れてしまう…最後には、ようやく手の空いたベテランが横取りして、１から作り直して完成した、なんて光景が…。そんな光景を見た覚えがありませんか？
というわけで、僕が新人プログラマだった頃の経験から、このままiPhoneアプリの実装に入ると開発は破綻とまでは行かなくとも、アプリの完成日がズルズルと後ろに延びてしまうのは容易に想像がつきます。
では、次からが本題。使用する言語(又はライブラリやフレームワークなどの)技術の知識・経験が無いのに、それらを使用したプロジェクトで破綻しないためには。
一見、不合理で回り道に見える方法が、実は最短ルートという場合もある
これから書くのは、使用する言語(又はライブラリやフレームワークなどの)技術の知識・経験が無いのに、それらを使用したプロジェクトで破綻しないための解です。
簡単に言うと、そのプロジェクトの成果物とは全く関係無くてもいいから、簡単なサンプルアプリから作り始めようよ、ということです。
これには理由があって、まず技術うんぬんを机上で調べものをしても埒があかないということがあります。使ったことのない技術なのに、読んだりしただけで分かるはずがない。じゃあ、とにかく手を動かしてみようよ、と。そうすることで、プログラマの血肉になります。また、簡単なサンプルアプリであることから、あまり時間を食いません。
簡単なサンプルアプリを作った後は、もうちょっと高度なサンプルアプリを作成します。そしてサンプルアプリの作成を続けていき、その技術に対して理解が深まってから、本番システム/アプリの作成にとりかかれば良いでしょう。
実は、この方法には大きなメリットがあります。
それは、プロジェクト後半の軌道修正が少なくなるということです。考えてみると、最初の「その技術への理解がおぼつかない状態」から、「さぁ作れ」と言われて暗中模索で「この方法で良いのか？」と疑問に感じながら作り始めたものの、実装が後半にさしかかったあたりで
「うわー、この方法は効率が悪い、実はあの方法の方が良かったのか。今からでもいいから作り直したいけど、リーダーが認めてくれなさそうだし…今から最初から作るんだったら、絶対あの方法にするのに…」
と思った経験はありませんか？これってプロジェクトが破綻しているパターンですよね。効率の悪いと見切った方法で続けざるを得なくて、大幅に納期が遅れてしまう状態。もしくは、効率が悪いと見切ったが故に、方針変更して大幅に納期が遅れる状態。
しかし、当初にひたすらサンプルアプリを作る方法だと、プログラマが技術を理解する→実装のイメージがついた状態から実装を開始するので、プロジェクト後半にさしかかってからの方針変更が少ないというとてつもないメリットがあります。
ここの「後半」と書いてあるのがミソで、なぜならプロジェクトというものは、行程が進むにつれて(後半になるにつれて)仕様変更のコストが高くなるという性質があるためです。
そのため、早期のうちにサンプルアプリを作るなどして、使用する技術への習熟度を高めておき、プロジェクト後半での方針変更を最小限に抑えるようにすれば、プロジェクト破綻のリスクは減らせるのではないでしょうか。
ただ、この方法のデメリットとしては、プロジェクトの初期段階でサンプルアプリ作成のために「余分と思われる工数」をさくため、なかなか実現できない（リーダー・マネージャが認めてくれない）ところです。ましてや、成果物に全く関係のないアプリを作るなんて言えば、正気を疑ってくるような人の方が大多数ではないでしょうか。
実際には、サンプルアプリ作成のために初期段階で多少の工数を食ったとしても、それはプロジェクト後半で大きなリターンとして返ってくるので、そこはリーダー・マネージャの説得に力をかけるべきだと思います。それができなければ…プロジェクト後半で大きなしっぺ返しを食らう可能性があります。。
仕事でプログラムを作る以上、なかなかサンプルアプリ作成のような工数を取らせてもらえませんが、プロジェクトで使用する技術に明るい人がいない場合、検討してみてはいかがでしょうか。*1
*1:逆に言えば、「その技術を知っている人」からの支援が得られればいいんですけどね。
