データ活用基盤を作ってみたその３(基本設計)

はじめに

こんにちは、NTTデータ先端技術の白木(@shiraki_ils)です。
本記事は、データ活用基盤を作ってみた連載記事のその3(基本設計)です。
本シリーズの取り組みの内容についてはその1(構成シナリオ)をご覧ください。
前の記事は、その2(要件定義)からご覧ください。
今回は、基本設計の考え方・進め方について記載します。

目次

• 前提
• 基本設計の考え方
• 基本設計で実施したこと
• 基本設計で注意したこと
  • クラウドPJ特有の注意事項について
  • 学習を目的としたPJ特有の注意事項について

前提

前提として、いわゆるウォーターフォールの進め方のように、「基本設計」「詳細設計」といった形で工程を分けて進めるやり方が良いかが論点となりました。
内部向けかつ小規模の開発、加えてAWS上での開発ですので、工程を分けてドキュメントを作らずに、一旦ある程度の俗人化を許容してスピード優先で開発することも選択肢には入るかと思います。
しかし、前段の記事でも触れている内容ですが、本PJは「データ活用基盤をゼロから構築することを通じて、PJの進め方を学ぶ」という目的で実施したものです。
そういった背景から、若手社員がシステム開発PJの実際の進め方を学ぶことも目的の一つと考え、ウォーターフォール的な進め方は踏襲することとし、基本設計・詳細設計の二つの工程でそれぞれ成果物を作成する方針としました。

基本設計の考え方

今回のPJでは、設計工程は基本設計→詳細設計（パラメータ設計）の二段階で進めることとしました。

そのうえで、今回のPJにおける基本設計は、
「要件定義で整理したお客様要件を漏れなく実現するために、システムをどのように構成(利用する機能、基盤構成、設計方針)するかを表現するフェーズ」
と定義しました。

設計工程の分け方については、PJの規模や特性によって変わるかなと思います。
例えば細かく分かれる場合では ①概要設計→②基本設計→③詳細設計→④パラメータ設計のように4段階に分かれるようなケースも見たことがあります。
今回のPJではチーム内で議論し、基本設計→詳細設計の二段階の進め方を採用しましたが、それが唯一の正解というわけではありませんので、これを読まれている皆様のPJにおいてどのように進めるべきかは、PJごとの特性に応じてご検討いただくことが必要かと思います。

基本設計で実施したこと

基本設計における成果物は基本設計書です。
こちらは社内で実際のPJで使われている基本設計書テンプレートをベースとしており、機能・非機能の観点でカットされているドキュメントです。
基本設計の工程では、要件定義をインプットに、システムの構成を調査・検討し、基本設計書を作成する作業を行いました。

基本設計で注意したこと

基本設計フェーズにおいて重要な点は、しっかりと網羅性を意識しながら要件に対して必要なシステム設計を行っていくことだと考えており、ここはいわゆる一般的なシステム開発PJと変わらないかと思います。

一方、今回のPJ特有の注意事項もいくつかありましたので以下記載させていただきます。
これらは自分の立場から見た内容を記載しておりますので、ある程度主観的な内容が含まれることをご了承ください。

クラウドPJ特有の注意事項について

今回のPJはクラウド（AWS）を利用するPJでした。
AWS特有という観点では、やはり各種AWSマネージドサービスの採用についての検討が必要であったことが大きいかなと思います。
特に、以下の2点が技術的な考慮ポイントとして大きかったように感じました。

1. データ活用関連のAWSサービスの選定
2. セキュリティ確保のためのAWSサービスの選定

1. データ活用関連のAWSサービスの選定 について

今回はGlue及びLambdaを採用しました。
こちらについては、要件定義のフェーズである程度AWSサービスを考慮しながら進めていたこともあり、サービス選定に対しては大きな課題はありませんでした。
ただし、VPCやIAMといったAWSの基礎となるサービスに対する前提知識がないメンバーは設計に苦労しているように見えました。（学習の良い機会になってよかったです。）
また、当たり前かもしれませんが、対象のAWSサービスを実際に触ったことがあるメンバーは、設計の進捗や精度が高いように感じました。
AWSマネージドサービスを利用する場合には、AWS側でどこまでマネージドな機能が提供されているのか（裏を返せば、利用者側でどこまで操作する必要があるのか）が重要となります。この辺りは机上の調査でなかなかわかりづらい部分もあるかと思いますので、対象のサービスを一度使ってみることは非常に有効だと考えています。

