最初に
「カイゼン・ジャーニー」楽しくも懐かしかったです。
「カイゼン・ジャーニー」の著者の１人の市谷さんとは、最初に出会ってから５年経ちました。
このブログは、カイゼン・ジャーニーを読んで思い出したことを中心に書きます。
思い出のようなものです。いわゆる書評とは違うので、気をつけて下さい。
そういった意味では、数年前から「カイゼン・ジャーニー」の中に居た１人ということが言えるかもしれません。
そんな少し偏った目線抜きにしても、カイゼン・ジャーニーは「開発に限らずサービスを作る立場の人間であれば、読む価値が十分にある本である」と胸を張っておすすめできます。
「カイゼン・ジャーニー」を読むと、本当に現場が改善できるのか、本当に価値があるのか疑問を持っている人に向けて参考になれば幸いです。
自分とカイゼンの出会い
自分と初めて市谷さんとお会いしたのは、市谷さんがまだギルドワークスを立ち上げる前でした。
出会いは、某案件のこと。新しいサービスを立ち上げる案件です。
その社内案件は、だいたいのコンセプトはありながらも具体的に必要な機能や要件がない状態です。
その開発部分を外部委託するに辺りファシリテーションをしていただいたのが市谷さんです。
「カイゼン・ジャーニー」にも記載されているインセプションデッキの作成やキャンバス、ユーザーストーリーマッピングなどを教えていただきました。それまで既存のサービスに付加価値を付けたものや、リプレイスがキャリアの中心であった自分には何もかもが新鮮で、とても刺激になったのを覚えています。実践でサービスを作りながらもブート・キャンプ（新人訓練）を受けているような感覚。特に顧客価値を中心に据えた考え方は当時の自分には新しく、その後のディレクター人生の大きな柱になりました。
カイゼンを実践・応用する
自分は、プロダクトオーナーと開発の現場をつなぐのが役割の現場が多い人間（ディレクター・ファシリテーター）です。
その中では、カイゼン・ジャーニーに描かれていることを実践して成果を上げています。
その事例を紹介します。
必要なカイゼンを必要なだけやる
インセプションデッキやキャンバスを作るには「開発のメンバーとプロダクトオーナーが一緒にやる」ことが重要だと思っています。
しかし、開発会社を外部に委託するときにはかなりのハードルがありました。外部委託した場合に、外部のディレクターやSEが会議に出席することはあっても、外部会社の社員である現場のプログラマーまでスプリントレビューに参加するのは、コスト・リソースに的にも難しい状況です。デイリースクラムもままならない中、どのように円滑に業務を進めるかに苦心していました。
じゃあ、アジャイル的な開発を諦めるか？
しかし、そのままではうまくいかないだろうことは明らか。
悩んだ結果、カイゼン・ジャーニーにも出てくる「そのままやらない」というのに行きつきました。
全部やるのではなく、必要なものだけを必要なだけ取り入れたのです。
取り入れたのは、次の２つだけ。それでも劇的な効果がありました。
【会議におけるそれぞれの立場を明確にする】
社内と外部をあつめる会議体の形成し、それぞれの役割を明確にしました。開発とプロダクトオーナーだけでなく、営業、サポート、品質管理の全員が参加し、それぞれのポジションから意見を言い合える場を作るのを最初に行う。
【開発の単位を明確にする】
いつまで（When）に何が（What）できるかを２週間に一度の定例ですり合わせる会議を設定し、スプリントレビューとして、報告するようにしました。それまでの外部委託案件では、モックの段階や機能に期待するすり合わせの回数が１ヶ月に一回程度、しかも、そのときに何をレビューすべきか明確になっていなかったのです。開発の単位を小さくして、細かく確認することにより、認識のズレに寄る差し戻しを最小限にしました。
結果、社内にはそれまで無かったスプリントレビューが社内に定着しました。
本来のスプリントレビューとはかなり離れたものですが、関係性構築→価値定義→品質管理→振り返りを短期間でおこなうことで、問題点や課題をサービスを作る全員で共有する流れができました。
外部委託だとアジャイルやスクラムは難しい。しかし、現状には不満があるという人は、部分的でも取り入れるというところから入ればいいです。理想のカイゼンを全部を同時にやる必要もなく、全部やる必要もない。それが自分の結論です。
営業もカイゼンする
あるプロジェクトの新機能開発ですが、プロダクトオーナーと営業社員に大きな認識のズレがあるのに気づいたときに、２０人規模で会社の会議室の壁を埋め尽くすユーザーストーリーマッピングをしたことがあります。
時間が短く、初めて付箋をつかったアイディア出しをするメンバーで始まる前は、すごい不安でした。
しかし、嬉しい誤算がおきました。みんな不満が溜まっていたのか、でたアイディアや現状の問題点は１００を超えたのです。開発に役に立つもの、そして、それ以上に営業現場の思考整理として役に立ち、その後の問題点のカイゼンに繋がります。
そして、出たアイディアの中から新しいサービスの開発案が生まれて、実際に商品化までされました。最初の想定とは違う嬉しい誤算で、その後の新規開発にも役立てています。
最後に
少ないですが実例は、以上です。
これらは、すべて「カイゼン・ジャーニー」を読む前に市谷さんから学んだ知識をもともに、自分なりに手法化したことですが、「カイゼン・ジャーニー」を読んでからやればもっと上手くやれると確信します。
アジャイルやスクラムに関する本は多く出版されていますが、日本の現場に適したという面では、カイゼン・ジャーニーは素晴らしい本だと思います。
後半は、開発の具体的な内容に触れている部分も多くなるため、プログラマーやSEではないとついていけないことも多いと思いますが、前半の部分は、今の現場に不満をいだいている人、カイゼン手法に悩んでいる人には、開発・営業・企画問わず役に立つことだと思います。
実際にカイゼンを体験した人間より。
