1. トップページ
  2. セミナー
  3. 【プロダクト責任者・DX推進担当向け】DX推進の要はプロダクトファーストにあり! ~ソフトウェア開発の現場から見た成功法則~

更新日: 2022年05月30日

【プロダクト責任者・DX推進担当向け】DX推進の要はプロダクトファーストにあり! ~ソフトウェア開発の現場から見た成功法則~

経済産業省はDXを「デジタルを活用してビジネスモデルや製品・サービスを変えていくこと」と定義していますが、同時に「業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること」と定義しています。

しかし、経営戦略や事業戦略ではDXを標榜しつつも、DXを成功に導くようなソフトウェア開発を中心とした企業文化やプロセスの変革に成功している企業はまだ一握りではないでしょうか。

本セミナーでは、メンバーズグループでアジャイル開発の支援を行っているメンバーズエッジ・カンパニー社長の塚本 洋より様々な顧客のデジタルプロダクト開発現場における事例や学びをもとに、DXがうまくいく現場・うまくいかない現場を考察します。
そこからDXを成功させるために必要な企業カルチャーや開発プロセスの変革や、真に競争優位性がある組織づくりのヒントをご提供致します。

セミナー内容

DX推進の要はプロダクトファーストにあり! ~ソフトウェア開発の現場から見た成功法則~

  1. メンバーズのご紹介
  2. DX推進と「内製化」の背景整理
  3. 企業ヒアリングからの示唆
  4. DXが成功する現場、失敗する現場
  5. まとめ
  6. メンバーズの課題解決アプローチ

登壇者紹介

塚本 洋

塚本 洋

株式会社メンバーズ 常務執行役員 兼 メンバーズエッジカンパニー社長

ジェーシービー、ソフトバンクグループを経て、2004年に株式会社メンバーズに入社。
プロデューサーとして、国内大手企業のWeb戦略策定、サイト構築・運用を多数支援するとともに、自社の中期経営計画の策定、SNS事業の新規立ち上げ、アジャイル開発・UX部門の設立などを行う。
2017年に株式会社メンバーズエッジを設立し代表取締役に就任(カンパニー制移行に伴い現在カンパニー社長)。
「開発現場から世界を変える」を合言葉にアジャイル開発で顧客のプロダクト開発を支援するエンジニアリング事業を推進している。

はじめに

メンバーズの塚本 洋と申します。今日はよろしくお願いします。

私たちは「お客さまのDX推進」ということで実際のデジタルプロダクトやソフトウェア開発をアジャイルで支援するということをおこなっております。

そういった現場でこのようにすれば上手くいくといった成功パターンやアンチパターンがたくさん出てきましたので、その事例を後半にお話したいと思います。

前半につきましては「DXとは何か?」といったところ、また「内製化」といったキーワードを出しますが「どうすればDX上手くいくのか」についてお話しします。また私は11社ほど大手企業を中心にDX推進についてお客さまにヒアリングをおこなってきましたので、そこから出てきたお客さまの悩みであったり、上手くいくためのパターンについてわかりやすくお話していきたいと思っておりますので、よろしくお願いします。

自己紹介

改めまして塚本 洋と申します。

私は株式会社メンバーズの常務執行役員をしておりますが、その他にも「メンバーズエッジカンパニー」の社長でもあります。

私がメンバーズに入社して17〜18年ほど経ちます。元々はWebサイトの戦略策定やサイト構築をおこなっておりました。2017年からはメンバーズエッジという子会社を作り、アジャイル開発であったり、お客さまのプロダクト開発の支援をおこなってまいりました。本日はそこで得た知見をお話できればと思っております。

背景の整理

では今日の話の背景の整理からおこなっていきたいと思います。

基本的には「DXはどうすれば上手くいくのか」というお話をしたいと思います。こちらは経済産業省が出しているガイドラインからの引用です。

DXというのは「製品やサービス、ビジネスモデルを変革するとともに、業務そのものや組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること」と書かれております。

