ソフトウェア開発プロセス

概要

• ソフトウェアの開発プロセスを説明しているサイトを見てもデファクトスタンダードが見つからない。
  • 粒度が異なったり、用語が異なったりしている。
  • 既存のプロセスも私の感覚と異なっており、ベストなモデルが見当たらなかった。
• 私の理想とする開発プロセスは、ウォーターフロー的にスケジューリングや観測が可能で、アジャイルのプラクティスによって進められるようなモデルです。
• ここ数年、大手企業のシステム開発に携わる事がありますが、この開発工程についての正しい認識と進め方が行われていないという印象があるので私の頭の中をドキュメント化しておきます。
• 先行事例を確認するためにIPAの最新の開発プロセス体系である「共通フレーム2013」を確認してみましたが、しっくりこない。
  • https://www.ipa.go.jp/files/000027415.pdf
  • 資料の中には複数の開発プロセスが前提となった記述があったりして、資料のスコープ時点でロジカルではない点が多数あり、標準な感じはしない。複数人で分担して書いて、くっつけたような資料の印象。
  • そもそも複雑！

私が考える開発プロセス

私が頭の中で、フレームワークとしている開発の流れは以下です。

• 0. ビジネスゴールの設定
• 1. 開発系
  • 1.1 要求定義
  • 1.2 要件定義
  • 1.3 外部設計
  • 1.4 内部設計
• 2. コーディング
• 3. 検証系
  • 3. 1 コードレビュー
  • 3.2 ブラックボックステスト
  • 3.3 受け入れテスト
  • 3.4 デプロイ＆微修正

プロセスの補足

• 上記のプロセスを使えば、以下のようなケースは対応出来ると考えています。このステップをマイルストーンとして進めるとして、各ステップを進行と管理を出来る人が必要です。
  • 世の中にはこのロールの人が少なくて失敗プロジェクトがたくさん生まれてしまっていると思っています。
  • プロセス管理は具体的に、スケジュール管理はもちろん、クオリティコントロール、リーダシップ、エンジニアリング面の相談に乗る、日々コードレビュー、自分で修正といったことをするスキルが必要です。
  • このロールの人は重要視されることは少ないですが重要です。スキルを評価しづらいし、ロールが管理業務になるので必要なスキルセットが一般的なPMみたいに誤認されてしまいます。
• 自分で下の方まで進めれば進めるほど、自分の頭の中のイメージに近い物が出来る。
• ベンチャーのシステム開発の1機能開発、1イテレーション。スクラムを使っていても、1つのtaskや機能にも当てはまるような汎用的なプロセスかなと思います。
• 要求定義と要件定義が1つになっている例が多いですが、明確に分けるべきです。なぜなら、ほとんどの場合、承認者が別だからです。要求と要件は明確に区別すべきです。

責任領域

• システム開発をもう少し具体的に言うと、「ビジネスゴールを達成するためのプロダクト開発」と定義することが出来ます。
• ゴールへ向かってビジネスサイドの責任者、プロダクト開発の責任者がお互いの領域を学習、理解しながら進めることが重要です。詳しくは、DDD本。
• トップラインから考えると、以下の3つの責任者は立てるべきです。プロジェクト責任者とビジネス責任者は兼務で良いと思います。
  • プロジェクト責任者
  • ビジネスサイド責任者
  • プロダクト開発責任者

各ステップの詳細

例なので、無くても良い。太字はビジネスサイドとエンジニアサイドで意思疎通をするためにも作るべき。

• ビジネスゴールの設定
  • 背景
  • 問題
  • 目的
  • アプローチ
• 開発系
  • 要求定義 (内容が多いので、別ページに分離しました)
  • 要件定義
    • 図
      • 要求定義で作った資料を清書、スコープなどを確定する。
      • 外注に出す場合にはしっかりと作る。
    • フェーズ定義
      • スコープを明確にするためにフェーズが切れる場合はフェーズを切る。
  • 外部設計
    • 重要なページのワイヤーフレーム
    • デザインをちゃんと入れるならデザイン案など
  • 内部設計
    • 主要部分のER図
      • DB設計をしっかり出来る人は意外と少ないので、自分で出来るなら作ってしまった方がコスパ高い。
      • カラム名のルールや、外部キーのルールなど、細かい所でルール作りが必要になってしまうので、ルールの定義をするよりかは自分で作ってしまった方が早い。
    • クラス図
    • デプロイ図
    • サーバソフトウェア、言語、ミドルウェアの選定
• コーディング
  • コーディング要件（静的チェックツールの設定など）
    • 最初は大変ですが、2回目以降は使い回せます。
  • コード
    • VCSは必須です。git必須。git使えない人やベンダーはあり得ないくらい。
  • ユニットテスト
    • プロダクトを継続的に運用していくなら、ユニットテストは必須です。ユニットテストが無いとリファクタリングが出来ないので。
• 検証系
  • コードレビュー＆ユニットテスト
    • コードカバレッジ
    • 静的チェック結果
  • ブラックボックステスト
    • なし
  • 受け入れテスト
    • なし
  • デプロイ＆微修正
    • リリースノート

補足

• システム開発の前段階の企画（ビジネスプラン）がちゃんと詰められている必要があります。企画が詰められていないと、要求定義や要件定義の前のフェーズである企画にまでシステム担当が入る必要がでてきてしまいます。