老舗モノ作り企業を変えたのは、「サービス起点」の考え方　エンジニアとビジネスサイドをつなぐ、UXデザインの重要性

部門よりも、チームのサービスを評価すべき理由

岩田和宏氏（以下、岩田）：次に、SaaSプロジェクトをどういうふうにやっていくか。ここはけっこう大きな課題だったんです。部門間の受発注的な体制や制度があったので、そこから部門横断プロジェクト体制を掲げました。

ここは全社的にというところで、いろんな役員と話をしたり、「こういうふうにやらせてくれ」というものを掲げました。部門横断体制にする上で、もちろん事業部門がプロダクトの責任を持つんですけれども、オーナーを置いていただいたり。

ここのプロダクトマネージャはどちらから出すということで、SaaSテクノロジーセンターと品質保証部門といったところを含め、3部門4部門をまたいだ体制で、サービスの軸としてはプロジェクト体制を引いています。

組織上はまだまだ縦割りもあるので、トップから下ろしていただいて、こういう体制でやっていくというところで全社的に発信してもらう。ここで3チームくらいでようやく動いています。

NP1もそうですけれども、PdMを置いて、「PdMって何だっけ？」から始めて、「こういう役割を求めます」といった話し合いをしながらやっています。

そこでプロジェクトチーム体制と、あとはチームタイプとしてプロジェクト型。これがサービスメインのいろんな横断部門で、STCの中では職能横断型で、プラットフォームやAI、各種エンジンを作るところはそういったチームを作っています。あとは横断型職能チームと言うと、ここもそうですね。

SREや全体のインフラの統一、データサイエンスでデータ基盤を作ったりしながら事業部をアシストする部門があったり、技術推進が先端技術を取り入れたりしながら、3つのタイプを定義してやっています。

一番大事なのはチームファーストで、部門の評価ではなく、「チームのサービスの評価が、あなたたちの評価です」というところを、しっかり打ち出しています。

これまでは正直、「事業部が」とか「開発が」というのが枕詞のように出ていたんです。「どっちが悪い」「どっちがいい」ではなくて、「君たちが」というマインドを持ってもらうことが重要だという話を常にしていますし、（自ら）ボールを拾うマインドですよね。

どんなに組織的に有能だと言っても抜け漏れがたくさんあるので、そこをいかに拾えるかがいいチームだと思います。そういったところが大事だと日々訴えています。

エンジニアにUXデザインの重要性を伝える試み

岩田：そんな中で、今の我々に足りないのは何かと言うと、モノ作りにUXデザインが欠けていたんです。青が改善が必要なフローで、赤が体験設計です。

従来はプロダクト計画があって、事業部から技術部へ開発見積もり依頼が来て開発スタートという流れでした。そうではなくて、DevOpsは、サービスロードマップをみんなで作って、チームで初期的なUXデザインをする。ここには事業部もいるし、STCもPdMもいろんな人がいて、開発チームも「じゃあ、どんな開発をするんだ」ということでチームを検討するといったフローに変えます。ここで、ONEチーム開発体制へシフトするという話をしています。

あとは、実際に「体験設計プロセスって何なんだ」というところで、最初のサービスを組む時は、ユーザーリテンション設計やベネフィットトラッキング、KPIとか含めた設計仕様、ユーザーストーリーマップとか、カスタマージャーニーを作ってMVP（Minimum Viable Product：ユーザーに必要最小限の価値を提供できるプロダクト）で進めました。

7割でいいからちゃんと作るところを明確にしようとか、DevOpsのフェーズになったらKPIをしっかりモニタリングして、価値提案をしたり、設計してアップデートすることが大事なんだということを絵にして説明しています。

（この写真は）実際にユーザーストーリーマップを作っている様子です。真ん中の人は、私が引っ張ってきたかなり優秀なUXデザイナーの方です。いろんな新規事業のユーザーストーリーマップを作ったんですけれども、初日はみんな「よくわからない」と恐る恐る離れているところがありました。

