プロジェクトとしてのチーム運営を考える場合、当然、リーダーの資質・覚悟が最も重要であると言えます。
なぜなら、リーダーが目的を見失ってしまったり、本来の責任から逃げてしまったりした場合、チームとしての機能は、うまく働かなくなってしまうからです。
一方、システム開発という仕事の中で、プログラマが次のキャリアアップを目論む場合には、サブSEとして設計に徐々に携わり、SEになっていく、といったことが通常となっていました。
しかし、プログラマとSEの職務の特性には違いがあり、ここに問題が潜んでいると思われます。
なぜならば、プログラマとして優秀な人というのは、どんな要求にも応えられる技術者を意味しているからです。
優秀なプログラマは、難易度が高いプログラムを、人よりもバグが少ない状態で、より速く生産するといったことが可能です。
そのため、孤独な戦いを強いられることが多く、人に説明したり、現状報告をすることよりも、とにかく作ればよい、結果を出せばよいといったことに目的をすり替えてしまう人も多く見られます。
しかし、大規模システムを、破綻無く成功させるためには、どうするか？
という視点で見てみると、こういった優秀なプログラマが居なくとも、また、そういった人の手を借りずとも構築できる仕組みが、圧倒的に望ましいのです。
仕組みに求められるものは、個人としての優秀さよりもむしろ、チームへの貢献度であり、それは、プロジェクト全体としての品質や生産性が安定することなのです。
そこで、プログラマとして技術が高い人は、共通のフレームワークを作ったり、プロジェクト全体のルールが守られているか、といった守り役を仰せ付かることになります。
実はこの役目こそ、先のSEやプロジェクトマネージャーとしての役割に直に結び付いているものとなります。
個人としての優秀な技能を、いかにチーム全体の品質、生産性の底上げのために使うのか、それこそが最も優秀なプログラマの役割となるわけです。
当然、予定外に自らの作業分担をはみ出した作業が発生します。
しかし、どんな場合もプロジェクトマネージャーに相談し、全体の効率、求める結果の優先順位を考えて作業に携わるべきであり、そのためには、個人としての当初の「達成度」や「満足感」を捨てなければならないことも多々あるわけです。
プログラマとして、新しい技術、より難易度の高い技術に挑戦することは、常識であり、当然のことです。
一方、チームとしての成果を求められるプロジェクトに係わっていく以上、その個人のキャリアステップは、どうやってチームに貢献していくか、どうやって全体としての成果を出すのかを考え、実践していくところにあるわけです。
プログラマ、SEといった職業名も、もっと細かく区分けされる時代ですが、実際のところ、役割名があるが故に、その役割名に準じた仕事をするのが自分の仕事だと思ってしまうことが、一番の問題であると私は思っています。
なぜならプロジェクトという視点で考えた場合に、個人が能力を発揮すればそれでよいというやり方では、やはり、成果を出すことは叶いません。
個人個人の積み重ねを、チームとしての成果に繋げるためには、常にチーム全体や「のりしろ」を気遣いながら作業を進めることが、SEだけでなくプログラマにも必要なのです。
Vol.00131