つまりは「どれだけ良い製品やどれだけ良いサービス、どれだけ良いビジネスモデルを作ったとしてもそれを実行していけるようなカルチャーや風土がなければ成功しない」ということです。図の右側がいかに大事かということです。

ですので、本日は「イケてるDX」についてお伝えするのではなく「どうすればDX推進するためのプロセスや風土を作っていけるか」というお話をしていきたいと思っております。

こちらはIT人材白書2020からの引用です。

その中にキーワードとして内製化という言葉がありまして、こちらについてDXに取り組んでいる企業とそうではない企業でどれくらいの差があるか見ていきますと、

DXに一生懸命取り組んでいる企業ほど、ITやデジタルのスキルを強化していくために内製化に積極的に取り組んでいるといった傾向が出ています。

システム開発や企画など、色々なプロセスの中でおこなっていかなければカルチャーや風土を変えていけないということで、DXに取り組んでいる企業ほど内製化を一生懸命におこなっております。

少し前に日経コンピュータさんでも「内製の極意」といった特集を組んでいたこともありまして、内製化という言葉をご存じの方もいらっしゃると思います。DXを上手くおこなう、つまり風土やプロセスといったものを改革していくためには内製化をおこない、中ではITの人材を育てていく必要があります。

「何でもかんでも内製化をすれば良いのか?」
「全て外にお願いしてはダメなのか?」という話ですが、

「内製化に向いているシステム開発」
「内製化しなくても良いシステム開発」

があると思っています。

例えば、答えが見えていて従来のメンバーで上手くできているものをわざわざ内製化する必要はありません。

図の右側にデジタライゼーションと書かれていますが、いわゆる「DX」と呼ばれているデジタル分野におけるサービスモデルの変革をおこなっていくうえで内製化が不可欠と考えております。

あらゆる企業がデジタルサービス会社に

何年か前のトヨタさんのWebサイトに載っていたのですが、トヨタさんは自動車を作る会社からモビリティカンパニーにモデルチェンジしていて、現在ではそのサービスを提供する会社であるということです。

サービスの提供はもちろんデジタルを通じてということになりますが、トヨタさんのような業界トップクラスの自動車企業が製造業から「サービス企業」に変わりつつあるということです。

従来の製造業としてのカルチャーやプロセスではなく、デジタルサービスの会社としてのプロセスや風土が新たに必要になってきます。

会社がDXを推進していく場合「われわれはデジタルサービスの会社なのだ」と会社の捉え方を変えて、その上でどのようにソフトウェアを作っていけば良いのか、プロダクトを作っていけば良いのかということを学んで身につけていく必要があるとお考えいただくのが良いのではないかと思います。

デジタルのサービスになっていくと、従来とマーケティングの方法が変わります。

図のようなパターンだけではありませんが、基本的には製品やサービスを企画し、それを完成させてから、どのように売っていくかというマーケティングをおこないます。

ですが、現在は右側のデジタルサービス(プロダクト)に変わってきておりまして、クラウドサービスやSaaSもそうですし、製造業ですとアプリを絡めて車を利用してもらうというのであれば、アプリ側がまさにそうだと思います。車の中にあるものであればソフトウェアをアップデートしていくといったものが該当するでしょう。

製品やサービスを作りながらマーケティングをおこない、フィードバックを経て、製品やサービスを成長させていき、マーケティングの在り方を変えていく。そういった形でプロダクト開発とマーケティングを並行させて、常にプロダクトを成長させていくという風にビジネスのルールが変わっていくということです。

DXを成功させるには、組織やプロセスを変えていく必要があります。その背景にはビジネスのルールが変わっているということもありますし、少なくともDXやデジタルのサービスを推進する領域においては従来のやり方ではない新しい作法が必要になってきているということを理解することが大切です。

昨今「プロダクト」というような言い方をよくしますが、プロダクトをグロースしていくといったような、そのために何が必要か、どういう組織が必要か、そういったことを理解していかなければならないと思っております。