モノ作り系のエンジニアもいっぱいいたんですけれども、2日目は積極的に入ってくれるようになり、体験できれば、もともとみなさん優秀なメンバーなので、（UXデザインが）できるんだというところを実感したいい例かと思っています。

これは新規事業でやったんですけれども、こんなことを日々やりながら、UXが大事なんだというのをみんなにわかってもらおうとしています。

ここは、実際にExcelなどでチェックリストを作っています。「こういうのが作られていますか？」とか「こういうのはできていますか？」とか、「アプローチはFirebaseでやるんですよ」とか。

こういうものを作りながら、SaaSプロジェクトのための説明書を作っていく感じですよね。「こういったことをみんなでやりましょう」と書いただけではわからないので、実践的にみんなで一回やりながらやっているところです。

さまざまなルールブックを作成し、ONEチーム体制を推進

岩田：その後、開発チームの組成プロセスにおいても、インセプションデッキをしっかり作って、「我々はなぜここにいるのか」というところから始まって、最低でもこういったメンバーを集めてキックオフしました。

「いろんな選定ツールを作るんですよ」という、「こういう流れでやりましょう」とか、1チームは10人以下くらいにしないと、指揮命令系統を含めて難しくなるので、こういったチームで編成しましょうという説明書をしっかり作ってやっています。

ここまでのまとめとして、バイモーダルITとか、プロジェクト実行でこういったチームスタイルを定義したり、パフォーマンスを高めるチームはどうなのかといった、いろんなルールブックを作成しました。

特に「UXデザインなどの重要さを明確にした設計をするんだよ」ということを通して、日々、事業部や開発の垣根をなくしながらONEチーム体制を推進しています。

塚本洋氏（以下、塚本）：1個だけ。このへんはけっこう大事なところかと思うのですが、1つは41ページにお書きになられていた、事業部側とSaaSテクノロジーセンターが一緒にやりますというかたちで、重なっている部分が大きいところですね。

ビジネスとテクノロジーが一体化しているようなところがミソだと思うんですけれども、実際は相当難しいのではないかと思っています。そのへんのご苦労や工夫がおありでしたら教えてほしいと思います。

岩田：今も四苦八苦しながらやっているのが正直なところです。苦労だらけというか、たぶん（実現したい理想の）体制を引かないと始まらないと思ったので、まず体制を引いて、その後に出てきた課題を今、一個一個つぶしている感じです。

塚本：なるほど。チームファーストみたいなところは大事ですよね。特に会社に所属していると、人ってどうしても縦割りになりがちじゃないですか。

岩田：そうなんです。第1弾はサービス起点を持ってほしいということです。サービスが悪いのはみんなのせいだし、いいのは自分たちの成果だとなる。そこが大事かと思っていますが、本当に細かいことも含めて日々いろんな事件が起きています。

塚本：部署を横断されて、真正面から向き合われている感じですよね。

岩田：そうですね。

エンジニアとビジネス視点を仲介する、UXデザイナーの役割

塚本：あと、UXデザイナーのお話が出てきたじゃないですか。エンジニアのほうがフォーカスされがちだし、採用しなければいけない人数や重要度が大きかったりはしますよね。でも、私もいろいろな現場を見ている中で、デザインの思想が入ることによって、エンジニアとビジネスが一体感を持ってモノ作りをしていけるところは非常にあるのではないかと思うんです。そのへんはいかがですか？

岩田：おっしゃるとおりで、今メインとなっているこの方は引っ張りだこと言うか、いろんな事業部（の開発者から）から「全部やり直したい」というリクエストが来ていて。こういうUXデザイナーの存在はすごく大事ですね。

塚本：エンジニアも「何を作っているのか」という価値に目が行くというか、機能ではなくて、ビジネス側とエンジニア側も会話しやすくなるような効能があるのではないかと思います。

