プロジェクト運営スタイルのむずかしさを考える

プロジェクト運営スタイルのむずかしさ

最近感じるのは、プロジェクトの運営スタイルがいろいろあって難しいということ。
１、小規模システム、プロト開発、メンバーが十分コミュニケーションがとれる状況
２、大規模開発、超絶品質が求められ、メンバー間のコミュニケーションが簡単じゃないような状況
３、サービスをβ版として開発、とにかく柔軟性とスピードが求められる。
それぞれ採用するプロジェクトマネージメントが違いますよね。たぶん。

２は、ＰＩＭＢＯＫみたいなＳＥ業界ではやりのきっちりとした管理が必要かもしれない。
アジャイルでＬＬな開発は、１とか３に向いているかもしれない。
特に、最近は、Railsとかスクリプト言語、フレームワークの充実、ＯＳＳやらでライブラリの充実、さらに使い方までネットに情報がころがってるということで、
システム開発のスピードはアップしていて、昔より少人数で開発できちゃう範囲が広がっている。
しかも、人数がすくないとしがらみが少ないので柔軟性が高まるし、コミュニケーション効率も高いので、いろんなリスクを減らしつつクールなのものができる可能性が高い。
もちろん、その人数で開発できるものという絶対的な制限があるし、どうしても品質チェックのリソースが足りなくなってしまう。
なので、売り切りシステムを出すのは結構怖い。バグ対応で全国行脚するはめになるから。
というわけで、少人数だとサービスとして出すのは非常にリーズナブル。

逆に、基幹系システムとか売り切りシステムだとか、規模の大きいシステムになると、いくらチームを適切に分けても、チーム間のコミュニケーションやらなんやらが一番のネックになってしまうのはしょうがない。というわけで、きっちり管理するプロセスが必要になってくるわけです。とはいえ、なんだかきっちり管理されていると、モチベーションの維持はそれなりに手段が必要だと思う。自分のやりたいこととマッチしているうちはいいけど、どうしても分業が進むと楽しくない仕事に割り当てられる人がでてくるのは否めない。

枠はきっちり管理するけど、それぞれのサブチームのなかみはＬＬな感じでうまくやっていけたらいいんだろうけどな。
なんかそんなうまい話はないだろか？

あと、思ったけど研究所だと、比較的少人数でプロト開発ってパターンがおおい。
うまく進むと、そこから、
・自分たちで大規模に商品レベルのソフトを開発する場合。
・自分たちはコンサルとか、小さなモジュールを担当して、メインは事業部が作る場合。
・自分たちで、小さな商品レベルのものを作る場合。
・自分たちでSaaSみたいなサービスをつくる場合（たぶん、そのうち）
に分岐するわけだけど、まず、それぞれに合ったプロジェクトマネージメントを考える必要がある。
次に、そのマネージメント方法がちゃんとメンバーに浸透しないといけない。
みんながいろんな種類のプロジェクト管理の経験があるわけじゃないし、とくに研究所の場合は、大規模開発とかなかなか機会がない。
そうなると、慣れないもんだから、いろいろうまくいかない可能性があって、だからっていい方法があるわけじゃないからがんばるしかない。
大事なのは、プロジェクトの進め方はいろいろあって、過去の経験がすべてに適用できるわけじゃないってことを知っていることなのかもしれない。
フレームワークの進化とか、ハードの性能アップとか、ブロードバンド化とか、どんどん変わってるってことを認識しないといけないなぁと思う。
今は、経験が浅いうちは、いろんな変化への感度が高くいられるけど、これから先も忘れずにやっていけるのかがちょっと心配。
技術の前線でプログラムを書いたりシステムを作ったりしてれば、その辺の感覚が分かるかもしれないけど、そういう機会が少なくなっていた時に忘れたり、ずれたりしちゃいそうだ。
やっぱり、少しでも技術に触れることを心掛けないといけないなと思う。なんか比較的変化に強いコアがあればいいんだけど、どちらかというとインテグレーションとかプラットフォームよりなことをしているから、置いて行かれるわけにはいかないよなぁ。