開発ワークフローを、いつどう変えるか

2013/12/05

こんにちは、岡崎 @watermintです。
このエントリは GREE Advent Calendar 2013の記事です。この記事は5日目の記事です。

今日はGREE Tech Talk #04 スマートフォン時代のソフトウエアテストが弊社セミナールームで行われます。岡崎は「Jenkinsによるテスト自動化の会社への導入」というパネルディスカッションに参加させていただきます。パネルディスカッションの内容がどうなるかは会場の皆様からのご質問などによって変わっていくと思いますが、今日の記事では開発ワークフローについての考えを紹介します。

開発プロセスをなぜ変えるのか

開発プロセスを変えようとするモチベーションはいくつかあると思います。組織規模、ビジネスモデルなどによって多少諸条件は違うとしても大まかには次のような目標を達成することがモチベーションになるでしょう。

  • 開発メンバーが変わっても対応できる体制をつくりたい
  • より早く製品やサービスをリリースしたい
  • より安く製品やサービスをリリースしたい
  • より高い品質で製品やサービスをリリースしたい
  • より高いレベルの製品やサービスをリリースしたい

どの目標を選ぶにせよ、とにかく今よりは良くしたい、という気持ちが原動力になります。きっかけは、他社や業界動向、自社内での気づき、直近プロジェクトの反省からなどいろいろあると思います。また常に何か改善しようという取り組みをされている組織もあるでしょう。

開発プロセスに限りませんがこういった改善しようという試みの中で気をつけたいのは手段と目的が逆転しないようにする事です。このコントロールは非常に重要でしかも、難しい課題であることがほとんどです。特に「現状に不満があるから変えたい」といったモチベーションで開発プロセスを変え始めると、変更後のプロセスがもくろみ通りだったのかどうかすらわからない状況になります。

開発プロセスはすぐには変わらない

どんなに優れていてシンプルな開発プロセスであっても、開発メンバー全体に浸透するには一定の時間が必要です。これは慣れの問題に加えて、コミュニケーションのために一定の時間が必要だからです。

たとえばある開発チームに10人いるとします。開発プロセスを変更しようとディスカッションや検証を重ねて、新しいプロセスを作ったとしましょう。10人もいると、休暇などで新しいプロセスの説明会に参加できなかったり、資料をよく読まない人もいるでしょう。さらには10人ひとり一人の理解度もそれぞれ違いますから、その理解度の差分を埋めるためには更なるコミュニケーションが必要です。

実際の経験上でも10人の開発者に開発プロセスを説明して、納得してもらうだけでもかなりの労力を必要としました。これが20人、30人、100人と関係者が増えるに従ってさらに多くの労力を必要とします。感覚的には関係者の人数に対してO(n log n)程度のオーダーで労力が増加するかなと思っています。

開発プロセス改善を推進する人に、そういった労力が全く必要ないと考えていらっしゃりそうなケースを見聞きします。個人的に知る範囲において、性急な改革は大きな反感を買って延期や中断に追い込まれたり、「どうしても変えるんだ」と途中から目的と手段が逆転しているようなケースが多い印象があり、反例はほとんど記憶にありません。

前述の通り「より早くリリースする」とか目的がはっきりしていれば開発プロセス改善を推進する中でも新しく課題が見つかって軌道修正することが出来るのですが、目的と手段が逆転の罠にはまるといつまでも自体が改善せず開発プロセス自体もなかなか有機的に機能しなくなってしまいます。

時間的制約から逆算する

前述の経験から、開発プロセスを変更するにあたっては時間的制約から改善のスコープやマイルストーンを逆算して実施するのが良いと思っています。あまり細かな計算をして計画を立てた事は無いですが、小さな改善を試してみて、その施策が1週間程度でチーム内に浸透したとか、ある程度参考になる施策を事前に試しておく事がスコープやマイルストーンの決定に役立ちました。

全く試した事のないタイプの改善であっても、チームがどの程度新しい事に耳を傾けてくれるか、興味を持ってくれるかは普段のコミュニケーションがどの程度円滑であるかが重要な要素と思っています。

浸透までの時間はあまり定量的に計測していないので経験上の感覚値ですが、2〜3人のチームであれば、比較的大きな施策でも1〜2週間程度の短期間で新しい開発プロセスに移行できる印象があります。チームの規模が20〜30人とかあるいはもっと大きな単位になると説明会を何度か開いたり、ドキュメントも分かりやすいように何度もレビューを繰り返したり周到に準備していても、1〜2週間といった期間ではなかなかうまく浸透せず、4〜12週間程度の時間が必要と思っています。

こういった時間感覚をあらかじめもって計画する事で、スコープやマイルストーンを調整し、チームが混乱しないよう開発プロセスを変更する事ができるのではないかと思っています。これは新しいプロジェクトに新しい開発プロセスを導入する場合も同様です。

グリーでの開発プロセス変更の事例

岡崎がかかわった開発のうちいくつかを振り返りながら、開発プロセス変更のポイントをまとめてみます。

GREE SNSアプリ開発

