デンソーの新しいチャレンジ、アジャイル開発で働き方改革を実践

デンソーといえば、トヨタの自動車部品を開発している企業と思われがちだが、実際にはトヨタ関連の売上は既に半分以下、海外向けの売上が半分以上を占め、売上高も4兆円を超える自動車部品のトップメーカーである。主に愛知県内に工場やオフィスを持ち、14万人以上の従業員を擁する製造業では屈指の優良企業と言えるだろう。ソフトウェアの観点ではQRコードを開発したのがデンソーということでデンソーの名前を認識したソフトウェアエンジニアも多いのではないだろうか。そんなデンソーに約1年前、ビットアイル・エクイニクス・ジャパンから転職したのが成迫剛志氏だ。成迫氏はデンソーではコネクテッドカーなどのクラウド側のプロジェクトを推進する役目を負っているという。成迫氏とプロジェクトのメンバーにインタビューを行い、伝統的な企業がアジャイル開発にチャレンジする秘訣などについて話を聞いた。インタビューに参加いただいたのは技術開発センター　デジタルイノベーション室の成迫剛志氏、佐藤義永氏、中山吉浩氏の3名だ。

ーー自己紹介をお願いします。

成迫：私は約1年前の2016年8月にデンソーに移りました。そもそもデンソーに移ったのは、役員の方からIT業界のやり方でプロジェクトを推進して欲しい、という話があったからです。車載システムの開発を見てもらえばわかるように、元々デンソーは組込系の開発が主だったんですが、自動運転やコネクテッドカーというものを見据えるとクラウド側と連携するシステムがどうしても必要になる。その時にこれまでのウォーターフォールのやり方ではなく、全く新しい方法論でソフトウェアを開発したらどうなるのか？ をプロジェクトとして実践しています。

成迫剛志氏

佐藤：私は今から2ヶ月ほど前に東芝から移りました。それまでソフトウェアの研究職として仕事をすることと同時にエンジニアとしても開発を行ってきました。転職を考えた時に研究職に行くか、もっとエンジニアとしてコードを書く仕事に行くか悩んだのですが、どっちかにするのではなく両方やりたいなと。そういう意味では欲張りなので（笑）。その時に成迫さんと話をして、これまでにないソフトウェアをゼロから作る、という部分に惹かれてやってきたと言う感じですね。東芝でも色々と新しいことをやらせてもらったんですが、どうしてもその時に稟議を通すというのが必要になってそういう社内調整よりも、もっとコードを書きたいという気持ちがあったのは確かですね。

佐藤義永氏

中山：私は2005年に新卒でデンソーに入社して以来、ずっと車載システムつまり組込系の開発をやっていました。方法論としてはウォーターフォールで品質重視という仕事をずっとやってきたんですが、成迫さんが来られて、エンジニアを探しているという話を聞いて自分から手を挙げてここにやってきた感じです。佐藤さんは社外から、私は社内からほぼ同時期にこのプロジェクトに参加したということになりますね。デンソーには組込系のエンジニアは多いんですが、サーバーサイドの仕事をして自分の幅を拡げたいという気持ちもありました。

中山吉浩氏

ーー今のプロジェクトではアジャイル開発、特にスクラムを使って開発を行っているということですが、そもそも成迫さん自身にアジャイル開発の経験はあったのですか？

成迫：ありませんでしたね。アジャイル開発は開発サイクルを短くするだけではなくサービスデザインをサイクルを回しながらやるという側面もあって、それに関しては「デザイン思考」でビジネスを考えるというのをずっと実践していたんです。その時に六本木にあるアジャイル開発で有名なPivotal Labsに何度かお邪魔することがありました。そこではアジャイル開発の方法論を使ってサービス開発を行うのを実践しているわけですよね、それは良い例として参考にしました。ただ今回のプロジェクトでは主にスクラムを使って開発を進めています。

ーープロジェクトチームの概要を教えてください。

成迫：今回のプロジェクトでは、私を除いて社員が4名、開発を行う派遣のプログラマーが3名という体制ですね。社員のうち一人は、主にユーザー側の人間でプロダクトオーナーという役割ですので、開発自体は6名でやっています。そのうち、中山がスクラムマスターです。そもそもこのプロジェクトの目的、私がデンソーに入った目的は、いわゆる「攻めのIT」を作ってくれということだったんですね。それをクラウドやオープンソースソフトウェアを使ってとにかく早く作る、ということを実践しようと。でもそう思ったとしても、これまでのデンソーのやり方では、アルゴリズムを考える人、コーディングする人、インフラを作る人、みたいな階層構造になっていたわけです。まぁ、メーカーとしてはそうなりますよね。それを「攻めのIT」という目的に対してこれまでのやり方で迅速に動く開発体制を実現できるんだろうか？という疑問があるわけです。なのでゼロベースで考えて、そもそもインフラとか後で考えれば良いんじゃない？まずはコードを書いてモノを作るところから始めようと。

