JaSST関西’18に行ってきた話（セッション 3A-1「老舗メーカーにアジャイル型要求開発を導入してみました」編）
セッション3A-1「老舗メーカーにアジャイル型要求開発を導入してみました」
https://www.slideshare.net/keinakahara3/ss-102572276
似たような会社に勤務しているというところもあり、気になっていたセッションです。講演者の中原さんは豆蔵やチェンジビジョンを経て2012年にコニカミノルタ入り。この講演は老舗の製造業系事業会社勤務の人向け、ということで私は対象ど真ん中な感じですね。
コニカミノルタさんはご存知写真がメインで創業事業ですが、今やそれはやっておらずという状況で、これからは業界や分野を越えた新事業が必要だ、というのがおおまかなバックグラウンドになります。ということで、経営のトップ階層からは「何か儲かる新規サービスを開発せよ」というお題目。ありがちです。私の周りでも年中聞こえてきます。新規サービスといっても難しい。
何が難しいか、中原さんは以下の２つを挙げます。
- 何が売れるのか不明（＝プロブレムソリューションフィット）
開発するソリューションが顧客の課題を解決するのかどうか、という点だそうです。なにかにつけては手持ちのソリューションをねじ込んでいき、あまり満足いただけない、みたいなことをよく見聞きしますね。 - （売れたとして）儲かるのか不明（＝プロダクトマーケットフィット）
こちらはちょっとピンと来なかったのですが、ソリューションとしてすごくいいんだけど、個別過ぎてとか、対象が限られすぎてビジネスとして成長できない場合があって、そういう場合は売れても儲からない、となるそうです。（成長できない＝売れないって気もするのですが、伸長していかない、というのが適切なのかな）
特にこの講演では前者を対象とするようなのですが、難しい以上「迅速に仮説検証しながら育てていく」進め方が良い、と中原さんは言います。スライドには「リンスタ/アジャイルやん」と書かれています。そんなことは自明と言わんばかりの書き方ですね。確かに最近の流行で言えばそうなりそうですが、これが老舗メーカーでは難しいと。ようやく本題に近づいてきました。
で、老舗メーカーでは何が難しいのかというと、「組織構造と文化」が問題とのことです。セクショナリズムとか「これまでやってたから大丈夫だろう」みたいなことですね。これをなんとかしようということで、中原さんがやられたのが
- チーム構成とマインドセットを変える
- 開発の進め方を変える
- 品質保証方法を変える
の３つということでした。
組織構造と文化により発生する具体的な問題としては２つあって、以下を挙げられていました。
- 「役割によってゴールが違う」問題
企画の人は企画を考えるのがゴールであり、ソフト開発は要求どおりのソフトをQCD守って作るのがゴール、というわけです。なのでコミュニケーションもうまくいかないし、そもそもうまく合意に到達できるわけもない、と。 - 「情報劣化や誤解」問題
ボールを投げるんだけどグレーゾーンがあってうまく伝わらない問題。「言わんでもわかるやろ」と「書いてないやん」が飛び交うというわけです。これは心当たりもあり、わかりやすいですね。
で、これをなくすために組織構造と文化を変えるということで、組織構造を変えるというのが壁をなくす、文化を変えるというのが「あとはよろしく」とか「ここまでが僕の仕事」というのをなくす、ということに相当すると。
徐々に核心に近づいていく感じです。組織の壁を取るために部門を横断したチームを構築したということを紹介されていました。いわゆるスクラムチームというやつで、企画部門がPO、開発部門がDev/ScrumMasterとなるようなチームを作ったそうです（外部からコーチを１名入れて、それが中原さん自身、ということでした）。正直なところ、それをどうやったのかとかいうあたりを聞いてみたかったのですが、そこはバッサリとカットされている感じでした。
参考としては https://www.slideshare.net/keinakahara3/ss-81883094 が挙げられていました。
ちょっと肩透かしをくらった感はあります。でもまぁ落ち着いて考えると、こんなもんは一念発起してやる以外にうまい手なんてないんですよ、という話なのかもしれません。参考資料のスライドの最終ページにも「勇気＜覚悟」って書いてあるし。言っちゃなんですが、私なんかは勝手に問題が解決することだけを期待してぼーっとしている部分がないといえばウソになるでしょうし。やっぱり行動しないといけないんだろうなぁと・・・。
やや脱線しましたが、文化の方の話にもどります。こちらはこれまで要求ありきだったのをみんなで考えるようにしたと。ソフト屋さんは脱御用聞きでチーム全体で要求そのものを開発するんだ、ということでした。そのためには開発者もビジネスを知らなければならないと。なのでビジネスの状況を共有したり、ビジネス上の仮説をカンバン化したり、リリースの狙いをボードにして共有したという事例が紹介されていました。
もう少し具体的な手法の説明としてはやや用語というか手法の名称先行な感じではありますが以下のような順で進んでいきます。
- 利害関係者の特定
インセプションデッキ/ステークホルダーリスト - ターゲットユーザーの共有
誰が使うのか
ペルソナを使用 - 顧客課題の共有
カスタマージャーニーマップ（ASIS）
UXベースで考える。不満は何かの機能に偏在しているのではなく、そこに至るまでの体験にも左右されている。 - 提供価値の共有
カスタマジャーニーマップ（TOBE） - 最小限の提供価値と実現範囲特定
ユーザーストーリーマッピング
と書き並べてみたものの、（アジャイル関係に明るくない私には）さっぱりわかりません。このあたり手法としては有名なのである程度名称だけで話が通じる前提で講演が進んでいく感じでした。とりあえず用語関係、結構しっかりフォローしないと理解が難しそうです。
なんにせよポイントとしては
- 誰のどんな課題をどのように解決し、どんな効果を狙っているのか
- そのために何をどこまで作るか
という2Stepであると説明されていました。特に仮説検証のための最小限以上のものは作っても無駄になる、というのが印象的でした。確かに間違っていたときの被害を最小限にするためには余裕があるからといって作りすぎは良くないですが、なかなか実行するとなると難しいですね。あれこれ積んでしまいがち。
講演内容が「アジャイル型要求開発」なので、あとはこれを繰り返すだけ？と思いきや続きがあります。『サービスとアクターのインタラクションしか表していない』ので、足りないと中原さんは言いますが、これまた勉強不足なのでその表現だとさっぱりわかりません。もう少し具体的には「機能横断的な非機能要求がカバーできてない」。これならイメージできそうです。負荷とか応答速度とかそういうやつですね。この辺次第でアーキテクチャはいくらでも変わるので、その辺を抜きにして要求が十分かというとそうではないということですね。なるほど。
でもまだ足りないと話が続きます。最後に出てくるのは「価値提供に値する品質なのかどうか」。品質、これがまた難しい用語ではありますが・・・。これに対するアプローチとして品質に精通している人に協力してもらうというのが出てきました。ちょっとJaSSTということで取ってつけたのかな？という気もしましたが、そうでもなさそうです。
参考に挙げられていた https://www.slideshare.net/keinakahara3/ss-81883094 でもそうですが、開発をアジャイルにしてもQA以降はプロセスが定義されていてウォーターフォール的に、というのは私の周りではちょいちょい目にします。最終製品としては出荷タイミングがあるんだからそれを基準に社内イベントを、というパターンですね。でもそれはこの講演の趣旨から行けば壁を容認することになるわけでダメですよね。となればQAを巻き込んでしまえというのはある意味自然な流れかなと思いました。（できているのが超スゴいなぁ、どちらかといえばそこまでの道のりを詳しく聞きたいなとも思いました。）
実際やったこととしては品質レベルをチームで決める（なぜならば提供する価値が仮説なので品質もまた仮説、よって品証部門だけに責任を押し付けられない）ということをやったそうです。確かに斬新すぎで評価できないというのはありそうな気がします。特に老舗だと分化が進んでいるのでQAがついてこれない、みたいなことは結構あるのかもしれません。となるとQAの巻き込みもそこまで見透かして（＝QAに振り回されたくないための作戦）のことかもしれないですね。受け入れ基準を自然言語で定義して開発がそれをテストケース化し実行、結果は自然言語でレポート、というのも受け入れ基準作成にQAを参画させてしまうためのやり方、という見方ができるかもしれないな、と思いました。
最後に質疑応答などありましたが「なぜなのかを明確に伝える」というのが回し方のポイントいう話をされていて、チーム体制とか文化を顧客中心な感じに組み替えていくと結局そうした組織の中で意思疎通するにはそういう軸で語ることが大事になるのだろうな、とある意味納得しました。
・・・
正直もうちょっとノウハウ的なものを労せずにいただけたりしないかなーと思っていたのですが、当然ながら現実は甘くなく、精進が必要だということを再認識した次第です。あと、アジャイル関係の用語とかは勉強しないとそもそも話が通じないなというのを強く思いました。カタカナ語難しい・・・。