この頃の開発は少人数でアプリ開発エンジニアが2〜4人、デザイナーが1〜2人、プロダクトマネージャー(ディレクター)が1人と少数精鋭のチーム構成でした。またフィーチャーフォンからスマートフォンへの移行時期でしたのでとにかくスピードを重視し、次々とリリースしていました。

エンジニアはプロダクトマネージャやデザイナーからの依頼などを受けて修正を行ったり、新機能を追加し、ビルドしたアプリのファイル(iOSなら.ipaファイル、Androidなら.apkファイルなど)をファイルサーバなどを経由して受け渡しし、バグ修正の確認などを行っていました。

この頃の開発プロセスは明らかに非効率的でしたが、一応運用として回っていたことと、リリース締め切りなどから考えるとなかなかプロセス改善に回せる時間がつくれず仕方なくこの方法を継続するというものでした。

この開発プロジェクトではまずアプリのビルド作業だけをとにかくJenkinsを使って自動化することで、ビルド作業の負荷軽減や属人化を防ぐことにしました。

  • 目的: ビルド作業の属人化排除、作業負荷軽減

Jenkinsでアプリをビルドできるように準備するのもリリース締め切りの合間の時間を使いながらでしたのでスムーズにとはいきませんでしたが、ビルドがうまく通るようになってからはチーム全員がこの開発プロセスに対して改善を提案したり自ら改善を加えるなどといったことができるようになりました。

これはごく簡単な例ですが、チームが小規模で、開発プロセス変更の目的や背景などもよく理解していたことから移行はスムーズでした。

GREE Platform国際化プロジェクト

このブログでも何度か紹介させていただきましたGREEの国際化プロジェクトでの開発プロセスについて振り返ります。

GREEの国際化プロジェクトには本当に多くの人がかかわっていました。同時にこのプロジェクトは多くのチーム、別々のオフィスとのやり取り、時差、切迫したリリーススケジュールなど多くの制約を抱えていました。これらの制約に対応すべく多くの開発プロセスやルールが日々に改善されていきました。

振り返るといってもプロジェクト自体が非常に大きく簡単には全体を総括することはできないので岡崎が関係した一部のみに焦点を当てて紹介します。

国際化ライブラリの開発プロセス

国際化ライブラリは多言語に対応するライブラリの他、地域ごとの法律や規約に従うためのルールを定めたものを扱うライブラリを国際化プロジェクトでは新規に作成しました。

このライブラリ開発プロジェクトの開発時の目標はとにかくリリース時期を遅らせないことでした。

このライブラリ開発では、実装難易度よりも、要件整理に多くの時間が必要でした。こういう機能が必要だろう、という想像のもとではいくつかAPIがデザインできました。実際のところそれをサービスとしてどのように提供するのか、まだグリーとしても決めていない時期でしたので、関係する多くのチームの中でイメージが固まるまでには多くの議論が必要でした。

リリースまでの時間は限られていましたし、このライブラリを使うという別のプロジェクトのリリース時期を考えると、ある程度固まっていない要件のもとでAPIをデザインをしていくことにしました。

このようにとりあえず作ってしまうというのはたいていの場合失敗します。特にこのような基盤ライブラリ開発においては、APIを慎重にデザインしないと手戻りでにっちもさっちも行かない状況になってしまいます。

この頃、各チームごとに2週間のスプリント計画を立て、2週間単位で定期的に全チームへの情報共有を行うという開発プロセスをとっていました。もちろん、個別に関連性の高いチーム間ではもっと頻繁に情報共有を行っていましたが、関連性の低いあるいは低いと思っていたチームに対しては意識のズレが少しずつ大きくなっていきました。たとえば下記の会話のように、

  • Q. ○○ということをしたいが実現はできるか?
  • A. △△を使えば実現はできる (が、いろいろ作り込まなければならない)

カッコ書きでかいたような制約の部分が、説明したつもりになっていたが説明していなかったり、説明したつもりでも理解まではされていなかったりと意識のズレが発生していきました。

このような意識のズレを生んでしまった原因はいくつかありますが、あまりにも実装スケジュールに焦りすぎてコミュニケーションに十分力を入れなかったことが大きいと思っています。このおかげでいくつものチームに大きな迷惑をかけてしまうことになりました。

目標がリリースを遅らせないことでしたが、結果的には自チームを中心にしかそれを見ることができていませんでした。

「意図と逆のことが起こる」場合、その背後にはかならず、『局所最適』の発想がある。
人材のサプライチェーンを正すにはより

この開発当時はなぜこうなったのかうまく状況を整理できていませんでしたが、振り返ってみれば上記に書かれている通り「意図と逆のこと」が起こっていて、自チームのために局所最適をしていた。ということなのだと思っています。

迷惑をかけてしまったにもかかわらず多くの方々が協力してくださりスケジュールを持ち直すことができたのは、本当にありがたかったのと、コミュニケーションの重要性をしみじみと感じた一件でもありました。

翻訳ワークフロー / 第一期