岩田：本当にそうですね。「何のために」という目線が合ってくるんですよね。UXデザイナーという観点で、間に入ってくれる人が1人いることは非常に重要なので、今はここを育てようとしています。

塚本：わかりました。ありがとうございます。では、最後に2つまとめてお話しいただいて締めにしましょうか。お願いします。

データ分析どころではない、ゼロからの立ち上げの苦労

岩田：1つはデータ分析に関するプロジェクトについてです。私も入社して最初に一番びっくりしたところなんですけれども、当初はデータ組織自体がなくて、ベンダーさん任せになっていました。そこで、そこから全社的にどうしていくのかを含めて、データチームを作りました。

全社横断でビジネスをリードするというところで、データインテリジェンス部をSTCの中に作りました。LINEやユニクロ・楽天などを経験したメンバーがちょうど入ってくれたので、リーダーはこの人を立てるしかないと思って進めました。

ここは今はもう2人くらい増えていますけれども、生え抜きのパイオニアのメンバーの若手や、メルカリから来たメンバーがちょうど融合して、いいモデルになっています。パイオニアのメンバーからすると「別の会社に来たみたいだ」という話も出ているくらいで、ここが一番小規模かつSaaSを実践しているチームになります。

我々はB2BからB2Cまでいろいろやっているんですけれども、こういうKPI設計を事業部と一緒にやったり、目的設計をしたりしています。グッド（いいね）のマークがついているところが、実現できているところです。

今、データ設計や収集を手伝ったり、可視化や分析をしています。あとはSQL習得の教育もミッションとしてやっています。

50代の営業社員がSQLを扱えるまでにカルチャーが激変

岩田：ここは簡単にまとめると、データの全社横断組織を作って活動しています。少数精鋭でフラットな、一番アジャイルなIT会社っぽい雰囲気でやれているチームになっています。

「データを見るカルチャー」というのは、SQLなどがぜんぜんわからなかった50代の営業の方が、自分でSQLを叩いてデータを引っ張ってきたといった話です。そこでみんなで感動したというか、「ここまで来たな！」という思いがあったりしています。

次は業務DXです。簡単に紹介すると、従来は紙での契約手続きや数十ページの登録システムがたくさんありました。そこで何をやったかというと、当たり前ですけれども、デジタル化です。ここはよくあるDXの話だと思うんですけれども、そんなことを実践しながら、「まだ山登り中です」という話です。

これも実際に我々が1年くらい前にやった話です。とあるプロジェクトの中で、関係する部門や業務フローをまとめました。

契約から導入、インストールとか、ハードの納品からカスタマーサクセスを含めて、何が起きているのかを全部可視化して、どこで分断されていて、どこに手作業が入って、CSVの入力が入っているのかを含めて現状を知り、「じゃあ、どうやるのか」と。

一番大事なのは、全部を可視化することなんです。何が起きているのかが可視化できないと、みんながクリアにならないので、いろんなステークホルダーを呼んで、3〜4名でやりました。

何を目指すのかというと、「Customer 360」みたいなかたちで、顧客を向いてやっていくことです。開発もマーケティング・インサイドセールスも、カスタマーサクセスもそうです。

今は1年くらいかけてようやく、営業やいろんな年代の方たちもちゃんと「Salesforce」でフォーキャストまで入力して、それを中心にきちんと回せる体制になりました。モビリティサービスカンパニーのCCO 兼 CMO石戸（亮）が中心になっていろいろやってくれているんですけれども、カスタマーサクセス体制でいろんなことを進めています。

理想のエンジニアは、どんなスキル・マインドの持ち主か？

西澤直樹氏（以下、西澤）：ありがとうございます。では、変革に必要なところまで、最後に振り返っていただければと思います。

