今年に入って、複数のお客様から
「品質を維持しつつ開発期間を短縮するために開発プロセスの見直しが必要だ」
というお話しを頂き、模索している中で上司よりお勧め頂いた本を読んでみました。

大きく第1章と第2章に分かれており、
第1章が本当に使えるシステム開発の進め方について、
第2章がクラウド対応のシステム設計書の作り方についての内容だったので、
今回は第1章だけを熟読しました。
第1章も以下のように開発プロセスに応じて解説されています。
・システム企画(目標設定、業務プランニング、システムプランニング、基本計画策定)
・要件定義
・基本設計
・詳細設計
・プログラミング
・テスト
まず所感としましては、
内容が業務システムを対象としたものでしたので、
我々がメインで行っている地図開発にそのまま適用できる内容ではありませんでした。
ただ、いくつかヒントとなる内容はありましたので以下に記載します。
システム企画フェーズは、なかなか携わる機会がないですが、
基本計画策定において「段階的リリース」を前提として
「業務結合度」と「システム結合度」を考慮したリリースセット(リリースする単位)を導き出すという内容が、
開発プロセス見直しの1つのポイントになるのではないかと感じました。
要件定義フェーズについては、特別目新しい内容が書かれていた訳ではないですが、
ユースケースを活用する上でシナリオの質を高める「INVEST」というテクニックや、
肥大化する非機能要求に対処するための「非機能要求グレード活用シート」の具体例が記載されており今後活用できると思います。
基本設計フェーズについては、画面設計、データ設計、機能設計も行う必要がありますが、
アーキテクチャ設計をメインに記載されており、かつ業務システムに対して既製品を活用することを前提の内容でしたのであまり参考になりませんでした。
ただ、業務フローをベースにドメインモデルを作成しデータ特性を分析する上での以下の注意点が参考になりました。
・少しずつモデリングする
・シンプルに作る
・モデルを公開する
詳細設計フェーズについても、特別目新しい内容はなく、
画面設計においては実装技術を使って実際に動くものを見せることでユーザーがイメージし易く、
プログラミングフェーズでその成果物をそのまま使用できるという内容は正にそうすべきだと思いました。
また、プログラム設計書(フローチャートなど)を作成しない場合は、
プログラムコードによってその役割を果たすべきで、
そのためにはコードの共同所有の意識を高める必要があり、それを促進する施策として
XP(eXtreme Programming)では「ペアプログラミング」「テストファースト」「CI(継続的インテグレーション)」が
謳われているが、これらを実践することは難しいということで、
「パターン(デザインパターン)」の使用を薦められていました。
テストフェーズでは、受入テスト駆動開発を勧められていましたが、
これについては我々も既に実践している内容です。
あとは、チケット駆動開発として、BTS(バグトラッキングシステム)やITS(課題トラッキングシステム)などの
チケット単位でプロジェクトのタスクを管理してテストやバグの状況を可視化することで
リズミカルにテストを進められ、要求や設計などの情報と紐づけられるので作業の見通しが良くなるということでした。
このチケット駆動開発を行うには、「CI(継続的インテグレーション)」という
プログラムコードの修正結果とチケットを自動的に紐づけてくれる仕組みが必要とのことです。
この仕組みのことを「ALM(Application Lifecycle Management)」と呼ぶらしく、
「定義」「デザイン」「ビルド」「テスト」「展開」という一連のプロセスとアクティビティを
シームレスに連携する仕組みだそうです。
代表的な統合ALM製品として「Microsoft Team Foundation Server」が挙げられていましたが、
習熟期間や目的が明確でないと導入しても効果は出にくいと注意書きがありましたので、
地図開発において有効かどうか実際に触って確認してみたいと思います。