死ねるプレイングマネージャ

 実動がSE一人、開発一人のプロジェクトで大炎上した。そもそもアサインされている人数が足りない、改修案件だったのだが使用されていたCMSを熟知どころか触ったことがある人もいないなど、火が起こらない理由のない案件だった。それでもいろいろ学ぶこと、やっておくべきとがあったなと思うので今後のために。
 ぼくは開発だったが、最初に入ったプロジェクトで起きた炎上を、SEとクライアントのあいだに立ちながら収めたので、「おまえがプロジェクトをリードしろ」と言われ、ぼく自身もその経験から間違った自信を持ったのでプロジェクトをリードしてきた。


・ゴールに向けて全員が歩を進められないといけない
 SEが技術知識をほぼ持っていないので、打ち合わせには「あとは細部を詰めてね」というとこまでずっと同行していた。その後に作業分担して、開発のために細部の固まったものをちょうだいねーと週一でつっつきながら待ったのだが、結局それが固まった状態でぼくの手に渡ってきたのは一次納品一週間前だった。途中でクライアントにもらっておいてねと言っておいた資料も間に合いそうになかったので、特急で自作した。SEは始終、「クライアントがなかなか返さない」と言ってきた。もしそうなら、クライアントに対して「~までに仕様が確定しないなら機能は実装できない」と言うべきだっただろう。


・仕事の責任を持つべき範囲とできる範囲を明らかにしろ
 開発が最大の責任を負うべき工程は開発だ。SEが未熟で些末なことができていなかったとして、これをサポートすることに注力しすぎるな。これで開発の時間が削れるようなことがあるなら、社内で遠慮なくアラートを上げていい。それでリソースを自分以外のところから融通してもらう。まず自分のやるべき範囲を確認して、それをしっかりやれるリソースを確保しろ。


・プロジェクト管理ツールを使え
 指示を出しておいたのに「聞いてないっす」と返されるのが多くて困った。責任の所在もあいまいになるので、プロジェクトツールを使ってもろもろ進行は管理すべき。グリードアイランド編でカードコンプリートまで残り一枚になったときに、幻影旅団を追い払ったレイザーの存在を思い出せるぐらいの記憶力があれど、相手に忘れられたと言われればあとは不毛な対決をするか引き下がるか、改善を施すしかなくなる。


 ぼくの持っていた自信のなにが間違いだったか。それはマネジメントというのはそう簡単なものじゃないということだ。プロジェクト進行の難易度を左右しつつも定量化しづらい外部要素が多い。クライアントの望む要件、チームメンバーの人数やそれぞれのレベルなど。そういうなかでうまくプロジェクトを進めていくには、やっぱりなあなあの部分がそこかしこにあってはいけないんだなと痛感した。
 とくに今回の案件はボリュームのあるもので、開発としては既存システムを十分に調査したうえで、要件をうまくシステムに落としこまなければならなかった。それには十分な作業時間が必要だった。そういう状況なのに開発が自分一人しかおらず、なおかつプロジェクト進行、メンバーのコントロールまでやるのははっきり言って無理だった。アサインされているメンバーの人数がぜんぜん足りていないと気付いた時点で、マネジメントを正規のプロマネに返すべきだった。
comment: 0