気難しいプログラマとの人間関係に必要ないくつかのポイント

SE・PGと上流・下流

»

 私は普段、同業者との会話の中で特別な意図のないかぎり「SE」という単語はめったに使わない。SEとPGのどちらが上なのか、などという巷によくある不毛な論争にも決して首を突っ込まない。承知の通り、SEという言葉はとうの昔に形骸化しており、SEという肩書きは職級や立場を表す名称以外の何者でもない。どちらが上かと問われれば「SEの方が上に決まっている」と答えるだろう。この質問は発注者と受注者、あるいは上司と部下といった主従の関係を問うているにすぎないからだ。

 個人的に利用している言葉を使わせてもらうならば、プロジェクトのメンバーは上流従事者と下流従事者に分けられる。文字通り、上流工程に従事する者と下流工程に従事する者だ。この言葉は必ずしも一人の人間に対して1:1の関係を持つものではない。設計もコーディングも行うのであれば、その人は上流従事者であり下流従事者でもある。もしあなたの上司が顧客の要件を聞いてくるだけの御用聞きだとぼやくのであれば、あなたは自分が上流従事者であることを自覚しなければならない。たいていの場合、プログラマはなんらかの形で上流に携わっており、SE=上流、プログラマ=下流という図式はまったくもって実状を表していない誤った認識である。結局のところ、「誰か」ではなく「何をする人か」で語らないからややこしいことが起こるのだ。上流工程の話をするときは上流従事者として、下流工程の話をするときは下流従事者としてカウントすればいいだけの話なのである。

 上流従事者は設計という業務を担っている点において下流工程の知識が必須となる。必ずしも下流工程の経験は必要ないとされているが、おそらくこれは机上の空論だろう。内部設計のできない上流従事者はみんなから影で馬鹿にされている。SE・PG論争の本質は、おそらくこれが原因だろう。

 開発言語やフレームワークなどの選定において、スキルの低いメンバーを考慮してこれらのレベルを下げざるを得ないという話をよく耳にするが、こういうプロジェクトに限って下流業務をメンバー全員が平等に分担するといった悪しきマネジメントが行われている。業務は分担するのではなく、スキルごとに割り振らなければならない。機能ごとに担当モジュールを持つのではなく、高いスキルを持つメンバーにはより設計に近い基底クラスを、スキルの低いメンバーには末端の派生クラスを担当させるといった具合に適切な割り振りを行うのだ。オブジェクト指向の効用は、このような課題にも非常に有効である。

 ただし、十分な効果を得るためには、上流従事者は適切な割り振りが行えるようアーキテクチャを意識した設計を行わなければならない。要は内部的なフレームワーク層の設計だ。非常に難易度の高い業務ではあるが、スキルの高い人間を上流に置くことで、こうしたスキルレベルの不均衡をある程度調整することが可能となる。日本の上流・下流の分離構造には確かに多くの問題点があるが、このような工夫によって低スキル者の影響を局所化するというメリットもあり、チームプレイを得意とする日本においては有効な組織構造と言えるかもしれない。

Comment(1)

コメント

通りすがりのIT屋さん

「上流」「下流」という言葉がいい印象を与えないよね。

そもそもウォーターフォールでしか意味が通らない言葉だし(詳細設計や実装の結果、前工程の成果を変えざるをえないなんて、よくあることで)。

あくまでも対等だよ。

コメントを投稿する