HULFTイベントレポート：第18回
｢HULFT Technology Days 2023｣
今年も開催しました！(Technical Day：その2)

弊社の社内でのデータ活用について、そしてそれを支えるデータ基盤について紹介をさせていただきました。

データ活用がこれからは大事だと、取り組みを進めようとしている組織は多いと思います。そしてデータを活用してビジネスを進めるんだ、みたいなことになると、情報システム部門がレポート作成地獄のような状況に陥りがちです。

たとえばデータから知見を得たいと誰かが思うたびに、情報システム部門などにこんな手間が発生するわけです。どういう状況で何が要望されているのかヒアリングして整理し、必要なデータを準備し、あるいはデータそのものを集めて作るところからの作業を行い、BIツールでレポートを作成する、大変な手間です。さらにはその後もレポートがほしいと言われるたびに、データの準備をしたりBIツールを使ったりしてレポート資料を作る作業をしなければならない。そんなことが起こりがちです。

このような事態を解決するためにも、ビジネス課題を持っている人が自分自身でデータ分析ができる状況が望ましいはずです。そこで、社内の誰もが自分でデータ活用に取り組めるような、社内データ基盤の整備に取り組むことにします。

そこで整備したのが、弊社社内でDDP（データドリブンプラットフォーム）と呼ばれている全社データ基盤です。弊社製品ももちろんしっかり活用しており、DWHとしてSnowflakeにデータを溜めており、HULFT DataCatalogで必要なデータを探せるようになっており、データの加工や処理の自動化はDataSpiderで実行可能で、データ分析やレポート作成はTableauで行えるようになっており、社員の誰でも利用でき活用できる基盤を整備しています。

データ基盤を整備するだけではなく、機能を追加拡張するエンハンス作業や、社内で広く使われるようにする取り組みにも力を入れています。

情シスだけで社内全体にきめ細かく対応することは工数的に難しいこともありますし、各部門の業務はそれぞれの部門自身の方が理解しています。そこで、各部門でデータ活用に協力してくれるアンバサダーを育成する取り組みに力を注いでいます。アンバサダーになってくれる人には、新しい取り組みへの好奇心旺盛なエンジニアや、ビジネス上の課題を解決改善したいと思っている人が多いそうです。

データ活用のスキルを身につけるためのトレーニングプログラムの整備にも力を入れており、データ活用で解らないことを気軽に聞ける環境の整備にも取り組んでいます。

トレーニングプログラムの最後では、教わったことを全部使わないと取り組めない課題を出すようにしていて、それをやってもらうことにより自分自身で使える状態になってもらっています。課題は頑張れば誰にでもできるものと、それができた人にさらに取り組んでもらうものを用意するようにしているそうです。結果、ITスキルと無縁の部門に所属していた人が、本格的な分析作業を日々行うようになるようなことも起こりました。

また、データ基盤のアップデートを日々お知らせする、社内での利用者による情報発信を行ってもらうようにするなど、社内での周知活動にも継続して取り組んでいます。機能追加についても利用者のアンケートをとり、アンケートの声を踏まえた機能強化を行うようにしています。

データ活用が定着してきたことにより、社内事例も多くできています。プロジェクト管理において、プロジェクトの状況をリアルタイムで二変数に集約して平面上にプロットすることで、外れ値のものや要注意領域にあるプロジェクトに気を配れるようになりました。従来においては集計作業だけで時間がかかったので、プロジェクトが終了してから問題があったことに気がつくなど事前の打ち手が難しかったのですが、そのような状況が改善されました。

また、製品やサービスの開発において、製品の評判や利用状況をリアルタイムで見える化し、それを踏まえた製品開発に取り組めるようになりました。

今後に向けた取り組みとして、生成AIを用いたデータ活用基盤にできないか検討をしているとのこと。例えば、自然言語でデータに関する要望を伝えるだけで、具体的にどこにどのようなデータがあるのか知らなくても、自分でSQLを書くこともせずに、必要な分析結果が得られるようにならないかと考えています。

次に、弊社社内での生成AIの取り組みを紹介するセッションです。

