 |
「開発プロセスが分からない人が多くいた。全社で共通に使えるドキュメントのフォーマットもない。社内で開発の現場を調査すると，そんな実態が浮かび上がった」（技術推進本部 技術リーダー 小賀昌法氏）。
業容が急拡大し，人材の採用を積極的に続けているヤフーでは，開発担当者によってやり方が異なるという弊害が出てきていた。そうした状況を改善すべく，2005年7月に標準化委員会を設置した。
それまでヤフーでは，Web系のサービスをリリースするまでの，承認やチェックのプロセスは定められていた。しかし，そこで承認したりチェックしたりする成果物の作り方を定めた標準がなかった。標準化委員会の目的は，それらの標準を作ることにある。
委員会は当初，システム開発の実装フェーズを想定して立ち上げた。ところが議論を進めていくうちに「要求定義フェーズを抜きに，実効性のあるものは作れないという話になった。そこで，社内で企画や設計を担当する企画部門や制作部門に加わってもらった」（小賀氏）という。
Yahoo!ゲームのシステム開発を担当する野口伸吾氏（ライフスタイル事業部 開発部 技術）は，「他のチームの要求定義の進め方を知らない。ノウハウを学べる面もあると思うので，委員会には期待を持った」と語る。Yahoo!ゲームは5年間で5人の担当者が入れ替わったので，システムの作り方やドキュメントのフォーマットが少しずつ変わってきていた。メンテナンス性が悪化してきたこともあり，再構築に踏み切ったところだった。
周りの環境により標準は異なる
委員会を始めてみると意外なことが分かった。「苦労してきた人たちの経験に裏打ちされたノウハウを期待したのだが，昔ながらのノウハウがヤフーの中では必ずしも生きない場面がある」（小賀氏）ということである。
システムを取り巻く事情は企業によって異なる。ヤフーの場合は，大量のアクセスに耐えられるシステムである必要がある。そうした問題を要求定義の段階でどのように解決していけばよいかは，特に（ヤフーの前の職場で）社内システムの開発に長く携わってきた人たちには分からないのである。
委員会では三つの観点から検討を重ねた。まず，作業はどのようなフェーズに分解すればよいのか。次に，どういう役割があり得るのか。そして，フェーズと役割ごとにどんなタスクを実施すればよいのか。それらを踏まえて，マトリックスを作った。
途中からメンバーに加わった秀誠氏（ライフスタイル事業部 企画部 企画2 チームリーダー）は，「とても良い取り組みだと思ったが，一律にやり方を決めてしまうと，開発のスピード感が損なわれる恐れがある。その点が気になった」と語る。おもしろいサービスやワクワクするサービスは，多少完成度が低くてもすぐに試してみたいものだ。だが，プロセスや成果物をガチガチに作ることで，そうしたサービスは作りにくくなるかもしれない，という懸念である。
このような声を反映する形で，標準プロセスは強制ではなく，カスタマイズして使えるものとなった。やり方が分からない人やうまくいっていない人への指針として使ってもらう。
バージョン1は2006年7月に社内Webサイトで公開された。9月には利用のためのガイドラインが作成され，現場への展開が始まった。
イラスト：ミオササノッチ
