高速開発が広まった背景
昨今の消費者はスマートフォンを持ち、日に日にインターネットを経由した情報の入手が容易になっています。またインターネットを介したサービス提供者の裾野が広がっていることから、消費者にサービスを提供する敷居も下がっています。
システム開発における成熟度の高まりもあります。以前は専門的な知識を求められたシステム開発も、パッケージソフトウェアやSaaS型サービスを購入することでシステム開発のコストを抑えることが望めます。システムリリースにおける成熟も進んでおり、本番環境で動作しているシステムに対し1時間に数千回のリリースを行う事例もあります。
サービス事業者は国境の見えないインターネット上に数多の競合がいるため、自サービスへ消費者を引き止めるとともに、継続的に機能を追加・更新することで常に魅力的なサービスを提供する必要性に迫られています。継続的なシステム開発が企業の競争力につながっています。
日本企業における開発現場の課題
私たちが複数のお客様を支援している中で、深く悩まれているお客様に傾向があると見受けられます。
「失敗しない」文化
読者の中には違和感を覚える方もいらっしゃるかもしれません。「組織としてノウハウを適切に蓄積しているほど失敗しないのは当然」と思われるかもしれません。
しかし、「失敗しない」のは何故でしょうか？従来から蓄積してきたノウハウを活かし確実に成功できる事業だけに取り組み、ノウハウを活かせないリスクの高い新しい事業に取り組んでいないことはありますか？
失敗しないことだけを目指してしまうと、昨今の消費者が期待する魅力に届かず、中長期的に消費者が離れていく恐れがあります。現場は新しいことへチャレンジを試みようとしますが、上司・経営層による歯止めもこの事象に当たります。
「失敗しない」システム
文化に由来し、従来からの社内規程（システム開発規程や作成するドキュメントなど）やアプリケーションフレームワークを利用しているケースがあります。社内で育ててきた規程やアプリは社内にノウハウがたまっており、長期従事している従業員は理解が深い傾向があります。
着々と積み上げ改善してきた社内規程に対し、外部環境は変化が続いています。サーバ資源はオンプレミス（自社設備）からパブリッククラウドへ移行し、サーバ設定はスプレッドシートを活用したパラメータシートからHashiCorp TerraformやAWS CloudFormationのようなコード化（Infrastructure as Code）が進んでいます。アプリケーションは仮想マシンへデプロイからコンテナ技術の活用に移行しています。さらに汎用的な機能はSaaSの採用が進んでいます。
これらにより、変化に適合している組織は開発チームの稼働を自社サービスの開発に集中できます。そして変化しない組織のサービスと差別化が進んでいきます。
解決のきっかけ
「失敗する」文化の醸成
経験のないことや、競合他社を含め未踏の領域へ挑戦するには失敗がつきものです。この失敗を「採ってはならない選択だった」と受け止め、「次に同じ失敗をしないために、企画や開発段階で行える対策は何があるか」と学習する機会とします。失敗するに至った選択の経緯や記録を確認し、今後の糧にできるチームを増やします。
そのためには開発するプロダクトを我が子のように育てられる文化が必要で、自社で雇用している開発チーム体制が近道になると考えます。これは従来から行われているようなSIerへの一括請負開発ではなく、SIerをシステム開発のプロフェッショナルとして自社の開発チームに寄り添うパートナーとして迎え、自社の開発チームとして取り組むことが今後の主流になると見込んでいます。
まったく経験がなくても、できる範囲の小さなものを作って経験を積むことが望めます。新しい開発スタイルを確立するために特定のテーマを設け、複数名をもって立ち上げることになります。
失敗を管理するシステム開発プロセス
ビジネスを展開する上であらゆるリスクをゼロにするのは困難です。ビジネスにおけるステークホルダは自組織に閉じるものではなく、取引先のような別組織や消費者と展開していくため、組織間のリスクをコントロールすることが難しいからです。
一方でリスクが生じる場面や影響を認識し、必要な時にコントロールすることは可能です。ここでのコントロールはリスクをゼロにする回避だけでなく、軽減や受容といった対処があります。
システム開発を取り巻くリスクも同じように対処します。すべてのリスクをゼロにするのは困難ですが、可能な限りのリスクを認識し、リスクの影響度や優先度から濃淡をつけたコントロールすることになります。またリスクが発現してから認識・対処は避けたいため、できるだけ早い段階でリスクの洗い出しと対処の計画を立てることになります。
セキュリティ分野における取り組み
ビジネス面では消費者の反応を見ながらサービス形態を修正する手法が適しています。そのため、機能開発と通じた試行錯誤の繰り返しがサービスの向上とつながり、効果的です。
一方でシステムが備えるべき機能の欠如により、利用者の個人情報が漏洩してしまうとどうでしょうか。利用者からシステム利用に対する不信感が増大し、漏洩事故に対する補償のみならず、長期的に利用者を失うリスクがあります。サービスの成長は少しずつ積み上げられますが、セキュリティは少しの見落としが大きな影響を及ぼすことがあります。
事故の事例
2019年に米国金融機関がパブリッククラウドに設置したセキュリティ対策に不具合があり、外部からアクセス権を取得できる状態になっていました。元従業員が不具合を利用し外部のネットワークからデータベースへのアクセス権を取得し、大量の個人情報を持ち出した事故があります。
またサービス設計の不具合もあります。サービスアカウントを所有する本人確認が不足していたことから、第三者が作成したサービスアカウントと銀行口座の連携ができてしまいました。これにより第三者は不正に出金し、決済・購入に至った事例があります。
セキュリティ対策の計画を立てづらい
従来はシステムがデータセンターに設置したサーバ機器で、開発の終わったアプリケーションは機能開発や重大な不具合が無い限り手を加えていなかったでは無いでしょうか。ネットワークと運用者の境界を明確にすることで守る範囲が明確で、それゆえ「ゲート型」の対策をとっていました。
昨今では頻繁にシステムを更新し、適宜利用者の要望に追従するよう開発しています。開発初期段階で境界を作ってもシステムの改修が進むにつれ境界が曖昧になり、「ゲート型」では守りきれないことが生じます。また、事前に計画を行なっても、将来発生するシステム変更まで読みきれず、計画を立てることが困難です。
セキュリティリーダの育成
DevOpsはプロダクトに関わるメンバは幅広く担当します。設計からアプリ・インフラの開発、運用になりますが、最初からメンバ全員がフルスタックエンジニアである理想的なチームはありません。それぞれメンバの強みがあり、最初は強みを生かした開発を進め、開発が進むにつれチーム内でスキルの共有と強化が進み、フルスタックエンジニアに近づきます。
セキュリティ観点で難しいところはサービス仕様に潜む不具合を見つけ改善することです。サービス仕様を検討する際に、特定の仕様や機能に限った不具合や改善策を検討するのではなく、サービス全体の仕様を俯瞰して利便性と安全性のバランスを取る作業になります。
たとえば、「ECサイトへログインする際に多要素認証で強化しているが、サポートデスクに電話をかけるとアカウントIDを名乗るだけで一時パスワードの払い出しと多要素認証をリセットしてしまう」といったケースが挙げられます。アカウントの認証情報をリセットする際は技術的な安全性の高さが求められつつ、実務上は当人が必要な情報を失念していることや引っ越しなどで使われなくなることもあり、サービス仕様の検討難易度は高いです。先ほどの例では、システム仕様と実際のビジネスプロセスを踏まえ、サービス仕様の変更を含めて改善の提案を行います。
セキュリティパートナーの活用
セキュリティはどこか1ヶ所でも弱いところがあると攻撃に利用されます。システムだけでなく、サービス仕様や運用を含め、広く俯瞰的な視点で対策を講じることになります。しかし、幅広い視点に1人で立ち向かうのは困難です。
NRIセキュアではサービス企画からシステム開発まで、それぞれの分野にプロフェッショナルを有しています。開発チームが抱える多種多様な課題を解決するにふさわしい人員にてアドバイスを行っています。
まとめ
ここまで触れた通り開発チームをもつ企業が増えていると感じます。特に一般消費者にサービスを提供する企業ではその傾向が強いと感じ、今まで以上に開発スキルを持つ人材は活躍の場が広がっています。また、特定の業務システムによらず、事業全体の俯瞰的な視点から必要となる基準を示しつつ、ビジネスを支援するセキュリティエンジニアも活躍の場が広がっています。お客様のシステムを理解するうえでアプリケーションの開発スキルやプロセス理解が求められます。NRIセキュアでは開発スキルを持ち、お客様が抱えるシステム開発にまつわる課題を解決しながらセキュリティエンジニアのキャリアを積みたい仲間を募集しています。
また、NRIセキュアでは開発プロセスごとに最適なコンサルティングを提供しています。サービスメニューとして以下のようなものがありますが、サービスメニューに関わらずお問い合わせをお待ちしています。
＜関連サービス＞
■デジタルサービス向けリスク分析支援
デジタルサービス向けリスク分析支援ではビジネスモデルとユースケース（ユーザーの利用事例）の観点から、デジタルサービスの脅威となりうるリスクを網羅的に洗い出し、適切なセキュリティ対策を提示します。
サービス仕様検討段階からセキュリティをしっかり考慮することで、セキュリティ要件をサービス仕様に組み込んだシステムの設計が可能になります。自社だけでは見落としがちな脆弱性に気づくことや、より適切なサービス設計やシステムの実装を図ることができます。また、企業がデジタルサービスをサービスインするか否かを意思決定する際の判断材料としても、活用できます。
■セキュアアプリケーション設計レビュー支援
セキュアアプリケーション設計レビューでは設計内容について設計資料を評価し、開発担当者様へヒアリングを行います。そのうえで、Webアプリケーションのセキュリティを確保するために考慮が不足している観点の洗い出しや、より良い設計方法について助言させていただきます。
開発着手前に問題点を洗い出すことで、セキュリティ設計の不備による手戻りや修正コストを最小限とすることができます。
■セキュアEggs応用編（DevSecOps）研修
開発チームが現場で使える知識を獲得する手段として研修メニューを用意しています。セキュアEggs応用編（DevSecOps）ではDevSecOpsとしてDevOpsやアジャイル開発の速度や文化に適したセキュリティの考え方やツールについて、講義と演習で学びます。