昨今、世間で大変な話題になっている生成AIですが、弊社においても社内での取り組みがあります。従来の機械学習では、学習データを用意して作ったトレーニング済みの学習モデルを使って、データの判別や認識処理を行う使い方でした。これに対して生成AIでは、現状では多くの場合は自社で学習や追加学習は行わず、利用方法としてもデータを与えて判断結果を得る使い方ではなく、生成AIに応答やデータを生成してもらう使い方になります。これまでとは挙動が違い利用ユースケースも異なります。

生成AIに関連して、社内のあちこちでそれぞれ独自に取り組みをやろうという動きがありました。大変話題になった技術でもありますし、他社においても社内において興味を持った人や現場で試してみようと思う人が出てきている状況は良くあるのではないかと思います。それら個別の動きを、全社活動として束ねて社としての取り組みとしています。それぞれの現場から参加者を募り、参加者はそれぞれの部門に所属したままで部署横断のバーチャル部門（LLM Mavericksという名前にした）として取り組みを進めています。

また、全社で生成AI（対話型AI）を活用できるインフラの整備も行いました。社内でのコミュニケーション基盤としてみんなが使い慣れているSlackから利用できるものと、ChatGPTを模したWebUIから利用できる環境が、誰でも利用できるようになっています。

Slackは普段から使い慣れていて利用ハードルが低く、他の人の利用ログも見えるため、どのように使っているのかが互いに見えることから、他の人のポストを見ているだけでも何となくどう利用するものか理解できる状況も自然に出来上がります。さらには、Slack上のコンテンツを参照する問い合わせも実行できます。

利用にあたっては、入力してはいけないデータがあることや、ハルシネーションがあり得るので間違った情報が入り込む可能性を踏まえた上での利用としてもらうガイドラインの公開と周知を行っています。およびプロンプトをどのように書いたらいいかの社内ガイドブックも作成しました。

サービスの中身は、Azure OpenAI Serviceを利用しています。入力したデータを再学習に使わないなど法人利用への配慮があること、および既存の整備されたAzureの利用環境をうまく使えることもメリットとして採用しています。

社内の利用は無事にどんどん伸びており、クラウドサービスの従量制の利用料金においても3.8倍となっていて、社内での生成AIの利用拡大に成功しています。

また、自分たちが蓄積したデータを生成AIに参照させて回答させる取り組みも行っており、世間的にRAG（Retrieval-Augmented Generation）と呼ばれている外部データを参照させる仕組みを実装しています。

構造化データと非構造化データで違う方法で対応しており、PDFドキュメンドなどの非構造化データについてはAzure上のサービスを用いて参照できるようにしています。DWH上の構造化データについては、様々な正規化がされた構造化データと生成AIの相性が必ずしも良くないこともあり、生成AIに認識させるために用途にあわせてデータマート化してから参照させるなどの工夫を行っています。

DWHを使って実現している全社データ基盤では、対象となるデータがどこにどういう形で入っているか理解してから検索や集計を行うSQLクエリを作る必要があります。生成AIを活用することで、利用者はDWH上のデータ構造やデータがどこにあるかを気にすることなく利用できる環境の実現に取り組んでいます。利用者は生成AIに欲しい情報を問い合わせるだけで、生成AIがDWHに対して必要なSQL問い合わせを生成し、それを用いて生成AIが回答を作ってくれるような仕組みです。

このような社内で利用している生成AIの利用基盤の構築サービスを、社外に提供する取り組みも始めています。例えば、Slackを通じて全社で生成AIが利用できる仕組みを構築するサービス、顧客から寄せられた声のテキストデータを生成AIに感情分析させてその結果を得られる仕組みについても、外部への提供に取り組んでいるところです。

次は、ソフトウェア開発を支援するオープンソースの有名ツールJenkinsの作者である川口氏によるセッションです。テーマは開発生産性ですが、ソフトウェアの品質の話が主な話題となっています。

プログラマなど開発の現場にいる人には良く知られたことながら、世間的にはなかなか知られていないことでもありますが、ソフトウェア開発にかかっている時間の大半は、雑に言うなら「バグが無いか確認して見つかった問題を修正する時間」に消費されています。川口氏も、プログラムを書くことは別にどんどんできるが、書いてしまったものをテストして維持する工数がとてもかかることが問題だ、としています。