私はデンソーの中では異分子なようで、そもそもスピード感が違うんです。このプロジェクトを始める時に「これは超緊急で短期でやらなければいけない」とある人から言われたんですが、IT業界で超短期と言えば、まぁ、6ヶ月かな？それとも3ヶ月で何かを動かさないといけないのかな？って思いますよね。それが「2019年には動かさないといけない」ということで、IT業界とはスピード感が違うことがあらわになったという笑い話がありまして（笑）。結局、クルマ作りっていうのはそういう時間感覚なんですよね。でもこれからは例えばIT業界の人たちと競争をしていかなければいけないという状況に対しては違う発想と方法論が必要だと思うんです。

ーー今回のプロジェクトでスクラムを実践しているわけですが、メンバーとしてどういう感想ですか？

佐藤：これまでの開発ではデベロッパーは黙々と開発を進める感じですが、それって普通は1つのタスクをモジュールごとに1週間くらい掛けてやるということだと思うんですね。でもスクラムだとそのタスクの粒度がもっと細かくて、ひとつのタスクに1時間から長くても3時間くらいで進めるんですよ。そしてそれを一人でやるのではなくてペアでやったり、ちょっと難しいものになるとみんなで別のテーブルに移って画面をみながら、コーディングを行うモブプログラミングをやったりとか。アジャイル開発の場合は、タスクをモジュールで切り分けずにもっと小さい単位で切り分けるので、全員が全てのモジュールに精通することもあります。黙々と一人でやるっていうようにはならないし、会話しないと進まないので、自然とペアプログラミングになったり、モブプログラミングになったりするんですよ。

中山：とにかくタスクを優先順位の高いものから片付けていくのが徹底しているので、一人でハマっていると（周りから）自然と判るんです。なのでその時はペアでやったりすることで助け合う感じです。最初は、そのあたりの具合がわからなくて、すごく疲れましたけど、今では朝9時に集まって、昼の12時半に進捗を確認する短い15分のミーティングをやって、夕方6時には終わる、残業はナシというのが当たり前になりましたね。

成迫：今回のプロジェクトでは実際に同じ場所に集まって開発をするところにすごくこだわっているので、プロジェクトの進捗もすべて壁全面に拡がったホワイトボードでやっています。スクラムをやろうとした当初から、いろいろな人にアイデアをもらったんですが、人によっては「まずこのツールを入れるところから。ツールを買え。」みたいな人もいるわけです。でも今回は徹底的にアナログでやってます（笑）。でも実際にプロジェクトは結果出ているし、残業は無いし、その観点では働き方改革を実践しているという自負はありますね。

中山：みんな同じ部屋にいるので、進捗を確認するという目的だけであればホワイトボードで全然問題ないんですよ。でもこのホワイトボードも実際には進めながら色々と変えたりしているので、そういうのってツールでやってると簡単にはできませんよね？ 例えば、今回、タスクの進捗について「ToDo」「Doing」「Done」という3つのフェーズに分けて管理しているんですが、DoingとDoneの間に「Review」を追加したんですよ。これはタスクが完了するためには必ずレビューが必要だということに気が付いて、それを追加しました。ホワイトボードなら一列追加するだけですから。で、レビュー待ちが3つになったら、それを終わらせないと次には進めないっていうルールを作って。そういうのはやりながら改善したっていうことです。

ーー以前、サンフランシスコのPivotal Labsに取材に行った時も聞いたんですが、小さなツールを開発する時にはアジャイル開発っていうのは簡単に理解できるんですが、大きなプロジェクト、例えばOSを作るみたいな時にはどうするんですか？

中山：それは徹底的にタスクを分割して、具体的な作業内容に落とし込むことを続けるだけ、です。逆にこのポストイットに書けない仕様はダメっていうレベルで。実際にそうすることで曖昧な仕様が無くなって何をするべきか？ がハッキリするんです。

ーーテストドリブン開発でやる「最初にテストを書いてそのテストが通るコードだけを書く」みたいな感じですね。

成迫：そういう意味では似てますね。とにかくタスクを細分化して、そのタスクを終わらせることに集中するんです。よくアジャイル開発っていうと適当にやってるんでしょう？ と言う人がいますけど、実際にはものすごくキッチリと開発を行っているという感覚ですね。しかも無駄が一切無い。無駄がないというのはつまりやるべきことがハッキリしている、わからなければプロダクトオーナーに確認する、オーナーが確認したらそれは決定ということで手戻りはしない。

中山：実際には手戻りがあっても、それを直すというタスクになって、それが次週のタスクの中で優先順位が高ければ直りますし、高くなければ先に送られるだけなので非常にハッキリしているんです。ユーザーの声を聞くという部分、よくある仕様の確認という部分も開発チームにいるプロダクトオーナーが全責任を持っているので、エンジニアはその人とだけ接点を持っていればいい。

成迫：逆にいうとプロダクトオーナーが大変ではありますけどね（笑）。

ーー今は6名で進めているプロジェクトですが、これから規模を拡大しようとしているんですか？