「Point of Sales」から「Point of Use」へ

この辺りは昔から言われている話ですが、どこにサービスやプロダクトの価値を最大限にもっていくのかという考え方についてです。

先ほどの左のモデルに近いのですが、業務システムを作るようなことであれば、作って、納品して、出来上がった時点の価値が最高であり、あとはそれを維持していくことになります。その後、何年か減価償却をおこなった後に新しいものを作ったり、古いものを廃棄することになるでしょう。

デジタルのサービスやプロダクトを上手く作ること自体が「DXの成功」であると仮定しますと(もっと低いところからスタートしても良いとは思うのですが)できるだけ早い時期にリリースをして、モノの価値を上げ続ける、常にアップグレードしていくといった「Point of Use」といった考え方が大事になってきます。

そういったものをおこなっていくためには、先ほど申しました「内製化」が大事ですし、プロダクトを成長させていく、グロースさせていくといった発想が大事です。

常に変化や新しいマーケティングから得た知見を基に、プロダクトをアップデートしていく、小さく産んで大きく育っていくというところをスムーズにできる社内体制を作っていくことが、内製化をする上で非常に大事になってきます。

最近「アジャイル」という言葉をよく聞きますが、そういった開発アプローチといったものも必要であると捉えていただければ良いのかと思っております。

単純に内製化と言っても、単純に社員やエンジニアを取れば良い、中で開発すれば良いという話ではなく、それをスムーズにおこなうために色々なことをおこなっていかなければなりません。

内製化と言っても、必ずしも純血主義のような形で社員だけでおこなう必要はありません。私たちのような外部パートナーと一緒に内製の思想で組織づくりをしていく方法があります。

その他にも色々と内製化を成功させるためにおこなっていかなければいけないことがあります。

図に書かれているような5つの項目をおこなわなければプロダクトをグロースさせていく、DXを成功させていくことは難しいとご理解いただければ良いのではないかと思います。

私たちはシステム開発のご支援をしていますが、よりお客さまの課題解決をしていくにはどういったことをおこなえば良いのかヒアリングをしてきました。お客さまがどのように取り組まれているのかということもこの先お話ししたいと思っております。

ヒアリングからの示唆

必ずしもメンバーズグループのお客さまというわけではないため、具体的な企業名は伏せさせていただきますが、大手企業さま11社にDXというものをどう捉えてどのように進めているかお聞きしてきました。

大手企業の代表者の方、CTOであったり、DXを担当されている役員、もしくは部長レベルの方、そういった方に「何が課題ですか?」といったことを含めて聞いてきました。

注意事項としまして、これは「私の主観」ですということです。

誰しもがDX推進を一生懸命おこなっているわけではありませんし、内製化で社内に開発チームを置いて、柔軟にプロダクト開発をしていく、俊敏性を持ってソフトウェアの開発をしていくということに取り組めているわけではありません。かなりバラつきがあります。

図は主観的にまとめておりまして、おこなっている事業そのものがデジタルに親和性があるかどうかというところを横軸に入れております。これは企業のカルチャーもあると思いますが、「DXをやらなければならない」という危機感を持っているかというところを横軸にしております。

例えば「教育」ですと、授業を動画で見るですとか、デジタル化しやすい面がありますし、

テストの実施もオンラインで可能です。極めてデジタルとの親和性が高いと思います。

反対に「食品」ですと、食品は基本的にはマス広告で店頭に並べることで買ってもらえるという事があります。DXを推進しないと、事業そのものが立ちいかなくなるというような危機感はあまりありません。実際に親和性に関してもさほど高くないと思います。

このような感じで企業を分けていきますと、企業がどこに分類されるかということで、よりDXについてどれくらい取り組まれているかがわかります。

・デジタルとの親和性が高い
・デジタルを通して事業が成長している
・ユーザーが獲得できている
・ベンチャーが参入&強豪が競り合っている状況が発生している

このようなところは内製化に成功していると言えますし、成果が出ているのではないかと思います。

