エンジニアtype - エンジニアのシゴト人生を考えるWebマガジン

じげんが1年越しでスクラム開発体制へ移行できた理由とは。「開発ワークフロー改革」担当者が明かす5つのポイント

公開

 
株式会社じげん取締役の海野慧氏(中央)と、制作基盤チームの浅沼敬氏(左)、多田雅斗氏(右)

株式会社じげん取締役の海野慧氏(中央)と、制作基盤チームの浅沼敬氏(左)、多田雅斗氏(右)

開発スピードの向上や、さらなるサービスの成長を目指し、従来の開発体制や手法の見直しを検討する企業が増えている。

しかし、アジャイルやスクラムのような流行りの開発スタイルを取り入れようにも、現場にフィットさせるのには、さまざまな困難が伴うことが容易に想像がつく。サービスや組織が成熟していればいるほど、導入は一朝一夕にはいかないはずだ。

大手転職サイトをまとめて検索できる『転職EX』や賃貸物件情報ポータル『SMOCCA!-ex』などのライフメディアプラットフォームを運営する株式会社じげんは、「開発ワークフロー大改革プロジェクト」と銘打ち、2013年4月からの1年で、スクラム開発やテスト工程を順次導入。2006年の創業以来続く開発体制を、ハイスピードで刷新することに成功した。

じげんは2014年現在、新規事業も合わせて20以上の事業を展開しているが、開発エンジニアをはじめとする各職種は運営サイトごとにチームに分かれるため、ナレッジがチームを越えて共有されていかないという問題を抱えていた。今回の大改革は、ナレッジを開発スタッフ全体で共有し、収益化までを見据えた事業を生み出せる体制を実現するべく断行したものだ。

改革は、以下のステップで進められた。

【1】属人化するナレッジ、プロセスに対する危機意識を共有(2013年4月)
【2】GitHub導入による開発の見える化(4月)
【3】スクラム開発の試験導入(8月~)
【4】「テスト」の普及(12月~)
【5】基盤チームの発足(2014年4月~)

また、具体的に導入した技術は下記の通り。

・GitHub+pull request builder
・Chef+serverspec+Vagrant
・Jenkins
・RSpec
・poltergeist+Turnip (End-to-End test)
・Rendezvous

多くの企業が構想しながら、あるいは試みながらも難航する開発体制の刷新を、じげんはいかにして実現できたのか。取締役の海野慧氏、現場でプロジェクトの中心を担ったエンジニアである浅沼敬氏、多田雅斗氏に、改革の各フェーズで直面した困難と、その解決策を聞いた。

【危機意識共有時のポイント】

GitHub導入を「旗印」にキックオフミーティングを実施し、不退転の覚悟を示す

GitHub導入を「旗印」に,、ワークフローの見直しの必要性を訴えるプレゼンを行った浅沼氏

GitHub導入を「旗印」に,、ワークフローの見直しの必要性を訴えるプレゼンを行った浅沼氏

じげんの開発現場からは、これまでも何度となく、開発体制見直しの必要性を叫ぶ声が上がっていた。だが、改革が実行に移されることはついになく、毎回立ち消えになっていたという。

今回のプロジェクトが計画倒れに終わらずに実行に移された裏には、先導役だった浅沼氏がプレゼン前に行った、ある根回しがあった。

「プレゼンしたその日からGitHubを使えるように、事前の導入を経営陣に直訴しました。今回こそは横のつながりを強め、ナレッジの共有を推進するんだという強い覚悟を示すためです」(浅沼氏)

開発現場ではこれまでにも、ナレッジの共有を目的としてフリーソフトが使われることはあった。だが、社内ツールとしてのGitHubの正式導入は、経営陣の不退転の決意を示すという意味で、それらとは一線を画する。GitHub導入は、いわば改革の「旗印」というわけだ。

2013年4月。じげんの大改革プロジェクトはこうして始まった。

【スクラム開発とテスト工程導入のポイント1】

新規サービスに先行導入。担当者の配置換えでノウハウを漸次浸透

「次々と新しい事業が立ち上がるじげんの環境が、改革推進にプラスに働いた」と振り返る海野氏

「次々と新しい事業が立ち上がるじげんの環境が、改革推進にプラスに働いた」と振り返る海野氏

だが、スクラム開発やテスト工程の導入は、浅沼氏が想像していた以上の困難を伴った。

「トップダウンの大号令で、もっと浸透するものだと思っていました。でも、サービスごとに違う状況や、人的、技術的リソースにはどうしても配慮せざるを得ない。足並みはそろいませんでした。RSpecテストを書いたことがある人がいないチームに、書いてと言っても無理な話ですよね」(浅沼氏)

そこで、一斉導入は断念し、新規で立ち上がる事業をモデルプロジェクトとして、先行導入する方針に転換した。

比較的リスクの小さい新規サービスで実績を作るとともに、そこで経験を積んだ担当者が既存のサービスの開発チームへと異動することで、約半年の時間をかけて、漸次ノウハウを拡散していった。

「大規模なサービスほどステークホルダーが多く、改革に腰が重くなるのは否めません。小さな事業が次々と立ち上がるじげんの環境は、改革を浸透させるのにプラスに働いた面があったと思います」(海野氏)

【スクラム開発とテスト工程導入のポイント2】

ユニットテスト原理主義からEnd-to-Endの現実路線へ方針転換

改革の実行部隊を務めた多田氏。「最大より最適を取る、発想の転換がポイントだった」

