ECナビの子会社のuniameでソーシャルゲームの開発をしている野口(@ntakaaki)と申します。

このBlogを読んでいる方はシステム開発に携わっている方が多いかと思います。
皆さんの会社や所属組織ではユーザーから上がってくる
システムへの新機能の追加や修正をどのように管理されているでしょうか。

最近ではRedmineやTracのようなシステムでチケットを
発行して管理されてるところが多いかと思いますが
ECナビ創業当時の2000年前後には課題管理にツールを使うといった話も
ネットで見かけることも少なかったかと思います。
 
ECナビでは会社の成長とともに膨らむシステムへの追加や修正案件を
どう管理していくか、その過程でいくつかの方法が試されてきましたので
その歴史の一端をご紹介させていただこうと思います。
システム化以前
 
会社創業期の頃は口頭やメールなどで直接エンジニアやデザイナに
修正の依頼が飛んでいきます。
 
この頃は、リーダー格の人が発生した案件をファイルサーバー上の
ExcelやMS Projectで共有というのが多いかと思いますが
  • 書いたはずの内容を他の人に上書きされてしまう
  • 履歴管理、変更管理がしにくい
  • 人によってフォーマットが違ってって読み合わせが大変
などでやはり破綻します。
 
ルールを作る事で、上記の問題は解決できるでしょうが厳密にルールを
周知・徹底させないとなかなかうまく行かないでしょうし、
人や組織がかなりの頻度で変わっていく状態だと 
そのコストも馬鹿になりません。 
それでもこの仕組みは5,60人くらいまでややってたかと思います。

初代管理システム


いい加減どうにかしないとという事でBugTrackシステムで管理するのが
良いんじゃないかという話が上がりました。
当時存在していたメジャーなBugtrackシステムはBugzillaかと思いますが
インストールして試してみたものの、いまいち使いにくいし英語だし
なんだか項目いっぱいあってよくわからないし、という事で自作する事に
なりました。
これが初代の案件管理システムです。
機能としては
  • 依頼内容を入力するフォーム
  • 受け取った依頼を一覧する画面
  • 依頼内容を修正する画面
  • 依頼ごとの掲示板
と、あっさりしたものですが当時としてはこれで十分助かりました。
依頼を受け取った担当部署のリーダーは管理画面で担当者のアサインを行い
アサインされた担当者は依頼毎の掲示板で依頼者とやり取りする事で
依頼の過程を記録に残せて共有などが図れるようになりました。
 
依頼内容もここで一元管理化出来たので、誰が何をやっているのかの
把握がそれまでに比べてずいぶんと楽になったと記憶してます。
 
二代目管理システム

これで大丈夫となったはずなんですが、また問題が持ち上がります。
それは大規模な案件対応とワークフローをつけろという偉い人たちからの要求です。
大抵の細かい依頼内容は頼んだ本人と作業する人間の間で完結しますが
サイトを丸ごと1つ作るような規模になってしまうとそうも行きません。
 
依頼を細かく出すのかそれとも1つの依頼で関係者全員が
そこでやり取りするのかどちらが良いのかという話になってしまいました。
そこでプロジェクト管理システムを作ろうという事になりました。
主な機能は下記になります。
  • プロジェクトの関係者を複数登録でき変更を通知できる。
  • プロジェクト内で異なるトピックごとに掲示板が作れる。
  • ログインすると自分の出した依頼、担当している依頼、自部署あての依頼がわかる。
  • プロジェクトの検索条件を指定でき、且つパーマリンクで保存できる。
  • 小規模案件用に簡易な入力フォームとワークフローも備える。
などの結構便利な作りになっています。
これが出来てからは自分のマイページに出てくる案件をチェックすることで
遅れや問題の有りそうなところの発見がずいぶん早くできるようになりました。
 
ちなみにシステム名をCPO(ChiefProjectOfficer)といいます。
ただ、こちらのシステムは現在のECナビのような複数の部署や子会社が
発生する事を想定したものではなく現在の会社の実態に余りあっていないため
最近では一部でしか使われてないです。

現在のシステム

その後エンジニアを中心にTracが使いたいという声が上がってきて一時Tracが
大量に立ち上がった事もありますが、最近主に使われているのはRedmineです。
Redmineを使うようになったのは、昨年の夏ごろからです。
 
当時私が所属していた部署では細かい依頼が発生する事が多くそれをCPOで
管理してましたが、CPOの入力の手間や案件のやり取りの情報の制御が手間というの
が課題となっていました。

それらの課題を解決すべくRedmineを導入しました。
その後、新規に立ち上がった部署などを中心に使われるようになり
現在はユーザー数が187名、プロジェクト数が123個になってました。

ここまでになってしまうと、一人で管理できるわけもなく、かといって全員を
管理者にして好き勝手にプロジェクトを立てくださいというわけに行かないので
部署毎にRedmine管理者を立ててもらうようにしています。

新規のプロジェクトの設置や新人の追加、トラッカーやカスタムフィールドの追加などは
各部署のRedmine管理者の判断でやってもらい、まれに全体に影響しそうな変更や
例外事項の共有を行うといった形で運営上特に問題なくやれてるかと思います。
 
プロジェクトはTopの直下に部署毎のプロジェクトを設置し、部署毎にもってるシステムや
案件をその下にぶら下げていくような形をとっています。
またアカウント管理も社内のLDAPサーバーと連携するようになってます。
 
Redmineはシステムとしては1つですが
  • プロジェクトの単位でメンバーやチケットを管理できる
  • 管理画面だけでカスタムフィールドや独自のトラッカーを追加できる
  • カスタマイズしても影響が全プロジェクトに波及しない等(一部波及してしまうものも有りますが)
分割統治的な仕組みが非常に良いところだと個人的には思ってます。

現在使用しているRedmineは0.8系なので、どこかのタイミングで1.0系に
移行できたらと思っています。

というわけで、ECナビの案件管理の歴史を振り返ってみました。

Redmine