例えば小売業の場合はアマゾン・エフェクトのようなものもありますし、海外のウォルマートの成功事例もありまして、危機感があると同時にデジタルの親和性も高いと言えます。

また危機感がありつつも、まだまだ取り組み自体に課題があります。内製化していきたいと思ってはいるが上手くおこなっていない、そういった企業は左上に該当しています。

われわれから見ますと「非常にデジタルとの親和性が高いな」と思いつつも、業界そのものは競争があまりない、ベンチャーが参入しづらい、規制があるといったところもあります。し、私が聞いた国内のトップ企業を例に挙げますと、デジタルとすごく親和性が高そうな事業をおこなっているのに、あまりそれに関して力を注いでいる様子もなく、子会社に任せているといった状況になっておりまして、

「内製化を進めよう」
「ソフトウェアファーストでおこなっていこう」
「プロダクトを作っていこう」

といった思想そのものがあまりないといったところが多かったように思います。

色々聞いているとやはり組織体制というものが色々あるわけです。

よくあるのがDX推進部、DX戦略部といったものはほとんどの会社さまで設立されているのが現状ではないかと思いますし、私が聞いたところでは大体そうでした。

だいたいが図の左のパターンです。組織横断型の部門が出来上がって、各部門のDXの取り組みを支援したり、情報収集したりといったものです。

もう少し取り組まれているところは、事業部門からDX支援部門のようなところに開発を依頼されていて、そこである程度管理しつつ、外部パートナーに投げていくといった形になっています。

先ほどのマトリクスで右上にあった企業の中で、本当に上手くいっているなと感じた企業さまは、ビジネスと開発が1つのチームになっていて、ビジネスの現場にデジタルの開発チームがありますし、外部パートナーの方も支援に入っています。

ビジネス人材とソフトウェアの開発チームがワンチームになっているというのが内製化が上手くいっている企業さまの中で共通している特徴でした。やり方をすごく熟知されていますし、多くの経験を積まれている印象を受けました。

多かれ少なかれ、DXを本気で推進していく企業さまほど図の右側のような形になるのではないかと思っているのですが、なかなか右側にいくのは容易ではないということがヒアリングの中で浮かび上がってきました。

右側が良いといっても、従来の「つくって売る」という発想からすればカルチャーギャップがすごくありまして、良いということのが一部の人に分かっていても、会社としてはなかなかそちらに移行していけないといった問題であったり、ビジネスとドメインはある程度わかるものの、これまではデジタル領域のシステム開発は投げてきたり、予算を取ってきたりすることを考えてきただけだったために、デジタルを推進していくためのコアとなる人材が不足しているわけです。

プロダクトファーストのようなところもありますが

「デジタルのサービスやプロダクトを作って成長させていくためのノウハウがない」
「ただ言われたことを作るだけで終わってしまう」

そのような従来型のものづくりになっているといったところがありまして、このような課題を乗り越えていかなければ、DXを推進していくようなプロダクトファーストの組織作りを上手く進めることは難しいのではないかと思います。

内製化を妨げる課題は、

「エンジニアがいない」
「採用が上手くいかない」

といったことではなく、カルチャーを変えていかなければなりませんし、コア人材を育てなければなりません。またプロダクトマネジメントの手法を持ち込む必要もありますし、プロダクトにコミットして成長していけるような開発体制を作っていかなければなりません。

人材の問題ではなくアプローチの問題であったり、カルチャーの問題であったり、そういった単にエンジニアを採用するだけではない課題があります。

この辺を乗り越えていかないと「DX巧者」と言われているような組織変革をしていけないでしょうし、プロダクトファーストやソフトウェアありきのDX推進を進めることは厳しいでしょう。

それを阻んでいるプロセスについてですが、「DX」と「戦略」といった描き方をすると「これらを実行しましょう」という風に予算がつきます。

