自分の状態を知るのは何事も改善の第一歩。ノーコードツールを使い倒してアセスメントも簡単に | DX解体新書 auカブコム編
レポート
日本CTO協会で2019年12月に公開したDX Criteriaを活用していただいているCTOにインタビューをしながら、気づきや戦略への活用事例などを深堀りする連載企画、『DX 解体新書』の3回目。今回は、auカブコム証券の石川さんをお呼びして、Power BIを使ったアセスメントの可視化・効率化とその意義をお話しいただきました。
インタビューイ 石川 陽一( Yoichi Ishikawa)
1999年 日立子会社SEを経て、カブコム創業メンバー。日本初のフルWindows等オープン系金融機関でIT担当。2004年～執行役（2012年迄）。システム監査・内部監査統括、サイバー等情報セキュリティ統括後、2020年4月からシステム統括役員補佐。DX、データ活用、システム開発等の改善を推進。ISACA 調査研究委員会委員長、CISA。
インタビュア 広木 大地 ( Daichi Hiroki）
2008年に株式会社ミクシィに入社。同社メディア開発部長、開発部部長、サービス本部長執行役員を務めた後、2015年退社。株式会社レクターを創業。技術経営アドバイザリー。著書『エンジニアリング組織論への招待』がブクログ・ビジネス書大賞、翔泳社技術書大賞受賞。一般社団法人日本CTO協会ではDX Criteria担当理事を務める。
たび重なる経済ショックの中でも、しぶとく改善を続けてきた。
まずは、auカブコム証券さんがこれまでどんな取り組みをされてきたかと、今回のアセスメントの対象である石川さんの管掌している範囲について教えてください。
まずは私の自己紹介なのですが、スライドを用意しました。勝手にCitizen Developerを自称しています。
1999年の立ち上げから参画していて、IT部門からスタートしました。2004年から2012年で執行役を務めております。
私はIT部門から始まって、ほぼ全部の部署を一周してる人間です。
開業メンバーっていうのはですね、社長の齋藤を含めて3人しか残っていなくて、齋藤、役員の1名と私だけになっています。
システム監査が弱いっていうことで2013年から監査部門に行ったり、ちょっと前は情報セキュリティも大事だよねってことでサイバーセキュリティやCSIRTといったことをやってました。直近ではMicrosoft 365をしっかりと活用していくぞってことになったのでそのへんの推進とかをやったりしています。
去年の4月にコアIT部門に戻ってきて、内部統制の3ラインディフェンス・フレームワークでいうと１現場部門→３監査部門→２リスク管理部門→１現場部門というふうにまた現場に戻ってきてるっていう感じです。
auカブコム証券は、伊藤忠の中から始まった日本オンライン証券が出発点で、その後、メガバンク統合などの流れの中、三菱UFJフィナンシャルグループの仲間として、2019年末からはさらにauフィナンシャル仲間として、インターネット専業の証券会社としてやってきました。
お客様の口座数は123万口座です。API提供も割と早くて2012年からやってます。主なトピックスとしては私がサイバー担当になってすぐにDDoS攻撃を受けたり、2018年にAPIシステムをAWS版に移行したり、去年は個人向けのAPIを提供したりとかですね。
色々とITも頑張っているとは思っているんですけれども、色々なシステムの過去からの積み上げがあるので中々常に最新の環境に…とは行けない現状ではありますね。
社員は180人くらいで、1/3くらいはIT人材。金融危機から、リーマンショック、東日本大震災、そして2020年のパンデミック。さまざまな経済や社会のショックの中を乗り越えてきました。次は、経産省のDXレポートで言うところの2025年の崖というのもありますから乗り越えていきたいですね。
また、アジャイルの手法やその元となるチームワークをもっと改善していこうという活動も精力的に行なっていまして、TMSっていうトヨタの方式をもとにソフトウェアの世界でもやっていこうっていうのを三井伸行さんという日経コンピュータ等で多く連載されている方の指導を受けまして、2017年から塾を数年にわたり複数回開いたりするなどして、改善活動を行っています。
それに関して2019年に日経XTECHにも10回の連載で現場改革の話が出たりしています。
過去の写真はこんな感じです。朝会をやろうとか、タスクの可視化をやろうとか、アジャイル開発等に行く手前のコミュニケーションの改善みたいなことを全社的にやったりしていて、5期までやっていました。コロナ禍でも昨年後半までやっていました。
これがコロナ前の雰囲気でマイクロソフトさんのTeamsの利用事例で取り上げていただいたものです。、今はリモートワーク中心でこんな雰囲気はなくて、ソーシャルディスタンスのついたてがあり、活気のあるほど人もおらずがらんとしていますが…。
DX Criteria、当初はわからなかった。ローコードツールを使い倒して、学びながらアセスメントをしていった。
これが小崎と言いまして、彼は去年の4月からCTOの立場で私より前にCTO協会に入会させていただいています。
彼が(CTO協会に)入ってDX Criteriaを知ってこれはいい、けどボリューム多いからどうしようっていう相談が私にきました。私は役員補佐で彼を助ける立場なので、じゃあ「やってみようか」と去年の6月くらいに思いたってやりました。
このチェックリストを最初に見たときに、「量が多いな」とか「こんな話があるのか」と色々と知らないことがいっぱいありました。ただ、なんとかまずは一周しなければなと思ってやった方法がありまして…
私達はグーグル文化ではないのでチェックリストのGoogleスプレッドシートを個人アカウントで見るのはちょっと辛く、GitHub上に色々データがあるとわかったのでそこから質問項目取り出して活用しました。
Power Automateっていう自動化ツールを使ってOffice365のMicrosoft Plannerに流し込み、評価分けをドラックアンドドロップでやれるようにする形を作りました。そのあと、私合わせて5人で評価分けをやりきりました。
やってみたら複数人で1日で簡易アセスメントはできたっていうのが去年の6月ですね。それをPower BIで可視化しました。
いま、DX Criteriaの改訂ワーキンググループでNotion上でやってることに近いかんじですね。
評価はIT戦略グループというIT構想とか品質のあり方とかを取りまとめる開発部門のメンバーとやっていきました。
最初作ったバージョンがこの6月版というものです。
131点で、最初の14社の平均点よりもちょっと下だという手応えがわかり、「デザイン」の部分が特に低いなっていうのはパッと見てわかりました。
半年ごとに小崎が全社員向けの方針説明でグランドデザインのネット勉強会をやっていて、そこでこういうふうにIT部門がやっていこうとしていると説明にも含めています。
昨年12月に半年経過した後としてもう一回評価し直しました。昔は”No”で諦めてたところを取り組み始めた(からスコアが上がった)というところが大きいと思います。これはレポート上の私のコメントですが、実施できていないので評価点0だった項目について実施に向けて着手したということで点数を押し上げました。
とはいえ、”Yes,but”とか”No,but”の所でどのへんが弱いのかという弱み集もPower BIレポートに集約してあって、それを品質メンバーでレビューしたり現場にも落とし込んで改善活動に盛り込んでいます。
評価見直しごとで「コーポレート」を集中的に見なきゃっていうのがあるんですが、「コーポレート」は読んでるだけでも時間がかかるので、一つの項目は一言でいうと○○ということ、と自分の頭で理解しないといけないと思って、Power Appsっていうローコーディングアプリも作りました。
当社にとってはここにあがっている項目が遠い話だったのを、ちょっとずつなじませて、とはいえ時間かけてやってたら全然進まないので、巻きを入れながらBIを入れながらやるっていうのがいいなって思って取り組んでいます。
これが二回目に行った12月の評価バージョンです。点数も上がりましたし、前回比でどこが変わったかっていうレビューや、231項目の未達事項を、5人でチーム分けして、注力する点をみています。
めちゃくちゃいいですね。ありがとうございます。
写真を見ると、いただいたアセスメントの新しいバージョンでは”No,but”的なところが多いですが、これは仕掛かりだということですかね。YesやNoの間の状態である”Yes,but” や”No,but”があることで、仕掛かりが増えただけでも点数が上がるっていうのはDX Criteriaの特性の一つだと思うんですけれども、それについてはどう感じられますか？
そこがすごくいいと思っています。
私も監査っていうのをする側とされる側の経験をどちらもかなりどっぷり入れ込んでやっていたんですけど、こういった監査系やセルフアセスメント系のチェックリストの特性として、やもすれば、マイナスになったことって「どうして君たちはだめなんだ」とダメ出しになってしまったり、そういう減点方式の議論に特に日本人は陥りがちなんじゃないかと思っています。
そうすると監査される側も嫌になって全然、改善活動にならないわけですよね。丸（○）にするためだけの活動をしてもしょうがないと思っています。
“No”とか”No,but”になったことって、何か一個やったら○になるってことでもないし、それについて考えていくとか自分たちに足りなかった視点を(得るために)知恵を働かすってことが大事だと当社の中では言うんですけど。
私は監査をやってきたからその大事さを痛感しているんですが、中々現場って伝わらないものですよね。
そういうことを話し合うきっかけになると思うので、とってもいいと思っています。
一番最初にDX Criteriaをやってみたときの気づきってどういうところにありましたか？
いろいろな観点がありますけれども、まず2つのDXのDeveloper eXperience(開発者体験)の方は、概念としてそこまで一般的ではないですよね？
私共は、ユーザー系IT金融機関なので、ベンダーと一緒に頑張って組んでやっていると、ある方面からはベンダーに丸投げでは？と言われたりして充実感が中々得られにくいことがあります。
そのようななかでこういったDeveloper eXperienceの考え方で、足りない観点がいっぱいわかって目からうろこ的で、とてもよいなと思いました。
IT屋内でよくあるのが、○○ツールがないからとか、CI/CDができないんだとか、アジャイル開発じゃないからどうなんだとか、そういう言い訳的な話が多くなるんですけれども、そこに5つの大きなテーマがあって、「コーポレート」の会社としての支えであったりとか、「チーム」の話とか「デザイン思考」だとか。
今も改定ワーキンググループで、議論してますけど、自社ではプロダクトマネジメントの考え方は特に抜け落ちている点も多く、意見としてはちょっとずつやらなきゃというのは出てる中で、具体的に推し進める材料としてCriteriaの各項目は役に立ちました。
二回目のアセスメントぐらいから手応えが出てきて組織の改善に実感を覚えた
実際、ユーザー企業からみた企業カルチャーの部分とDeveloper eXperienceの部分って随分と隔たりがありますよね。役割を指す言葉やプロジェクトの進め方など随分と違ったりするので、最初の導入時に、これは違う世界の話かな、ってなるんじゃないか思ます。石川さんがそういった文化の違いを受け入れられたのはどういう背景があったんでしょうか。
受け入れレベルとしては最初の6月と二回目の12月では差があると思ってます。6月の最初の時点では急にあれだけの項目をやったっていうのもあって正直ただ疲れました。
腹落ちどころか、頭に全然残らなくて点数だけに頭が行っちゃったり、知らないことが多いんだなーぐらいの感じで、しばらく見たくない状態になりましたね。
私が勝手に思いついたドラックアンドドロップでやったのは自分なりにいけてると思ってましたが(笑)。
スプレッドシートでは質問を見てはこっちに戻って答えてってやらないといけないのでもっと疲れるでしょうし、なんとなくでもわかる人が少ないと思うんですよね。IT企業でも。
そうするとユーザー企業側のIT部門になると、よりやっていこうという人がいないんじゃないかと思ってました。
DX Criteriaって、ベンダーとユーザー企業だったらユーザー企業は少ないっていうことであっていますか？
ベンダーかユーザー企業の二択よりは、自社開発している会社においては内製のエンジニアがたくさんおられると通じることが多いと思います。なので、ある程度内製化されていて、ベンダーさんとも協力しあっていて、という狭間にいらっしゃるところだと思っていて、そのなかでDXするという点ではターゲットになると思いますね。
6月にやってから12月にもう一回やりますよっていうところまでで、受け止め方の変化はありましたか？
初回やったときはNoが多いから、残念だったり、疲れてしまったりというのもありました。
一方で、これまでもずっと行ってきた改善活動でも何をやるかなどについて悶々と議論ばかり続くなぁっていう状態があったのですが、それが一定量解消したり、小崎からもどこが成長してどこが悪いのかより知りたいというリクエストがあったりしていたのですが、二回目のアセスメントのときは、Power BIを使って比較する形で改善の「見える化」が進んだりしてくるなど手応えも感じられました。
二回目のときはすでに項目もわかっているし、他のメンバーがアセスメントしてくれたものもあるので、私自身が総なめして、明らかに出来てるYesの項目は一度置いておいて、そうでない項目にフォーカスを当ててみていってるというのが現状です。
全員が全員、「私達がやるべきことだからすぐにやります！」っていうふうにはならないですけど、進めなきゃならないぞって項目をしっかりとやってるっていう感じになりました。
そうすると、最初はしんどくてわからないコメントもあったけど…という状態から、なんとんなくは組織の改善にとっては役立つものかな？という状態に。
あ！めちゃくちゃ役に立ってますよ。
うちの人事から、スキルアップのために計画を出しましょうっていうのがあって、ある意味ぼんやりと聞こえていました。一生懸命つくるだけで終わる話とか、半年に一回記録をつけて出してくださいとか。
工夫はしてるんでしょうけど、軸になる考え方を考えながらやることを決めていったほうが良くて、その要素とかヒントがDX Criteriaのなかにいっぱいあるんじゃないかなと思っています。
DX Criteriaの考え方の一つに、説明責任を反転させたいっていうのがあります。
何かやる時に、「なんでやるの？」っていう議論で大変だった部分を、やらない理由を上から聞かれるようになっていくと、議論がより生産的に進むかなと思っています。
まず網羅的に、「こういう状態だよね」っていうのを提供していけることを目指したので、議論が生産的な方になったのは、僕としては作った甲斐があった。
だから、もっと広めたいわけですよ（笑）。
やっぱり、やろうという気持ちにならない人もいっぱいいると思うんですけど、そういう人もやってほしいですし、DX Criteriaの使い方で間違いやすい点だと思うんですけど、点数上げるためだけにやるわけではないってものですし。
でも、「こういうことをやっていかないと」って感じが共有できるのがよいですよね。
自分の状態を見るのは何事も改善の第一歩
概して、こういうチェックリストで自分たちに採点をするのはプレッシャーがかかることで、開けたくない扉を開けちゃうといった要素もあると思うんですけれども、こういったものに挑戦していこう、やっていこうと組織として思えたのはどういった背景がありましたか？
そういうバリアについては、2017年から三井伸行さんの指導のもと、チーム改革をしていったのものよかったです。いろいろな「見える化」だとか仲間のタスクの状態をもっと知った上で活動しなきゃだめだよっていうアジャイルの根底にあることは塾で教わり、私自身がBIに傾倒しながらいろんなことを見える化して業務をやれるのがいいかなってことで自分自身のテーマにおいています。
そのためには、自分の現在の状態をデータ化するなり向き合うなりするのが第一歩だと元々分かっていました。分かっているからには、メンバーに対しても一緒にやってみようというムードを作って。
Teamsの会議で、ただアセスメントするだけマルバツつけるだけじゃ面白みもないけど、こういうツールを使ってこうやったらすぐできそうだよねっていうのを「全集中」でやってみようって言ったら、面白がってやれる、という巻き込みはできているかなって思いますね。
自分の状態をみるのは何事も第一歩だと思っています。
そうなんですよね。
最初DX Criteriaはレクターという会社のパッケージ商品で売ってて、その一部を公開したんですけども。
経営者からみた技術組織の状況等を可視化して、現場からの言葉だけだと届かない、あまり投資できてない点をはっきり見せていくために作ってました。自分で自分の体重計に乗るのは大変だったりするので、それをやれる人に使って頂いてるっていうのは僕らにとってとてもいいことだなって思っています。
なので、「こういった形で見える化をしていた」とか、「見える化の業務に携わっていた」というのはとてもヒントになりますし、そういった業務をされている方から見るとアセスメントも一つ重要な観点と捉えていただけたんですかね？
おそらく通常と比べると私の入り方はマイナーかなって思います。
でも私の周りの監査に近い人やDXをアセスしながらやっていきたいと思っている人で、IPAや経産省のDX指標だけでなく、ちゃんと自分たちでサービスの中身を作りたいっていう方にはいいんじゃないかなって思いますね。
やってみた中で、「できてたな」とか「今までの投資やアクションが生きてたな」など強みになったポイントってありましたか？
割と「コーポレート」は高いのかなって思ってます。
経営が20年間突っ走ってやってきてるものの、銀行系の面があったり、2019年12月からのオレンジの面が加わったりし上場廃止までして、今の51-49%で赤とオレンジに囲まれる現在があります。
そのような中現場の組織体系では、今1グループって最大7人としていて、これは全社的にそのようになっています。そうでないと部下のことを見れないというチーム作りの人数のコンセプトで組織を作っていって、数年来アジャイルができる組織にしていこうと少しずつやってきたことが、今回「コーポレート」のところで割と点数が高いことにあらわれていて、骨格としてはいいかな、という気になりました。
一方で、やはりものづくりのデザイン思考が弱いところが課題で、基本ウォーターフォールでいつもユーザー部門との要件定義の精度論がまだまだ続いているところもあり、いわゆるユーザーストーリーベースでものごとを作るというのが全然主流ではなく、ひずみが相変わらずある。そういうところは弱いと思っています。
アセスメント結果とご自身が感じてらっしゃってた課題感が符合するところはありました？
システム分野のCI/CDのところでは、モデルケースのベストプラクティス的なものはクラウド活用が肝であり、そういう流れの上で一連の良い物事ができてくという流れだと思ってます。こういったところは当社ではまだまだいろんな意味で弱いです。オンプレでデータセンターまで持っている会社なので、なかなかついていけない、あっていない、まだまだだなっていうところは多くあるなと思いました。そういう複合的なことを考えさせられた上での腹落ち感はあります。
たしかにこのDX Criteriaのシステムにある項目には、「クラウドを使いなさい」とは書いてないけど、クラウドを使うと楽なことがたくさんあったりするんですよね。実際にクラウド化する前の僕の前職であるミクシィから自分たちで作ってた仕組みも結構ありますし、クラウドができてからも自前でやってたものも結構あったりするので、その時代からするとめちゃくちゃ簡単になったなっていう感覚ですね。
いろんな事情で、クラウド使う上でオンプレのほうがよかったっていうこともあるかもしれないですけど、一方でクラウドを使うと絶対的に楽なことは事実とは思っていて、逆に初期のクラウドってそんなに機能なくて最近は本当に充実してきたので、そういった意味でやりやすくなっているんだろうとは思います。
お客様向けのシステムと社内改善的なシステム、マイクロソフトでいうとPower Platformが正にそうだと思うんですけども、社内のことをいちいちIT部門に作ってもらわなくても社内の有識者が集まって業務を見直したうえでできることは作ればいいんじゃないかということが、最近少しずつできるようになってきたと思ってます。ここにある要素は、いろんな意味で社内全体に浸透させるといいなと思っています。
一部のことは、今の私たちのできてない度が10くらいだとして60ぐらいの合格点までには開きがあるなっていう壁があるので、IT部門のメンバーによってはだめだとしか言わないムードもある。それを、社内ごとでもいいんでこの部分はできてるよねっていうムードを少しでも作っていってネガティブ派の考えを変えさせたり、経営者で考えがわかってない人を変えさせたりする後押しになるといいなと考えており、私もいろいろな意味で取り組み途上ですがやっています。
判断する人が雰囲気だけで判断すると中々難しいので、数字とか見える化されていくのは重要なポイントですよね。
なので、今回は全然初期のわかってない時代と、半年後のちょっと取り組み始めたのを可視化しました。
次にやらないといけないのは、未達事項リストの中から良好事例を一個ずつでもいいから作っていって、「これができたからスコアも上がるよね」っていうのを社内で示して、一人でもそう考えていく形に持っていければいいなと。そういう活用の仕方をしていきたいなと思っています。
ちなみに最初は数名で取り組まれたという話でしたが、社内としてのDX Criteriaへの向き合い方も変化してきましたか？
さっきのボードは、Teams内のPower BIで社内メンバーはすぐに開けるようになってます。
GitHubやPDFの資料でしか見たことない人はボリュームに圧倒されて、うちは遠いなって終わっちゃうこともあると思うんです。当社は少なくとも社内メンバーが一回以上評価してるので、クリックすればどういうとこが弱いとか、観点にはどういうこと書いてあるんだろうといったことを検索できるようにしています。
小崎他関係者との会話にも、よくそういう議論になった時に、この辺にこういうヒントがあるぞという感じで、目標立てをする時や見直しの時に使っているので、一つの社内ツールに溶け込ませてる感じだと思います。
現場のみなさんから、なにか声をいただくこともありますか？
チーム分けする5人から、これがあるからこれやりましょうっていう提案がそろそろ来るはずだなって思ってるんですけど（笑）、もう一歩かなという感じですかね、（自発的に）考える余地や余裕が作られてないっていうのが実情ですね。
そこは押しすぎても良くないと思ってまして、行き詰まって何かアイデアが必要だという時にヒントを取り出すようなストーリー作りや雰囲気作りが必要かなと。
強制的に、あれやれ・これやればかり言ってやれるものでもないと思います。
なので私自身も理解を深めたいと思って、DX Criteriaの改訂メンバーに加えてもらって4月10日のCTOの日に向けて、さらにわかりやすいCriteriaになればと思っていますので、まずはFAQとか用語解説作りにできるだけ取り組みたいと思っています。
ありがとうございます。
DX Criteriaに書かれてる事は、一部は表面的に判断できるっていうのを重視しているので、(いいか悪いか)判断できるけれど、実際に取り入れていくとそれがなかった時のことが思い出せなくなるようなものなので、仕事し始めて体感として価値が認識できるかなと思います。なので、DevOpsでもよく言われるんですが、やってみないよりはいい、形から入って徐々に自分のものになっていく、血肉になるという風にできるといいですよね。
話題変わって、DX Criteriaに限らず、これからauカブコムさんが取り組んでいきたいIT部門としての挑戦はどういうところですか？
これは、2つあって、1つはいわゆる最近のクラウドのいい点を活用しながらのお客様サービス提供により一層つなげていかねばならないという点です。
効率的にやろうとしたらクラウドしかないっていう世界だと思うので、より一層取り入れていくと、うちのシステムサービス提供はもっと良くなると思います。クラウド率を上げたいというのが1つ目ですね。
もう1つは、コロナ禍もあってより強いチーム作りが難しい時代になってると思いますので、その中で結束を強くしてチーム力を上げるために、DX Criteriaをコミュニケーションの中で議論するツールとして上手く使って、もっと強固な組織、最終的にはOneカブコムという、会社全体が一つのチームのようになれるといいかなと思っております。
課題感もあるので、そこをより攻めていきたいと思っています。
DX Criteriaの中で直接触れていないところですけど、僕はよく「IT組織のエマルション」って言葉を使ってまして、エマルションってパスタ作るときにソースが乳化する現象のことなんですけど。
多くのエンジニア組織や技術組織を見てると、IT部門とそうじゃない部門がはっきり分かれている時と、上手くかき回されて事業部門とIT部門が乳化して上手く溶け合ってる状態があって、会社のDXのフェーズが進んでくると乳化していくというのがあります。
ウェブ系企業やベンチャー企業は、事業とソフトウェア開発が一体となってるところが多いので、ノーコードの利用も、ソフトウェアエンジニアとそうじゃない人の区別が徐々になくなっていくようなとってもいい乳化の事例だなと思いながら話を聞いてました。
ノーコード、ローコードをどんどん取り入れていくのは、そういった組織的観点もありますか？
はい、それはあります。もう一ついうと、最もダメなところで、日本の金融機関等企業であるあるなんですけれども、なんでもExcelなんですよね。
スプレッドシートを超えて図を共有するだけでも、Excelに貼って共有しますかとか、これワープロですか?とか、会議もExcelのシートを出して、数行の事で議論がずっと進まない状態でいたりとか。
どんな部署の打ち合せに出てもそういう場面に出会うことが多くて、そういうのを止めたいっていうのが本音でありますね。
なので毎週水曜日に参加させていただいてる（DX Criteria改訂）ワーキンググループのNotionでの打ち合わせの仕方っていうのはまさに理想だと思っています。ツールは違いますけどPlannerやPower BIを使っています。ちょっとでも生産性高いことをやっていかなきゃなと考えています。
このExcel話はどの部署行っても同じ感じがあるのでそこは変えたいですね。
ユーザー部門とシステム部門の壁とか、混ざってる感がないっていうのは当社もあります。その壁を壊すためにも、例えばデータというのはどの部署でも取り扱うので、私も他の部署メンバーでも勉強会をやって、相談があればアドバイスしてこんな風にできるよって返してるので、そういう壁壊しの文化作りにもBIとかノーコード、ローコードはいいのかなって思ってます。
余談ですけど、ローコード系のものって業務部門がいじれる分、メンテできない何かが生まれる懸念が多いツールかと思っているんですけど、肌感としてはどうですか？
マイクロソフトさんもその辺は意識しているとこもあるかなって思います。
ベストプラクティスの紹介でも、CoE（Center Of Excellence）といった中央で管理していく考え方が、特に海外中心にスタディ的に少しずつ出されてますけど、過去のEUCで作った人しかわかりませんとかアクセス権が適切じゃないからめちゃくちゃになってましたとかがないように。
こういったところはクラウド製品のものを使ってますので、セキュリティを直接ではないもののわかる人が見ていかないと危ない部分はあります。逆にちゃんと見ていけばアクセス権なり認可される範囲が適切であれば使ってもいいと思っていて、野良RPAが横行するよりは全然いいかなというふうに思っています。
見えるところでやっていけるってのが一番なんじゃないですかね？
ソフトウェアをコントロールしていくためにはよくわからないところがあるっていうのは大変ですからね。ワーキンググループに参加していただいているので、追加したい項目や、セットで気にしてる事があればお教えください。
私自身は5テーマと8カテゴリの形は美しいと思ってまして、まだ大きく変えてくフェーズじゃなくてもいい気もしてます。一方でリモートワークの主流化をきっかけとした見直し等が入っているのはいいことだと思ってます。
もともと広木さんが前身の集まりや会社とかで培われたことや練られたことが相当入ってるのがすごくわかるので、大きくいじらずにしたいですね。
逆にそこにあることで、これは何だろうとか、当社ではどうなんだろうとか、使う側が考えるのに汗をかくフェーズがあってもいいと思っています。今回のQ＆Aと用語解説、参考リンクの三本柱が加わったリニューアル版ができるとすごく良くなると思ってます。なので項目自体を変えていかなければとは思っていません。
一つあるとしたらPower Appsで見せたように、「この話は一言でいうと？」とかCriteriaごとの用語説明とかですね。
例えば「コーポレート」の中にスパンオブコントロールがあってその中に8項目があって、その8項目もなんとなく頭に入ってれば、その人は相当いろんな観点で物事を見られる状態になると思っています。
そのときに、アセスメント項目でメインタイトルがどこ？と思うものがあって、この話はキーワードで一回咀嚼して理解しておきたかったり、人(内部の人や関係者との勉強会のメンバー)に説明する時に早いなというのがありますね。
一言で次の議論にいきたいなって時にあるといいと思ってまして、それは私の言葉で我流で作ってみて、そういうのがオフィシャルなものとして公開があっても無くてもいいと思うですけど、見える化して選んだキーワードがでるようなものをPower BIとかで作って置いてあると理解が進むのかなって思います。
字面だけ見て投げちゃう人で、やる気はあるんだけどもう一歩踏み込めない人に向けていくものはあってもいいのかなと思います。
ユーザー企業のシステム部門の人がこれを見て、なんかIT用語が多いな、これってベンダー向けなんじゃないの？ってあきらめてしまってよく読んでもらえないのが残念だと思うので、そこを引っ張りこむようにできたらなって思ってます。そのために縮小版もいいですよね。
ちなみにどんな人や会社にDX Criteriaを勧めたいってありますか？
いまってDXブームで、どっかのベンダーの何かを買えばDXが進むんじゃないかと思ってる人にこれを読め！ってバーン！と叩きつけたいですよね。でも少し見ただけだと、キャーってなると思うんですけど（笑）。言い続けないといけないんじゃないかなって思いますね。
まずは石川さんのように、社内で受け止めて咀嚼する人がいるっていうのは重要なことかもしれないですね。
そうですね。BIの世界が似てると思ってまして、BIの勉強会で膝を突き合わせてブートキャンプ的に半日とかやる会もあるんですけど、大体BIを推進してる人って各企業に一人いるかいないかっていう状態が多くて、でもその人がデータを集めたりこんな風にできるよって一生懸命に言ったり勉強会をやったりしてるんですよね。
DX Criteriaの世界もそういったことがもしかしたらあるんじゃないかなと。
こういったことができる、CTO協会にも入って活動もしっかりしてる見本的な人は、そういう企業に少ないと思っていて、一人でもそういう人がいるっていうのでもだいぶ違うのかなと思いますね。
最後に一言ありましたら。
4月10日、CTOの日にDX Criteriaを新しくするメンバーに私も参加し協力していて、さらに素晴らしいものになると思います。一人でも多くの人にDX Criteriaを目にしたり、ちょっとでもいいから手に触れて自分の会社はどうなのかなと考えてみていただきたいです。
—
日本CTO協会では、日本のDXに貢献するため、様々な企業のDX Criteriaを集計し、集計レポートを会員企業に向けて、作成・配布しています。ご興味のある方は法人会員向け申し込みフォームからお問い合わせください。
インタビュイー
auカブコム証券株式会社 システム統括役員補佐 石川陽一
インタビュアー / 執筆担当
日本CTO協会 担当理事 広木大地
企画・運営・協力
株式会社サイカ 執行役員CTO 是澤太志
日本CTO協会 臼井俊太郎
日本CTO協会 山中はる
日本CTO協会 松下清隆
