前回は、ISO/IEC12207（ソフトウェアライフサイクルプロセス）といった国際規格など、開発プロセスに関する基本的な知識についてご紹介いたしました。
今回は、策定の際に気をつけておくべきポイントを取り上げたいと思います。
プロセスの範囲として、ISO/IEC12207のうち、ソフトウェアへの要求分析から設計・構築・テストを実施する 「ソフトウェア実施プロセス」に着目して考えます
図 １ ISO/IEC12207
※ISO/IEC12207については、前回の記事をごらんください。
■ 開発プロセス策定の留意点
開発プロジェクトを進める際の作業の順序や成果物の定義、作業を実施する役割定義を行うなかで、しばしばスムーズに進められないことがあります。慣れの問題と片付けることもできますが、気をつけておくポイントについてもう少し分類してみましょう。今回は、策定対象と策定体制の大きく２つに分けて考えてみました。
１）策定対象に関すること
ア）組織の責務
システム開発にはいくつもの組織が関係します。以下に簡単な例を示します。
図 ２ システム開発にかかわる組織の例
こなれた標準プロセスを持たない組織の場合は特に、プロジェクトごとに組織間の責務が曖昧なことがあります。
ある部門が何を行いどのような成果物を作成するのかは、その成果物をインプットとする別の部門にとっては大いに関心があるところです。特に、プロジェクトの規模が大きかったり、ウォーターフォールの開発手法を選択した場合、開発が始まってから、「こんなインプットでは不十分だ！」といった事態になると大変です。直接成果物を作成する組織でなくとも、たとえば、要件定義する際にユーザーへヒアリングしながら要件を引き出していく場合には、要件定義の際にユーザーの参画が必要であることを関係者間で認識しておく必要があります。ユーザー部門は通常の業務を抱えながら要件定義に参画することも多いため、負荷のかかる作業の発生には慎重にならざるを得ません。
企業によっては、情報システム部門がインフラ部門とアプリケーション部門に分かれていたり、開発部門と運用部門に分かれていたりするなど、さらに組織が細分化されているため、責務の検討・調整には時間がかかります。
【留意点】こなれた標準プロセスを持たない組織の場合には特に、プロジェクトごとに組織間の責務を調整する必要があります。プロセス策定の際には、関連部署の調査や、調整時間も含めて計画することが必要です。
イ）他の統制ルールとの関係
企業によっては品質管理部などがシステム開発に関する社内共通のルールを定めています。たとえば、開発工程の定義や誰の承認を受けるべきか、作成すべき報告書や成果物等に関するルールです。共通のルールから逸脱した開発プロセスを策定すると、社内審査に通らないといった問題が発生します。例えば、システムのリリースが迫っているにも拘らず、社内共通のルールで定義されている設計成果物が作成されておらず、後づけでその設計書を作成しなければならなくなったり、内部統制などの監査時にひっかかったりする、といった事態です。また、全社的に管理しているデータ辞書の有無とか、IDの採番ルールの存在も確認しておく必要があるでしょう。
もちろん、共通のルールが今回のプロジェクトにどうしてもあわないケースもあるでしょうから、その場合は共通のルールを発行した品質管理部などと調整しながら進める必要があります。
【留意点】共通のルールを意識しながらプロセス策定を進めることが必要です。
ウ）アーキテクチャとの関係
開発するシステムのアーキテクチャによって必要な成果物が異なる場合があります。「要件定義書」や「基本設計書」といった大まかなレベルの成果物は同じでも、そのコンテンツである個々の成果物定義は、作るシステムにあったものにするべきです。ところが、実際にアーキテクチャが決まるのは、プロジェクトの途中であることがあります。にもかかわらず、プロジェクトの始めに成果物のフォーマットや記入要領を作成する策定計画にしていると、実際に記入要領等を作る際に未確定なアーキテクチャに足をとられてうまく進めることができません。
【留意点】アーキテクチャや使用する製品の決定後に、成果物の記入要領やフォーマット等の成果物定義を見直す計画を立て、それに向けた予算取りなどをしておくことが必要です。
エ）プロジェクト特性との関係
品質に重きを置くプロジェクトでは、設計書等のレビューやテストなど品質に関わるプロセスを重要視する必要があるでしょう。また、数百人規模の開発プロジェクトと１０人で行う開発プロジェクトでは、開発の大まかな流れは同じでもプロセス策定側の意識はかわってきます。例えば、小規模プロジェクトの中でケースバイケースで作成する成果物は、大規模プロジェクトでは管理上おしなべて作成する方針が採られることもあります。小規模プロジェクトは小回りが利くため個別の判断に対応しやすいためです。
また、既に作成済みのシステムに対し、追加で開発をする場合などは、新規で開発するプロジェクトに比べ、アーキテクチャ等のリスクは下がりますので、簡素化できるプロセスも出てくるでしょう。
【留意点】規模やリスクなどプロジェクトの特性を考慮し、プロセスや成果物を手厚くしたり簡素化したりすることを検討します。
２）策定体制に関すること
ア）範囲が広く利害関係者が多い
前述の「組織の責務」で述べたように、開発プロセスの策定は多くの組織が利害関係者となることがあります。だからといって、大勢で策定すると「船頭多くして船山に登る」状態になり、話がまとまらないことがあります。私の経験では、プロジェクトの規模の大小にかかわらず、検討会の場は10人が限度という気がします（成果物の様式や記入要領作成いった作業実施は納期に合わせて人数を増やすこともありますが）。ある程度プロセスの概要が決まってきたら、関係部署へのヒアリング等を実施し、調整していきます。相反する意見も出てきますので、標準化を推進する力のある組織の後ろ盾と辛抱強い調整力が必要となります。開発現場のメンバーが自主的にルールを作って広げようとしても、そこに強制力を持たせて統制することは難しいため、大規模プロジェクトになるほどトップダウンで進める必要があるでしょう。結局はいわゆる「うるさがた」や「声の大きな人」の意見が通ることもありますが、それでも開発プロセスの策定の段取りを計画し実行しコントロールすることに努めなければ、仕事の終わりが見えず開発プロセス策定メンバーのモチベーションにも影響します。
【留意点】開発プロセスには多くの人に関係がありますが、策定検討に多くの人が一斉に関わることはせず随所で意見調整ができるようにします。また、策定完了に向けた段取りを明確にしておく必要があります。
イ）適切な人員をアサインできない
この問題は、特にプロセス策定の仕事に限った話ではないのですが取り上げることにしました。要件定義のプロセスを検討するメンバー全員が要件定義未経験者というのでは、策定作業をスムーズに進めることはなかなか難しいのではないでしょうか。とはいえ、例えば、これまでウォーターフォールで開発していた組織が、今回は初めてアジャイルに取り組むなど、メンバーが勉強しながら策定にチャレンジするプロジェクトもあるでしょう。その場合は社外の有識者に参画を依頼するのも一案ですし、社員へのスキルトランスファーも含めゆとりを持ったスケジュールを組み、実際のプロジェクトを実施する前に、策定したプロセスを試行し評価する期間を設けるなど、計画に工夫をする必要があります。
【留意点】開発プロセスの策定は、全員が開発プロセスの専門家や策定経験者である必要はないと思います。プロセスの知識を持った人に加えて、開発現場を知っており、そこに問題意識を持っている人が参画すると、より現場に役立つプロセスが策定できると思います。
■ 最後に
そうはいってもなかなか一筋縄でいかないのが開発プロセスの策定なのですが、何かしら皆様のヒントになれば幸いです。
最後までお読みいただきありがとうございました。
*本Webマガジンの内容は執筆者個人の見解に基づいており、株式会社オージス総研およびさくら情報システム株式会社、株式会社宇部情報システムのいずれの見解を示すものでもありません。
『WEBマガジン』に関しては下記よりお気軽にお問い合わせください。
