- #開発現場コーチング
株式会社ミスミ
「ギルドカンファレンス2018」では、ギルドワークスが現場でクライアントやその問題についてどのように向きあっているのか、複数のクライアントから普段の姿を語っていただきました。
登壇したミスミの趙様、芝田様、そして合同会社JEIの稲野様には、「正しいものを正しくつくる」現場を増やすことをミッションとしているギルドワークスの現場コーチが、実際の現場でどのように関わったのかについてお話しいただきました。
登壇者
・趙 黎明様（株式会社ミスミ 3D2M企業体 3D2MInnovation推進室 meviy事業基盤開発チームリーダー）
・芝田 篤史様（株式会社ミスミ 3D2M企業体 3D2M金型事業部 3D2M金型加工品事業チーム 事業チーフディレクター）
・稲野 和秀様（合同会社JEI CEO）
・中村 洋（ギルドワークス株式会社）
##現場コーチを呼ぶきっかけ
ーー（会場からの質問）現場コーチを呼ぶきっかけは？
芝田：トヨタ生産方式をとある研修で勉強したときに、トヨタ生産方式のメリットを論理的に説明するのは非常に難しいことを知りました。トヨタ生産方式も、単にカンバンを導入しただけではうまくいかないように、スクラムもきっと単に手法だけを取り込んでもうまくいかないんじゃないか、と思いました。これは知ってる人にいてもらわないとうまく行かないな、と。
中村：元々ミスミさんに出会ったきっかけは、ヌーラボさんからのご紹介でした。ヌーラボさんのBacklogを使ってタスク管理をされていたんです。それからしばらくして、芝田さんから「スクラムでやりたいだけど、どうしたらいいんだろうか？」と昨年11～12月頃に相談がありました。
##カンバンの項目
ーー（会場からの質問）カンバンの項目詳細を可能な範囲で教えていただけないでしょうか、現場を知らないステークホルダーが見てもいいと分かるものはどんなものか知りたいです。
趙：我々のカンバンは大きく2つのパートがあります。左側は企画のカンバンです。まずはアイデアレベルで出して、仮説検証して、それが終わったらMVPを作って、さらに検証します、というプロセスをカンバン化しました。
開発をしようと決めたら、そこからさらに顧客価値で細かく分割して開発用のスプリントバックログを切ってカンバン化していきます。
中村：少し補足すると、開発はスクラムでやっています。その前後にアイデア出し、検証MVPを作る、そしてリリースしたものの効果測定を作るといったところはカンバン上で流れています。
粒度的には「これが売れたらなんぼになるの？」くらいの粒度になっています。APIという単位ではなく「オンボーディングをこう変えるとどうなる」「この商品を増やしたらどうなる」みたいな感じのカードが左側です。右側の開発ステージで色が変わり、オレンジのカードになっているのはもう少し細かい機能単位だったりタスク単位に分かれたものです。
偉い方がいらっしゃった時に目についたのが左側の方で「これなんぼになるねん」と言われて、POが口頭で答えたら「書いといて」ということになったエピソードがあります。
芝田：まだ書いてないですが（笑）
中村：元々開発チームはタスクボードというやり方でやっていました。それを崩す必要がなかったのでカンバンとタスクボードが混じっているのが特徴ですね。
##チームビルディング以外にしたこと
ーー（会場からの質問）：新しい試みを始めると少なからず後ろ向きの人が出てくるかと思います。どのようにして説得もしくは納得してもらうようにしたでしょうか？
チームビルディング以外で、何か特別にしたことや、メンバー同士で気をつけたことは？
稲野：チームビルディング以外ですか……1on1やったり。飯食いに行ったり。
中村：やったことで言えばスプリントレビューのやり方ですかね。当初は、開発チームが作ったものをプロダクトオーナーに見せ、承諾してもらう感じでした。「スクラムのスプリントレビューはそうではないよね」という話をして、ステークホルダーを呼んで、お客さんのところに行く営業さんに触ってもらい感想を言ってもらったですよ。
そうするとそれまで作ることにしか興味がなかったメンバーの何人かが「こう使われるんだ」「こういうフィードバックをもらうんだ」ということが分かって、そこから変わってきた。さっきのように展示会に一緒に行ったというのもありました。
趙：スクラム、アジャイルを導入する時、開発チームはそんなに前向きじゃなかったんです。「なんかまた面倒くさいこと始めるなあ」という意見もありました。でも2スプリントぐらい回したら、開発チーム、特にリーダーから「これはいけそう」「これはちゃんと回せば自分達は良いプロダクトづくりができそう」という声が出てきました。
よく考えたらそういう方向性にすると決めたら、思い切ってやるという意思表示が非常に大事かなと思っています。効果が出たらみんなやっぱり合わせてくれる。
でもどうしても後ろ向きのメンバーはいます。「ふりかえりは必要なの？」って言うメンバーもいる。その時大事なのは、そういう意見を受け止めて全員が一緒に議論するのを徹底することです。
違う意見でもどんどんみんなの前で言ってもらって、一緒に前向きに真面目に議論をしましょう、というのが我々のスタンスです。なんでそう思っているのか、どうやってもっといい方向に変えることができるのかをみんなで議論して、異なる意見のメンバーの懸念や心配事を解消することが大事。皆で話し合うことで、チームの心理安全性と情報透明性が高まり、だんだん前向きなムードに変わっていくかなと思っています。
中村：ミスミさんは丁寧に「なんでそれをやるですか」というやりとりをしますね。「いいからやれ」と言わないのはすごいと思います。
##ロードマップをどう見せるか
ーー（会場からの質問）アイデア出しから関わるとのことですが、サービスとしての全体像と言うかロードマップみたいなものをステークホルダーから求められることがあったと思います。どういう風に見せていたのでしょうか？
中村：全体像があるのかどうかとあるとしたらどういう風にやっていくかということですね。
芝田：ロードマップとかリリース計画はずっと中村さんに書けと言われていて、いまだにそれらしいものができていないのが反省点ですが、ミスミは毎年、事業計画をきちんと書いて更新しています。
僕は事業責任者として、事業をどうしていくか、何をやって売り上げを上げていくかといったことを事業計画書にまとめます。そして、年度初めに全員を集めて事業計画のプレゼンテーションをしています。ただ、機能開発については触れられていないのが現状ですね。
趙：芝田が言うように、まだちゃんとできていないのが正直なところです。大きな計画は毎年、年の初めに我々事業のトップが直接開発チームに説明はしています。事業全体の方向性は分かってくれたか思いますが、事業戦略からロードマップまで落とし込むのは、我々ミドル層の役割で、それをもっと強化していきたいと思っています。
##上からの反対への対抗策
ーー （会場からの質問）中の人が外部に頼むのを頑なに拒んでいる場合はどうしたらいいでしょうか？アジャイルコーチなんかいらんという組織、上司にはどうすればいいのか、コーチを呼んだお2人から悩んでいる方にアンサーをお願いします。
芝田：僕がある程度の予算権限を持っていたので、中村さんの見積もりを見て「これは俺の権限の範囲で行けるな」と（笑）
中村：偉い人になればいいということですね。
芝田：もし僕の予算権限枠をこえた見積もりだったら僕の権限で決裁できるサイズに落としたら何ができますか、ということを聞きます。
中村：上の人の決裁を取らなくていいサイズで、まずはお試しでやってみる。
芝田：そうですね。
稲野：実際コーチが入ってくるのをWebチームは嫌がっていたじゃないですか？
趙：本音を聞けばあるかもしれないですね。自分がアジャイル開発未経験者なので事前に有名な本は何冊か買って目を通していましたが、実際やり始めると本だけでは足りないんですよ。
例えばPOがふりかえりに参加した方がいいのか？しない方がいいのか？とか。休日が挟まる場合、スプリントのサイズは変更するのか？キープするのか？とか。色々な細い悩みがありまして、自分たちだけで頑張るのはどうしても難しい。
隣で伴走して、そういったことを常に相談できる人がいるというのが、プロジェクトの成敗に関わる重要な要素のひとつかなと思っています。
中村：私も最初から長い期間をするより、最初はお試し期間として、お互いの合う合わないを判断しましょうという話をしていました、予算に応じて小さくやれる範囲があるといいんじゃないでしょうかね。
##アジャイルコーチがいたから実現できたこと
ーー（会場からの質問）アジャイルコーチを導入しないと実現できなかったことはありますか？
趙：やっぱり立ち上げかなと思っています。「とりあえず1、2ヶ月やりましょう」とコーチに言われたら、開発チームも「じゃあやりましょう」となり、最初の抵抗を崩すこと自体はやりやすいかなと思っています。コーチがいると立ち上げが非常にスムーズにできて、その後も順調に軌道に乗って行けるかなと思っています。
芝田：やり方が分からないまま本を読みながらやっていたら、全然立ち上がらなかった。完全に空中分解してたと思います。
趙：我々が1番困っていたのは、大きな機能をいかに価値のあるユーザーストーリーを分割するかとのことです。機能が必要というのは分かりますが、1スプリントに収めるサイズにどうやって分割するのか、私ともう1人のPOが悩んでいました。
これは本で勉強しても答えはどこにも書いていません。答えは書いてないからコーチに聞いて「こういった考え方がありますよ」と教えてもらって、だんだんやってきて慣れてきた、ということがひとつの実例かなと思います。
中村：最初のバックログは2ヶ月ぐらいかかるバックログでしたね。「今週は要件定義だけします」というよく分からないプロジェクトが上がってきたり、懐かしいですね。
##将来、どんな現場になっているか
ーー（中村）最後に、今後はどうなっていきたいとお考えですか？
芝田：開発チームは10チーム弱あり、スクラム開発をやっているのはまだ2チームだけ、ぜひ全チームに導入していきたいと思っています。スクラムを導入していないチームは、バグが障害になって思うようにリリースができない、事業が立ち上がらない、ということに直面していまして、他のチームもスクラムを導入することでスムーズに事業が立ち上がっていくじゃないかなと思っています。
趙：同じくスクラムを全チームに横展開したいという思いがあり、今まさにそれに向けて頑張っています。あと全体的にミスミと開発ベンダーは発注と受注という契約上の関係ではありますが、同じ目標に向かって頑張っていき、開発と事業両輪でお互いに支えながら進められるような良いチームを作っていきたいと思っています。
中村：では、お時間になりましたので、私とミスミさんのセッションはこれでお終いです。ありがとうございました。
この記事をシェア
こんなことでお悩みの方はお気軽にお問い合わせください。ギルドワークスのメンバーがお話をお聞きします。
- 立ちあげたい事業があるが、本当に価値があるのかどうか自分で確信が持てない
- 新規事業を立ち上げなければならなくなったが、潤沢な予算があるわけでもないのでどうしたらよいのかわからない
- 企画が実現可能かどうか開発の視点を組み入れながら仮説検証したい
- はじめてのことばかりで右も左もわからない