成迫：ひとつのプロジェクトを大きくするのは限界があります。それは各人がコミュニケーションを取るのにオーバーヘッドが大きくなり過ぎるからですが、だいたい6〜8名くらいがマックスかなと思っています。でも今後のことを考えると今の1チームを2018年の4月には4つくらいにはしたいなと思っています。ただチーム内の構成というのが結構重要なので、その辺は徐々にと言う感じですね。

ーーやはり密接に働くという意味では相性は大事ということですか？

成迫：それはそうですね。ただ正社員か派遣社員かに関してはあまりこだわっていないです。とにかく個人事業主でも正社員でも派遣社員でも朝9時に集まって6時に帰るというのが大事です。

佐藤：開発そのものは50分集中して10分休憩、というのを決まりにしているので私個人はあまり疲れたと言う感覚は無いんですが、話をするということが必要なのでその部分では相性はあるかもしれません。だから作るのが好きな人、新しいことが好きな人には向いていると思います。

中山：ペアにしてもそれほどカッチリ決めるわけではないのでそのあたりはそのチームに任せるという感じですね。

ーー4つのチームになった時に各チームのスクラムマスター同士が協調するということになるんですか？

中山：はい、そうなると思います。なのでスクラムオブスクラムという感じです。ドイツのSAPなどは実際にそういう風になってると聞いてますし、SAP社内に数百にプロジェクトが進んでいるということなので、やればできるんだなと思ってます。

成迫：その意味ではどのチームも同じ場所にいることが大事だと思っているので、4つになっても同じオフィスで働くことになると思います。スクラム内の会議が15分、それをスクラムマスター同士が集まってやったとしても15分なのでそのあたりの仕組みは良くできていると思いますね。

ーークラウドはAWS、Gitでソースコードを管理して、進捗はホワイトボードということですが、いつかはツールを使うことになるですか？

中山：進捗のメトリックスを取ろうとするのであれば、ツールでやるべきかなとは思います。タスクがどれくらいの時間で完了しているのか？ それを改善するにはどうしたらいいのか？ などを計測しようと思うとプロジェクト管理ツールは必要かなと思いますが、まだ要らないですね。

成迫：AWSも特にこだわっているわけではなくて最初にアカウントを取ったのがAWSだったというだけのことです。中身はDockerとKubernetesでマイクロサービスになっています。ツールというか開発言語に関しては面白い話があって、まだプロジェクトの最初の頃にメンバーが自己紹介というか自分が過去に使ってきた言語などを紹介した時に、共通していたのがJavaだったんですよ。なので開発手法もアジャイルで初めてだし、言語に関してはみんなが知っているJavaにしようと言うことになったんですが、金曜日の夕方だったかな？ 仕事の後にみんなでビールを飲んでる時に私が「みんな、本当にJavaでいいの？ もっとPythonとか他の言語やりたいんじゃないの？」って切り出したんですよ。そしたら皆んながザワザワして、「じゃあ、週末にみんなで考えてきて来週もう一度、意見を聞こう」ということになって、それで最終的に開発言語はGoになったっていうことがありましたね（笑）。

ーーいかにも新しいプロジェクトらしくて良いですね。細かい話ですが、タスクの見積はどうしているんですか？このタスクはこのくらいかかるというのが分からない経験はありませんか？

佐藤：1つ1つのタスクに対してみんなで「せーの！」で工数を出すんです。みんなが2時間だと言えばそういうものだし、みんなが1時間って言ってるのに一人だけ3時間っていう人がいれば、それについて徹底的に議論する、っていうことを繰り返します。

成迫：あと、最終的な納期が分からないとよく聞かれますが、細かいものを積み上げるのを1週間づつやるだけなので、最終的にいつ終わるかは分からないし、そもそもこれまでのウォーターフォールの方法論でも納期なんて正しかったことは無かったじゃないか？ だからそんな無駄なことに時間を使うのはもったいないというのが本音ですよね（笑）。

オフィスに飾られていたアジャイル開発に関するマンガ
元ネタ：http://herdingcats.typepad.com/my_weblog/2014/07/the-myth-of-incremental-development.html

ーーエンジニアの評価とかレポーティングについては？

成迫：個々のエンジニアの評価については、結局、チームで仕事をしているのでそのチームの評価が個人の評価になるんだと思います。ただ、違うチームで働いているエンジニアをどうやって評価するのかは、そもそも共通の単位が無いこともあるので難しいとは思いますね。エンジニアからのレポーティングはやっていません。プロジェクトに関してはオーナーが進捗を知っているし、ホワイトボードを見ればわかります。チームで毎日一緒に仕事をしているので、個別の報告書は書かせていません。

ーーそのあたりも開発に集中したいエンジニアにはありがたいでしょうね。

今回は、デンソーの新しいチャレンジであるまだ始まったばかりのアジャイル開発プロジェクトに関するインタビューをお届けした。まだサービスとして公開されるまでは時間がかかるようではあるが、これからも定点観測をしたいと思わせるプロジェクトであった。今後のアップデートに期待して欲しい。