プロダクションレディ開発プロセス ―SIer の開発標準に学ぶ
新しい Web サービスを「本番環境に載せられる品質で作っていく」のは大変です。一体何から考えればいいのでしょう。インフラ？ テーブル？ API 仕様？
「MVP (Minimum Viable Product) で」とか「アジャイルで」といった話はよく聞きます。一方で「どのような順番で、何を考えていくと、いい感じに出来上がるのか」という話はあまり聞きません。「Web サービス 作り方」などと調べても、個人開発にフォーカスしたものがほとんど。
これに対する私の解は、「SIer の開発標準に学ぶ」です。
SIer の開発標準
大手 SIer は、開発プロセスを標準化した「開発標準」を持っています。「この通りにやれば誰でも一定品質でシステムが作れる」というガイドラインで、ノウハウの塊でもあります*1。
ありがたいことに、 TIS は CC BY-SA 4.0 で Nablarch 開発標準を公開しています。この Nablarch 開発標準をちょっと覗いてみましょう。
(参考) SIer の開発標準例:
- 富士通: SDEM
- NTT データ: TERASOLUNA の標準手順
- TIS: Fintan の 要件定義フレームワークや Nablarch アプリケーション開発標準 等
- IPA (情報処理推進機構): 共通フレーム 2013 （電子版 500 円、やや抽象的な表現が多いです）
Nablarch の開発標準をちょっと覗く
まずは「開発プロセス標準」にある WBS (Work Breakdown Structure) を見てみましょう。 Excel ファイルですが逃げてはいけません。
「1. 概要」シートには、典型的なウォーターフォールでの開発工程の図があります。
なるほど。では、「要件定義」ではどういったことを考えるのでしょうか。「2. WBS」シートを見てみます。
要件定義: 非機能要件定義
要件定義に「非機能要件定義」なるワークパッケージがあって、補足説明にはこう記されています。
非機能要件定義書には下記のような内容を記載する。
- セキュリティ要件
- バックアップ要件
- 可用性・信頼性要件
- 拡張性要件
- 保守容易性要件
- 性能要件
- システム環境要件
- アプリケーション方式要件
- 外部接続要件
- システム監視要件
- ジョブ運用要件
アーキとインフラが主担当となって作業を進める。
機能だけ実現しても、「ダウンしたことに気づかない（監視要件漏れ）」「ログが出ていなくて調査できない（監視要件漏れ）」「バックアップがなくて戻せない（バックアップ要件漏れ）」なんて事態は望ましくありません。非機能要件定義をすれば、これらを回避できるわけです。
慣れてしまえば「そらそうよ」という内容ですが、意外と忘れたり漏れたりしやすい部分です。
（補足：非機能要件を具体的に決めるには IPA の非機能要求グレードがおすすめです）
外部設計: テーブル定義は INDEX も
要件定義の次は「外部設計」を見てみましょう。「データベース論理設計」ワークパッケージのアウトプットに「テーブル定義書」とあります。
テーブル定義書のサンプルがデータモデル設計にあるので見ましょう。
名称、データ型などのほか、 INDEX の指定まで記入欄があります。
インデックス設計をこの段階で行うかは若干悩ましいですが、少なくとも「インデックス設計は必要な作業である」と認識はできます。
インフラ構築: サイジング設計
今度は、並行する「インフラ構築」の「サイジング設計」ワークパッケージの補足説明を見てみましょう。
機器選定に必要な詳細情報のサイジングを計算する。サイジング設計書には、下記に示す容量について、必要量の見積もりとその根拠を記載する。
- CPU
- メモリ容量
- ディスク容量
ポイントは 根拠を記載する です。インプットに「非機能要件定義書」や「方式設計書」とあり、そこには性能要件やアプリケーションのアーキテクチャなどが記載されています。これらに基づいて計算せよということです。
ただし、 Nablarch 開発標準はおそらく機器購入（オンプレミス）が前提になっています。クラウドサービス前提であれば、実際に動かすなり性能試験するなりして「根拠」が十分揃ってからサイジングするほうが良いでしょう。
めくるめく開発標準の世界
あっさり目ですが、 SIer の開発標準例として Nablarch の開発標準を覗いてみました。
私は既に SIer にはいませんが、それでも次の場面で開発標準（のようなもの）を思い浮かべ、それに助けられていることが多いです。
- 新しいサービス（マイクロサービス含む）を作り始めるとき。大雑把な進め方を決めたり、タスクを洗い出したり、決めるべきことを整理したり、ざっくりと見積もりしたりするとき
- 本番環境へのデプロイ前に、「やるべきことを(やった|やらないという意思決定をした)か」確認するとき
何かのお役に立てれば幸いです。
本記事は Nablarch 開発標準のライセンスを継承し CC BY-SA 4.0 とします*2。