岩田：ここはエンジニアの話ではないのかもしれないんですが、エンジニア採用をする時に「こういう人がいいですよ」という話だと思っていて。エンジニアリングって「創る」ことが大好きなのが大事なんですが、自走力ですよね。ベンチャー、スタートアップ、大企業でも共通して言えることだと思います。

コミュニケーションをしっかり取れるところとか、特に最近は要求エンジニアリング（あいまいな要求を取り込み、何を開発すればよいかを明確にし、文書化すること）ができないエンジニアは多いんですけれども。

ビジネスの理解や背景のモデリングをしっかりして、体験（UX）プラス実装力を持ったエンジニアが理想なんだというのを、うちのエンジニアにもよく話をしています。

必要なことは本当にいろいろあるのですが、一番最初に「成し遂げられる組織をつくる」としています。リーダー・人材を集めることが大事だなと。経験のある人がいないと、特にQCD（Quallity、Cost、Delivery）がはっきりわからないんですよね。それは致命的なので、リーダーをしっかり集めて立てることは必要かと思っています。

（次が）「戦略・戦術を描き実践する」です。どこの会社でも戦略を描くんですけれども、戦術までドリルダウンして実践するまでハンズオンしなければいけない。ここがすごく重要だと考えています。

あとは、評価制度やMission Vision Valueも、特に大きい会社はあまり変えないんですけれども、我々は人の集まりなので、部門単位でもいいので、「何を目指すのか、何を大事にするのか」は大事にしたほうがいいのかなと考えています。

最後、マインドセットです。ここは非常に重要で、受動的マインドからプロアクティブに変わるだけで組織が大きく変わります。組織・評価の制度も変えなければいけないでしょうし、何をすればいいのかを日々考えながら行動しています。

あと、歩み寄りと強制のバランスもあります。歩み寄りという、しっかり説明して理解を得ることも大事なんですけれども、ある程度強制して導くところのバランスがすごく大事だといろんなマネジメントをしていて思います。

マーケティング活動をどう「手の内化」していけるか？

西澤：ありがとうございます。最後に、本編の中で1つお伺いできればと思いますが、先ほどデータ活用を手の内化していく、自分たちで活用できるようにしていくというお話がありました。そのデータはもちろんサービスや事業に活用されていくと思います。

一方、マーケティングです。実際にお客さまに何かサービスを提供したり、コミュニケーションをしていった時に、本来そこも含めて内製化をしていくべきだと思っています。どちらかと言うとデジタルマーケティング側の担当者は、広告代理店や我々のようなパートナーと一緒に組んでお仕事をするケースが、今までは圧倒的に多かったのではないかと思っています。

その中で、御社のマーケティング側の方たちが、どういうスキルを習得されようとしているのか。自分たちでマーケティングの技術やSaaSのプラットフォームを使いながら、マーケティング活動そのものをどう手の内化していけるのかという点について、お伺いできればと思うんですが、いかがでしょうか？

岩田：そもそもデジタルマーケティング部門がなかったので、今はいろんな経験者を含めて、マーケティングオートメーションツールなどを導入するところから始めています。

西澤：今の開発現場の中にマーケティング担当者や機能をを入れて、そこも一体的に運用ができる体制を目指されてらっしゃるわけですね。

岩田：そうですね。デジタルマーケティングを含めて、まさしく今、この体制を目指しています。なので、（デジタルマーケティング担当が）数名来たんですけれども、そこから劇的に変わってきているところです。

西澤：ありがとうございます。ちょうどお時間だと思いますので、いったん本編はこちらで終了とさせていただきます。みなさまからお寄せいただいたご質問は、後ほどご回答させていただきます。

「出したら終わり」のプロダクトアウトの文化を変える苦労

司会者：岩田さま、西澤さん、塚本さん、ありがとうございました。それでは、岩田さまに再度ご登壇いただき、質疑応答に移らせていただきたいと思います。よろしくお願いいたします。

塚本：貴重な機会なので、ご質問があればどんどん投稿してください。もしご質問がなくても、「この質問いいな」と思ったらいいねを押していただければ、多いところから質問していこうかと思います。