社内予算を通すときにやはり企画のところに予算を使ってしまったりします。決まったものを作るだけで先ほどのような「つくりながら成長させる」ような、マーケットに対応しながらプロダクトを成長させるような発想ではなく、従来のいわゆるウォーターフォールのプロセスになっているけれども、社内の予算を取る流れがそのようになってしまっている。もしくは経営会議で決議をもらうのも、こういったプロセスを通さないとダメだという風になっています。

大きな企業のDX変革のプロセスそのものを変えていかなければなりません。経営レベルで意思決定の方法を変えていかなければならないのだろうなということをヒアリングをしていく中で感じました。

社内にチームのようなものを作って内製化に取り組むことはありますが、従来のIT産業はSIerの二重受け、三重受け構造がよくないと言われておりまして、これ自体も機能するようなジャンルもありますので、このこと自体は悪ではないのですが、先ほどのように作りながら、売りながら開発をして成長させていくようなところで言いますと、従来の構造はすごく機動性に欠けるわけです。

ですので、アジャイルが良いといった話になるのですが、結局社内で開発しているけれど、事業部門の人がいて、DX推進部が間に入って、IT情報システム部門があって、開発者は中で雇っていますとなっても、構造同じだとプロダクトを成長させていく、つくりながら変化に対応していくといった構造にならないわけです。そういうところを乗り越えていかなければならないと非常に感じました。

組織の話でもありませんし、人材だけの話でもありません。

もちろんどちらも大事ではあるのですが、そのコアにあるビジネスの捉え方とか、チームを作ってそれを変化に強くしていって育っていくといったカルチャーであったり、プロセスや思想も含めて「DX」というものを受け止めていかないと、上手くいかないということが色々な企業さまからのヒアリングで改めてわかったことです。

成功する現場、失敗する現場

われわれは実際に開発チームのエンジニアとしてチームのお客さまと一緒に開発をおこなったりするわけですが、そこでどういった現場が上手くいっているのかについて、現場視点、エンジニア視点が色濃いとは思いますが、成功パターンなどについてお話ししたいと思います。

これにはいくつか法則があります。

1つ目は基本的なソフトウェア開発は最初に作るものを決めて、それがどれぐらいでできるのか見積もりをするわけですが、本当に上手くいっているところはチームを固定しています。チームで「1月に1回リリースしていこう」と決めているわけです。

それを永続的なチームとして置いておき、優先度が高いものを見積もっていく。このような考え方でチームを作っていることが上手くいっている企業さまの共通する特徴です。

「良いチームを作るためにどうすれば良いかということをしっかり考える」

チームを最初に作ってから作るものを後から決めるなんて、何だか上手くいかない気もしますが、そういう考え方が実際には上手くいっているわけです。

その上で「どういうチームを作れば良いのか」という話になってきます。

先ほど、のデジタルのサービスを作りながらマーケットに適応していく。成長させていく。といった捉え方をした上で、それを「プロダクト」と呼ぶと、図にクロスファンクショナルチームと書いていますが、そのチーム内である程度自分たちで必要な機能を有していた方が、変化に強いですとか、スピード感が出るということです。成長に寄与できます。

同じチームの中にビジネスの人、エンジニアの人、デザインの人をワンチームにしていく。

独立してそのチーム内でおこなえる単位でチームを作っていく。そういった考え方をしっかりとすることが大事だと思っております。

ですので、職種ごとに組織を分けたりすることもありますが「変化に強い」という意味で求められているのは、職種をまたいだ機能横断型チームを作って、そのチームにある程度裁量を与えて、サービスを作っていくそういった発想でチーム作りをしていくことが大事であると思っております。上手くいっている企業さまはそういった作り方をされています。

S:開発者とビジネスは膝を突き合わせる ビジネスとソースコードの距離を近づける

あとは「開発者とビジネスの担当者の距離がいかに近いか」です。私たちは受託で開発支援をしているのですが、お客さまと日々膝を突き合わせて仕事をすることを大事にしております。

