プログラマSEが若手中心で戦力不足なプロジェクトを回す方法

2016年10月1日に投稿 → 2018年6月1日に更新仕事術アフィリエイトリンクを含みます

「これから始まるプロジェクトのメンバー戦力やばい、絶対トラブルなるわ…」
「うちの会社って全体的にスキル低くていつも炎上してるんだが…」
「戦力不足のメンバーでもうまくやれる方法ってないかなぁ？」

ある程度経験のある人が集まって仕事をすれば、プロジェクトを成功させるのは比較的かんたんです。

一方、新卒で入ったばっかの人が4割、二年目が5割、10年の経験者が1割みたいなメンバー構成の場合、9割のメンバーが経験2年以下のメンバーとなります。この条件でプロジェクトを成功させるのは、とても難しいです。

「これでは戦力不足だから、もっと経験のあるメンバーを入れてください。」と言っても、「空いてる人材が他にいない」なんてことはよくあります。大抵の場合、空いてる人の中で最も案件にマッチする人が招集されてるわけですからね。

こんな無茶振りな仕事でもなんとかして成功させなければなりません。

いかにして成功させる可能性を上げるか、そのためのアイデアを紹介します。

Contents

戦力不足な人って、どういう人？

一言でいうと「知識や経験が少なくて、仕事を遂行する能力が低い人」です。

こう書くとすごくけなしてるように感じられるかもしれませんが、そんなつもりはありません。

仕事を始めたばかりであれば、知識・経験・能力が低いのは当然です。誰も悪くありません。

そういう人たちに仕事をうまくやってもらうには「仕事を細かく分けること」がポイントです。

仕事を細かく分ければ誰でもできる！

例えば、「AさんはSQLを書けるようになってください」という役割を与えます。SQLの文法を覚えてもらって、データベースアクセスのプログラムの書き方（トランザクションやORMの使い方など）を教えます。この人にはデータベースアクセスのプログラム選任の人になってもらいます。

すると、経験の少ない人でも一つの領域に絞れば必要な知識を身につけ、同じようなプログラムをいくつも書いていくだけなのでうまくできるはずです。

仕事を分けるためのモジュール分割

プログラムをレイヤー(層)ごとにモジュール分割すると仕事を分けやすくなります。

フレームワークを使えばMVCなどのように自然とモデル、ビュー、コントローラと役割に応じたレイヤー分けがなされます。

先ほどの例(DBアクセス専任)を適用するのであれば、モデルレイヤーの中をビジネスロジックレイヤーとデータアクセスレイヤーに分けると良いでしょう。

そうして、Aさんにデータベースアクセスレイヤーのプログラム開発だけに専念してもらいます。

機能毎に作業分担する場合との違い

通常の開発では、作業分担は機能毎に行うことが多いと思います。

例えば、

ユーザー登録機能をAさんが担当
商品検索機能をBさんが担当

みたいな割り振りです。

この場合、Aさんはユーザー登録の

ビューである画面のHTMLやJavaScript
リクエストを処理するコントローラー
ロジックを実行するモデル
DBアクセスするデータアクセスレイヤーのプログラム

を開発します。

一人で担当機能の全レイヤーを開発するには、

ビューを作るために → HTML/CSS/JavaScriptの知識
コントローラーやモデルを作るために → サーバーサイドのプログラミング言語(Java, PHP, Ruby, C#等)の知識
データアクセスの実装 → ORマッパー、SQLの知識

が必要とされます。

一人に幅広いプログラミング能力が要求されるわけです。

それに対してレイヤー毎に担当を分ける方法だと、

ビュー担当 → HTML/CSS/JavaScriptの知識だけあればOK
コントローラー、モデル担当 → サーバーサイドプログラミングの知識だけあればOK
データアクセス → ORマッパー、SQLの知識だけあればOK

それぞれのレイヤーで必要とされる知識だけを修得すればよくなります。

その分、担当する機能の数は増えます。

ビュー担当のAさんはユーザー登録機能と商品検索機能とその他多数のビューを開発することになります。担当する機能は増えますが、レイヤーが同じなので、技術スキルを使いまわせるメリットがあります。

希少なベテランメンバーの使いどころ

一方ベテランの人たちは全レイヤーを実装する知識を持っているので、フォロー役をやってもらいます。

新人Aさんにビューレイヤーを担当させて、ベテランCさんがフォローする（仕事のやり方や知識、ノウハウを伝承していく）編成にすれば、短期間で新人Aさんがビュー領域においてはベテランレベルに向かって急成長できます。

実際やってみたらうまくいった

実際に、このやり方（レイヤーで担当分け）で仕事をしたことがあります。と言っても、その時の私は入社三年目だったので、私主導でではなく、PMの提案でこういうやり方になっただけなんですけどね。

そのプロジェクトのメンバーは若手中心（入社2年目比率が高い）でした。ベテランもいたのですが、そのプロジェクトで使っているプログラミング言語(Java)やオブジェクト指向に精通している人が少なかったため、大部分が初心者みたいなやばい状況でした。

この話ってけっこう古くて2002年の話です。業務システムをWebアプリケーション化する仕事が多くなり始めた時期で、それまで汎用機でCOBOLのプログラムを書いていたような人たちをWebアプリケーション開発のプロジェクトに押し込んでいました。

そんな状況なので、個々人が身につける技術をできるだけ少なくて済むようするために、レイヤーで作業分担することになったんです。

作業を分けすぎて、おかしなことにもなったけど…

このプロジェクト、やや過剰な作業の分け方をしていて、JavaにはValueObjectとかDTO(Data Transfer Object)っていう概念があります。DTOとかいうと、なんかたいそう立派なもののように聞こえますが、一言でいうとデータの入れ物クラスです。C言語で言う所の構造体みたいなものです。

public class UserDTO {
    private String email;
    private String name;
    public void setEmail(String s) {
        this.email = s;
    }
    public String getEmail() {
        return this.email;
    }
    public void setName(String s) {
        this.name = s;
    }
    public String getName() {
        return this.name;
    }
}

なんとこのプロジェクトでは、データの入れ物レイヤー選任担当の人が二人もいたんです。

この人たちはデータの入れ物クラスだけをひたすらコーディングして、setXXXメソッドでセットした値がgetXXXメソッドで取得できるかというテストをしていました。

「そんなのプログラミングと言えるか？」って感じですが、それでも、入れ物クラスのコーディングという雑多な作業をその人たちがやることで他のメンバーの作業が減るのですから、多からずチームに貢献できています。

「いやいや、DTOとそのテストコードまで含めて自動生成できるわっ！！」っていうツッコミもありますけどね(笑)

一種の雇用創出というかクライアント企業への水増し請求じゃねーかと言う気もしますけど、まぁ１０年以上も前のことですし。

ただ、このやり方でチームはとてもうまく機能したことは確かです。

まとめ

実際やってみて、本当に、

HTMLだけ作る人
コントローラーだけ作る人
SQLだけ書く人
フレームワークや共通クラス作る人

みたいな分け方でうまくいったので、メンバーのスキルレベルに不安がある場合は、このようなレイヤー毎に担当を割り振るというやり方をぜひお試しください。