プロジェクトマネジャーに贈るプロセス改善事例 第5回現場で使われない開発標準―その理由を尋ねてみると……
開発プロセスや成果物の標準化、そのドキュメント作成に関わった経験があるだろう。しかし、それらは今どうなっているのか？ 書棚の奥でホコリまみれになり、その存在自体が忘れ去られていたりしないだろうか。
企業や組織がプロジェクトの品質を向上させるためには、プロセスや成果物などの「標準化」を行うことが有効である。個々の担当者の進め方に依存していては、品質が安定しないばかりか、情報やノウハウの共有が難しくなる。そこで、ソフトウェア開発のためのベストプラクティスをベースに、ドキュメントなどの開発標準を整備し、プロセスや成果物を統一化することで品質の向上を図るのである。
しかし、その標準が開発現場で有効活用されているとはいえない組織も多いだろう。今回は、標準化にありがちな「使われない開発標準」の利用環境を整備することで、開発現場での利用を促進し、さらに継続的な改善活動につなげた事例を紹介する。
書棚の奥に眠る「開発標準」
K社は、製造業や金融業など幅広い業界のシステム開発を受託開発する中堅SIベンダーである。メインフレームやオープンシステムなど幅広いソリューションを取り扱っている。K社では、メインフレームの開発については、メーカーが提供するマニュアルをベースとして十数年前から開発標準が整備され、これらの資料に基づいた開発が行われている。このため開発者が組織を異動しても、開発プロセスや成果物に関して一定の品質を保つことができている。
一方、オープンシステムの開発現場では、メインフレームのようには開発標準が利用されていない。オープン系の開発標準はメインフレームのものをベースに策定されているが、開発現場ではほとんど使われていなかった。プロセスや成果物は各プロジェクトで自由に定められているのが実情であった。
このようにK社では、プロジェクトマネジャーおよびメンバーのスキルや経験によって品質が左右される危険性があり、開発標準の利用促進が課題として認識されていた。
「なぜ使われないのか」その理由を探る
K社では、標準が利用されない理由を探るため、品質管理部門が中心となって、以下の項目に関するアンケートを開発現場に対して実施した。
・開発標準を（一部でも）プロジェクトに適用したことがあるか
・開発標準を利用しない理由は何か？
その結果、オープン系の開発エンジニア240人から回答を得た。
アンケートの結果によると、オープン系の開発標準は全体の76％が利用しておらず、その理由として「存在を知らない」「適用方法が分からない」「使い勝手が悪い」など利用方法に関するものが63％、「現場の業務実態と乖離（かいり）している」「品質が低い」など開発標準の内容に関するものが18％となっていた。
この結果から、K社の開発標準は内容に関する問題以前に、利用方法やその利便性が悪く「利用しないのではなく、利用できない状況にある」ことが分かった。
また、開発現場のリーダーにさらに尋ねてみると、以下のような理由を挙げた。
- 文書量が膨大で理解に時間がかかる
- 全体像が不明確で、プロジェクトへの適用がイメージできない
- 部分的な情報の引き出しができない
この調査結果を基に、品質管理部門では「標準の利用促進が必要である」と考え、「標準化推進チーム」を組織した。
標準化推進チームは、当面の目標として「文書構造の簡素化」「利便性の向上」を設定した。「膨大な文書を読まなくても全体から部分へ把握しやすい構造にしたり、開発標準の使い勝手を改善し必要な部分を引き出しやすくしたりする」という取り組みを開始した。
Webブラウザで参照できるようにした
K社の開発標準は、印刷物一式が複数冊の分厚いバインダーで各部門に配布されていた。また、グループウェア上に文書ファイルとして保管されており、対応ソフトを利用して参照することもできた。しかし、百ページを超える文書もあり、結局は印刷して読むしかなく、使い勝手を悪くしていた。
そこで、標準化推進チームは社内イントラネットに標準ポータルを設置し、開発現場の目に触れやすくする工夫をした。K社の社員は社内広報活動や情報共有にイントラネットを活用しているため、その基盤を活用することが良いと判断したためだ。
また、標準の文書形式をすべてWebブラウザから参照できるHTML形式に変換した。ハイパーリンクを利用して全体から部分への遷移や、参照したい個所への遷移ができるようにした。
さらに、標準化推進チームはプロセス定義用のオープンソースソフトウェアである「Eclipse Process Framework 」（以下、EPF）を利用して、標準文書を作成し直した。EPFは、標準プロセスを定義するための専用フレームワークで、以下のような機能を持つ。
- アクティビティやタスクなどのプロセス要素を「アイコン」として定義でき、その遷移が可能
- アクティビティやタスクの関連性を「流れ図」として定義できる
- タスクに関するロールや入出力成果物などの詳細を定義できる
- テンプレートやサンプルを成果物として登録でき、ハイパーリンクが可能
- プロセス定義では表現できないノウハウやTipsなどをガイドラインとして添付できる
以下に、EPFで定義した標準文書の例を示す。
ワークフロー全体の流れ図
「外部設計プロセス」の構造をさらに詳細に記述したものこのように「見せ方を工夫する」ことで、標準化推進チームは開発現場における標準の利用促進を目指した。
問い合わせの受け皿を万全に
標準化推進チームでは、利用が促進されると標準に対する問い合わせや意見が多発すると予測し、品質管理部門が中心となって「標準プロセスコールセンター」を開設した。コールセンター要員は問い合わせへの応答だけでなく、開発現場に直接出向いて積極的に説明会を開催した。
この取り組みの結果、標準プロセスコールセンターへの問い合わせや意見は約6カ月間で100件を超えた。その中には「開発標準を利用してメリットがあった」という意見や「内容を改善してほしい」という意見などがあった。
開発現場の声
（利用して良かったという意見）
- 標準の内容を理解でき、プロジェクトに適用することができた
- 開発の流れをプロジェクトメンバー間で再認識できた
- 成果物のテンプレートを利用することで、開発生産性が向上した
（内容の改善を求める意見）
- 成果物のテンプレートの中に、実践に即していないものがある
- 直列に定義されている複数のタスクは、並列で実施した方が生産性が良い
- ガイドラインの内容に、プロジェクトで獲得したノウハウを反映してほしい
また、公開から半年後に利用状況に関するアンケートを再度実施した。その結果、利用率は改善前の約3倍となり、利用しない理由には「定義内容に関する不満」が多く見られるようになった。
上記のアンケート結果や標準プロセスコールセンターへの問い合わせなどを考慮すると、K社における「開発標準の利用促進やそのプロセス改善活動」が本格的に開始したといえるだろう。
今回の成果について、ソフトウェア開発プロセスの能力成熟度モデル「CMMI（Capability Maturity Model Integration）」を参照した場合、利用しやすい開発標準を定義したことは「組織プロセス定義（OPD：Organizational Process Definition）」に相当し、開発現場からのフィードバックを基にさらに改善することは「組織プロセス重視（OPF：Organizational Process Focus）」に相当する。また、開発現場が標準を利用してプロジェクトを進めたことは「統合プロジェクト管理（IPM：Integrated Project Management）」に相当するといえる。
利用促進には「サービス精神」が重要
現在、標準化推進チームでは、標準利用をさらに向上させる施策を検討している。
まず、「開発標準活用ハンドブック」を社員全員に配布する予定である。これは、標準プロセスの全体像や適用するためのポイントなどを、標準のオーバービューを図表や絵を使って分かりやすく説明した小冊子であり、10分あれば一読できる。プロセスの詳細は実際に標準を参照しなければならないが、ハンドブックが手元にあることで「開発標準の存在を社員に意識付ける」効果を期待している。
また、今回の目的は「開発標準を利用させる」ことにあったが、今後は「標準を利用して品質や生産性を向上させる」ことを目標として設定した。そのためには「品質や生産性を向上させる標準」になるよう、組織全体でブラッシュアップしていかなければならない。
標準化推進チームでは、開発標準を適用して品質や生産性に何らかの成果を挙げたプロジェクトや、多くのフィードバックを与えたプロジェクトに対して、経営層からの表彰や賞金を与えること、人事評価面で加点評価を考慮することなども検討している。
これらの施策を実施するためには、品質や生産性の評価指標や評価制度の具体化などの整備が必要になるが、組織的に標準を定着させるためには有効な施策といえるだろう。
K社の事例では、バックオフィスである品質管理部門がさまざまなアイデアや施策によって、開発現場への標準利用を浸透させている。ともすれば、バックオフィスの施策は、規則に縛られた「お仕着せ」の対応に終始してしまうことがあり、開発現場の負荷を高めてしまうことも多い。今回、K社が成功した最大の理由は、品質管理部門の開発現場への「サービス精神」にあるといえる。
最後に、標準利用促進のポイントをまとめておく。
（1）使ってもらうこと第一。アイデアはさまざまである
まずは利用してもらうこと。そのためには見た目や使い勝手の改善によって現場の開発者に「利用したい」と思わせることが重要である。
（2）問い合わせへの対応は迅速に。開発現場を放置しない
開発現場は、常に顧客の厳しい要求にさらされている最前線である。その現場を少しでも改善するために開発標準が存在するのである。バックオフィスでは現場を第一とした支援が必要である。
（3）改善活動は永遠に続く。組織に適した方法を取り、無理をしない
開発標準の策定やその利用は、一時的なことではない。また、企業や組織としての活動が継続される限り、その改善活動は続く。体制やコスト、スキルなどの観点から、組織の力を十分に考慮しながら、無理のない施策を継続的に実施していくことが重要である。
製造業を始めとする「ものづくり」の現場では、「個々人の能力向上（技を鍛える）」や「最適な技術を導入する（道具をそろえる）」ことだけでなく、「効果のあるプロセスで統一する（進め方をそろえる）」ことによって、品質の向上と安定化を図ってきた。
システム開発も紛れもなく「ものづくり」であり、標準化の必要性は誰もが認めるところであろう。しかし、効果のある開発標準を策定しても、必ずしも現場が利用するとは限らない。K社のようにさまざまなアイデアと施策によって現場で利用してもらうことではじめて標準化され、多く利用されることでさらなるプロセス改善が可能となる。こうした継続的な努力が企業の成長を助けるのである。
＜筆者紹介＞
堀江弘志
株式会社豆蔵 BS事業部 エンタープライズチーム 主幹コンサルタント
専門分野：プロジェクトマネジメント、プロセス改善
ユーザー系のSI企業でソフトウェア開発やプロジェクトマネジメントに携わった後、2005年より株式会社豆蔵に在籍。現在はコンサルタントとして、システム開発プロジェクトのプロジェクトマネジメント支援コンサルティングや、プロジェクト管理標準や開発標準の策定と定着化支援、プロジェクトマネジャーの育成など幅広く手掛ける。PMP資格保持。PMI会員。
この記事を読んだ人にお薦めのホワイトペーパー
この記事を読んだ人にお薦めの関連記事
ITmediaはアイティメディア株式会社の登録商標です。