初めての省庁系システム開発（第6回）～自社に馴染んだ開発手法に持ち込め～

開発手法を選ぶ際、背伸びは程々に

　この連載では、省庁系システム開発において、著者が経験したプロジェクトを例として、どのような技術を使用したかだけでなく、省庁系システム特有の掟などを書き綴っていきます。本記事では、省庁系システム開発において、失敗しないための「開発手法」の選び方や注意点を紹介します。

はじめに

　一次請けであれ二次請けであれ、または準委任であれ、省庁系システムの開発は、初めて経験するものには戸惑いを与えます。金融系システムや流通系システムなどを経験した技術者にとって、知っておかないとうまく事が運ばないことがあるので注意が必要となってきます。技術面は後ほど紹介することとして、著者が4回の省庁系システム開発で学んだことは次の点です。

1. 誤字・脱字を侮るな
2. コミュニケーションルートを確保せよ
3. 受領資料の意味を熟考せよ
4. 査読すべき資料を早急に収集せよ
5. 省庁の影にコンサルタントの気配あり
6. 自社に馴染んだ開発手法に持ち込め

　第6回目の今回は、省庁系システム開発における「自社に馴染んだ開発手法に持ち込め」について解説していきたいと思います。

これまでの連載

　本編

• 初めての省庁系システム開発（第1回）～誤字・脱字を侮るな～
• 初めての省庁系システム開発（第2回）～コミュニケーションルートを確保せよ～
• 初めての省庁系システム開発（第3回）～受領資料の意味を熟考せよ～
• 初めての省庁系システム開発（第4回）～査読すべき資料を早急に収集せよ～
• 初めての省庁系システム開発（第5回）～省庁の影にコンサルタントの気配あり～

　技術編

• 初めての省庁系システム開発（技術編第1回）～オープンソースで構築～
• 初めての省庁系システム開発（技術編第2回）～認証基盤でつまづくな～

開発手法は馴染んだものを

　1次請けの場合、技術提案書に開発手法を記載する必要があります。省庁から特定の開発手法を要求されることはありません。また、受領資料の中の「将来体系」には、DFD（データフロー図：Data Flow Diagram、DFD）が記述されていますが、開発手法をDFDやERD（実体関連図：Entity-Relationship Diagram）を使ったデータ中心手法にする必要もありません。DFDはあくまでもデータの流れを示すためであって、要件定義時に、このDFDを詳細化する必要はありません。RUP（ラショナル統一プロセス：Rational Unified Process）など著名な手法を用いても構いませんし、自社の開発標準を使用しても構わないのです。最悪なのは、選択した開発手法に対し明らかにスキル不足にもかかわらず、技術提案書の点数稼ぎのために無理をして、開発時に大変な苦労をプロジェクトにかけてしまうことです。

技術提案書には、使いこなせる開発手法を記載すること