製造業アジャイルを語る人は、デブサミ2008のベストスピーカー賞を受賞された、那須のケント・ベックこと咳さん以外、お目にかかる機会がしばらくなかったのですが、RSGT2018に突如現れた半導体アジャイルな人々を見て、「製造業アジャイル」というジャンルが出来つつあることを注目していました。この波の行方を感じたくてblog枠で滑り込み参加させていただき、したためてみました。何分初めてのことで、至らぬところも多々あると思いますが、読んでくださる皆さんのお役に立てれば幸いです。
beyond-hardware-agile.connpass.com
オープニング：及部 敬雄さん（デンソー）
最初に、、、、この会場は、medibaさんにお借りしています。「medibaなう」「medibaさんありがとうございます！」など感謝の気持ちをつぶやいて頂けるとうれしいです。
さて、製造業アジャイル勉強会に来た人はどんな人か、スマホでアンケートに答えて頂きたく。これに答えて頂けると、スピーカーの人は、どんな人が来ているかイメージが付きやすいので、ご協力ください！
参加者アンケート結果
この会を何で開催することになったのか、お話しします。最初に自己紹介すると、及部敬雄と言います。株式会社デンソーのMaaS開発部というところにいます。前職は楽天株式会社にて、今年の7月にチームごとデンソーに移ってきました。ソフトウェアの会社からハードウェア、製造業の会社に移ってきて、勉強しながら働いている状態なのですが、他にも製造業アジャイルをやっている仲間たちと話をしたときに、製造業アジャイルを携わっている人たちの悩みがよくわからないので、やっている人たちを集めてイベントにしたら面白いものになるのではのではと盛り上がり、今回企画してみました。
製造業でもソフトウェア、アジャイルやらなきゃならないという記事をよく見ます。アジャイルやスクラムのルーツは、日本の製造業。そこからヒントを得て、アジャイルが出来、ソフトウェア開発の中で発展してきたのだけど、いままた一巡して、日本の製造業にアジャイルのトレンドが来ていることが面白いと思ってます。その一方で、ソフトとハードの境がなくなっていることも感じています。
「製造業なのにアジャイルやっててすごい」と言われがちだと思いますが、「私たちスゴイ」というところまで持って行きたい！というのが今日のモチベーションです。「製造業なのにアジャイルやっててすごい」という状況をぶっこわすことに、共感してもらえたらうれしいし、共感してもらえなくてもこの場を楽しんでもらえればと思ってます！皆さん「自分たちスゴイ」と思って是非帰って頂きたいです。
ということで、第1回の講演にここから移っていきます。今回は、7月に開催されたアジャイルジャパンでお話しされた、ホンダの船戸さんの講演を抜粋版で、お話し頂きます。
講演「製造業と大企業におけるアジャイル開発とそびえ立つ壁たち」船戸 康弘さん（ホンダ）
八方塞がりな状態。その中でも一つづつ解決していけばなんとかなる。大切なのは一個目の突破口を探すこと。大企業でもアジャイルの開発は出来るということが今日のメッセージです。聞いて頂いた皆さんが、壁を壊したり、ボトムアップで何かするときに、今回の話が参考になれば幸いです。
1:大企業あるある問題と我々のぶっ壊し事例
我々の部署は、生産本部完成車技術企画部デジタル領域に位置しています。作っているものは、車ではなく、生産性を向上するための社内向けシステムを作っています。
今のチームは、2018年10月に発足し、社内外18名体制、社内は13名です。こういう風に言うと「ホンダだから出来るんでしょう？」「ホンダさん自由でうらやましい」とよく言われるのですが、現実はそうでもなくてですね（苦笑。
社内の人から言われた「心に沁みる一言」として
- 業務でチャットでコミュニティを取っていると「遊んでいるじゃない！！！」
- 英語でミーティングをしていると「真面目に日本語でやれ！」
- 最終的に言われたことは「工場の人たちが必死で削って稼いだ1円・1秒を、IT投資が一瞬にして使ってしまう！許せない！」
など、面と向かって言われた言葉です。皆さんの職場は、こんなこと言われたことありますか？？？？
自動車の製造にはたくさんの人が関わっています。開発フロー標準化の縛りや、法律も当然準拠しなければならない、それをまとめるためのリーダーがそれぞれにおり、会議が多い、開発は99%ウォーターホール。こういう状況だと、ゴミばっかり作ってしまうことになりがちで、技術的にもフロー的にも文化的にもかなり良くない状況でした。
我が直面した壁は6つです。
1-1:ソフトウェア開発メンバー不足
内製したいと思われている方も多いと思います。その一方で、開発できる人がいないので、最初から内製出来ないと思っている方も多いのではないでしょうか？我々も同じ問題ぶち当たり、委託開発にも挑戦しましたが、残念ながらうまくいきませんでした。
いまは、派遣社員と社内公募でなんとか人を確保している状況です。大企業だからか、探せば思わぬところに逸材がいたりするんですよね。趣味でやっている人の中に逸材がいました。
委託はどうかという話なのですが、今もデザインのところだけ委託でやっています。当初、いろいろな問題が起きていました。レビュープランニングした後に、デザインだけ外注していました。デザインを依頼して1週間で納品されてくるのだけれど、開発チームのスプリントレビューのタイミングと合わない状況になりました。つまり、デザインを反映していないままスプリントレビューし、次のスプリントで一工程前のデザインを反映することになったわけです。
この問題を解決するために、委託会社と一緒にやったことは、スクラムイベントに参加してもらったり、チームメンバーとこま目にやりとりしたりと、やり方をいろいろ変えました。今はより、デザインをブラッシュアップしていこうと言うことで、コンポーネント化などをトライしている状況です。
このように試行錯誤を同じチームとして一緒に動ける委託会社さんや協力会社さんとやれるのであれば、アジャイル開発は可能かなと思えるようになりました。
1-2:企画書承認の・・・・パワーポイントを作り続けることに
我々チームが初期段階の頃、バリューストリーミングマッピングをしたときに、開発1ヶ月なのに企画書に3ヶ月みたいな現象が、起きたことがわかりました。どんなシステムを作るかの企画書だったり、予算取りだったり、フロー評価会議を通したり、日程管理だったり、、、3ヶ月間ずっとパワーポイントを作っている人もいました。
よくよく考えると、元々は自動車開発に合わせたフォロー。我々が作っているものは、自動車開発には関係ない部分のソフトウェア開発だから、前提条件にはまっているだけではないかと考え、それぞれ対策していきました。
- 企画書→インセプションデッキにして、1日になった
- 予算取り：内製化にすることで、一括で企画してまって、こま目にアプリケーションをリリースし、予算取りの報告回数を減らした
- 評価会：社内フロー回避すればイケた
- 日程管理：カンバンなどいろんなところで見える化回避
- 情報共有化会：結構やっかいで後ほど話します
1-3.社内フローをどう回避するか？？？
開発フェーズでできあがった成果物を評価して、次の開発フェースに行くために、大量の資料作成が発生します。社内フローはなぜ必要なのか？を考えてみると、これも企画承認のときと同じように、元々は、自動車開発のチェックフローから始まっている訳なんですけれども、自動車会社であっても、自分たちの作っているのは、自動車ではないので、社内の今あるルールを守らなければならないという前提条件にはまっているだけなのではないかと気が付きました。
というわけで、どこまで社内フローに乗っ取らないでやっていけるのか、やってみました。そうすると、
社内フロー回避できるかチャレンジ
1-4.マネージャーの理解
このプロジェクトを始めるとき、マネージャーの理解が得られませんでした。解決策としては、気にせず始めた（会場笑
そして、結果が出始めると後押ししてくれるようになりました。
1-5.他部門との関係性
組織が大きくなってくると、部門の実績の主張、予算取り、評価者の声がけっこう気になってきます。システム部門もそうで、部門の評価を気にしすぎてしまい、いつしかユーサーって小さくなってしまっていることになりがちです。これらは、すべて、マーケット課題だと思っていて、チャンスだと思いました。大企業でもしプロダクトオーナーやスクラムマスターをするのであれば、製品だけではなく、そういう企業の「ヤバイ」部分にも爪痕を残しておくといいことがあると考えました。つまりは、「関わる人全員に価値を届ける」という持って取り組むといいと思いました。
「現場」は、早く帰れるようになってうれしいし、「現場のマネージャー」は、自分の工場が社内で注目されたり、労働環境が良くなってうれしいし、「我々のマネージャー」は、現場に貸しを作れてうれしいし。そんな感じでみんながハッピーになる価値価値を提供することが重要だなと思いました。これをやることによって、スクラムチームがより効率よく働いて生産性が上がることをイメージし、「誰に」「どんな価値を提供するか」を一つづつ提供することが大切だと思い至りました。
1-6.1日1クレーム問題→気にせずすすめる
大企業の規律とか風土とみたいなものを、ネタとしてみんなでWikiにまとめたりしています。例えば
- はみ出すな。おやつのスペースを勝手に使うな
- おやつ神社に人が集合すると、目立つからやめろ
- モニター電源、2分ぐらいですぐ消せと言われる
- 通路にはみ出してミーティングをしないこと
- 事務所で作業着を着用すること（笹さんは作業着を着なくていいと確認して、着ていかなかったら怒られた）
- ディスプレイはいくらしたんだ！購入するなんて、聞いていない
- 社内で非公認なwifiがあるようだけどコレは何だ！→野良wifiを立てていた人がいた。自分たちのチームに疑いを持ち怒られた（当然、自分たちのチームには犯人はいない）
- 付箋を使っていると→仕事とは何かについて説教された
みんな偉そうなんです。工場の人もITの人も（苦笑。
2.チームの軌跡：短縮版
アジャイルを始めたきっかけは何かというと、現場のスタッフの困りごとを解決するアプリを1人で片手間で作成したことからでした。現場の人たちが残業時間に、データをポーティングしていたのを見て、データベースからデータを取って、Webで可視化する簡単なアプリケーションを作って見せたところ、現場のスタッフの人たちが「わーい、わーい」と喜んでくれました。そしたら、現場の人たちが「作って作って」と作業が滞ってしまうぐらいバックオーダーを抱えてしまい。。。。。直属のマネージャーに人数を増やして大きくしていったらどうかと提案したのですが、はじめは反対されました。
そんなとき、現場のマネージャーが「こんなに現場が良くなっているいるから人数を増やしたらどうだ」と、直属のマネージャーに話をしてくれて、メンバーが増えることになりました。
一人からチームに変わるわけですが、ここからもいろいろ問題が起きました。まずは、エンジニア問題。委託で人を増やしたら、社内のシステムが特殊だったことと、私のやろうとしていたアプリエーションの開発スキルにマッチする人がいなかったため、システムが出来なかった。 委託先の会社の中でスキルが合うエンジニアを確保してもらい、ホンダのある栃木と大阪の2拠点で開発をすることになりました。
そうすると、今度は、委託会社の中で、内紛状態がおこり大変なことに。原因は、委託業者内のコミュニケーション不足。フロントとバックを拠点を分けて開発していたのですが、その責任区分がもめ事を生んでいました。でも、委託業者内のことなので、問題が勃発しても自分は何も出来ず。そこではじめて、内製開発をはじめることを決意しました。
やってみると、ものが出来たけど、ゴミばかりになってしまっていた。現場の言うことをそのまま作ってもいいものは出来なかったですね。現場のユーザー自身も、本当に欲しいものは何だったのかよくわかってなかったと思います。そこから、現場と一緒に「インセプションデッキ」をやったり「ユーザーストーリーマッピング」をやったり「デザインシンキング」をやりながら、少しづつ本当に欲しかったものは何か、考え作っていくようになりました。
それだけではなく、エンジニアとユーザーが交流を密に持つようになって、プログラミング体験をしたりしながら、お互いの理解を深めるようになりました。こういうことを繰り返すことで、やっと使われるものが出来きてきました。1年ぐらいかかって、やっとチームが動き始めまた感じです。
3.これまでの成果と今後の課題
たまたま同じようなアプリの仕様のもので、バリューストリーミングマップを、1年前と今でやる機会がありました。比較してみると、リードタイムが70%減！主に企画の時の時間が減っていました。
今後の課題としては、2つあると思っています。
3-1.技術力があまり高くない
チームメンバー自身も認識しているところが救い
- ラーニングセッション 2wに1回
- モブ
- ワークショップを週1程度開催している
かなり教育に時間をかけて、技術力アップに努めています
3-2.チームが大きくなり、他部門に巻き込まれることも増えた
- IT部内（開発チームの一元化？）
- 全体最適的の話（その裏には派閥？）
良くない傾向だと思っています。我々のチームの課題をぶっ壊すため計画中で、来年の暖かくなる頃には結果がわかっているはずです。
4.まとめ
一つづつの解決して、突破口を見つけるとアジャイルを導入することは出来る。大切なのは一つづつの積み重ねだと思っています。
そんな、順調に進んでいるところで新たな問題が発生しました！「予算削減」からの「チームシュリンクの危機」の波が来たのですが、現場の人たちがお金を出してくれることになり、チームが存続することになるという事件がありました。
ちょっと前の現場の人たちは「IT投資にお金を使いたくない」と言っていた人たちでした。その人たちが、我々のためにお金を出してくれるようになった。信頼を取り戻して、仲間が増えていきました。
仲間が作ることで、定型的な日本の製造業が変わっていけばなと思っています。みなさん、製造業な方も、製造業じゃない方も、一緒に製造業を盛り上げて、日本を楽しくしていきましょう。 ありがとうございました。
5.個人的に印象に残ったQA ：[司会]笹 健太さん (クリエーションライン）
車の開発にアジャイルは使えますか？
アジャイルの定義が何かにもよりますが、近しいことは出来ると思いますただ、皆さんが想像しているアジャイルとは違うと思いますけれど、仕事の進め方とか、スクラムっぽい感じで問題を捌くことは出来るかと思いますが、金型など、リードタイムがかかるものがあるので、ハードをユーザーの要望に応じて毎週変えていけるかというと、多分そういうことには今はならないと思います
どうしてバリューストリーミングマッピングをやってみようと思ったのでしょうか？
アジャイルコーチとして支援に入ったときに、現場の状況がわかってなくてスクラム導入支援やるのも抵抗があり、どこに問題があるのか現状を理解し納得して次に進むために提案させていただきました。（笹さん）
ホンダさんの元々いた人たちも変わってきたことがありますか？
ありますね。現場の人たちもアジャイルなやり方に慣れてきて、企画書を作らずにいろいろなシステムが出来たり、フィードバックをもらうときにも言ってくれるようになった。ITに対するスタンスが変わってきて、ITを活用しようとする意識になって来ているのを感じる。はじめの頃、インセプションデッキをユーザーさんと一緒に作ろうとすると「なんで、俺らもやらなければならないのか」という人がまあまあいたように感じていたが、この頃は、一緒にやることに抵抗がなくなってきたように感じています（笹さん）
はじめに現場の困りごとのアプリを作ったときの契約形態と予算の付け方などを教えてください
当時、自部門の予算として、他部門のお助けをやっていた。一人で片手間に作ったので、予算は工数のみ。カイゼン工数だけ。今は、オープンソースの組み合わせで大体できるので工数はかからない。何でやろうと思ってかと言うと、これ簡単に自動化できることは自分にはわかっていたので、やったら、喜んでもらえるかなと思ってやった。
システム連携は（販売・購買など）？
システム連携はまだしていない（販売・購買など）システム連携をすると、連携先との調整が必要なので、まだ出来ていない状況。品質の担保は最近、TDDをはじめた。
ホンダのわいがやの製作体制は死んでしまったのでしょうか？
死んでいないとは思う。どこかでやっているのではないか？自分の周りで言うと、モブでガヤガヤしていると怒られちゃうところは残念 。
社内の浸透度
部長までは巻き込まれている。OSSを使うことはOK。 価値をどんどん提供してお金を増やす。人が確保するために、予算を取るときに、人員計画など年に1回そこはしっかりやっている
=========================
6.プロフィール
船戸 康弘
本田技研工業株式会社
スクラムマスター
2006年本田技研工業株式会社入社
生産技術開発部門で生産ロボットシステム開発を経験後、データサイエンス領域を担当。画像処理やテキスト分析を中心としたデータ分析業務を経験。現在は、アプリケーション開発チームを立ち上げて奮闘中。
笹 健太
クリエーションライン株式会社
アジャイルコーチ
2018年にクリエーションラインに転職し、DevOpsチームに入る。他社のAgile・DevOps導入支援を通じて、変革のお手伝いを行っている。前職ではScrumを採用した開発を実施していた。認定スクラムマスター（CSM）、認定LeSS実践者、DASA DevOps Fundamentals。
謝辞/雑感
- 一般枠がいっぱいで補欠枠にいたところを、スタッフのさとりゅーさんに声をかけていただき、blog枠で申し込ませていただきました。 さんくす！さとりゅー♥
- 初めてのことで、座った席から取る写真だと、編集してもこんなにひしゃげてしまった（スマソ）
- 船戸さんのチームをアジャイルコーチとして支援されている、クリエーションラインの笹さんのショートセッションは、筆舌に尽くせないほどスゴイだったので、お知りになりたい方は、是非直接、笹さんにお話を聞いて頂ければと思います。
- 書き起こしのため、何度も何度も聞き直しましたが、そのたびに、勇気づけられる言葉にしみじみ。話してくださった船戸さん、企画してくださった、及部さん、笹さんはじめスタッフの皆さんに感謝します。読んでくださる皆さんのお役に立てるといいなという願いを込めて、ポストします！また、誤字脱字や認識違いがあれば、お知らせください！
最後に、、、、次の製造業アジャイル勉強会が開かれるといいなと期待を込めてつぶやいておきます（笑。