お客さまの方がプロダクトマネージャーなどを置くことが多いですが、そういった方とワンチームで近い距離で仕事をするといったことが非常に大事だと思っております。

次に実際にプロダクト開発をグロースしていくときにどういったロールが必要かということを参考に出しております。

真ん中にプロダクトマネージャー、そういったロールの人がいまして、それを支える形でデザインのアプローチ、色々なデザイナーがいます。

マーケティング系をやっていくのであれば、マーケティングプランナーといった方が寄り添って開発順を決めていくところの下にエンジニアであったりとか、スクラムでやる場合ですとスクラムマスターを置くのが一般的です。そういった形でフラットなチームを作りおこなっていく体制づくりが一般的と思っております。

逆にデジタルネイティブのベンチャーさんのやり方を学んだ方が大手企業へ転職などで入ってきたりして、プロダクトマネジメントを持ち込むといったやり方が成功される企業さまで見られる傾向です。プロジェクトマネジメントやプロダクトグロースに必要な体制については、ロールもしっかりと作って取り組むことが必要であると思っております。

その中心に「プロダクト」というのがありまして、変化の激しいマーケティングに対応していくということなのですが、

・プロダクトがどのような価値を提供するものなのか
・どういうものがあるべき姿なのか
・どういう風に開発していくのか
・どのようなユーザー・ニーズに答えるのか

といったところを考えていくということでセミナーの見出しを「プロダクトファースト」と書いていますが、プロダクトマーケティングといったものを学んで、それに精通した、そのカルチャーに対応できるチーム作りをしていくことが非常に大事だということを申し上げています。

そのやり方についてですが、こちらは私たちの事例です。

インセプションデッキと言われるものを作ったりするのですが、

「プロダクトの理想は何なのか」
「あるべき姿は何なのか」
「何のためにおこなっているのか」

といったプロジェクトのビジョンをチームメンバーで共有していくのが非常に大事です。

先ほどクロスファンクショナルチームというものがありましたが「私は言われた機能を作るだけです」「私はデザインするだけ」ではなく「こういった社会に、こういったプロダクトを提供していく」ということをみんなで共有して、ヴィジョンを明確にした上で作っていくことが非常に大切になっております。

それが理想のプロダクトの目指すべきものだとしたら、これはユーザーストーリーマッピングと言いますが、どういうユーザー体験を機能的に提供するのかについて、ビジネス側とエンジニア側ですり合わせて作っていくものです。

「MVP」などとよく言われますが「最低限必要なものは何か」「一番最初に作らなければいけないものは何か」について話し合って、アクティビティに落とし込んでいき、チームとして何を優先的に作るかを一緒に決めていきます。

これは「Miro」というツールの画面を並べております。

別にスプレッドシートや専用のツールで管理しても良いのですが、このようなプロダクトで、こういったユーザー体験を提供したいということが決まったら、優先度が高い順に並べるわけです。これはアジャイル開発の一般的な手法なのですが、本当に価値が高いものから作っていくということが非常に大事です。

「全部作って」とか「全部大事です」とか「全部盛り込みたい」「3ヶ月後のリリースまでに全部作ってください」というようなことを言われるということは、ありがちなケースです。

そうではなく「プロダクトの理想はこう、最低限のば必要な機能はこれ」ということをみんなで話し合って、優先度の高いものから作り、どんどんリリースする発想の方が上手くいくでしょうし、実際作らなくて良いものは結構多いわけです。

作りかけのものは基本的に価値を生みませんので、優先度の高いものからどんどんマーケットに出していって、反応を見てみるといった発想で、リリースしたい優先度で順番に並べることはソフトウェア開発の場では大事なことですし、DXの成功にもつながってきます。

セルフマネジメントといったキーワードも結構大事です。先ほどピラミッドのようなものがありましたが、何を作るかを最初に決めてしまうわけです。

場合によっては稟議書を書くときに設計に近いようなことをおこなって「この通りに作ってください」とエンジニアに指示したりします。それはそれで100%分かっているものであれば良いものができるでしょうし、企画が正しいのであれば特に問題はないとは思います。

