FLINTERS Engineer's Blog

FLINTERSのエンジニアによる技術ブログ

プロジェクトマネジメントのあれこれ

f:id:s_hayase:20150722153238j:plain

※この画像と本文は全く無関係です

どうも。@kakeyangです。


好きなドラゴンボールは四星球です。


今日は、いわゆるエンジニアブログではあまり見かけないテーマで書いてみようかなと思います。

プロジェクトマネジメントってなんだろうねって話です。


参考になるかどうかはわかりませんが、

僕が日頃感じていることをつらつらと書いてみたいと思います。


また、色々異論・反論あるとおもいますので、忌憚のない意見を頂ければと。


※この記事にある内容を実行すれば素晴らしいマネージャになれるなどという高尚なものではありません。

※だいたい10〜30人月程度のWebシステムの開発を想定しています。当然、対象となるプロダクトの性質に応じて事情は異なってきます。

背景

僕はここ1年くらい、自社サービス開発のマネジメントをさせてもらっているのですが、

日々勉強(反省?)の繰り返しです。


答えが無いからだと思います。


だからこそ、Tipsをため込んで日々PDCAサイクルをくるくると回すこと、

これこそが存在するかどうか分からない「正解」への近道と思い、

この記事を書いてみました。



Tipsを列挙してみます

結構、当たり前のことを書いてたりするかもしれませんが悪しからず。


スケジュールと成果物を明確に

「これを作ってね〜」だけでは担当者によって出てくるものは

まちまちで、そもそもプロジェクトとして必要なものが出てくるとは限りません。

「いつ」までに「なにを」必要とされるのかは明確にしておくのが優しいでしょう。


モジュールで担当者を分ける場合は誰がどこまでを実装するのかを明確に

後になって「あ、それ俺の担当だったんだ」といったことは誰しも経験があると思います。

僕も結構あったりします。



これは担当者の責任感云々の話ではなく、解釈だとか思い込みの要素が強いです。

なので、こういう状況に陥った作ってしまった場合はマネージャの責任です。

(そもそもマネージャは責任を取るのが仕事ですが)



弊社には「気づいたら、それが仕事」という行動規範があったりするのですが、

システム開発においてはそれでは「漏れ」が出てしまいますので、明確にしておきたいところです。

特に、モジュールとモジュールの境界はより明確にしておく必要があります。



インターフェースを明確にしておくことも非常に重要です。

例えば、クライアントサイドとサーバサイドで担当者を分けた場合、

データのやり取りをJSONでやるのであれば、そのフォーマットは早い段階で決めないと

開発は先に進みませんので。


コアになる技術は時間を割いてでも関係者全員理解する

直接関わりのない担当者でも、必ずその理解が必要になる時が来るものだからです。

また、いつでも誰でも手伝えるようにできるメリットもあります。


仕様書が正という状態を常に保持するスキームを作る

特にWEBサービスの開発では重要のはずです。

WEB界隈では周辺の環境変化が早すぎて、開発を進めていく過程で

「この機能をどうしても付けたい」とか「この機能は不要になった」といった

いわゆる仕様変更がどうしても出てくるからです。



極端な話、その場で口頭で決め事をしたりなんてこともよくあると思います。

言い換えれば、完全に仕様がFIXした状態で開発が進むケースはむしろ稀です。



そんな中、結局のところ何が「正」なのかはドキュメントを拠り所にするしかありません。

というわけで、面倒だろうがドキュメントの更新は「必須」です。

僕らは仕様変更があった場合は、

  • 仕様変更となった理由とその内容
  • 仕様書変更のタスク
をチケットとして管理していこうと試みています。

また、本番環境と開発用の両方のドキュメントをバージョン管理するのがベターです。


上流設計はリリース作業の簡潔さや既存サービスへの影響の小ささも考慮に入れる

バージョンアップ時の話です。



見落としがちですが、工数削減のために非常に重要です。

そしてそれは、上流設計で決まります。

この段階でリリース時のことを想像することってなかなか難しいので、

頭の片隅に入れておくだけでも違うと思います。



この記事を書いてみて

Tipsって言えるほどのノウハウ的なものが以下に自分の中で

たまってないかを痛感しました・・・orz

もっと頑張んないと。



あと、そもそもイケてるプロジェクトって何なんでしょうね。。。