Articles from 5月 2018

今回のMountain View滞在のメインテーマはITの巨人のプレゼンテーション方針を探りに行く、なのだけど、サブのテーマとして、世界観の導線に合わせた開発プロセスの答えを見つけにくる、というのも含まれていました。
「最適化された開発プロセスの都合でプロダクト戦略を導き出すことの限界」
が今回のキーワードです。
今回SFOの名村さんや宿泊したスタートアップシェアハウスのエンジニアや事業かとの話などを受けて、ちょっと考察が進んだので書いてみようと思います。

まず開発プロセスを最適化し、それに基づいてプロダクト戦略を決める、というアプローチの凝り固まりやすさ

アジャイルという言葉に引きずられて『プロダクトオーナーは開発プロセスを理解して、プロダクト戦略を引くべきだ』という方向へ極端に引っ張られてるチームを昨年くらいまで本当によく見ました。
言葉を変えると作り手の基準に合わせることでチームの生産性（＝市場における攻撃力）を最大化しようという観点を最大限重視した解釈でしょう。
これはプロダクト戦略の内面を重視したアプローチで、チームのアセットへの深い理解や、一人一人の生産性を役割分担の最適化によって限界までチューニングすることでこのアプローチの成果は最大化されますが、実のところそこまでやっているチームはあまり見かけません。
そしてこの方針をとる事業チームの中の開発チームが持つ特徴として、一度手にした一見効率的な開発プロセスに固執しがちなことが挙げられます。
ASAP出力型のスクラム開発チームと事業計画が噛み合わない、などが非常にいい例で、初期開発をできるだけ早く終わらせるべきフェーズや、ABテストサイクルなどを用いた改善プロセスによってできるだけ短時間である指標を引き上げるべきフェーズなどで用いられるべきASAP出力型スクラムを、逆にそれ以外のフェーズで適用してしまったケースです。
イベントに合わせた機能リリースやリニューアル、といったプロジェクトをスクラムで開始しているような場合は、スクラムのスケジュール調整がスプリント単位でしか行えない（ので、遅れるときはスプリント分盛大に遅れる、などがあり得る）ことを十分に理解した上で適用しなければなりません。

とはいえ、開発チームはスクラムというスタイルを身につけてはおくべきだと僕は考えています。
スクラムはその仕組みやフローへの制約が非常に強力で、コミュニケーションのヘルシーささえ仕組みでカバーしようという試みの元に生まれ、ブラッシュアップされ続けているものなので、どんなに深刻なスランプに陥ってしまい、出力が出なくなってしまったチームでも、一旦初心に帰ってスクラムを組むことで、自分たちのペースを取り戻すことができるからです。
これを自己的にできるというのは、チームにとって大きな力となりますし、これ以上プリミティブで強力なフローを他に見たことがありません。
また、スクラムの出力はあくまで「標準」と捉えるべきです。
なのでスクラムを身につけたチームは、それに固執することなくそれよりチームに合ったやり方をどんどん探しにいくべきですが、それについてはまた時期を改めて書こうと思います。

このように、生産性を最大化した強固な開発プロセスを作り上げ、それを軸にプロダクト戦略を導き出していくことは悪いことではありませんが、非常に諸刃の剣感があることを忘れないでおきたいものです。

事業推進上の危険

ではなぜこうした強固な開発プロセスを基軸に事業を進めることが危険なのか、というのが次のテーマです。
答えを言うと市場自体がそんなに静的なものではなく、よっぽど動的な性質を持っていて、それに対してプロセスや生産性をチューニングしすぎるのは「身動きが取れなくなる」という点で危険だからです。
そして、これは案外誰もが察しています。
この感覚は明確にそうだと感じることができる人は少ないですが、言語として表すことはできないが、プロダクト戦略を引くときにどうも拭いきれない小さな違和感として常に付きまといます。