2. セキュリティ確保のためのAWSサービスの選定 については、

AWSサービスの様々なセキュリティサービスの使い分けがかなり難易度が高かったように思います。
AWSには様々なセキュリティサービスがあり、要件定義などの上流工程では、「いろいろなサービスを使ってセキュリティを確保する」という方針くらいしか決まっていないことも多いかと思います。
設計工程でもその方針はもちろん変わらないのですが、どのようなセキュリティサービスがどういったレイヤーに対してどのようなセキュリティ保護をするのかを理解していないと、設計を行うのは難しいように感じました。
本記事では個々のサービスの紹介までは割愛しますが、複数サービスを組み合わせてセキュリティ確保するにあたり、それぞれどのような目的でどういった機能を利用するのか明記することを心掛けて設計を行いました。

以上がクラウド（AWS）における考慮事項でした。
もしクラウド領域のPJを進める機会がある場合、上記を参考にいただければと思います。

学習を目的としたPJ特有の注意事項について

本PJは若手社員が学習するという目的も兼ねており、システム開発の経験がそこまで多くないメンバーも含まれていました。
そういった状況でのPJにおいて有効だったポイントを3点紹介します。

1. AWS有資格者が多かったこと
2. 社内ナレッジの設計書テンプレートを利用できたこと
3. 資料レビュー期間を比較的長くとったこと

1. AWS資格について

今回のメンバーは若手社員も含めてAWS有資格者が多く、AWS関連の技術的な知識はある程度机上で所有していたことが良い方向に働いたように感じています。
実際の案件でAWSによる開発を行ったことがあるメンバーのほうがやはり習熟度は高かったですが、AWSクラウドプラクティショナーや、AWSソリューションアーキテクトアソシエイトといった資格の勉強を通じ、各種AWSサービスの名前などの共通言語が通じる状態をベースにできたことは大きかったように感じており、やはり資格勉強のような机上勉強も無駄ではないように感じました。

2. 設計書テンプレートについて

今回の設計書は、社内で実績のあるクラウド・データ活用系の案件でも使われるテンプレートを利用して進めていたこともあるため、ある程度ナレッジによる補強があった点は大きかったように感じています。
特に、基本設計においては対象の網羅性が非常に重要となるため、テンプレートを基に埋めていくだけで網羅性を確保しやすかった点は非常に良かったと感じています。
逆に、基本設計工程をもしゼロから進める場合には、設計対象の網羅性を担保するのが大変かなと思います。
その場合には、AWSが提供するWellArchitected Frameworkのような資料と、非機能要求グレードや各種書籍などAWSに限らないシステム設計向けの資料を合わせて参考にしていく必要があるかと思います。

3. 資料レビュー期間について

設計書の作成経験が少なく不慣れなメンバーがいることもあったため、設計書のレビュー期間は長めに確保しました。
これは、作成→レビュワーからの指摘→修正 というサイクルを多く回すことを目的としています。
少し手間はかかりましたが、非常に実践的な形式で設計書作成を学ぶ機会を提供できたことは非常に良かったように思います。
通常のPJと比べて若干スケジュールが長くなってしまうのですが、その分若手社員が主担当として作業を担当しているため、リーダー層・レビュワー層の工数を少し軽くできる副次効果もあったように思います。

以上が学習観点での注意点でした。
もし学習目的でPJを進める機会がある場合、上記を参考にいただければと思います。

最後に

今回は、基本設計工程についてご紹介しました。
どちらかといえば主観的な内容が多くなってしまい恐縮です。ご意見・ご感想などございましたらぜひコメントいただければと思います。
次章は、その4(詳細設計)についてです。
ここまでお読みいただきありがとうございました。