ただ「本当に企画が正しいか」や「一人の知恵で考えたものが本当に良いものかどうかわからない」もしくは「マーケットに出してみなければ反応がわからない」という場合は、何を実現したいかを開発チーム側に伝えて、どう作るかなどはチームで考えてもらいますう。そういったチーム作りであったり、やはりビジネス側から開発者へのアプローチを持ち込まなければ、真のDXを推進するカルチャー作りが上手くいきませんし、こういったことをしっかりおこなっているチームほど成果が出ております。

実際にそういったものをおこなううえでフラットなチームであることが大前提になりますので、フラットに協力し合えるカルチャー作りをおこないましょうということです。

こちらは私たちの支援事例です。コロナ前になるのですが、レゴでワークショップをおこないました。一見遊びのように見えるかもしれませんが、ピラミッド型の組織でずっと働いてきた人にとっては結構新鮮な体験であると言えます。

開発者と同じ立場で、ビジネスの人が仕事をしていくカルチャーを作っていくことはとても大事で、そういったことを私たちは支援しております。

最終的に「これ作って」というものだけができて「なぜこれを作るのかわからない」といった状況よりも「なぜこれを作るのか分からない場合は、これを見ましょう」といった形で、情報はやはりフラット・オープンな組織を作ってカルチャーを変えていく場合には非常に大事です。

オープンの仕方は色々あると思います。私はMiroをワークショップなどでよく使いますね。Miroの巨大なホワイトボードに全部残していって、それを見ることで誰もが平等に情報にアクセスができます。こういったことも成功パターンの大事なところであると思っております。

フラットなチームだからできることではあるのですが、振り返りをきちんとやっていくことも重要です。私たちがお客さまを支援する場合、基本的には週に1回は何かをリリースしてみんなで振り返るというサイクルをおこなっております。良かったこと、課題があったこと、次にどう改善していくのかといったことを出していきます。

するとチームの中でもだんだんと生産性が上がって欲しいものを作れるようになっていきます。プロダクト開発やデジタルサービスを成功させるためには長期戦を強いられますので、チームそのものをどんどん強化していくプロセスを最初から盛り込んでしまうことも非常に重要な要素であると思っております。

このようなことをおこなうことによって、管理型の組織よりも、非ウォーターフォール型の組織と書いておりますが、創造性が生まれる・イノベーションに寄与するといったところですので、新しい開発のルールにはこういった形が合うのではないかということがデータに出ております。

あとは技術です。ベンダーごとに出してしまうとベンダー依存でロックオンされてしまったり、ブラックボックス化されてしまうところもありますので、色々難しいところはあるのですが、そこはきちんとオープンにしていき、専門家たちで話し合ってオーナーシップを意思決定していく、ベンダーに丸投げをしないことも非常に大事だと思っています。

私たちもこの辺りをオープンにしてお客さまと決めていくプロセスを大事にしております。

システム品質に正しく投資する

次に「目に見えないもの」です。

テストが自動でおこなわれるとか、心理的安全性もそうかもしれませんが、リリースが安全にできる、そういったものへ正しく投資していく発想も大事であると思っております。そういったものを上手くおこなえるかどうかが、DXの成功へ密接につながっていくのではないかと思っております。

まとめ

まとめとしまして、DXの成功のためにということで「プロダクトファースト」という言葉も出しましたが、良いプロダクトづくりであると捉えるべきだと思っています。

良いプロダクト作りというのは、良いプロダクトの企画も大事なのですが、良いチームを作ること自体が実は成功への近道ではないかということです。ですので、チームそのものにきちんと投資をして、チームそのものの共創を大切にしていこうといった、そういうアプローチです。良いチームを作ることがDXの一番の成功への近道ではないかとお考えいただくのが良いのではないかと思っております。

私からのお話は以上です。ありがとうございました。

Q&A