一方、逆の極端な例として、プロダクト戦略の外面、つまり事業計画城のスケジュールによって開発フェーズを組むやり方は、ここ数年意識の高い開発者の中では悪として捉えられてきました。
これら、それぞれ端側（事業と開発）の意志は
「ユーザーに届ける体験と、それによってユーザーが感じる世界観の推移を注意深く洞察し、それに合わせてプロダクト開発計画や事業計画が適切に見直される」
という触媒をもって接続されるのが望ましく、Goodpatchなどが国内にも影響を与えて潮流として認識されたUXドリブンや、昨年あたりから輸入され始めたUX Researchといった考え方がその役目を担うのではないかと期待され、実際に西側諸国ではそれが機能しつつあります。
国内も本来的には是正（外面と内面の重要性の認識バランスが取れてくる）されてくるはずだと思うのですが、そのUXの考え方自体が、話題にはなるがなかなか浸透しないという状況も併せ持って、推進が遅れている印象です。
これは非常にもったいない状況だと考えています。

なぜUXが大切なのか？と、それが浸透しないのはなぜか？

事業チームにおけるUX / UX Reseachは「その変更によってユーザーにどう言う影響を与え、その結果提供している世界観はどうなったのか」に常に注目しながら開発や事業を推進していくという思想から来たやり方です。
それがなかった頃の事業体では、開発チームの執り行うデータ解析や、事業チームが執り行う市場解析の結果に基づいた仮説ベースで方針を決定していました。これらをマージする役目がいなかったために、うまいこと回らなかったのです。
UXはそのマージを担うことがミッションであるとも言い換えられます。だから、UXのプロフェッショナビリティは言うまでもなくInsight（洞察力）です。PMがその役を担う場合もありますが、事業全体が30人を超えてくるくらいの規模で適切にデータを集めている開発チームと事業チームを持つ事業体では、一人で取り扱える情報量を超えてきます。そうなると、Dirやデータアナリスト、マーケターなどとの協業を経て初めて十分な検討ができるという感じです。

浸透しない理由は、僕が浸透しなかった組織にいた頃の経験を振り返ると「その入門編みたいなことをチームの誰かがやっていて、入門なりの答えを出している」からです。

結果それらの活動はちょっとずつ興味や専門性を持ったDirやマーケターによってバラバラに行われ、それぞれバラバラな結論を出すのですが、一応結露自体は導き出せてはいるので、その洞察をとりまとめる役の重要性を理解できない、ということなのだろうと思います。
ただ人材のパワーが限られるチームの中でこの「間違えないための取り組み」が成果を上げてきているチームが数少ないながら存在することが示すように、この取り組みは未来を見据えると絶対に必須です。

アジャイルをもう一回考え直す

本来、アジャイルという言葉はそもそもそういう社会状況に対するすばしっこさを諦めない、という意思を表す言葉でした。
日本語翻訳された

• 小さなチーム＆大きな仕事
• アジャイルサムライ
• SPRINT
• How Google Works

などを読んでいて微妙にアプローチのズレを感じるのは主にそのためで、これらは「なぜチームはそのプロセスに至ったのか？」という前提を「その時々の成功者を観察した結果の一般的な成功者モデル」に置き換えることですっ飛ばして、完成度の高いプロセスを解説することに重点を置いているからです。
本当はプロセスが完成するまでのプロセス論が非常に大切なのですが、これの構築には幾度のチャレンジと長い時間がかかるので、なかなかそれを実践し切れている企業はありません。

今の国内でもよくできたエンジニアリングチームは本当にプロセス最適化がうまいし、大抵の状況に対しての最適なプロセスを
「プロダクトを通じて表出する世界観の導きステップをどう設計するか、」
に合わせて柔軟に編み出します。
幾度もビジネス状況に合わせてプロセスを組み替えた経験のあるチームでないとなかなかできないのですが、この力こそ変化が速く見える世界で開発チームが戦い続けるための本当の力であると、僕は考えています。

みんなで、がんばろう。