unoh.github.com by unoh

こんにちは satoです。

ウノウはサーバ構築、設計開発から運用まですべてプログラマが行うのですが、
以前100人以上が関わるプロジェクトの設計を主任でやらせていただいたことがありました。
開発規模が大きくなると、リクルーティングや開発効率の点から、このような体制になることも
多いかと思います。

設計者やプログラマ、運用者がすべて同じ会社の人間の場合の話なので、参考になるかは
わかりませんがそのときに感じたことを書きたいと思います。

・一番大事なのはユースケース
　
　大規模なサイトでは「設計上一番美しい設計が運営上最良ではない」ことが
　多々あります。原因には「組織の力関係、歴史」や「運用者のITリテラシー」
　など設計者一人では解決できない問題も多々あります。
　
　用件の分析などをする場合は必ず、関わる人の職場を自分の目で見ること、
　関わるひとと実際話してみることが大切だと思います。

　特に、新機能がリリースされる前には運用や開発の責任者に相談（根回し）を
　しておいたほうがスムーズにリリースできることが多いです。

・仕様書は更新できる分だけ作り最新に保つ
　
　「更新されない仕様書は悪」です。他のサイトからこちらのインターフェースを使用する際に、
　更新されていない仕様書を参考にして作ってしまう可能性がありますが、こちらは
　全く把握できません。

　仕様書は必要かつ自分が更新できる分だけ作成し、必ず更新日、更新者、更新履歴
　をつけるようにし、　仕様が更新されるたびに最新の状態に保ち、プロジェクトの
　MLなどで告知しましょう。

・設計者とプログラマの関係
　
　設計書を実際のコードに起こすのはプログラマなのですが、プログラマと
　設計者の間で、上流、下流という概念は捨てるべきだと思います。

　プログラマは設計者の大きな見方になりうる（唯一の？）存在で
　レビューをすり抜けた設計書の穴を見つけてくれるのもプログラマであることが多いです。
　実装レベルの話になると、プログラマのほうがよく知っていることも
　多々ありますのでプログラマに対して謙虚に接して、設計に関してもよく話し合いましょう。

　また経験豊富なプログラマと新人プログラマが担当する箇所があらかじめわかっている場合には
　プログラマのレベルに応じて設計の自由度などを変えたりすることも有効だと思います。

大人数のプロジェクトになると技術力よりむしろ人間力が試される場面が多く、僕自身その
役目をきちんと果たせていたとは到底思えないのですが、これからそのような場面に
直面する方の参考になればと思います。