Q1:弊社の上層部は人材をまず揃え、組織を作ってからチームをまとめるといったことを基本方針として考えています。その方針自体を転換することが必要であると感じていますが、どのようにスタートさせれば良いか、あればご御教示いただきたいと思います。

塚本

結構難しいところはありますし、私たちもそこから変えるということになると、1つのアプローチとしては正面からグループで取り組むことです。

コンサルタントの会社などもありますし、組織コンサルのような形で、やろうとしているプロダクトはどのようなものなのかですとか、人材がどうであるとか、組織構造はどうなのかといったことを分析させていただいて、従来通り作っていくものと、アジャイルなど向いているものを切り分けて、そちらに対してのアプローチをご提案していくといったことで寄り添って、方針自体に向き合い、外部の知見を入れながらおこなっていくことが1つあると思います。

もう1つはこういったものは「なかなか成功体験がないと難しい」ところがあると思います。会社の上の方にいる人は答えがはっきりしていた時代で多く過ごしたため、従来型の成功体験を持っています。やはりそういったものは通りにくいという話はあると思いますが「パイロットプロジェクトをまずやってみませんか」ということで、直近で何か作らなければいけないといったことがあって、知見も外部パートナーも選ぼうと思えば選べるような小さな案件もあると思います。

まずパイロットプロジェクトでアジャイルを入れてみて、キーマンの方と一緒にプロセスを進めていくといった形で小規模でゲリラ的にスタートするといった方法があります。

Q2:技術者の外注に興味はあるのですが、取り扱っている情報的に風通しがよくできないという課題があります。どうしたら良いでしょうか?

塚本

一般的に言われるのは「アジャイル」というのは非常に透明性を大事にしているわけです。

アジャイルというのはドキュメント文も書きませんし、ブラックボックスになりがちだと言われていますが「何を開発すべきなのか」「優先順位」「誰が今開発しているのか」といったことを全部オープンにしますし、ツールを活用してお互いオープンに見えるようにしていくことや何よりもお互いに信頼性があることが大事になってきます。

ブラックボックスになっているというのであれば、開発アプローチそのものに課題があったり、アジャイルといったものを上手く提供できてないのではないのかと思います。

コミュニケーションの量にも比例すると思います。私たちの場合はほとんどすべてのチームで「朝会」を実施しています。昨日おこなったこと、今日やるべきこと、詰まれている課題など

を話し合います。次に1週間なら1週間でリリースできたものをレビューしてもらいます。それが先週比でどれくらいと多く作れたか、作れなかったのはどこの課題だったかについて話し合います。

情報をオープンにしつつ、透明性を意識しながらこのようなプロセスを取っていますので、そういったものを上手く取り入れていただいたり、もしくは「アジャイルでやりましょう」「スクラムでおこないましょう」といったことを言っていただくことによって、その辺が解決できるのではないかと思います。

Q3:現在アジャイル開発にシフトする勉強をしておりますが、何か良い参考書籍があれば教えてください。

塚本

少し前に社内メンバーで座談会を実施したのですが、同じような質問が出てきました。私がオススメしたのは「アジャイルサムライ」という本です。

結構古い本なのですが「アジャイルの技法」といったものがたくさんありまして、それをこの本で学べるのですが、基本的には先ほどのようなオープンな考え方であったり、もしくは「強み」があることは大事だという話をしましたが、お互いに対する関係性をどう作るかといった基本の姿勢がすごく大事だと思っております。

もしスクラムをやるのであれば、スクラムガイドという20〜30ページの資料があります。スクラムやアジャイルのやり方というのは、それくらいのページ数の資料を読めばやり方自体は書いてあるわけです。

むしろ、それをどうおこなうかというマインドの方が大事でして、スクラムガイドを見ていただきつつ、アジャイルサムライを読んでいただき、実践していただく流れが良いのではないかと私は思います。


ご質問等がございましたら、お手数ですが下記運営事務局までご連絡のほどよろしくお願いいたします。
メールアドレス:pgt_marke@members.co.jp

 

一覧に戻る