ITに詳しくない人は、ソフトウェアのバグは全部取れるものだと思っていて、開発を発注したらバグが無いものが納品されるのが常識だと思っている人も居たりしますが、不具合をなくすことは不可能なことです。また、不具合の有無は開発する人の気持ちの問題であるとか思ってしまい精神論にしてしまう人もいますが、精神論で解決できない問題であり、技術的な対応が求めらます、そうしなければ不具合を減らすことは出来ません。

このようなことは、これから盛んに取り組まれるであろう内製開発でも踏まえなければいけない基本的なことです。

セッションでは、対処がとても厄介で開発工数の大半を実は費やしている、テスト（不具合対策）に関連する技術的な取り組みが主なテーマとなっていました。

昔ながらの開発手法では、作るべきものをドキュメント化し、実装し、実装が終わってから要望通りに作られているか不具合が無いかなどを確認するテストを、開発工程の最後のテストフェーズで行っていました。しかしこの取り組み方ではテストフェーズで非常に時間がかかる傾向があります。そこで実装が終わってから品質を改善するのではなく、開発工程全体の各プロセスで品質改善を行う考え方での取り組みが、最近進められつつあります。

さらには、システムのアーキテクチャそのものや利用する技術にテストへの配慮を施すような取り組みも進められつつあります。例えば開発フレームワーク自体がテストの機能を備えたものにするとか、適切に実装せざるを得ないような作りにする取り組みがあります。

そこまでやらない場合でも、テストの行いやすさに配慮してオブジェクト指向のクラス設計がなされることは良くあることではないでしょうか。振り返ってみると、DI（依存性注入）などの過去に普及した技術でも、テストしやすくなることから広まったものがあります。

リリース後の本番環境を利用してテストを行う取り組みもなされています。本番環境の検索クエリを開発環境にも流し込み、本番環境と応答に差異が生じるか確認すれば、今開発作業で書き換えている開発環境において、以前からある機能の挙動が変更されていないか、実利用に即したデータで確認できます。

さらに、本番環境で不具合が出てしまうことも前提として、問題発生時の影響を小さくする設計や運用にしておく取り組みもあります。建物の防火対策で、たとえ火事になってしまっても防火壁で建物全体に燃え広がらないようにするとか、避難経路だけはとにかく守られるようにするような取り組みがありますが、それと同じようなことがソフトウェア開発でも行われていることがあります。

旧来的な考え方ではテストなどを通じて不具合を取り除いて「リスクをなくそうとする」取り組みが多かったと思います。しかしクラウドサービスなどでは、品質は一定水準を確保した上で機能をリリースする速度の方を重視したい場合があります。そのような考え方ではリスク（不具合）は無くすものではなく管理すべきものになります。

開発組織での開発の行い方を変える取り組みも行われています。旧来は、開発チームごとにそれぞれに独立した開発のやり方があって、全体での横のつながりがない傾向がありました。

各チームそれぞれのやり方を維持した上で、全体の状況を改善する方法として、開発環境のセットアップを補助する取り組みがあります。開発作業に取り組むにはその前に開発環境を整える（プログラミング言語や開発環境のインストールなど）準備が必要になりますが、そのような開発環境を事前に整備してあって開発を補助する便利なツールなども設定済みになっている環境を事前準備して提供する取り組みです。

開発者からするとセットアップの手間をかけずにいきなりコードを書けるようになり便利なので利用されるようになります。その結果として、皆が同じ環境を使って開発するようになれば、開発のスタイルや方向性は揃ってゆきます。

さらにはITインフラ側で同じような取り組みができます。例えばモニタリング機能などを共通部分として、事前に整備された環境を用意すれば、社内SaaSが提供されているような状況にすることができます。開発チームから見るとITインフラ部分の手間が減って開発に集中でき、開発のやり方の前提をさらに社内で揃えることができます。

ここまでの取り組みでは開発が前提とする環境を揃えていますが、チームの開発のやり方や開発文化は異なったままになっています。また、開発を支援するツールも導入しただけでは活用方法が解らないこともあります。

そこで、社内でツールの使い方や、良い開発の進め方などを社内に宣教師のように広めてくれる人が必要になります。そのような取り組みによりようやく全体で開発のやり方や開発文化の統一を進めることができます。

