企業のIT活用/IT経営の基礎知識

進捗管理にガントチャートとWBS

進捗管理の基本はガントチャートとWBS。WBSはWork Breakdown Structureの略で、日本語では作業分解図と呼んでいます。作業項目を洗い出すことで受注側、発注側それぞれに誤解が生まれない共通の言葉を手に入れることができます。

水谷 哲也

執筆者:水谷 哲也

企業のIT活用ガイド

進捗管理はガントチャートが昔から定番

進捗管理の基本はガントチャート

進捗管理の基本はガントチャート

システム開発などプロジェクト管理の基本となるのが進捗管理です。

進捗管理を行うためのツールがいろいろありますが、よく使われるのがガントチャート。ガントチャートと聞くとなにやら難しそうですが縦軸に作業内容や担当者を書き、横軸に日時を書きこんで予定と実績を管理するいわゆるスケージュール表のことです。

ガントチャートはエクセルで作成可能ですが、本格的ツールとしてはマイクロソフト・プロジェクトなどがあります。またVectorなどで「ガントチャート」と入力して検索すればフリーソフトを見つけることができます。

WBSの作成をまず行う

ガントチャートは、一目で状況把握できる進捗管理ツールとして昔から使われています。ガントチャートを活用するには、まず縦軸に書き込む作業内容を洗い出さなければなりません。

縦軸に作業内容を書きこむために、仕事を分解し個々の作業を具体化していきます。最初に行うのがWBSの作成です。WBSはWork Breakdown Structureの略で日本語では作業分解図と呼んでいます。WBSとはプロジェクト全体を大項目レベルに分解した後、それぞれの項目について、細かい単位に分解し階層化していきます。最下層には具体的な作業項目が並びます。

システム開発であれば、まずサブシステム単位に分解し、次に個々のサブシステムをプログラム単位に分解します。さらにプログラムをモジュール単位に分解し、詳細設計、プログラミング、単体テスト、システム結合などプロジェクトメンバー個々が行う単位へ作業分解していきます。

分解していくだけで作業項目を洗い出せるので簡単です。自分だけ使うスケジュール表の場合は我流でかまいませんが、発注側、受注側など複数人で同じガントチャートを使う場合、お互いが誤解しないような作業項目にする必要があります。これが大変です。

発注側、受注側では同じ日本語でも通じない

受注側、発注側の共通言語がない

受注側、発注側の共通言語がない

システム開発の発注側(ユーザー)は業務は分かりますがITについてはよく分かっていません。反対に、受注側となるITベンダーはITについてはよく分かりますが業務はよく分かっていません。お互いに仕事の領域が違うため、同じ日本語をしゃべっていても言葉そのものが通じません。

金融機関でシステムを作る場合、融資という言葉に対してITベンダーの認識は「事業者が金融機関からお金を借りること」という意味で解釈しますが、金融機関側では「手形貸し付け、商業手形割引、証書貸付、当座貸越による設備資金、運転資金の貸付」と解釈しています。さらに「プロパー資金(銀行リスクによる貸付)、保証協会付き融資」も融資という言葉の意味に含まれます。

融資という言葉から単なるお金の貸し付けと思ってシステムを組み始めると、ITベンダーはあとで痛い目にあいます。実際に利率計算で金融機関から最初に出てきた仕様書はA4の紙一枚でしたが、仕様を詰めていく段階でバインダー1冊の仕様書になったことがあります。

金融機関の業界では常識でも、他業界では非常識ということに気がついていないことから発生する問題です。反対にITベンダー側にも同じ問題があり、IT業界の常識は他業界の非常識になります。

業界による言葉のとらえ方の違いで、スケジュール遅延になったり見積もりが大幅に変更になったりします。そこでIT業界にしぼり発注側、受注側の双方が同じ言葉を話すことができるよう共通の枠組みとなるガイドライン「共通フレーム」が提供されています。

共通フレームをコミュニケーションツールとする

発注側、受注側の誤解を防ぐ共通フレームが本として出版されています

発注側、受注側の誤解を防ぐ共通フレームが本として出版されています

発注側、受注側で誤解が生まれないよう用語や作業内容の標準化が行われました。経済産業省の音頭取りでIPA(情報処理振興事業協会)に部会が作られ、ユーザー企業、ITベンダー、大学などが参加、ガイドラインを作成。最新版は共通フレーム2013としてまとめられ出版されています。

共通フレーム2013はソフトウェアのライフサイクルに関する国際規格(ISO/IEC 12207)をベースに日本独自の拡張をしたもので、ソフトウェアの企画、開発、運用、保守、廃棄まで、つまりソフトウェアが生まれてから無くなるまでの全てのライフサイクルについて定義されています。発注側、受注側双方が共通して利用できるよう相互の役割や業務の範囲・内容、契約上の責任などが記載されています。

例えばシステム結合は下記のタスク(仕事の単位)から構成されていると定義されています。
  • システム結合テストの準備
  • システム結合テストの実施
  • システム結合テストの評価
  • 利用者文書の更新
このタスクがWBS(作業分解図)のベース。作業を行う上で忘れがちなタスクが定義されていて参考になります。例えば、「利用者文章の更新」というのはドキュメントの整備のことです。テストばかりに気をとられていると、作業が必要なのにスケジュールとして記載を忘れがちです。結果的に実態にあっていないスケジュールになってしまいます。

また協力会社やオフショア開発などシステム開発を外部に出す場合にも有効です。ITベンダー個々についても企業文化が違うため、同じシステム結合と作業でも手順が微妙なところで違ってきます。必要な作業項目や成果物を共通フレームによって洗い出しておき、作業前にお互いに確認しておくことで誤解による手戻りを防げます。
  • 1
  • 2
  • 次のページへ

あわせて読みたい

あなたにオススメ

    表示について

    カテゴリー一覧

    All Aboutサービス・メディア

    All About公式SNS
    日々の生活や仕事を楽しむための情報を毎日お届けします。
    公式SNS一覧
    © All About, Inc. All rights reserved. 掲載の記事・写真・イラストなど、すべてのコンテンツの無断複写・転載・公衆送信等を禁じます