改革の実行部隊を務めた多田氏。「最大より最適を取る、発想の転換がポイントだった」

理想と現実の間でいかに折り合いをつけるかも、新しい開発フローを定着させる上で、大切なポイントになる。じげんの今回の改革の場合、テスト工程の導入は、その最たる例だ。

「当初はユニットテストを導入しようとしましたが、成長中のサービスは新規の開発に忙しくて、テスト工程に割くリソースがない。コスト的に見ても非現実的な面があり、なかなか受け入れられませんでした」(浅沼氏)

そこで、ユニットテストの導入は一部の新規プロジェクトを除いていったん凍結。ロジックが合っているかではなく、ちゃんとページが表示されるかを外から確認する、End-to-Endのテストに切り替えた。

実行部隊のリーダーだった多田氏は、当時の心境を次のように振り返る。

「当初は僕もユニットテスト原理主義的な考え方でしたが、途中で『最大より最適を取る』発想に切り替えました。カバレッジ率90%以上なんてエンジニアにとっては憧れの世界ですが、20個中5個のサービスだけで90%を超えているより、20個すべてで50%を超えている方が良いと割り切りました」

コード規約やスクラム開発についても同様で、時間を追うごとに、現場の実状に合わせた柔軟な運用へと移行していった。

【スクラム開発とテスト工程導入のポイント3】

非開発陣を含めた全社的な人事の大シャッフルでナレッジを拡散

こうした流れをいっそう加速させたのが、2013年末に行われた人事の大シャッフルだ。非開発陣を含めた50人規模の全社的な大異動により、ノウハウの拡散を図った。

「じげんはサービスの幅が広い。転職サイトと不動産業では、求められる知識が大きく違います。今回の開発フローの見直しはもともと、収益化までを見据えて事業全体を考えられる人材を育成するのが目的。ノウハウの拡散はもちろんですが、個人の幅を広げてもらうことも狙って、シャッフルを行いました」(海野氏)

そうは言っても、運用といくつもの機能開発が同時に進む主力サービスに、新しい開発フローを浸透させるのは容易なことではない。事業部のトップは目に見える利益貢献度を考えざるを得ず、短期的な成果が見えにくい改革には二の足を踏みがちだ。会社としても、ノウハウの拡散を狙ってシャッフルをしようにも、そのたびにキャッチアップに1カ月を要するようでは、経営に支障が出てしまう。

そこで持ち上がったのが、後の「制作基盤チーム」につながる発想だった。モデルプロジェクトなどで改革の最前線に立ってきた多田氏らが、事業部に所属することなく、外から開発フローの普及をサポートする体制を整えた。

【制作基盤チーム立ち上げのポイント】

あえてCTOを置かないことで広くアイデアを吸い上げるハブに

各チームから広くアイデアを吸い上げ、全体に共有する「制作基盤チーム」が、新生「じげん」で果たす役割は大きい

各チームから広くアイデアを吸い上げ、全体に共有する「制作基盤チーム」が、新生「じげん」で果たす役割は大きい

前述の多田氏らが担っていた役割を拡大し、開発フローの整備・普及から、採用広報や研修の実施まで、エンジニアユニットとして全体で取り組むべき課題全般の解決を目的に、2014年4月に「制作基盤チーム」が立ち上げられた。メンバーにはエンジニアに加え、デザイナーも名を連ねた。

基盤チームは、あえてCTOやユニットリーダーを置かない形を取る。その理由を、海野氏は次のように語る。

「CTO室のような形を取ると、CTOが考えたことしか落とせなくなり、結局個人に依存してしまう。それでは組織として限界があると思います。制作基盤チームは意思決定を行うのではなく、広くアイデアを吸い上げるハブの役割を果たします」

もちろん、組織を動かすには時に、トップダウンの決断が必要なこともある。それは開発フロー改革の立ち上げ時などにも表れている。基盤チームは、経営陣からのトップダウンと、各開発チームからのボトムアップを、バランスよく取り入れる、重要な役割を任されている。

多様に進化するスクラム GitHubは全社的なコミュニケーションの軸に

GitHubはいまや、非開発職も巻き込んだ全社的なコミュニケーションの軸となっている

GitHubはいまや、非開発職も巻き込んだ全社的なコミュニケーションの軸となっている

当初、開発陣の間での導入を目指していたスクラムは、全社的な人事のシャッフルなどを経て、現在では採用担当などの非開発職の間にまで広がっているという。

「やっていくうちに、スクラムとは方法論ではなく、チームで同じ方向性を共有するというスタンスのことだと気付きました。そう考えると、手法自体はすべてのチームが同じものである必要はなく、むしろチームごとにいい所どりで活用することが強みにもなります。多様に進化したナレッジを月1の全体ミーティングなどで共有することで、チーム間の相互作用でさらにブラッシュアップされていくという好循環が生まれています」(多田氏)

1年前は何も張り出されていなかったオフィスの壁が、現在では無数の付箋やメモ書きで埋め尽くされている。各チームがアイデアを積極的に披露し、壁の取り合いまで発生するオープンな風土が生まれているという。

開発ワークフロー改革の「旗印」として導入されたGitHubは、現在ではマーケッターや営業までを含めた、社内全体のコミュニケーションの軸になっており、GitHubを導入したプロジェクトのデザイナーは、「これがなかったら、このチームは炎上していたと思う」と話しているという。

改革は道半ばだが、先導していた当人たちの予想を超えた効果ももたらしているようだ。

取材・文/鈴木陸夫(編集部) 撮影/竹井俊晴