「Qiita Meetup エンジニア駆動で進めるDXとは？」イベントレポート
DXを推進していくために欠かせないのが、エンジニアとビジネス部門の伴走です。そこでQiitaでは、「エンジニア駆動で進めるDX」をテーマに、エンジニアが推進するDXの可能性や主導するエンジニアのあり方について、ゲストを招いて考えるイベントをオンラインで開催しました。今回はその模様をダイジェストでお伝えします。
目次
プロフィール
取締役専務執行役員（技術部門管掌）
Principal Technical Architect
CEO/ジェネラルパートナ
プロダクトマネージャー
セッション①：エンジニア駆動DXへの招待 ～チームの隙間を埋めるための3つの提案～
エンジニアはリーダーシップとフォロワーシップを発揮せよ
中野氏はセッションの狙いについて、「デザイナーやエンジニア、そうした方々のチームのマネージャーに対し、DXを積極的に進める方法、チームの取り組みの成果や今後のキャリアの明確化にDXを生かす考え方を提案したい」と話します。
「DX」という言葉は、さまざまな文脈で多様な使われ方がされていると中野氏は述べます。DXを捉えるにあたり、中野氏は自身が最も納得したという、naoto氏のnote記事「DXコンサルが絶対に言わない後ろめたい真実」を紹介しました。
その記事では、DXを「デジタルがコモディティ化する『前』に完成した『ビジネスの型』を、デジタルを前提としてリデザインすること」だと捉えています。「デジタルがコモディティ化する以前から存在してきたビジネスを、デジタルへと最適化する方法」とも言い換えられるでしょう。
そんなDXについて、中野氏は最近見かけた記事の中から「これはまさにDXに該当するだろう」と感じた例を2つ紹介します。1つは、NHKの記者が地図情報を自ら手に入れることで、新しい記事の企画につなげられるようになった話。
2つ目は、市の職員が自分でアプリを作り、電子政府のような機能を提供できるようになった話です。
中野氏はこれら2つの事例について「エンジニアがリーダーシップを取っている部分と、フォロワーシップを発揮してうまくビジネスをサポートしている部分があるのだろう」と推察します。顕著な例として2つ目のケースを取り上げ、エンジニアが後方支援する体制を取っていなければ、職員のみでローンチすることは難しかっただろう、と指摘しました。
この例を踏まえた上で中野氏は、「リーダーシップとフォロワーシップを同時に発揮すること」がDXで求められる資質だと明かします。
「DXを効果的に進める上では、エンジニアのチームがビジネスメンバーや経営層も含めた他のチームを巻き込みながら、時にリーダーシップを取り、時には裏方的なフォロワーシップを発揮することが成功に近づけるポイントではないかと考えます。
エンジニアがリーダーシップを取るべきところは、テクノロジーに近い領域やIT技術を駆使しなければならない領域です。
フォロワーシップを発揮するべきは、ビジネスサイドのチームが前面で活躍している時や、ビジネスサイドの方がデジタルに興味を持って、何とか問題を突破しようとしている時です。ビジネスサイドのチームのお株を無理に奪わずに取り組みを支えられると、全体としてうまくいきやすくなります」
エンジニアはDX全行程に主体的に関わっていく存在であれ
DXの全行程において、エンジニアは主体的に関わっていく存在でありたいとも中野氏は話します。リーダーシップを取るべきところとフォロワーシップを存分に発揮するところをうまく棲み分けながら、エンジニアのフォローが必要な場面で、相手からサポートを要請される状態をどのように作り出すかが非常に重要だと語ります。
では、具体的にどのような対策を取ればよいのでしょうか。中野氏は「時間を作るために、最大限の工夫をする」「視座を上げる」「人を動かす力を身につける」という３つのポイントを挙げます。
この内、「人を動かす力」を磨くために中野氏が推奨するのが、人を動かすための資料作りです。
「システムの開発とは少し違う内容の資料の作り方を、ぜひエンジニアの皆さんにも学んでほしいと思います。エンジニアがこういう資料を作れると、普段の構造化や言語化スキルと組み合わさって、より説得力のある言葉で語ることができます」
中野氏は、先ほど紹介したnaoto氏の記事から、「問題の根本は人と制度や仕組みにある」という言葉を引用します。DXを成功させるには人の習慣や文化を変える必要があり、リーダーが変革に向けて動かなければなりません。
ただnaoto氏の記事にある、「変えうるのはリーダーだけである」という表現については注意が必要だといいます。もしリーダー以外が読むと、思考停止を生んでしまう危険なフレーズだからです。
「リーダーだけに変革の仕組みづくりを任せてよいのか、常に自らに問いかけ続ける必要があります。リーダー以外の人間は、リーダーを本当に応援しきれているのか、フォロワーシップを発揮しきれているのか。ITとデジタル技術を前に苦戦している方を、十分にサポートしきれているのか。その代わり、リーダーになった時は思い出してほしい。やっぱり自分自身が変えなきゃいけないのだと。この両方の意識が必要だなと思っています」
中野氏は、説明を続けます。江戸時代の下町は、道の真ん中がきれいだと評判でした。左右に住んでいる人たちが、それぞれ真ん中より向こうまで掃き合うからです。
「エンジニアとビジネスサイド、エンジニアとマネージャーはそれぞれ対極する立場だと認識されています。それぞれが江戸の下町に住んでいた人たちのように、『向こうまで』という気持ちでコラボレーションして、初めて物事は前に進むのではないでしょうか」
最後に、中野氏は「DXという非常に大きなトレンドに対して、自分がけん引していくという意識を持った上で取り組み、自らのキャリアアップのチャンスとしていただきたいと思います」と締めくくりました。
セッション②：ノーコードからプロコードまで、DX時代のアプリ開発プラットフォーム
クラウド3.0を実現するプラットフォーム
「私がこれからお話しするのは、デジタルトランスフォーメーションを支えるデベロッパー・エクスペリエンスのDXです」という滑り出しで、阿部氏はDX時代のエンジニアを支えるSalesforce Platformの特徴を説明します。
Salesforceはノーコード／ローコード、つまりプログラミングのスキルが不要なプラットフォームとして認知されていますが、実はエンジニアにこそ使ってほしいものなのだと阿部氏は語ります。
初めに、阿部氏は「Salesforceが定義するクラウド3.0」について、「端的にいえばどこからでも仕事ができる環境」だと定義します。
どこからでも働ける環境が普及することは、場所を問わずビジネスにイノベーションを起こせる環境が整っていることも意味します。あらゆる業務が自動化されることによって、ビジネスの規模はどんどん拡大していき、あらゆる人を支援できるようになります。まさにクラウド3.0によって、誰もがどこからでも誰かをサポートできる環境が整ってきたのです。
ただ、自動化やイノベーションの拡大を阻害する要因は数多くある、と話した上で阿部氏は以下を例として挙げます。
● 新しい機能を追加しようと考えた時、ツールに柔軟性がない
● 複数の開発案件が同時に進行していてうまくいかない
● テストが自動化されていない
● データのセキュリティやガバナンスが守られていない
これでは、なかなかリリースまでこぎ着けることができずに、時間やコストだけがかかってしまいます。こうした要因の存在によって、我々がイノベーションに割ける時間はおよそ46％程度だと言われている、と阿部氏は明かします。
阿部氏は、そこでデベロッパー・エクスペリエンスの向上が必要になるとして、「オープン」「モダン」「柔軟性」の大きく3つが求められると語ります。
上述した3つのポイントを全て備えているのが「Salesforce Platform」だとして、阿部氏はさらに説明を続けます。
「Salesforce Platformでは、アプリケーションのライフサイクルを管理する機能や、DevOpsを支援できるCI/CDツール、デプロイやリリースに役立つツールを提供・連携可能。これらの機能によって、Salesforceにおけるアプリケーション開発は、従来と比較して68％も時間短縮しているという記事もあるほどです」
アプリケーションライフサイクル管理（ALM）について、Salesforceは必要となるほぼ全ての機能を提供しています。
阿部氏は上述した「ほぼ全ての機能」について、具体的に紹介します。
まずは開発機能について取り上げ、Salesforceはノーコード／ローコードに限らずコードで開発することも可能で、それを支援するVisual Studio Code エクステンションが公開されていることを明かします。
テストについては、開発・テスト環境のSandboxをクリックするだけで用意することが可能だと紹介。
DevOpsにおけるリリース機能について、阿部氏は以下のように続けます。
「アプリケーションをまとめてパッケージ化することで、他のお客様にも提供したり、『AppExchange』というエコシステム上で公開したりできます。また、CI/CDとも連携できるので、デプロイの自動化も可能です」
Salesforce Platformならではの特長とは
次のセクションとして、阿部氏は「Salesforce Platform」ならではの特長を紹介。初めに、従来のアプリケーション開発とは、データベースの上でプログラムを動かすものだったと振り返ります。
その一方でSalesforceはレイヤー単位で開発する、と前置きした上で、「疎結合されているので、分かれて開発することも、一度に改変することも可能です。ビジネスサイドに近い方が画面上のコードだけをローコードで開発することも、エンジニアがソースコードで開発することもできます」と阿部氏は紹介します。
自分が注力したいところにフォーカスして開発できる点がSalesforceの強みだと語りました。
Salesforceのサーバー側については、ApexというJavaに似た言語を使って、簡単にビジネスアプリケーションを開発できると紹介。
コーディングしたプログラムについては、画面を組み合わせて実現できる仕組みだと語ります。
さらに、ここで阿部氏は「フロー」というSalesforce Platformの大きな特長の1つについて触れます。
「フローチャートのようにパーツを組み合わせるローコードツールがあるのですが、Apexで開発したものも1つのパーツとして組み入れられます。ですので、アプリケーションのパーツとして再利用性の高いApexのモジュールを作っておけば、それをビジネスサイドが組み込みながら開発を進められます。プロコードとノーコード／ローコードをうまく切り分けながら、シームレスに連携することが可能です」
また、Salesforceではe-ラーニングのシステムを用意しており、アカウントを作るだけで、すぐに学習を始められると阿部氏は明かします。
また、Salesforce Platformを実際に試してみたい場合は「Developer Edition」を使えば、サインアップのみで無料で利用できると紹介。ドキュメントやヘルプを豊富に用意しているため、困った時は参照しながら進められるとアピールします。
セッション③：エンジニアの価値が最大化される”繋がる仕組み”の実装例
価値ある技術とは何なのか
佐伯氏は、自身のセッションの内容を「DX」や「Salesforce」といったキーワードに限らず、「価値ある技術の定義」をエンジニア視点から考えた上で、Salesforceのプロジェクトを紹介するものと位置付けます。
佐伯氏は「DXやSalesforceに興味はありますか？」と問いかけます。その理由は、以下の2点に集約されます。
● DXはエンジニアの現場からするとやや遠い距離に存在する言葉である
● Salesforceに関するイメージは必ずしも好意的ではないと認識している
それを踏まえた上で、佐伯氏は「ただ流行っているからとか、ただ求められるからという理由で技術を選択するのは、あまりオススメできません。エンジニアとしての自分の生き方、キャリアプランを改めて考えながら聴いていただきたい」と話します。
そして、エンジニアとしてのキャリアプランを考える時に気になることとして「その技術は価値ある技術なのか考えた上で、取り組むとよいのではないかと思っています」と強調します。
「DXとSalesforceは同義語ではなく、Salesforce以外にも価値ある技術はあると思います。自分にとって価値ある技術は何か、その価値はどうやって生まれているのか。そういった観点に立ってSalesforce Platformにはどのような価値や技術があるのか考えていただけると幸いです」
Salesforceの価値と技術
佐伯氏はSalesforceを価値と技術に分解して説明します。
初めに、Salesforceの価値について、「つながる」という付加価値の存在とつながり方のスケールを特長として挙げています。
「Salesforceは、ある程度型が決まったものにカスタマイズを施すもので、どうしても実現できない時には独自言語で拡張して開発するものと理解されていますが、これはとても部分的な話です。実際にはSalesforceには非常にたくさんの製品があり、関連製品を多数提案し、それに価値を感じてプロジェクトを立ち上げるケースが非常に多いのです。広いスコープがつながることがSalesforceの価値であり、エンジニアの価値や活躍の場も広がっています」
また、佐伯氏は「プラットフォームの制約は悪いものとして捉えられがちですが、品質の悪いコードを排除できるなど、デメリットばかりではありません」と続けます。対象となるスコープが広いだけに、ローコード／ノーコードが主体であることは、価値あるエンジニアリングリソースについてフォーカスできるという良さがあることをアピールしました。
Salesforceでの実装例
ここから解説は、Salesforceにおける実装例に入っていきます。佐伯氏は、Salesforceが提供する「サクセスナビ」を例として挙げます。
Salesforceが提供する「サクセスナビ」を例として挙げます。(リゾルバ社が企画・開発協力)
「エンドユーザーにサービス自体は提供できていても、使われない、もしくは想定外のアクションをされると意味がありません。そのため、一旦サイトができた後であっても仕様の変更は起こるものです」
佐伯氏は、サービスを「作られた瞬間から、さまざまな仕組みや技術をどんどん求められ続けるもの」と定義します。中にはフルスタックエンジニアが開発すれば良いと考える人もいるかもしれませんが、全てをカバーするのは非常に難易度が高いことです。
佐伯氏は、「サクセスナビは下図のようなアーキテクチャです。関連製品全体の拡張や連携方式を熟知していれば、自分でマネージしながら、適切な場所にエンジニアリングソースを投入できます」とSalesforceのメリットを挙げます。
佐伯氏は、以下の流れについて実際の画面を見せながら紹介します。
1.アプリが使われる
2.アクションログが統合される
3.BIで即座に分析される
4.結果抽出されたリストに対して、マーケティングオートメーションを使いフォローアップする
そして「革新的なサービスを開発できるエンジニアは存在しますし、革新的なサービスは世の中にたくさんあります。Salesforceにおけるエンジニアリングの魅力の1つは、サービスに関わるあらゆる担当者や業務をつなげる仕組みまで、スコープに入れて考えられることです」と締めくくりました。
パネルディスカッション
3つのセッションの内容を踏まえて、パネルディスカッションが行われました。トークテーマは、「エンジニアから見たDXの現在について」と「DXの文脈でエンジニアが学ぶべき技術や考え方」の2つです。
1つ目のテーマである「エンジニアから見たDXの現在について」では、中野氏が「プロダクツの開発をご支援するケースと、社内のシステム開発をご支援するケースがあります。どちらにおいても内製化という文脈でお手伝いすることはありますが、それぞれのケースにおいて起こっていることは異なります」と切り出します。
プロダクツの開発ではビジネスが優先され、エンジニアはどちらかというと受け身に回ることが多いといいます。そうすると未来に向けた投資、よく言われる「技術的負債」の返済のために工数を割くのが難しくなる上、エンジニアも疲弊しがちです。
一方で社内システムを開発する場合は、未だにウォータフォール方式をとるケースが多く、上流工程がうまくさばけていればスムーズに進められることが多いようです。
続いてモデレーターの清野は、クラウド3.0の時代に突入したことで生まれている課題について、阿部氏に見解を求めます。
阿部氏は、「リモートにすればいい」でDX構想を終わらせてしまうのでは根本的な解決にならないとし、「全社的にどのようにDXを進めていくべきか構想しなければ失敗に終わるでしょう」と話します。
しかし、いくらエンジニアが現場や環境を変えたいと思っていても、非エンジニアの経営陣を説得することは難しいという意見もあります。
中野氏は「王道はないと思いますが」とした上で、2つのパターンを紹介しました。
1つは、通したい案をブロックしている人に対し、説得できる人を探すというものです。そして、会社全体を動かそうとした時に「自分自身で何とかしなければ」という思考回路を持つことも、DXを阻害する要因の1つだと指摘します。
2つ目は、自社と近い業界や規模感で成功している会社を探し、思い切って質問してみるというもの。同業他社でも、意外に丁寧に対応してくれることが少なくないといいます。
その後、議論は2つ目のテーマ「DXの文脈でエンジニアが学ぶべき技術や考え方」へと展開していきます。
阿部氏は先ほど挙げた「経営陣の説得」について、説得の際にもSalesforce Platformが有効だと強調します。
「Salesforce Platformなら、とりあえずプロトタイプを作り、実物を見てもらって評価してもらえます。強い論拠を持って説得にあたれるのです。そのため、技術や考え方よりも、個人的にはとりあえずやってみる勇気が重要かなと思います」
では、現場社員やエンジニアが、まず始められることは何でしょうか。
中野氏は、システムの構築全体に関しての方法論を学んでおくことが、その後のスピードアップに役立つと紹介します。
「若いうちに、システム開発作業の目次を自分の中で構築できるようになるといいと思います」
イベントでは、チャットを通じて質問を募集しました。「DXを実現させるために、エンジニアの立場で一番重要なことは何だと考えますか」との問いに対し、阿部氏は「先ほども言ったように、勇気かなと感じます。エンジニアの経験をDXにうまく活用できるので、今の時代はエンジニアがリードすべきだと思っています。中野さんからも話があったように、周りを巻き込んで上にあげていくスキルが要りますが」と答えます。
中野氏もこれに同意した上で、「愛が必要」だと応じます。
「DXの推進では環境を変えることが目的になりがちですが、最終的にはその先にいるユーザーやプロダクト、チームや会社に対して、どれだけ愛があるのかの勝負になると思っています。自分が触っているアーキテクチャや技術に対しての偏愛でもいいでしょう。何かこだわっているものがないと軸がブレてしまいます」
イベントの最後に、中野氏は「問題の原因を自分以外にあると考えがちなのは人間の本性でしょう。ですが、自分も問題の一部なのだと思って、自分自身も変革しなければいけないのだという感覚でいると、人にも優しくできるのではないでしょうか。常に道の真ん中の向こうまで掃ける人間でありたいなと、自分で話しながら改めて思いました。ぜひ皆さんで、日本という道の真ん中をきれいにしていきたいですね」と振り返ります。
そして阿部氏は「DXに限らず変化の多い世界なので、変化を恐れずに次に進むためには愛が重要だなと私も思います。この変化に乗ることを楽しんで愛を持って接すれば、必ず良いエンジニアにもなれるだろうし、さらに良い世界が待っているのではないかなと考えています」と締めくくりました。