マイページ
開発手法①：最初に厳格な定義を行う「ウォーターフォール型」
エンジニアやプログラミング言語の種類を理解したところで、次はどのような流れでシステム開発が進んでいくのかを見ていきましょう。
システム開発の手法は、ウォーターフォール型とアジャイル型の大きく2つに分けられます。
ウォーターフォール型は、その名の通り、滝の水が上から下へ流れていくような、トップダウン的な開発手法です。要件定義→設計→開発→テスト→リリース→メンテナンスという主な工程をたどります。
もう少し細かく見ていきましょう。プロジェクトが立ち上がると、最初のステップとして、プロジェクトのビジョンや目的、システムにどのような機能を付けたいか／付ける必要があるか、などをできるだけ明確に決めます。これが要件定義です。
要件をしっかり固めたら、次は、設計に入ります。システム全体の構造（アーキテクチャ）、データベース、どんな画面にするか、ユーザーにどうやって使ってもらうか（ユーザーエクスペリエンス（UX））などを考える工程です。
設計の次は開発。ここでプログラミングが登場します。複数のエンジニアが手分けして、自分の担当のコードを、設計に基づいて書いていきます。
開発が終わったらテストに進み、作ったソフトウェアが想定通りに動くか、バグがないかなどを確認します。単体テスト（ユニットテスト）、統合テスト、システムテストなど、各段階にはさまざまなテストが存在します。
無事テストを通過したら、ユーザーが実際にソフトウェアを使える状態となるリリースに進みます。しかし、これで終わりではありません。リリース後に発見された不具合の修正、連携していたほかのサービスの変更に対応するためのアップデートなど、開発が終わってからのメンテナンスも重要な工程です。
開発手法②：“手探り型”の開発工程をとる「アジャイル型」
はじめに全体の方向性をがっちり決めたあとに細部を作り込んでいくウォーターフォール型の開発に対して、小さいパーツを一つひとつ作りながら、全体の方向性を考えていくもうひとつの代表的な開発手法がアジャイル型です。ボトムアップ的とも言えるでしょう。
アジャイル型開発においても、プロジェクト立ち上げ時に、まずビジョンや目的を明確にする点はウォーターフォール型と同じです。しかしそこからの流れは大きく変わります。
ビジョンや目的が定まった後に、開発すべき機能や要件を小さい単位で書き出し、優先度順に並べたリストを作成します。前もって優先度を完全に決めるのは難しいので、多くのケースでは「これからすべきこと」が山ほど積み上げられた状態のリストが出来上がります。このリストのことを、プロダクトバックログと言います。
プロダクトバックログを作ると、実際の開発作業が始まります。プロダクトバックログでリストアップしたなかからひとつの機能を選び、1～2週間という短い期間のなかで、その機能に対して開発→テスト→リリース→レビュー→改善をすべて行います。短距離走で全力疾走するイメージから、この1回のサイクルをスプリントと呼びます。
1回のスプリントが終わると、「次はこの機能に取り掛かろう」と話し合い、次のスプリントを始めます。プロダクトバックログのなかから着手する機能を選び出し、どのように実装するかを話し合うミーティングは、スプリントプランニング、またはスプリントミーティングと呼ばれます。
ウォーターフォール型と違い、最初に厳格な要件定義や設計をしていないので、アジャイル型における開発工程は、かなり“手探り”です。スプリントのサイクルを回しながら、少しずつ、ゴールに向かって進んでいきます。
アジャイル型開発の成功は、メンバー全員がいまの状況を正しく把握し、同じ方向性を共有しているかにかかっていると言っても過言ではありません。そこで、アジャイル型開発では、スクラムというコミュニケーション手法がよく使われます。スクラムを採用するソフトウェア開発を、アジャイル型開発の一種として、スクラム開発と呼ぶこともあります。
カタカナ言葉で物々しく聞こえますが、要は日報ですね。アジャイル開発の現場では毎日、デイリースクラムと呼ばれるミーティングを開き、10～20分ほどかけて、進捗報告と課題共有をします。主催する人はスクラムマスターと呼ばれ、チームでの活動やミーティングの生産性を最大化する役割を担います。会議のファシリテーターやプロジェクトリーダーに近い存在だと考えるといいでしょう。
スピード感や臨機応変さを求めるなら「アジャイル型」
ウォーターフォール型とアジャイル型の違いを、料理に例えてみます。
最初に「今日はカレーを作る」と決め、レシピを考える。チームで手分けして必要な具材を買い、各チームで具材を切ったら、切った野菜を鍋に入れて煮込み、味見をして問題なければ食卓に出す。これがウォーターフォール型です。
対してアジャイル型は、「みんなのお腹を満たそう」というビジョンをまず設定します。最後にできるのがカレーかどうかは必ずしも決まっていないが、とりあえず、調理器具を用意する、具材を買ってくる、油で野菜を炒める……というTo Doリストを作る。各チームはリストを見て、「今日はニンジンを買ってきます」「じゃあ私は包丁研いでおきます」と話し合う。ニンジンを買いに行った人が、「ブロッコリーが旬ですごく美味しそうでした」と報告する。それを受けて、「やっぱりブロッコリーもいれて、シチューを作ることにしよう」と決める――。
ウォーターフォール型と比べて、柔軟に軌道修正しやすいことが、アジャイル型開発の最大の利点です。大企業ほどに資本や人手がなく、スピード感や臨機応変さに勝機を見出すベンチャー企業や中小企業で採用される傾向があります。
「アジャイル型」は、コミュニケーションコストが高くなる
アジャイル型は、変化の激しいいまの時代に適した手法だと言えますし、開発の大規模なやり直し（ロールバック）が発生しづらいため、エンジニアから好まれる手法でもあります。
だからといって、現代のシステム開発ではアジャイル型がベストな手法だというわけではありません。
アジャイル型の開発は、チーム内での日々の進捗確認がウォーターフォール型開発以上に重要になるため、コミュニケーションコストは高くなります。しかも関係者が多い大きな組織では、利害調整の難易度が跳ね上がります。多くの部署やメンバーが関わる開発では、はじめに全ステークホルダーの合意を取り付けるウォーターフォール型のほうがスムーズに進むでしょう。
管理職にとって大事なのは、2種類の異なる視点を持つこと。自分が携わるプロジェクトでどちらの開発手法を採用すべきか判断できますし、「ウォーターフォールで進めているけれど、できるだけこまめに情報共有してアジャイルの要素も取り入れていこう」というように、“いいとこどり”を叶えることもできるでしょう。
