■http://anond.hatelabo.jp/20141129112709

新米マネージャが管理する小規模プロジェクトにおいて発生する諸問題とその対策について

※マネージャを多少悪者気味に書いていますが、マネジメントの大変さはわかっているつもりです。

「自分が開発すればこのくらいでできる」問題

上司「この間言ってたプロジェクトの見積もりできた？」

マネージャ「たぶん2週間ぐらいでできますよ！wordpressなら学生のころバイトとかでもよくインストールしてたから楽勝です！」

デザイナ「完全オリジナルのwordpressデザイン2週間か、なんとかなるかな?」

プログラマ「PHP未経験なんだけど大丈夫かなあ…」

.... 略 ....

上司「あれから2週間だけど、こんなにバグ多すぎじゃリリース無理じゃない？」

マネージャ「違うんですよ！デザイナーが全然テンプレートの使い方覚えてくれないし、あのプログラマ人PHPわからないとか言って仕事中にPHPの本とか読んでるから遅れたんです！たぶん自分だけだったらこんなに時間かなりませんよ。」

デザイナ(「XHTMLになってない！」とか余計な所に口突っ込んできやがって！）

プログラマ(PHPなんて簡単だよとか言ってJavaプロジェクトからコンバートさせたのテメーだろうが！)

原因

• 開発能力の高いプレイングマネージャが自分の能力を元に見積もりをしてしまっている。
• デザイナーや外部ベンダーとのコミュニケーションの見積もりをかなり楽観的に見積もっている。
• マネージャが本来やるべきマネジメント業務を放棄して開発業務に多くのリソースを使ってしまっている。

対策

• 基礎となる開発工数を「マネージャを除く開発メンバーの平均開発能力 + バッファ」で出す。　
• 自分で見積もったことの無いタスクは、他のプロジェクトのスケジュールを参考にして出す。
• マネージャが開発に携わる場合その分マネジメントタスク用のバッファを大きくする。
• メンバーはスケジュール上の不安を早めにマネージャに伝える。マネージャが聞き入れない場合マネージャより上の人間にアラートを出す。

「テストは開発工数に含まれないよね？」問題

マネージャ「このスケジュールなんだけど、テスト期間長過ぎじゃない？」

プログラマ「え、でも機能もこれだけありますし10日程度は妥当かと」

マネージャ「いやいや、画面たったこれだけじゃない、通しのテストなんてみんなでやれば1日ぐらいで終わるでしょ？」

プログラマ「バグがあったらどうするんですか？」

マネージャ「俺がレビューしてるんだからそんなでかいバグ出るわけねえだろ。ナメてんのか」

.... 略 ....

プログラマ「テストでバグこれだけ見つけました」

マネージャ「へー、それじゃこれ今日のうちに修正してね」

プログラマ「セキュリティ周りのバグもあるので、修正には3日程かかると思いますが」

マネージャ「ふざけんな！テストは今日で終わるスケジュールだろ！」

原因

• テスト工数をクライアントが認めてくれない。
• 「テスト工数は無駄」という文化が会社にある。
• テストはスケジュール上に存在するがバグ修正が含まれていない。

対策

• 「ユーザエクスペリエンス調査」とかの適当な名目でダミータスク作り、その分をテスト工数にあてる。
• 何かの開発工数を過剰見積もりして、過剰見積もりした分でテストを行う。
• テストの価値をわかりやすくするためにJenkinsのテストレポートやカバレッジ等、目に見えるアウトプットを用意する。
• テストと対になるバグ修正バッファをスケジュールに組み込む。

「バージョン管理は効率悪くなるからダメ」問題

プログラマ「前のプロジェクトでgitを使って便利だったので、今回のプロジェクトでも使いたいのですが…」

マネージャ「バージョン管理とか使ってるの?あんなの効率悪くなるからやめたほうが良いよ」

デザイナ「私もそういうの面倒だからあんまり使いたくないな」

マネージャ「前に俺がやってたプロジェクトではフォルダで日付ごとに管理してた。同じ風にすれば大丈夫だろ」

プログラマ「でもロールバックが…」

マネージャ「古いフォルダからファイルをコピーすればいいだけだろ。馬鹿か」

.... 略 ....

マネージャ「なんで古いソース持ってきても動かないんだよ！」

デザイナ（間違ってファイル上書きしたのは黙っておこう）

プログラマ（ローカルにgitリポジトリあるのは黙っておこう）

原因

• バージョン管理ソフトに対する無理解。

対策

• バージョン管理についてちゃんと勉強して利点と欠点を理解する。
• gitはプログラマ以外に受けが悪い場合が有るので、用途に合わせてsvnを使う等メンバーに不満が出ない様柔軟に対応する。
• ローカルでgitリポジトリ等を使って自己防衛する。

「フレームワークにバグがあったらどうするんだ！」問題

マネージャ「何このCodeIgniterっていうの？」

プログラマ「あ、それ最近流行ってるPHPのフレームワークで、URLのルーティングが…」

マネージャ「はぁ！？フレームワークとか使わないと開発できないわけ？これだから最近のゆとりはダメなんだよ。」

プログラマ「でも、便利ですよ？」

マネージャ「俺のプロジェクトではそういう怪しいやつは使わないから。バグがあったらお前責任取れるの？」

.... 略 ....

マネージャ「どう、俺の書いたURLルーティングライブラリすごく便利じゃない?」

プログラマ「大文字を使うとうまく動かないのですが」

マネージャ「あー、それは仕様だからしょうがないよ。mod_rewrite使えば問題無いでしょ？」

プログラマ（他人が再発明した車輪のバグを修正するのって本当に不毛だな…）

原因

• フレームワークに対するカスタマイズ性、パフォーマンス、潜在バグ等の不信感、知識不足。

対策

• フレームワークについての調査をタスクとしてスケジュールに組み込み、ちゃんと評価してから採用/不採用を決める。
• 「あのサイトでも○○使ってますよ」等、実績をあげるなどして安心感を持たせる。
• 社内勉強会を組織して会社としてフレームワークに対する不安を解消していく。

Permalink | 記事への反応(0) | 19:34

ツイートシェア