DX時代に求められるエンジニアでも知っておきたいスキル・知識

はじめに

「DX」というキーワードをよく耳にするようになり、様々な企業でDXの推進が求められるようになってきました。この変化に伴ってエンジニアに求められるスキルも少しずつ変わってきたように感じています。DXを推進していくには、最先端の技術に加え、幅広い知識やビジネススキルが必要不可欠です。私は数年前まで技術系のエンジニアでしたが、DX支援の業務に携わるようになってから、技術支援だけでなく、サービスの開発・企画支援や営業支援を行うことが多くなってきています。

今回は、エンジニアでも覚えておきたいビジネススキルやDXに関する知識について、私が業務で経験したことを交えてお伝えしたいと思います。

戦略(経営戦略、システム戦略)の知識

最近では、上流工程を経験してないエンジニアでも、企画や要件定義のフェーズの段階から加わるケースも増えてきました。特に、企画や構想案などができたタイミングでエンジニアとして技術的な面から意見を求められたり、PoC(新しい技術やアイデアを実現できるかを検証)を企画段階で実施するケースが多いです。

DXは、主に新しいサービスやビジネスモデルを構想する、また今までに使ったことない新しい技術(AI、IoT、RPAなど)を用いることが多いため、技術検証をしないまま要件定義や設計に進むと、想定しなかったことが発生した際に手戻りが生じます。そのため調査や検証、プロトタイプ開発をしながら進めます。ここでの検証や開発は、ビジネスの目的や顧客目線を意識しながら進めることが重要になり、QCD(品質、コスト、納期)を守ることよりも、戦略・スピードを重視することが多いです。エンジニアも、企画段階で決まった内容や検証目的を理解し、意見を述べることや戦略に則ってプロトタイプを開発していくことがプロジェクトを進める上で必要となります。

コミュニケーション能力

コミュニケーション能力は以前からシステムエンジニアに必要と言われていますが、DXを推進するプロジェクトでは、より求められます。コミュニケーション能力の中でもお客様からの要望を引き出すヒアリング能力は重要です。DXはお客様の業務部門や企画部門と一緒に進めていくことが多いため、一般的にIT部門がベンダーにシステム発注する際にまとめる内容(機能要件、非機能要件、制約条件など)は漏れるケースが多々あります。そういったことがないように、エンドユーザーからいろいろな情報を引き出す能力が必要です。私は、お客様が抱える課題の本質を見極めるために、資料の読み込みはもちろん、現場に足を運んで業務風景を見学させてもらったり、場合によっては雑談や飲み会などの場で、会議ではなかなか言えない現場の本音や課題を聞いたりします。そういったコミュニケーションの中で、事前に伺っていた内容とギャップがないか確認していきます。一度システムを作ると、決まっているものには対応できますが、イレギュラーなものにはほとんど対応ができず、改修が必要になります。そのためお客様の本質的な課題を見誤ってしまうとプロジェクトは失敗します。事前にきちんとヒアリングし、正しく事実認識をして、課題を解決する提案につなげていきます。

アジャイル開発

DXを推進するプロジェクトでは、ウォーターフォール開発よりもアジャイル開発で実施するケースが多いです。これは経済産業省も推奨しています。アジャイル開発では、開発メンバーでも開発以外のことをたくさんこなします。具体的にはお客様への積極的なヒアリング、パッケージデザインの作成、チーム全体での見積内容の検討、フィーチャー(機能)の洗い出し、納期までのスケジュール作成などです。これらの作業を実施する上で、前述した戦略の知識、コミュニケーション能力はとても大事になってきます。お客様の要望をきちんと理解した上で本当に大事なものを優先的に開発していくことが求められますし、急な確認事項や変更があれば、お客様にすぐに連携・相談できる良好な関係を保つ必要があるからです。

システムアーキテクト