自社の事情にあわせた独自の開発スタイルをとる場合と、オープンソースの取り組みなどを通じて世界中で共通して取り組まれている開発スタイルをとる場合があります。

自社独自のやり方は自社の都合にあわせてある強みがありますが、独自文化を作り始めると、一から十まで自分たちでやることになりかねません。世界で公開して共有されている共通のやり方は、その組織に対して最適ではない代わりに、世界全体の力により世界が進む速度で進化します。そのため、いつしか独自開発と効率性すら逆転してしまい、黒船来航のようにして独自路線を諦めなければいけないこともあります。

Pre-merge testing：

変更差分を製品のソースコードにマージする前に、変更差分だけでテストするテクニックがあります。それ単体で問題があるなら、マージするまでもなく開発者に差し戻しできます。

Sharding / parallelization：

当然の取り組みとして処理の並列化による高速化が考えられます。しかし、並列に出来ることは限られるので、並列性を高めようとするほどに並列実行できない部分がボトルネックになって効率を下げてしまうため（アムダールの法則）、このやり方だけでの効果には限度があります。

Merge queue：

複数の変更差分をまとめて一気に確認する方法があります。例えば5つの変更差分を一気にマージしてテストし、それで問題なければ5つとも合格と考えるやり方です。もし失敗した場合には、二分探索法（そういう「探す」アルゴリズム）で失敗の原因になっている変更差分を探します。

Incremental building & testing：

変更が影響しうる範囲を分析し、影響があり得る部分だけをテストするやり方もあります。例えばプログラムやテストの呼び出し構造を調査することで、どこを変更したらどこに影響が及ぶ可能性があるのかが解ります。そうすれば、確認すべき部分と確認しなくてよい部分が明らかになります。

Predictive test selection：

さらに、行われた変更により失敗する可能性の高いテストから実施するやり方があります。割り出した影響範囲から実行する必要のあるテストがABCの三つあったとして、Cが不通過になる可能性が高く、AとBは以前と変わらずに合格になる可能性が高いなら、Cを先にチェックしてNGかどうか確認する方がチェック時間を無駄にせずに済みます。

自動テストを悩ませる大問題に、不安定なテスト（フレーキーなテスト）があります。何回か実行すると時々失敗することがある、あるいはテストが失敗したので再現しようともう一回実行してみたら成功してしまうような、結果が不安定なものです。このような現象は本来望ましくないものなのですが、現実の開発においては残念ながらおなじみのものです。

実行タイミングにより動作が不安定なテストが、不必要なテスト失敗を出していることが多いので、自動的に一定回数再実行してOKがでるならテスト成功とみなして済ませている場合もあります。しかし、本当に不具合があるけれど、タイミング次第の要因があり時々にしか検知できないような場合もあります。このような問題が本番環境で火を噴くと大変に厄介であり、見つけにくいが厄介な問題こそ、どうにかして見つけなければいけません。しかし、再実行してOKにしていたらそういう問題は見逃してしまいます。

自動テストでエラーが出たならその都度、人手で不安定さの原因を調査して何が起こっているのか見極めればよいですが（不具合なら対処、テストが不安定なら対策）、時間もかかるのでなかなかそうもいきません。

そこで実行結果が安定しない自動テストを自動検知して、Noisy Testとして自動で隔離する取り組みがあります。そうすると、自動テストは安定して実行できるテストだけになるので、テスト本体はスムーズに実行できるようになります。

Noisy Testとなったテストは実行方法を変えて実行してみるなどして現象が調査され、不具合ならプログラマに修正を依頼し、そうでないなら自動テストを修正して安定化します。

最後にソフトウェア開発におけるAI活用について、どのようなことを期待しているかを伺いました。CopilotのようなAIの支援によるペアプログラミングが効果的であると期待しているそうで、特にジュニアエンジニアの効率化に効果的だと考えているそうです。

また、今後のAI活用については、様々な取り組みがなされているけれども、既存の開発手法とどう組み合わせていいかわからないことも多いため、今後どう活用されるようになるのかはわからないとしつつ、トリアージやテスト失敗の分析に期待しているとのこと。

