プログラマが成長するには、プロジェクトの把握能力を高める

開発者にとって、開発プロセスを学ぶことはとても重要な意味があります。

開発プロセスとは、開発を進めていく手順のことですが、特にプロジェクト全体の進捗と開発がやるべき仕事はとても密接な関係があります。

開発プロセスを知らずに開発を進めていくと、開発が大きく手戻りして納期に間に合わなくなったり、重要な仕様が未完成となり製品の仕様に大きな影響を及ぼすことがあるのです。

そのためにも、「今は何をするべき時期なのか」ということをしっかり把握した上で、そのための活動をしっかり進めていくことが必要なのです。

「プロジェクトの大きな流れは、1人のプログラマである私には無関係」などと考えてはいけません。

プログラマの判断ひとつがプロジェクトに大きな影響を与えることもあるのです。

たとえばあなたがWebのクライアントエンジニアで、「この仕様はJavaScriptで解決できます」と言ったとします。

少し知見があれば「検証した方がいい」ことだったかもしれないのですが、確実でないにしろ「おそらく大丈夫」と「軽く」考えて、「実現できます」と言ったのです。

「よし、わかった」ということでプロジェクトはどんどん進んだのですが、実際に実装してみたらうまくいかないケースがあることが検証でわかってきました。

調べてみると、現状のJavaScriptの仕様では正式に実現されていなかったことがわかりました。

それで、あなたはプロジェクトリーダーにこう報告します。

JavaScriptの仕様だから解決できません、と。

JavaScriptでその問題が解決されるまで待つことができればいいのですが、多くの場合そうではありません。

このプロジェクトとしても、この問題をなんとか解決しなければならないので、知見者が集まって対策会議を開くなどして対応を協議しないといけません。

何度も集まって協議した結果、JavaScriptでは解決できないことは事実であると判明し、その対策のためには、

「サーバーサイドで対応するしかない」

という結論に達したとします。

そうすると、これまでならクライアント側でJavaScriptで解決できると思って設計してきたのに、サーバーサイドで解決するように設計を変更しなければならなくなるのです。

あなたが「軽く」発言したばかりに、設計の見直しをしなければならなくなるのです。

これが大きな手戻りとなり、プロジェクトには大きな影響を与えてしまいます。

こういうことが後になって起これば起こるほど、プロジェクトへの影響は大きくなるのです。

この事例で大事なことは何でしょうか？

それは、サーバーサイドで実現するか、クライアントサイドで実現するか、という極めて設計に大きな影響を与える「アーキテクチャ」を決める段階での決定に必要な実現性の検証を先送りしたことに原因があります。

経験上、あるいは仕様として確実に間違いがないということを確信しているのであれば問題はありませんが、そうでなければプロジェクトに影響を与えかない重要な点や検証が必要なことはあらかじめ確認しておくことが大事になります。

もしも、不確実なことで検証が必要だけれども今は実施できないのだとしたら、技術検証するという課題に追加しておいて実施時期を決めて管理するのも良いでしょうし、

たぶん大丈夫だけれど念のため「リスク」として管理してもらわないといけないのです。

エンジニアとしては、「不確実である」ことは正しく伝える責任があるのです。

不確実さを正しく伝えること、プロジェクトを進める上で、とても大事なことになります。

「不確実さ」を伝えるにはいつでもいいわけではありません。伝えるべき適切な時期があります。

物事の程度によって違いはあるにせよ、多くの場合プロジェクトの計画を引く段階で話をすべきでしょう。

開発の終盤になって「実はこのバグはまだこの技術が確立されていないからです」などと言おうものなら、どうしてそんな技術を選択したのか！と叱責を受けるのは間違いありません。

プロジェクトの初期段階であれば、「技術が確立されていないけれども、影響がないかどうか検証する」ことを計画しておけば、プロジェクトに影響を出さないように進めることはできるのです。

そして検証して使える技術なら使うし、そうでないなら別の技術で代用できないか、設計の見直しが必要か決めていけば良いのです。

それがプロジェクトの終盤であれば影響が大きすぎるのです。

このように、「今は何を検討すべき段階なのか」をわかった上で開発に関わっていくことが欠かせないのです。

そのためには、開発プロセスを知っておくべきなのです。