企画を考えるメンバーがまとめた資料に沿って、実装すべきシステムの設計ができる能力を持ちます。プロトタイプなどを作る際も、あらかじめ設計書を作った上で作成していくこともあります。例えばUI/UXなどのフロントエンドで入力されたデータの処理、データベースのシステムなど、ユーザーの目に見えない部分のバッグエンド処理や、AIでデータを解析するデータ周りの処理などを設計してサービスに起こしていきます。この設計技術をエンジニアや顧客目線でも分かるようにドキュメントに起こしていくと、プロジェクトがスピーディーに進みやすくなります。この役割は、お客様であったり自社のエンジニアであったり、専任の担当者が担いますが、私の経験ではエンジニアが実施することが多いです。幅広い知識とスキルが必要なので難しい領域ですが、DXを推進していく上では必要になる能力です。

攻めのDXと守りのDXの分類

最近、よくこのキーワードを耳にします。「攻めのDX」は新しいビジネスモデルなどを新しい技術で作ること、「守りのDX」は業務改善などを新しい技術で実装することを指します。守りのDXは従来の開発手法や進め方で実装することが多いですが、攻めのDXは、エンジニアが企画段階から参加することが多いため、前述したビジネススキルが必要になるケースが多いです。一般的に言われているDXとは攻めのDXを指します。どちらのDXで進めていくかで開発手法が異なります。

攻めのDXは、企画の後にすぐにプロトタイプを作るフェーズに入り、うまくいけばそのまま本番の開発に進みます。そのためR&D(研究開発)を実施することや、アジャイル開発で進めることが多いです。逆に、守りのDXでは改善すべきところがはっきりしているケースが多いので、アジャイル開発のときもあれば、ウォーターフォール開発で実装するときもあります。まずはお客様の要求がどちらなのかを見極めると、次の進め方も見えてきます。

顧客要求をすぐにシステム要求に整理する

このスキルは、開発者が会議に参加する場では間違いなく必要になります。何度も言いますが、エンジニアはDXプロジェクトにおいてユーザーの企画をただ待っているのではなく、技術的にできることを押さえつつ、ユーザーと一緒に企画や要求、要件を整理していく振る舞いが求められます。

ここで言う整理とは、ユーザーが出したアイデアを構造化・具体化し、実現性や優先度を可視化して判断できるように支援することです。例えば、顧客側の意見が「AIを使って解約率を削減したい」だった場合、「料金請求や問い合わせ履歴から解約の可能性が高い顧客を分類したい」というシステム要求に整理します。そこから優先度を判断したり、新しい意見が出てきたりすることもあります。また、データの十分性や開発コスト、難易度など複数の視点から実現性の可否も確認できます。エンジニアには、こうした検討ができるように、要求を整理して意見を述べる能力が必要になります。

ITはなんのためにあるのか

DXプロジェクトとして作る新しいサービスは、大元をたどると経営戦略で決まった内容がきっかけだったりします。その内容を目的・目標に落とし込み、達成するための強力なツールとしてITがあります。言い換えるとITは経営課題を解決する1つの手段にすぎないということです。

達成する目標に対して、AIやIoTなど最先端の技術を必ずしも使わない、場合によってはシステム化しなくてもすでに導入されているツールなどで解決できるケースもあります。DXやAIに注目が集まる中、お客様が何かの情報やきっかけをもとに最先端技術を使った企画を考え、エンジニアに意見を求めるケースがありますが、実際の課題や要求を聞くと、開発や学習に係るコストなどを踏まえ、別の解決手法にたどり着くこともあります。DXが必要な理由や、大元の背景を聞いた上で、エンジニアとして目的を達成するベストな意見や提案ができるようになることもDXプロジェクトを進める上で重要になります。

おわりに

私も普段からお客様のDXを支援する業務に携わっていますが、技術面はもちろんこと、ビジネススキルや様々な知識をもとに対応することが常に求められています。DXプロジェクトでは、ビジネスプロデューサーやデータサイエンティスト、UI/UXデザイナーなど、様々な役割を持つ方々とも連携しながら進めていくことも多く、幅広い知識やコミュニケーション能力が必要です。そして、なによりプロジェクトの目的を正しく理解することが一番大切です。技術、ビジネススキル・知識を身につけ、お客様の真の課題を把握し解決することこそ、今のエンジニアに求められていることだと考えています。