また、AI活用で今後チャンスがあると思うのは、日々繰り返し行われていることへの適用、壁打ちの支援や開発の補助などサジェストやアシストをする機能、また生成AIについても今までの中で最も非連続的な変化なので、その可能性に期待しているとのことでした。

―自己紹介をお願いします。DataSpiderやHULFT Squareを開発したきっかけについても教えてください

• 小野 和俊 氏

私は1976年生まれで、小学生の時からBASICでプログラミングを行っていました。DataSpiderを開発するきっかけになったのは、大学生の時に野村総研でアルバイトしていた時の経験がきっかけでした。あちこちからデータをとってくるソフトウェアを書いていたのですが、データソースごとに形式も文字コードも全部バラバラでその都度それを変換する手間がかかった経験からでした。

大学卒業後は、サンマイクロシステムズに就職してシリコンバレーに行くことができました。そこでEAIというのがあることを知りましたが、使うためにはいろいろと設定が複雑だったりで、自分で開発する手間とあまり変わらないと思えました。

プログラマとしては、「ある」ものならそれを使い、「ない」なら作ろうと思うわけですが、必要だと思ったものが「ない」と解りました。他社に聞いても、この手の開発は個別の作りこみで対応している、となっていて困っているなら作ろうということで作ったのがDataSpiderです。「ない」から起業して作りました。

• 有馬 三郎

ずっとSIerに所属していて、お客さんのシステムを開発してきました。そこから社内のR&D部門の立ち上げ、当時セゾンテクノロジーのCTOだった小野さんが作った「テクノベーションセンター」の立ち上げに応募したのがキャリアチェンジのきっかけです。

HULFT Squareをなぜ作ったかですが、クラウド・アジャイル・DX・デジタルトランスフォーメーションと、世の中に失敗してもとにかくやろうという流れがあったのに対し、オンプレミスで利用する前提のパッケージ製品ではアジャイルのような考え方と齟齬が出てきたとおもったことがあります。

お客さんはシステムを作りたいわけではなく、ビジネスでやりたいことが目的に変わってきたこともあり、我々の持つ製品をマネージドで素早く提供すること、お客さんのスモールスタートを支援することを重視すべきだとおもったこと、また我々が長年苦労しているグローバル事業の戦略製品としても開発する必要があると思いました。

HULFT Squareは、シリコンバレーにSaison Technology International, Incという子会社を立ち上げて共同で開発をしています。

―チャレンジが必要な一方で、世の中では安定を求められていて、失敗できないプレッシャーがあることや、失敗がトラウマになっていることもあると思います。安定とチャレンジの両立についてお願いします。

• 小野 和俊 氏

80年代には、プログラマは魔法使いみたいなもので、プログラムを書いて自動化すること自体が喝采されたと思っています。しかしその後、書いたプログラムは動いて当たり前、動かないと怒られるようになったと思います。そのため、褒められることがなくて、いつも詰められているようなところがあります。

―私も元情シスなので、その状況はとても良くわかります。

IT業界がそもそもそんなところがあります。IT業界に入ってきた人は怒られたくて入ってきたわけではないはずで、自分が作ったもので多くの人に貢献したい、喜んでもらいたいと思って入ってきたのに怒られている。

ITがものすごく安定重視の方向に引っ張られる状況が、20年以上つづいてきたと思います。気を抜くと、「安定が大事である」の重力が強すぎて全部持っていかれてしまうようなところもあると思います。

しかし最近ではDXとも言われるようになりました。CTOをやっているクレディセゾンの属するクレジットカード業界でも変革が求められていて、もう安定だけでは勝てなくなっていて、安定とチャレンジはとても重要なテーマだと思います。

安定とチャレンジは二律背反的な考え方ではなく、「チャレンジするためには安定させないといけない部分がある」と発想を変えないといけないのではないかと思っています。

去年大きなリリースに取り組んだのですが、その時にテストコードのカバレッジを100%にしていました。かなり難しいチャレンジのプロジェクトでしたが、そうしていれば、なにか予期しない方針変更があってもテストが守ってくれると思うことができてチャレンジしやすくなりました。

自動テストのカバレッジが守ってくれるからチャレンジする、というように、安定を武器として使いながらチャレンジする考え方が必要なのではないか。そして実際に、安定の部分でHULFTやDataSpiderが寄与している実績もあります。