Zoomにも質問いただいているんですけれども、事前申し込みの時にもいただいている質問があるので、最初はそこからお話ししたいと思います。今回は製造業として変革していくというところがあって、製造業からSaaSの企業になっていくとか、サービス企業になっていく上でご苦労されたことは何か、というご質問をけっこういただいています。

とは言え、今日のお話は製造業ではなくても同じような課題で、同じような対応ができるところはあると思っています。質問が難しくなってしまうかもしれないんですけれども、製造業ならではでご苦労されたところや工夫されたところを、「製造業でなくてもデジタルをやる上で普遍的に必要なことですよ」という部分があれば、お話しいただけないでしょうか？

岩田：一番苦労したのは、バイモーダルのところです。開発プロセスやマインドがまったく違うので、そこですよね。

「アジャイルって何？」というところから始まるので、「アジャイルってこういうものだ」とか。その後サービスとして出してからが勝負で、そこをいかに改善しグロースできる体制に持っていけるかということも含めてですね。

プロダクトアウトの文化だったので、「出したら終わり」だったんです。出して利益を見るようなかたちで、あとはマーケティング次第だったんですけれども。

そこへの理解は、何度も口で言って本にもいろいろと書いてある中で、実践していかないとわからない部分があるので、今はまさしくそこを体験しながら変えているところです。今も一部、苦労はしています。

塚本：「作ってから売る」ところから、「作りながら売る」というか、「売りながら作る」というか。そこへの変革で、カルチャーの壁がだいぶ大きいのが製造業の特徴だというところですね。

岩田：そうですね。

ベンチャー企業とも共通する、チーム作りの型

塚本：ただ、その一方で、前回たまたまカインズさんにもセミナーでお話しいただき、似ている話が非常にたくさんあったんです。今回の組織の考え方やプロダクトの作り方、エンジニアの考え方、UXの考え方は、例えば金融業でも小売業でも普遍的なことが多いと感じたんです。

製造業だからこう、というわけでもないと思っていて、実際のチームを作る中身はベンチャーとも共通性があるのではないかと思うんですけれども、どうですか？

岩田：そうですね。そこは共通性があります。ただ単に体験しているかしていないかの違いというか、そこをいかに体験させて埋めるかという感じですよね。型とかやり方はほぼ一緒ですね。

あとはサービスをやる以上、ライバルはSaaSカンパニーやIT企業になってきます。ベンチャーやスタートアップも入ってくるので、同じスピード感でやらないと、確実に負けてしまいます。

塚本：目指すべき姿は一緒で、たぶん業界や業種ごとに持っている課題や、そこへのアプローチの仕方が違うというところで、たぶん製造業ならではのご苦労はいっぱいされているんだろうと、あらためて（感じます）。

岩田：そうですね。そのギャップの埋め方のアプローチは、たぶん業種ごとにいろいろあるかと思います。

安心･安全に関わる開発とそれ以外は、明確にルール化して区別

塚本：ありがとうございます。次はZoomからのご質問です。一番いいねが多いのが、「カーナビ等の車載器など、人命に関わる部分もあり、アジャイルやトライ＆エラーと馴染まない領域もあると思いますが、従来のモノ作りとアジャイルのバランスや住み分けを、どのように考えられていますでしょうか？」というご質問はいかがでしょうか？

岩田：そこはおっしゃるとおり、IoTのTのThing、モノのところは、従来の品質保証のゲートチェックや、特に安心・安全のところは徹底的にやっています。

例えば、お天気ニュースを流しますといった、OTA（Over the Air：無線経由でデータを送受信する技術）サービスの部分など、特に人命に関わらないところはアジャイル的なプロセスでチェックします。

そこはちゃんと会社の基準があって、安心・安全のところと、単純にSaaSサービス的な要素はわけていますね。ネイティブアプリのアップデートといったところはどんどんやっていきます。そこはルールを明確にしています。

