アーカイブ動画
これまでの蓄積を活かしつつ、スピーディかつアジリティな開発にシフト
株式会社NTTデータ 第一公共事業本部
パブリックサービスデザイン事業部 第二システム 統括部長 稲山 明彦氏
公的年金や医療費関連のシステムなど、国民に必要不可欠な大規模社会基幹システムの構築を得意とするNTTデータ。一方で民間のシステムも手がけるなど、名実ともに、私たちの暮らしをビジネスで支える、日本ナンバーワンのシステムインテグレーターである。
最初に登壇した稲山明彦氏は、まさに中央官庁のシステムや病院ビジネスのアプリケーションの開発に取り組んできた人物で、現在は事業部内のインフラ技術者集団を統括する。
長きにわたりNTTデータを見てきた稲山氏は、ここ2〜3年における開発現場の変化を次のように話した。
「小規模な開発を短期間で行う案件が増え、開発現場ではスピードと瞬発力が求められます。一方で、これまでの大規模公共システムの開発では経験できなかった、例えば自動化など、最新技術や多様な開発に携わるチャンスも増えています」（稲山氏）
事例１：半導体不足でサーバが納品されない危機にどう取り組んだか？
株式会社NTTデータ 第一公共事業本部
パブリックサービスデザイン事業部 技術支援G 課長代理 栗田 裕亮氏
続いて登壇した栗田裕亮氏も、稲山氏同様に開発現場で起こっている変化をこう述べた。
「以前はUnixやLinuxといったOSやミドルウェアの設計はほぼオンプレで行っていましたが、2019年頃から潮流が変わってきたように感じます。現在はクラウドネイティブなシステム開発が増えてきており、マイクロサービス、サーバレスなアーキテクチャを考える仕事が中心となっています。とはいえ、オンプレミスの案件もまだまだ健在、といった状況です」（栗田氏）
栗田氏が発表した事例は、機械学習、自然言語処理を行うプラットフォームをLinuxサーバ約30台など、オンプレミスで構築する開発プロジェクトだ。
しかし近年の世界的な半導体不足により、予定通りにハードウェアが納入されないという問題が生じた。具体的には、2022年8月にすべてのハードウェアが納品される予定であったが、Linuxサーバが1カ月後の9月末に遅れることとなった。その他、ネットワーク機器などはさらに遅れての納入となったのだ。
このままでは期日までに構築が間に合わないと考えた栗田氏は、大きく3つの取り組みを行うことで、課題解決に取り組んだ。
まず1つ目は、AWS上に可能な限りオンプレに模した環境を構築する。そしてIaCツールAnsibleを使い、すべての構築内容をPlaybookに記述していった。栗田氏は取り組みを進める上での工夫を、次のように語っている。
「ネットワークが複雑に分離されていること、搬入される機器に順序性があることから、スケジュールに応じて、Playbookのパターンをいくつか作りました」（栗田氏）
そしてこの工夫が奏功し、ハードウェアの納入後はPlaybookを流すことで、数日でシステムを構築完了することができた。
2つ目は、コンテナレイヤーでの取り組みだ。こちらもパブリッククラウドを活用した。従来行っていたオンプレ構築のやり方ではなく、AWS上にコンテナイメージを作成、アーカイブし、オンプレ側に構築したコンテナレジストリにイメージを運搬。あとはオンプレ内のコンテナ実行サーバがレジストリからイメージをダウンロードする仕組みを構築したことで、こちらも時間短縮を実現した。
3つ目はインフラテストの取り組みである。こちらもPlaybookと同様、ストレージの搬入前と後で、テストを分類。加えて、ストレージ導入前に行えるテストはすべてテストコードにしておき、導入前後でそのコードを流す戦略を採用した。
なお、インフラテストの自動化ツールはBats (Bash Automated Testing System)を採用。その理由を次のように説明した。
「インフラテストの自動化ツールは有名なツールも含め、豊富に揃っています。あくまで私見ですが、学習コストが高いと感じていました。そこでシェルスクリプトの知識があれば、習熟が容易なBatsを採用しました」（栗田氏）
事例２：クラウドの流れによる短納期システム開発
昨今、パブリッククラウドの活用が前提となる案件も出てきた。このような状況に対し、栗田氏は単なるクラウドの導入ではなく、“活用”することが重要であり、AWSやAzure、GCPといったメガクラウドの知識は必要だと語る。
構築手順書やIaCについて、時間をかけて作成する余裕がないケースも多く、マネージドサービスやサーバレス知識が重要となる。また、一日に何度もリリースするケースも多く、CI/CDは当たり前になりつつあるという。
そして、絶えず発生する要求の変更に柔軟に対応できる、クリーンなアーキテクチャが求められている。これら全般の知識や技術を身につけていることで、良きシステムが構築できると、栗田氏は強調する。
栗田氏はアーキテクチャを設計する際は、元々自身の成功事例をベースに考えると語り、AWSにおける3つのパターンを紹介した。1つ目は、ALB（Application Load Balancer）やEC2などのサービスがパッケージングされたElastic Beanstalkを軸とした構成だ。採用するシーンにおいては次のように説明した。
「サーバ側の処理に寄せるような構成となっているため、JavaScriptやTypeScriptといったフロントエンド寄りのエンジニアが少なく、逆に、Javaが得意なエンジニアが多いときなどに採用することが多いですね」（栗田氏）
2つ目はECS（Elastic Container Service）を軸にした構成だ。コンテナを活用したり、別クラウドへの移植が予定されているシステムの場合に採用する。
3つ目はCloudFrontとS3でフロントエンドを組み、バックエンドはAPI GatewayとLambdaで組む。フロント・バックエンドをきっちり分けるアーキテクチャであり、栗田氏が毎回、実現したいと思い描いている構成でもある。
また、構成を考える際にはマネージドサービス、サーバレスの活用を常に考えており、理想形としているが、開発難易度が高くなったり、適用が難しいケースもあるという。そこで理想形を掲げながらも、要件に応じ、柔軟にアーキテクチャ設計を考える力が求められている。最後に次のように語り、セッションをまとめた。
「クラウドを常に使うわけではなく、リードタイムが短くなるから活用する。このような応用が大事です。アーキテクチャの設計においては、銀の弾丸は存在しません。自分の中のコアパターンを毎回考えるとともに、システム開発は甘くないことを理解し、日々成長することが大切だと思います」（栗田氏）
事例３：公共系で続々と押し寄せるAI需要への対応
株式会社NTTデータ 第一公共事業本部
パブリックサービスデザイン事業部 技術支援G 主任 照井 裕貴氏
続いて、中央官庁のAI活用PoC事業に複数従事、提案からモデル開発、検証に取り組んでいる照井裕貴氏が登壇。近年ますます盛り上がりを見せているAIにおいて、公共領域での需要の実態、事業部のアプローチなどを紹介した。
公共領域でのAIの需要は、法制度の複雑化や業務の多様化に対し、GPT-3などのAIモデルを活用して業務の効率化や高度化を実現したいというニーズがあるからと推察している。
現状はPoCフェーズということで、具体的な取り組みの流れと、生じている課題も挙げた。1つ目の課題は、専門知識とドメイン知識を掛け合わせた提案で解決したトラブルだと照井氏は説明。具体的な解決策とともに次のように話した。
「技術的観点では問題が見つかりませんでしたが、当初検討していた学習方法では思ったように機械学習モデルの学習が進みませんでした。そこでドメイン知識をもとに学習方針を変更し、データセットに対して改善のアプローチを試みたところ、学習が進みました」（照井氏）
2つ目の課題は、検証パターンが多岐に渡るため、リソースが足りなかったことだ。世の中には数多くのモデルがあり、同様に解決するタスクも多くある状況。それらの組み合わせに対して検証を行い、よりよい機械学習モデルを追及することとなるとパターンが膨大になるため、検証期間に対してリソースが不足するケースがあった。
また、最適なモデルにあたりを付けたのちに、モデルの精度を高めるために追加で学習させる必要がある。こうした課題を解決しようと、照井氏は機械学習専用のハードウェアの利用を検討。事前に検証を行うと約20倍の時間効率化が見込めたため、導入を決めたという。
公共系領域でのAI需要の波はこれからまだまだ高まるであろうということ。先述の課題解決のとおり、クライアントのニーズに的確に応えるには、AIに関する専門知識に加え、対象となる業務領域のドメイン知識が必要なこと。そしてこのような「業務理解×専門知識」の重要性はAI案件に限ったことではないと語った。
「新しい技術のキャッチアップ、積極的な利用（チャレンジ）といった点を意識して続けていくことが、非常に大事だと考えています」（照井氏）
事例４：顧客の内製開発部隊を急遽支援することに対する取り組み
株式会社NTTデータ 第一公共事業本部
パブリックサービスデザイン事業部 技術支援G 課長代理 山岡 俊祐氏
オンプレミス環境でのLinuxの設計・構築業務に携わった後、クラウド化の検討業務に従事してきたキャリアを持つ山岡俊祐氏は、2022年に顧客先に常駐し、内製開発支援に取り組んだ事例を紹介した。
その案件の開発体制は複数のスクラムチームから構成され、アジャイルで進められていた。開発工期は半年。山岡氏は各スクラムチームを支援するサポートチーム内のインフラアーキテクトチームの所属となった。山岡氏は自分がアサインされた理由と、当時感じた課題を次のように話した。
「開発メンバーは揃っているものの、インフラまわりの知識が不足気味でした。特に、非機能面やシステムアーキテクチャの検討、構築が負担となり、スクラムチームが本来実施したい仮説検証に十分なリソースを割けていない状態でした」（山岡氏）
この課題に対し、山岡氏は2つのミッションを自らに課すと同時に、いくつかのことを心がけながら進めていった。例えばミッション1に関しては、できるだけ早く正確に、求められている情報を提供することだ。
デイリースクラムには毎日参加して問題箇所を把握し、回答するように心がけた。その場で分からない内容に関しても、翌営業日には速報することとした。工程に関しても常に先回りし、クライアントが目指している状態、重要視している内容に合わせた情報提供や提案を行った。
情報提供の際には、各チームに合わせた言葉で伝えることを意識したり、メリット・デメリット両方を伝え、判断はクライアントサイドが行えるよう配慮した。こうした姿勢によってチームからの信頼を獲得。システムは予定通りのリリースを成し遂げた。
続いてはミッション2、標準的に使えるアーキテクチャの検討・提供を実現するための取り組みだ。山岡氏はポイントを次のように語った。
「お客様のキーマン、責任者と目指すべき状態、重要な価値観、判断基準などをコミュニケーションを通じてすり合わせることを意識していました。加えて、合意した内容は常に掲げ、迷った際の判断材料としました」（山岡氏）
山岡氏は実際に掲げていたドキュメント「アーキテクチャリファレンス」も紹介。実際、判断に迷ったときは早目にコミュニケーションを取り、お互いの仮説をメモベースでも構わないから擦り寄せる。方向性がズレない取り組みをこまめに繰り返していったことを、繰り返し強調した。
実際の成果も紹介された。CI/CDの導入やマネージドサービスの活用といった点は、まさに顧客が目指す方向性であり、「運用負荷を減らしたいというニーズを把握していたからこそ提供・実現できた」と、成果を振り返った。
開発プロセスでは繰り返しになるが、手作業も含め負荷を減らしながらも、セキュリティも含めた品質が担保されたアーキテクチャとすること。さらには資材一式と手順を整備することで、クライアントがすぐに利用できるような状態で提供したという。
IaCの仕組みも導入し再利用を可能にしたり、各チームに汎用的に利用してもらえるよう、成果物をWebコンテンツとして共有するなどの工夫も行った。
「お客様の目指している状態、重要視する価値観を正確に把握すること。こまめなコミュニケーションを取り、意識合わせを実施しながら対応すること。そして最後は技術力をベースに柔軟かつ迅速に行動することで、要望を実現することができました」（山岡氏）
事例発表に対して、参加者からの質問で盛り上がる
続いては、事例発表に対して参加者が質問。登壇者が回答するQ＆Aセッションとなった。
Q．オンプレをクラウドで模した際の一番の苦労点は？
栗田：今回のシステムではLinuxのLVM（Logical Volume Manager）という機能を使い、ボリューム管理を行っていました。管理対象のボリュームがかなり多かったので、AWSで再現するのに苦労しました。
最終的にはEBS（Elastic Block Store）をたくさん作り、一括でサーバに認識させ、Playbookをどんどん作っていく手法で進めました。ただ物理的なデバイスパスは、AWSとオンプレで一致させることができないため、納入後に修正を行う必要がありました。それが、今回のシステムでは一番苦労した点だと思います。
Q．クラウドに抵抗感を持つクライアントへの提案で意識している点は？
栗田：セキュリティに対する不安を持つお客様が多いことから、当社がどのようにセキュリティを担保しているのかの取り組みなどをご紹介し、安心してもらうことを意識しています。安心するとクラウドの利点を聞いてくださる機会が多いので、その段階で構築方法によってはコストが安くなる可能性があるなど、プラスのご提案をするようにしています。
Q．クラウドアーキテクトにおける開発と運用チームの連携について。凝った構成だと難しいのではないか？
栗田：ご指摘のとおり、流行っているマネージドサービスを活用して凝ったアーキテクチャなどを構築すると、運用負担が大きくなります。そのためチーム・組織内で実績のあるアーキテクチャに寄せていくのが、基本的なポイントだと思っています。開発者が運用者をフォローできる体制を構築することも必要だと思います。
Q．コンテナやKubernetesの知識の必要性を感じることはあるか。普及はどうか？
栗田：開発環境に関わらず、既存アプリケーションでもコンテナを使うことは多いので、知識はかなり必要です。一方でKubernetesに関しては運用負担が大きいことも事実です。特に、バージョンアップ対応。使う際には一度、本当に必要なものかどうか、立ち止まる必要もあると思います。あえて技術ドリブンで使いたいと提案することもあります。
Q．データセットの再加工で工夫した点は？
照井：当初はデータを再加工した際に細かくし過ぎてしまったため、学習が進まない課題がありました。そこで細分化したデータをまとめ直したのが工夫であり、解決策です。
大量のデータを一括して渡して機械学習させるのではなく、データセットをいくつか分割して少しずつ学習させるのは、一般的な方法でもあります。
Q．公共領域の中でAI活用が進みやすそうな分野は？
照井：AIの根幹を考えると統計や数学であり、ルールや規則性を見出す意味合いがあります。規則性を元に判断を行うような、例えば審査といった領域で活用が進んでいくのではないかと考えています。
Q．内製開発は支援後の運用が肝だと思うが、工夫した点は？
山岡：DevOpsの考えを導入することやマネージドサービスの活用により、運用の負荷を軽減するよう工夫しました。また、AWSを使っているところはアカウントを統合管理する仕組みを導入し、統合管理すべき箇所は、ガバナンスを効かせる意味でも、しっかりと監視を実施しました。さらに、各スクラムチームが最低限作成するドキュメントを規定し、確実に引き継ぎが行われるようなルールの整備を行いました。
Q．スクラムチームはリモート、オンサイトどちらの体制だったのか
山岡：3チームいずれもハイブリッドでしたが、8割オンサイトのチームもあれば、逆にオンサイトが2割といったチームもありました。コミュニケーションをとるにはオンサイトの方が効果的ですから、毎週全チームがオンサイトに集まるイベントデイに、会話や意識合わせがしっかりとできる場を、確実に設けるようにしていました。
パネルディスカッション：今年度のプロジェクトと努力を振り返る
ここからは稲山氏がファシリテーターとなり、パネルディスカッションとなった。最初のテーマは、「SE/PMに大切なものとは何か」。
テーマ１：今の時代、SE/PMに大切なものとは何か？
栗田：クラウド・オンプレ問わず、まずは知識が必要になってきます。これらを柔軟に受け入れて勉強する。古い知識をスクラップし、新しい知識に置き換わったときに何をやり直すべきか。それが大事だと思っています。
例えば私が入社した頃は、UnixサーバでシェルスクリプトやPerlを使用して開発していました。Perlは便利な一方、少し読みにくい、書きにくい部分を感じていたので、2015年頃にPythonに知識を置き換えました。ただし、Perlの知識は今でも捨てることなく、使う場面もあります。実現したいことを違う技術でも実現できるよう、定期的に知の見直しは必要だと思います。
このようなスクラップ＆ビルドを繰り返し、新しい知識を取り入れて手数を増やすことが、現代では重要だと考えています。
照井：自分が携わっているAI領域でもそうですね。いま台頭している「ChatGPT」なども、ビジネスで利活用していく際には、どうしても壁が出てきます。壁を乗り越えるためには、二次方程式やベクトルといった数学的知識が必要であり、道筋を立てるきっかけになったりするからです。
栗田：知識をアップデートすることや、コアとなる知識レベルの層を増やすことが大事だと思います。また、違う言語や技術を経由して取り組むと、実は理解していなかったことがわかったりもします。
テーマ２：ドメインエキスパートはいた方がいいのか
照井：いた方がいいと思います。事業部側のエキスパートと、AI側のエキスパート両部隊が歩み寄るのが理想ですね。両ドメインを掛け合わせた、ハイブリッドな人材を目指していきたいと思っています。
稲山：一方で、ドメインエキスパートが思い込みでプロジェクトの進行に悪影響を及ぼすこともあるのではないでしょうか？
照井：なきにしもあらずですね。お客様に説明する際にもドメイン知識があると、納得感も得やすいと思います。そのためにはお客様に聞き込むことも大切ですし、実際に人がどのように考え、処理を実行しているのかを学ぶことは、非常に大事だと思います。
稲山：お客様の想定と、AIの結果が大きく異なる場合はどのように対応していますか？
照井：機械学習モデルには得意不得意があるので、きちんとその内容をお伝えし、モデルを置き換えるなどして、タスクに見合ったモデルを改めて探索していきます。その際はモデルとタスクを複数並べて掛け算し、最適な組み合わせを見つけていく手法が有効だと考えています。
栗田：まさにAI系のシステムで、人の判断とAIの結果が違い過ぎる事例がありました。業務を知らない人間は、AIの合理的な判断が間違っていても進めてしまう事例です。この事例では調整を進めたのですが、お互いの折り合いをつけられず、ハレーションが発生する事態となってしまいました。
照井：AIが出した結論をそのままお客様に報告することはなく、検討フェーズの時にドメインエキスパートに、どう解釈をしたらいいのかを確認することが大事ですね。ある程度入り口の仮説の段階で、どの業務にAIが適用できそうかを考えることが重要なので、そういった意味からもドメインエキスパートも、AIの知識は必要だと言えるでしょうね。
テーマ３：CI/CD、アジャイル、クラウドなど。学習における順番やコツは？
山岡：昨年、新しい仕事にアサインされたのをきっかけに、アジャイルを学習しました。お客様の開発スタイルがアジャイルだったからです。会話や意識合わせをする際にもスクラム用語を使った方が浸透しやすかったですね。
リソースとしては、サポートチームの中にアジャイルコーチがいたので、その方にいろいろ教えていただきました。クラウドやCI/CD等は元々学習していたので、アジャイルを学んだ後に、さらにクラウド、CI/CDの学びを深めていきました。クラウドとCI/CDの学習に関しては、必要なリソースを使い、自分で動かすなどしてある意味独学で勉強しました。
栗田：私はCI/CDから入りました。当時はJavaの大規模開発プロジェクトに参画していたのですが、このような大規模プロジェクトには大抵、ビルド職人と呼ばれる人がおり、その人の知識を託される形で、自分もビルドジョブをよくメンテしていました。
その後はクラウドの知識を身につけました。SDKのリファレンスを参考にして、AWSの知識を身につけていきました。たくさんプログラムを書いて慣れていった形ですね。一方で、自分で学んだ知識だけでは偏りが生じるので、その後は資格の勉強もしました。
照井：AIに特化して知識を身につけています。私も実際に動かすところから学んでいく流れでした。そして数学や統計などの知識だけでなく、法令や倫理といった知識についても、資格取得も含め、網羅的に勉強することの大切さを切実に感じています。
テーマ４：難局を乗り越える際、リーダーとしてのマインドは？
栗田：丸投げするのではなく、一緒に考え、取り組んでいるスタンスを出すように意識しています。実際すぐ解決するようなこともあります。イメージとしてはペアプロに近いと思います。
照井：私もメンバー側から積極的にチームリーダーとともに方針を固めていく動きをすることが大事だと思います。
山岡：チームが目指していることの共通認識をとても重視しています。実現に向けては会話を行い、目指すべき先に向けて何をすればいいのか議論を重ねる。その結果、一人ひとりが自ら積極的に動くようになる。そのような相乗効果も意識しています。
株式会社エヌ・ティ・ティ・データ
https://www.nttdata.com/jp/ja/
株式会社エヌ・ティ・ティ・データの採用ページ
https://www.nttdata.com/jp/ja/recruit/
関連するイベント