2015年くらいからHULFTもDataSpiderもクラウド時代に求められる製品に変えつつありました。そして当時、業務システムをAWSに移行する動きが始まっていました。

オンプレにあるシステムをクラウドに持って行く取り組みをするとして、全部一気にAWSに持ってくるチャレンジだと危なすぎます。

そこで実績のあるシステムはオンプレミスに残し、そこから安全安心で確実な足回りとしてHULFTを使ってオンプレミスとクラウドの間を連携し、絶対事故がないように連携できる基盤を整備してから、そこを足掛かりにしてクラウド上で新システムを作るチャレンジならばできます。

我々が推奨しただけではなく、お客さんが自分で選択したアーキテクチャでもそのような形のものがありました。

• 有馬 三郎

SEを16年やってきたので安定側の人間ですが、今はHULFT Squareの開発で技術的にも、要望への対応などでもチャレンジしている立場にあります。

かつてはお客さんが安定を求めていたからこそ安定を重視してきたところはあると思います。そして、安定を実現するために本当にルーティーンな仕事が多かったと思います。安全を守るためには手順を守る必要があり、それら手順がルーティーン化していて、日々その繰り返しで、そこから外れないことで安全性を担保するようなところがありました。

SEをやっていると皆さん良くわかると思います。そのやり方でちゃんと動くけれども、でもそれではチャレンジすることを忘れてしまいます。

2017年に当時セゾンテクノロジーのCTOで上司だった小野さんに、毎週報告資料を作っているんだけれどもそれが面白くないと言ったら、それは有馬さんの資料が面白くないんだよ、と言われたことがあります。

ルーティーンで資料を作っているということ自体が当たり前で、そこに面白さとは考えたことがなかった発想でした。有馬さんの資料がつまらないと言われて、そうか私はつまらないことをやっていたのかと気がついた。それがすごい発見だった。

たしかにそこに創意工夫などはほとんどなかった。面白いことをしていいんだという気付きは強烈だった。

• 小野 和俊 氏

そのことは覚えています。有馬さんはすごく嫌な顔で資料を持ってきたのも覚えています（笑）。

確か心理学でリフレーミングというのがありますが、ルーティーンの嫌なやらされ作業だと思うと資料の内容もつまらなくなります。そうではなくて、役職が上の方の人たちにメッセージを伝える機会だとおもったりすると、遊び心とか、ここを変えたらどうだろうとか、思うようになる。

無意識にやっていると、何でも安定になってしまう。しかし安定を全部捨ててチャレンジしろとか言われても無理はあります。それでも考え方ひとつで、あまり大きく変えなくても、新しいことは出来ます。

• 有馬 三郎

たくさん文字が書いてあってそれを読みあげるだけでは面白くない。報告を読んでもらって上の人に動いてもらう、楽しそうだと思ってもらう。それが大事だと思うようになりました。

―新しいことにチャレンジすることに関連して、マネージャとして、部下の人がつまらなさそうにしていることがあったらどうしますか。

• 小野 和俊 氏

自分の得意なこと楽しいことこそが成果につながるところがある。パフォーマンスがあんまりだなと思うときには、その人の強みが何なのか考えてみたい。

日本の義務教育なんかもそうですが、まず足りないところを埋めようとする傾向があります。でもそれやるとみんな普通になってしまうので、得意なことは何か、好きなことは何かをもう一回振り返って、それと今の仕事のアサインメントがあっているのかどうかを考えてみたい。

そういうことを確認してゆくと、まさかのビフォーアフターで、活躍できていなかった人がものすごく活躍するケースもありました。

―これまでのキャリアで意識してきたことを教えてください。

• 小野 和俊 氏

キャリアだけでなく人生全般について、「心が動いたらブレーキはかけない」やり方で生きています。

「これはめちゃくちゃ面白い」となったら、それやっちゃったらあれが、というようなことをいったん忘れて、全部何もない状態で考えたときに、全力で飛び込んでゆくのがどこまでできるかという感覚で生きています。

24歳の時に社長になりましたが、それまで部下すら持ったことがない、でも、できない言い訳とかもなしでやってみた。当然、その後反省することも多かったのですが。

