CodeZine(コードジン)

特集ページ一覧

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

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

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2009/08/10 14:00

目次

失敗しないためにも

 開発手法は、開発対象の特性に応じたものを選択するのが鉄則です。その次に、その開発手法を採用した場合、手慣れているか否かで決定すべきです。開発対象の特性に応じた開発手法が自社にスキルとしてないのであれば、入札しないのが賢明だと思います。開発手法が分からない、スキルがないということは、高層ビルの建て方は知っているが、橋の架け方を知らないのと同じで、非常に失敗の可能性が高いプロジェクトになると予想されます。以下は、筆者の経験です。

慣れない手法

 前ページで触れたように、スキルのない開発手法を技術提案書に無理に記載したのは、筆者がいたプロジェクトです。その時に開発手法としてRUPを選択したのですが、実際は本格的に利用したこともないのに無理をしました。RUPのように著名な手法はコンサルタントの得意分野なのです。調達仕様書を書いたコンサルタント会社にはSE出身のコンサルタントも多く、RUPに熟知している人がいても不思議ではありません。筆者たちが提出したWBSを見て、苦笑いされてしまいました。プロセス定義もできていないのにWBSなど作れるわけがありません。ここはRUPに強い別のコンサルタントの力を借りずにはいられませんでした。3日程度でWBSを作り上げ、成果物のフォーマットを定め、タスクの意味までしっかり伝授していただきました。これ程、恥ずかしい気持ちになったことはありませんでした。顔には「これでよく落札できましたね」と書いてあるようでした。

 このように万が一、提案書の点数稼ぎのためにスキルの伴わない開発手法を選択した場合、調達仕様書を書いたコンサルタント会社とは別のコンサルタント会社に依頼して早急にプロセス定義を行い、早急にWBSを完成させるしかありません。WBSのできが悪い場合、システムの構築能力を疑われる結果となり、省庁との信頼関係に悪影響を与える結果となります。誤字・脱字以上に信頼回復は困難なものとなります。

手慣れた手法

 慣れない手法に比べ、手慣れた開発手法のプロジェクトへの適用は、メンバーの士気を大いに高めてくれます。

 筆者が手慣れた開発手法を適用したプロジェクトの例として、オブジェクト指向分析・設計を選択したことがありました。オブジェクト指向分析・設計といっても、ユースケース図は知っている、クラス図、シーケンス図も知っている。ただ、これらがどのように結びついているのかがよく分からない状態でした。その当時、C.T.アーリントン著の「UMLによるエンタープライズJava開発-ソフトウェアモデリングによる効率的なJavaシステムの構築」が出版されました。一読して、成果物同士が一気につながりを持つことを確認できました。これを元に小さなプロジェクトに適用していたため、この手法を取り入れて成功に結びつけたことがあります。上記の書籍は翻訳本であったため、タイムラグがあり、古くなった部分も多かったのですが、少し改良することでりっぱな開発手法にすることができました。プロセス定義も整備したため、WBSも短期間で作成できました。大切なことは、省庁がその手法でシステムが完成できるというイメージを持つことができるかどうかなのです。おかげさまで、出だしでこけることなく、信頼を得ることができました。やはり手慣れた開発手順に勝るものはありません。

 たった1行、技術提案書に記載する内容で、プロジェクトが天国に行くか、地獄に行くかと言っても過言ではありません。何気なく例を挙げましたが、非常に重要なので肝に銘じていただければと思います。

WBS作成のためにも

 省庁に限らず、プロジェクト計画書やWBSはお客様の1番気になるところです。これらの作成が遅れるとプロジェクトの進捗に重大な影響を及ぼします。繰り返しますが、各工程のタスクと入出力を見てシステムの構築がイメージできることが1番大切なことです。WBSがないまま作業に突入し、結局大きな進捗遅れが発生することは予想以上にあることです。プロジェクトの最初に、誰が見ても1つ1つのタスクの定義が分かるようWBSを作成するのは、想像以上に大切なことです。例としてあげたコンサルタントの導入は効果的ですが、メンバーに対する教育をすることも大切です。立派なプロセス定義ができても、実際に手を動かすメンバーがその意味を理解していなければ、仏作って魂入れずとなりかねません。

 繰り返しになりますが、第1回「誤字・脱字を侮るな」と同じように「WBSを侮るな」というのがここでの重要なアドバイスとなります。省庁の方はWBSを見て、システム構築の能力を判断します。WBSが綿密に作成されていない場合、PMやPMOはWBSの作成に忙殺され、プロジェクト運営が疎かになったという経験があります。要件定義の成否はプロジェクトの成否に大きく影響します。この時期に要件定義に品質を管理していないとしたら、結果は見えています。

WBSは綿密に作成し、省庁に提出すること
WBSは綿密に作成し、省庁に提出すること

アジャイルは可能か

 省庁系システムの開発スタイルとして、アジャイルが適用可能かは定かではありません。省庁以外のシステムでは試みたことがあり、小さなシステムではありましたが非常に生産性が高かった経験があります。適用可能であれば、小さな案件でやってみたいと考えています。ネットで検索しましたが、それらしきものにヒットしませんでした。ご存じの方は、コメントをいただければと思います。

 次回は、技術編の第3回として、省庁系システム開発における「アプリケーション関連のセキュリティ」を紹介します。



  • LINEで送る
  • このエントリーをはてなブックマークに追加

バックナンバー

連載:初めての省庁系システム開発

もっと読む

著者プロフィール

  • チャーリー・佐藤(チャーリー・サトウ)

    ここ10数年、プロジェクト・マネージャやソフトウェア・アーキテクトという一見相いれない仕事を繰り返してきました。プログラミングも大好きで、自宅ではいろんな言語を楽しんでいます。 年齢も40過ぎ、徹夜の連続では耐えられないようになってきました。

あなたにオススメ

All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5