ただ、そういったところ以外は、「すばやくデイリーで、どんどんアップデートしましょう」というマインドはあります。

塚本：なるほど。逆に製造業という言葉って、安心・安全に返すだけの強みがたくさんあるので、そこは大事にしつつ、そうではなくてもやれるところをちゃんと切り出して、アジャイルが適しているところ・そうではないところを、うまくハイブリッドにされているイメージですかね。

岩田：そうですね。だから、ハードはウォーターフォール的なプロセスもあるし、アジャイルはSaaSのアジャイルになるので、同時のリリースタイミングを合わせるというのはけっこう大変ですよね。そこは難しいと、今も思っています。

塚本：たぶん他社さんでも、（ソフトと）ハードを両方やれているところは同じようなご苦労も聞くので、うまく社内でいろいろトライ＆エラーしながら、やり方そのものもアジャイルに変えて最適を見つけられている感じですよね。

岩田：そうですね。基本はONEチームにして、モノ作りチームもプロジェクトの中では一緒なので、ここで連携はしています。

塚本：さっきの交わっている横のチームの中に、ハードウェア系やソフトウェア系、安心・安全とやれるところとどんどんやれるところ、両方が混ざって本当にONEチームになっているというところですよね。お客さま第一で作っていくという。

岩田：はい。

外資系企業で感じた、効率的でドライな意識

塚本：ありがとうございます。いいねが多い順に行きますと、「岩田さまは外資企業と日本企業、どちらにもおられましたが、DXについての意識の差は、どの程度あるものでしょうか？」というご質問をいただいているんですけれども、いかがでしょうか？

岩田：私も（外資は）1社しか行っていないんですけれども、人に対する考え方とか、そもそもいろんなことが違うじゃないですか。終身雇用的なところが多かった日本と、昔からジョブ型なんて言葉がないくらいスペシャリストが集まってやっている欧米とかは基本、そうだと思うんです。

私はプログラマーだったんですけれども、当時の日本ではプログラマーというときつい仕事みたいなイメージで、アメリカだと超優秀な人がなる仕事という感じで、ぜんぜん違いましたね。

いろんなことがあったんですが、いろんな意味で、外資系企業はデジタルネイティブなんだろうなという。効率が当たり前になっていて、ドライとウェットの差はすごく感じます。

内製化を進めてきて、一番良かったと思えること

塚本：わかりました。ありがとうございます。最後の質問は「内製化を進める上で苦労したこと、内製化をしたことで一番ポジティブだったことは何でしょうか？」。せっかくならポジティブに終わりたいので、内製化して一番ポジティブになったこと、よかったと思ったことをお話しいただけるでしょうか？

岩田：顧客目線とか顧客起点、サービス目線での話が増えたことです。自分が一番気にしているのは「内向きか外向きか」です。正直、内向きの仕事が非常に多かったのもあるので、よく言っているんですけれども。内部調整、社内調整、会議のための会議、事前会議ではなくて。

顧客やサービス、プロダクトを見る、外向きの話に時間を使ってほしいんです。そういった意味だと、内製化して見えてきたところを含めて、外向きの話やサービスベースの話が増えたところはあります。

塚本：今の話は、意外とおもしろくて、内製化しなくても、本来であればカスタマーファーストは狙えたはずだとは思うんです。でも、カルチャーを変えていくことと内製化という体制を変えていくことを、セットでやらなければいけない。そういうものを伴う部分があると思いました。

岩田：内製化と外注だと、正直、「プロダクト愛」はぜんぜん違いますよね。

塚本：愛があると、お客さまに使ってもらいたいとか。

岩田：あとは自分ごとになりますよね。

塚本：最後にいい話、ありがとうございました。Q＆Aは駆け足でしたけれども、以上になります。ありがとうございました。

岩田：ありがとうございました。