セゾンテクノロジーと一緒にやるという話になったときにもCTO仲間に止められています。やったことない領域でしょ？とか、やり方があわないんじゃないの、とか。でも日本の社会インフラを支えているやり方はむしろそういうやり方だし、面白そうじゃん、と思って入りました。

クレディセゾンに来た時も、金融の大きなところだからそれなりに大変だよ、とは言われています。

• 有馬 三郎

私はSIをやってきました。自分のすることはシステムをきちんと作ることでした。一方で、HULFT Squareでは作ったものがお客さんにどういう価値があるか、価値について考えるようになりました。システムの開発だけだとどうしても安定重視になってしまう。

システムを作るところにずっといると自分の基準だけでしか人を見られなくなります。小野さんにも「有馬さんはバランスがいいけど、自分のレーダーチャートで見ちゃだめだよ」と言われたことがあります。

お客さんに価値を提供するためには、とんがっている人とか、いろんな方向にとんがっている人をまとめることが必要で、自分のレーダーチャートにあてはめない、それが大事なんじゃないかと思っています。

―会社にずっといると、自分のレーダーチャートというか、会社のレーダーチャートで固まってしまう思います。有馬さんはどこをどうやってそれを壊しましたか。

• 有馬 三郎

それはシンプルで、今ではもう、私が技術の世界のすべてを抑えられるわけではないと思っているからです。

クラウドとかAIとか、それに関係していろんなプログラミング言語なんかもでてきていて、それをすべて自分で抑えることは出来ない。そうなれば、だれかといっしょにやる、チームで得意な人に任せる、任せるっていうことがとても大事なことになります。

―海外のエンジニアと一緒に開発をしていて、気づきはありますか

• 有馬 三郎

この三年半、北米のチームと一緒にやってきました。そこで最近刺さったことがあり、日本には敬老の精神があるんだよという話をしていたのですが、アメリカ人エンジニアが「でも日本はエンジニアに経験みたいなものを軽視するよね？」ということを言ったことがありました。

振り返ってみるとSIの時にはエンジニアが若い人が多い。考えてみると30歳や35歳になるとみんな課長や部長になって現場からいなくなる。残っている人はすごく優秀な人もいるんだけれど、そのラインに乗れなかった、そんなレッテルみたいなものが張られている。そういう状況から経験を軽視しているのではないか。

日本ではエンジニアのまま上に上がってゆく階段が不足している、そう考えている。

―クレディセゾンではとても活躍されている年のいった方がおられるということですが

• 小野 和俊 氏

有馬さんの話は大事なことを言っていて、キャリアの多様性とか能力のレーダーチャートの多様性は大事なことだと思っています。

日本が製造業で世界一位だった時の勝ち方では、ある部署で部長できるなら他の部署でも部長ができるような、「交換が効く同じような能力」を育ててゆく、欠点があったらその欠点を埋めることをする。

そのやり方はその時代ではうまく行ったのは確かで、ある状況のある産業では勝つことができることは証明されている強いやり方だと思うけれども、今のように変化の時代で先が読めないような状況だと、そのようなやり方がフィットしなくなってきている。

フィットしなくなってきているが、成功体験もあるので変えることができなくなっているのが、今の日本でDXがなかなか難しいと言われている根本原因の一つではないかと考えている。

今では技術だけをとっても多様なものが必要なので、多様な能力や多様なレーダーチャートを受け入れられるようなマネジメントが必要で、そういう組織設計ができるように転換ができるかどうかが、DXという話の根幹にあるのではないか。

シニアで活躍している人も、プロマネ的なこともできるけれど、現場の技術がすごく解っている人なのでそちらで活躍している。彼の強さがあるんだったら、それが最大限に生きるお願いをするし、そういう給与体系を用意しなければいけないという考え方です。

最初に話題になったように、人を型にはめようとせず、その人の良いところを見つけて、それに合わせてゆくことが必要だと思っています。

―型にはめない方が良いですよね。最初の方であったように、その人の良いところを見てあげて、あったところに転換してあげる考え方はとても大事だと思います。

―すごく話が楽しいので残念なのですが、時間が来てしまいました。安定とチャレンジということで、お二方からは色々な貴重な話をいただけたかと思います。本日はありがとうございました。

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