GREE Platformを多言語対応するにあたって、テキストをどのように翻訳してプログラムに組み込んでQAを行うか、一から開発ワークフローを組み立てる必要がありました。翻訳は単純に日本語や英語のテキストをエクセル等のスプレッドシートで管理して翻訳していくのではなく、翻訳の再利用性や品質担保のために翻訳メモリを利用します。

翻訳メモリは過去に翻訳した類似のテキストから類似度などを計算し、一部だけを再翻訳すればよいなどの支援をしてくれたり、語彙や表現を統一するようなワークフローを搭載しているものもあります。翻訳メモリは使えば使うほど翻訳テキストが資産として蓄積できるので、開発プロセスの中に組み込むことを重要な課題として設定しました。

この時点での開発プロセスを設計するときの目標は次のものでした

  • テキストをもれなく翻訳し、プログラムに組み込める
  • 翻訳メモリに翻訳資産を蓄積し、翻訳コストを低減する

ただ本格的なワークフローを管理するシステムを用件定義、設計、開発、リリースするような時間は全くありませんでした。

このため、まずはスプレッドシートを翻訳ワークフローの中心的な存在とすることにしました。ワークフローは下記のように、ほぼ既存のシステムを組み合わせることで実現しました。

  • スプレッドシートに新しい翻訳対象のテキストを書き込んでもらい、
  • JIRAを使ってテキスト翻訳状態やQAの管理を行い、
  • Jenkinsを使ってスプレッドシートと翻訳メモリの連携を行い、
  • プログラムへの組み込みデータもJenkinsで生成する

このときに気をつけたのは開発ワークフローの詳細なドキュメントし作成、使い方の説明会を何度か開催し、場合によっては直接使い方を操作する人の席までいってレクチャーするというところでした。その他サポートも可能な限り最優先で行うこととしました。

目的に設定した通り、テキストをもれなく翻訳するための作業標準化でもあり、翻訳コストを低減することでした。これは別システムを作る担当者からすれば直接的な目標ではありませんので、目標達成のために協力してもらっているという格好になりますので、こうしたサポートは当然のことでした。

この開発プロセスが全体に行き渡るまでの期間は、おおよそ8週間程度だったとおもいます。それでも、非常に多くの協力的なチーム／メンバーの支えによるもので、個人的な社会経験上でも規模・期間から考えるとこれほどスムースに開発プロセスが立ち上がるのは初めてのことだったと思います。

翻訳ワークフロー / 第二期

翻訳ワークフローは前述の通りなんとかうまく立ち上がりましたが時間が経過するにつれ、人手の作業によるミスや時間的なコストが気になり始めました。
そこで第一期で構築した翻訳ワークフローをシステム化することにしました。
第二期の目標は「人手の作業によるミスや時間的なコストの削減」です。

第二期の開発を行うに当たっては国際化ライブラリ開発の際に要件定義やコミュニケーションミスなどで多くの迷惑をかけてしまった反省から、しっかりとユースケースを定義して、スプリントごとに実際のシステムで運用テストをできるような開発プロセスとしました。

第二期は第一期ほどスケジュールがひっ迫していませんでした。また第二期開発のメンバーも少数精鋭でしたので、コミュニケーションを頻繁にとることが可能でした。

開発プロセスや使うツールも色々な方法やモノを試しながらにはなりました。システムの画面デザインもペーパープロトタイピングを行ったり、仕様策定の段階で多くのレビューを重ねるなど、開発プロセス自体を見直すための時間を確保することができました。

第二期開発はスムースに進みましたが、時間的な余裕と少数精鋭という開発プロセス見直しに有利な条件がそろっていたのが非常に大きかったように思います。

まとめ

開発プロセスを変えていくことは、非常に時間と労力のかかる仕事です。グリーは幸いにして、新しい物好きの文化も手伝ってこういった開発プロセス改善に皆協力的です。そういった文化的な土壌があったとしても、とくに時間的なプレッシャーによって開発プロセスを変えていこうというモチベーションが生まれにくかったり、変えようとしても目的と手段が逆転したり、局所最適のワナにはまってしまうなど簡単にはいかないものでした。

開発プロセスを変えていこうとするとき、少数精鋭／時間的余裕／現状とのかい離を少なくする、といったプロジェクト体制上の工夫をすることで、生産性の向上といった当初の目標を達成しやすくなります。GREE SNSアプリ開発プロジェクトや、翻訳ワークフロー第二期開発プロジェクトはこれに当てはまる例です。開発プロセスの変更に抵抗感のある組織においては、このように開発プロセス変更に好条件となるプロジェクトを探して適用し、徐々に組織的な対応力を高めていくのがよいでしょう。

上述プロジェクトの際、これは無理だなとか、不可能だなと思うことも多々ありました。特に時間的なプレッシャーはその思いを強くします。それでも、当初の目的を確認したり、少しでも工夫できることは何かないか。と探すことで、最初無理だと思っていたことが実現できるようになりました。もちろんそれまでには数ヶ月単位の時間が必要なこともあるのですが、あきらめずチャレンジすることが状況を変えていくのだと身にしみて感じました。

次は@yaakaitoさんです。