開発の進め方

要点と定義

開発モデルは、要求を形にする工程の進め方です。ウォータフォールモデルは要件定義、設計、実装、テストなどを順に進め、工程ごとの作業を終えてから次へ進みます。工程の後半で誤りが見つかるほど、関連箇所の修正が広がり、訂正コストが高くなる傾向があります。要員数は一般に途中で増えてピークを迎え、終盤に減りますが、実際の推移はプロジェクトによって異なります。

プロトタイピングは、要求を理解するための簡易なソフトウェアを早い段階で作り、利用者に確認してもらう方法です。図や業務の流れを示すだけでは、操作できる試作品とは限りません。

アジャイル開発は、短い反復で動くソフトウェアを作り、顧客のフィードバックを得ながら変化する要望に対応しやすくする進め方です。文書を作らないという意味ではなく、包括的な文書より動くソフトウェアや顧客との協調を重視します。短い開発・評価サイクルはイテレーションと呼ばれます。スクラムは、複雑で変化の激しい課題に反復的・漸進的に対応する開発フレームワークです。

共通フレームは、ソフトウェアを中心とするシステムの開発や取引のプロセスを明確にする枠組みです。利用時には組織やプロジェクトの状況に応じて修整できます。

開発に関するその他の用語も区別します。既存プログラムを解析して構造や設計情報を明らかにするのはリバースエンジニアリングです。海外の事業者や子会社に開発を委託する形態はオフショア開発です。開発側と運用側が連携し、自動化などで導入や更新を迅速にする考え方はDevOpsです。

ハッカソンは、参加者が短期間に集中的にプログラムなどを開発し、成果を発表したり競ったりするイベントです。

適用条件と例

工程を順に完了させて進める状況はウォータフォール型、要求の理解に試作品を使う状況はプロトタイピング型と考えます。要望が変わりやすく、短い周期で確認・改善する状況ではアジャイル開発が適します。たとえば、利用者の反応を見て画面や機能を少しずつ見直す場合です。短い周期なら反応を早く確かめ、その結果を次の改善に取り込めます。反復はアジャイルの進め方を表し、スクラムはそのためのフレームワークの一つです。

共通フレームはプロセスを整理する土台として使い、必要に応じて作業範囲や項目を調整します。既存システムの保守資料が不足している場合は、プログラム解析から設計情報を起こすリバースエンジニアリングが役立ちます。開発場所・委託先に注目するならオフショア開発、開発と運用の連携に注目するならDevOpsです。短期の集中開発イベントを指すならハッカソンです。

誤りやすい点

ウォータフォールは工程を順に進めるモデルであり、後工程での変更費用が必ず一定という意味ではありません。プロトタイプは要求確認のための簡易ソフトウェアで、要求を記した図そのものとは異なります。