「HOME’S」の超高速改善プロセスの秘密とは？！大規模サービスにおけるプロジェクト管理の最前線を丸ごと聞いてきた
物件数No.1の不動産・住宅情報サイトHOME’S。
この大規模サービスを運営する株式会社ネクストは、カイゼンプロセスが超高速だとプロマネ界隈でよく話題に上がります。
その謎に迫るべく、HOME’Sの中の人にプロジェクトの進め方についてインタビューしてきました。
インタビューしたのは、デバイスソリューションユニット デザイナーの小林武蔵さん
小林さんは、2009年に新卒で株式会社ネクストに入社。
現在まで一貫してHOME’Sのデザイナーとして活躍してきました。
入社当時はPCサイトのデザインから始まり、ガラケーサイト、スマホサイトのカイゼンやフルリニューアルに携わったのち、メールマーケティングでHTMLメールのデザインをゴリゴリ作る期間を経て、2014年からiOS、Androidアプリを管轄するスマートデバイス部門に異動。
現在はAndroidアプリをメインに日々のカイゼンプロジェクトに取り組んでいます。
左：coach4pm 千歳紘史（インタビュワー）／右：株式会社ネクスト 小林武蔵氏
Q. いきなり本題です。何でそんなにカイゼンが速いんですか？
元々ネクストは開発の品質と速度に対する社内外からの評価が高い会社でしたが、それでも色々な課題がありました。
その中で僕が所属するデバイスソリューションユニットは、特に高速な開発スピードを誇っています。
その秘密は、ウォーターフォール×アジャイルのハイブリッド型開発プロセスです。
最初はウォーターフォール型、次にアジャイル開発、そしてプロダクトデザインスプリント（Product Design Sprint）を試して最終的に型にはまったのがこの形です。
僕たちの組織にとてもフィットしていて、一気にスピードが上がりました。
Q. 最初はウォーターフォール型だったんですね。どんな点が課題だったんですか？
僕のチームはプランナー、デザイナー、エンジニアが全員いる、いわゆるCFT（クロスファンクナルチーム）です。
このメンバー構成でウォーターフォール型の開発プロセスを取ると、どうしてもデザイナーとエンジニアの待ち状態ができてしまいます。
複数の施策の実施タイミングをうまく重ねることで緩和できる部分もありますが、それでも稼働のロスがかなり発生してしまっていたんです。
ウォーターフォール型の利点である手戻りの少なさは確かにあったのですが、それよりも待ち時間の問題が大きいと考えていました。
だからカイゼンをさらに高速化するには、とにかく稼働ロスをなくさなければと考えて、次にアジャイル開発を取り入れてみました。
Q. アジャイル開発なら、待ち時間の問題は解決しそうですね。
いえ、実は解決しなかったんです。
HOME’Sのような大規模サービスの場合、関係各部との仕様調整、数字的裏付け、他デバイスや関連サイトへの影響の確認など、仕様凍結するために行わなければいけないタスクが膨大にあります。
これらのタスクはプランナーが担うのですが、1～2週間のスプリントで開発を進めながらこれらの調整を行うのは限界がありました。
プランナーの仕様凍結が完了しないと最終的なデザイン・実装も完了できないため、結局足並みを揃える必要があります。
そうするとプランナーがボトルネックになってしまうので、デザイナー、エンジニアの待ち時間を減らすことはできませんでした。
Q. アジャイルサムライの教科書的に言えば、デザイナーやエンジニアがプランナーのタスクをカバーすべしとなりますが、それではダメ？
人員リソースの偏りや、個々のスキル不足の問題がありました。
デザイナーやエンジニアがそれぞれの立場からアドバイスはできても、企画面の深い話まで入り込むことができません。
メンバーが固定的で、プロダクトさえ成長すればいいのであれば、四苦八苦しながらもデザイナーやエンジニアが実装以外のタスクをこなし、徐々にスキルを身に付けていけばよいかもしれません。
みんながゼネラリストになろう！という発想です。
でも現実的には、メンバーそれぞれのキャリアプランがあり、それぞれの専門性を高めたい人もいますし、常にいまのメンバーのリソースを確保しつづけることも難しいです。
だから、デザイナーやエンジニアがプランナーの職務を補うのではなく、開発プロセスを改善して課題解決を図ろうと、次はプロダクトデザインスプリントにチャレンジしました。
Q. プロダクトデザインスプリント・・・？
プロダクトデザインスプリントは、Google Venturesが提唱している開発プロセスで、Design ThinkingやIDEOのメソッドをGoogle Venturesがスタートアップ向けに最適化したものです。
この方法論も考え方としてはアジャイル開発のように「創りながら考える」ので、結論としてはHOME’Sには馴染みませんでした。
ただ、Google社が主催しているデザインスプリントのワークショップなどにも参加して勉強する中で、プロダクトを中心に考えることの重要性や、創りながら考えることの重要性を感じ、その部分は取り入れなければと強く感じました。
だから、創りながら考えるスタイルを取り入れつつ、プランナーがボトルネックにならないようにするためにはどうしたらいいだろう？と考えて生まれたのが、冒頭でお伝えしたウォーターフォール×アジャイルのハイブリッド型開発プロセスなんです。
Q. ハイブリッドって何かカッコイイですね。2つの開発手法のどんな要素を組み合わせたんですか？
プランナーはウォーターフォールで作業を進め、デザイナーとエンジニアはアジャイルで開発を進めます。
図で表すとこんな感じです↓
プランナーが施策を起案するところがすべてのスタートになります。
他部署調整や数字的な裏取りをして仕様を凍結する作業をプランナーが進めている最中に、デザイナーとエンジニアはプロトタイプを作り始めてしまいます。
チームは同じオフィスの同じ島に座っていますので、プランナー、デザイナー、エンジニアが常時コミュニケーションをとりながら、仕様が固まるにつれてプロトタイプに反映していきます。内製のいいところですね！
そうすると、すべての調整が完了して仕様が凍結されるときには、大枠のデザインとUI側の実装が終わっている状態（いわゆるホットモック）になります。
この段階が、僕のチームでは「キックオフミーティング」になります。
すべての仕様が固まっているので、あとは正式にリリースするための本実装とテストを行うのみ。
そこから一気に作って、施策規模によってスケジュールにバラつきはありますが平均1週間から2週間程度で作業完了となります。
現在はプランナー1名、デザイン1名、エンジニア4名のチームで、常時4本程度の施策を進めている状態です。
Q. キックオフのときには仕様が確定しているって素敵すぎますね！このプロセスを導入する上でのポイントなどはありますか？
プロトタイピングの段階では当然手戻りは発生しますし、社内の承認が通る前に作り始めるので最悪お蔵入りになるリスクがあることをメンバー全員で受け入れるのが最大のポイントだと思います。
手戻りやお蔵入りのリスクと引き換えに、稼働ロスをなくし、実際動くものをつくることで実装期間を確保し、納得できる品質のモノにまで仕上げているんです。
Q. 最悪お蔵入り・・・。メンバーのモチベーション下がりませんか？
実はそこは逆で、メンバーのモチベーションが高く保てるようになったんです。
これまではプランナーが考えたものを実装メンバーが実装する構図だったので、どうしても実装メンバーの当事者意識が高まり切らず、特に期間が長いプロジェクトではモチベーションが維持できない傾向がありました。
施策の狙いや仕様に納得はしていても、そこに自分の意見は反映されていないからですね。
ハイブリッド型に移行すると、プロトタイピング期間にプランナー、デザイナー、エンジニアの3職種のコミュニケーションが非常に活発になります。
実装メンバーが企画の意図を汲み取り、同時並行で進めていくことで当事者意識が高まり、比例してモチベーションも高まります。
そもそも前提として、手戻りやお蔵入りリスクを受け入れるのがメンバー全員の共通認識ですから、仕様が固まる前に作り始めたものがポシャったとしてもモチベーションに与える影響は軽微です。
むしろお蔵入りというより、持ち球が増えたという認識でいます。
いまは難しくても、いつかリリースできるときにそこからコンテニューできますからね！
Q. そんな素敵なプロセスを実現しているプロジェクト管理ツールがあれば教えていただけますか？
ツールとしてはChatWork、Confluence 、JIRAの3つを併用しています。
企画が起案されるたらチャットワークの部屋を作ってコミュニケーションを開始します。
日常のコミュニケーションはすべてこの部屋で行っています。
ドキュメント管理に使用しているのが、Atlassian社が提供しているConfluence（コンフルエンス）です。
議事録や仕様書などのドキュメント類はすべてコンフルエンス上に格納する運用をしています。
ただ、数字の計算が苦手なツールなので、まだまだエクセルを使うことも多いです。
タスク管理はJIRAです。
コンフルエンスと同じAtlassian社が提供しているものですね。
作業ごとにチケットを発行してチケット上でステータス管理や実装の記録などを行うような、よくあるチケット開発をしています。
過去には影舞やRedmineなどを使っていたこともありました。
RedmineよりJIRAのほうが高機能なのだとは思うのですが、正直なところRedmine以上の使い方は残念ながらできていません。
ただ、それでもJIRAを使うのは、コンフルエンスとの相性がとても良いためです。
JIRA側でコンフルエンスへのURLを記述すると自動的に相互リンクが表示されるなど、痒いところに手が届く感じです。
1つ1つを取り上げると大したことではないのですが、毎日何度も発生する作業が簡略化されるのは作業するのにとても気持ちがいいです。
JIRAもコンフルエンスもマクロで自由度の高いカスタマイズができるので、今後さらに組織にフィットした運用ができるよう運用改善を進めたいと思っています。
Q. とても勉強になりました、ありがとうございます。最後に、プロジェクトマネジメントに悩む読者に一言お願いします！
今日お話しした開発プロセスやプロジェクトマネジメント手法がうまくいっているのは、HOME’Sの文化や組織体制にうまくフィットしているからです。
つまり、ネクスト以外の会社でこれをそのまま適用しようとしても必ずしもうまくいかないはずです。
それはスクラム開発であれ、エクストリームプログラミングであれ同じこと。
本に書いてあったり、誰かが教えてくれたりした開発プロセスをそのまま適用しようとするのではなく、 僕たちがこのスタイルにたどり着いたように「プロセスに対してのPDCA」を回していく思想を皆さんと共有したいです。
そして僕自身はHOME’Sのモノづくりを担う立場としてより良いプロダクトを作り続けていくと同時に、HOME’Sのモノづくり文化を積極的に社外に発信して業界にも貢献していきますので今後のHOME’Sにご注目ください♪
よろしければ、ぜひ僕たちの創ったアプリもダウンロードしてみてください！
■Android
HOMES(ホームズ)-賃貸・不動産-住まい探し検索アプリ - Google Play の Android アプリ
■iOS
