工程管理とは？基礎知識からソフトの選び方まで完全ガイド

工程管理とは

工程管理とは、プロジェクトを無事「完了」に導くために必要な管理活動です。プロジェクトは、製品やサービス・システムを作り上げる活動を意味するものとします。では、工程管理の前提となるプロジェクトの「成功」とは何でしょうか？

工程管理の先にある、プロジェクトの成功とは

プロジェクトの真の成功は、その製品やサービスが完成した後に、自社製品や自社サービスであれば、その製品・サービス自体がより売上向上に貢献することかもしれませんし、受託システム開発であれば顧客満足の実現かもしれません。

成功の形は、製品やサービスにより、大きく異なります。ですので、私はあえて、工程管理とは、プロジェクトを「成功」に導くために必要な管理活動です、とは言わなかったのです。

プロジェクトマネジメントの世界では、プロジェクトの成功とは、プロジェクトそのものを無事完了させることに他なりません。更に掘り下げますと、プロジェクトを無事完了させるための要件とは何でしょうか？

プロジェクトを無事完了させるための要件

プロジェクトを無事完了させるための要件。それは、QCDと呼ばれる、品質(Quality)、コスト(Cost)、納期(Delivery)において計画通りにプロジェクトを完遂することです。

とはいえ、実際には、最初に立てた計画通りに全てがうまくいくプロジェクトなんてない、と考えておくべきです。プロジェクト規模が大きくなればなるほど、プロジェクトに関わる人が多くなればなるほど、計画の変更は当たり前に発生します。プロジェクトの進捗(計画に対する進行度合い)を随時適切に観測し、必要に応じてプロジェクト計画を変更し続けることこそが重要なのです。

このように、プロジェクト計画とその実行を主に進捗という側面で管理・支援するための手法こそが、工程管理です。

工程とその管理手法

工程管理でいう「工程」は一つひとつの作業単位です。
プロジェクト計画を立てる際、プロジェクトマネージャは、プロジェクトの作業・工程の分割を行います。例えばシステム開発業であれば、要件定義工程、設計工程、開発工程、テスト工程、といった具合です。

粗い粒度で分割されたこれらの工程を必要に応じて更に細分化し、工程ごとの期間を決め、担当者をアサインし、かかる工数等の原価を予算化し、工程表、いわゆるガントチャートと呼ばれる管理表が作成されます。

この考え方は、プロジェクトを軸に進む仕事(システム開発業、建設業、広告イベント業等)においては、極めて一般的な考え方で、手法としてはウォーターフォール型のプロジェクト管理方法と言われます。滝の水が下へ落ちることと同じように、それぞれの工程が終わり次第、次の工程へ進み、前の工程には戻らないことが名前の由来です。

一方、近年では、主にシステム開発業を中心として、アジャイル開発というプロジェクト管理手法も、プロジェクトを無事完了させるための手法の一つとして台頭しています。

アジャイル開発とは

アジャイル開発とは、適応型ソフトウェア開発などともいい、未来を予測することは困難であるという前提にたった上での管理手法です。

ウォーターフォール型のような計画立案、実行を重視するのではなく、臨機応変に対応することに重きをおいた管理手法です。

イテレーションと呼ばれるサイクル（要件確認～テスト）を一定期間設け、それを複数回繰り返すことで、プロジェクトを無事完了へと導きます。

これは言わば、上述したとおり、プロジェクト計画が変更されるのは当然であるという考え方を、イテレーション毎に変更された計画を実施する、というプロセスに組み込んだ手法とも言えます。

とはいえ、大きな意味では、この手法も工程管理の一種です。

工程管理のスコープ

冒頭で触れたとおり、工程管理はあらゆるプロジェクトを無事完了させるために必須です。工程を管理しないプロジェクトはありません。

ここでは工程管理で管理すべきスコープ、QCDと呼ばれる、品質(Quality)、コスト(Cost)、納期(Delivery)について詳しく解説します。

①品質の維持・向上

品質の維持・向上をするには、各工程で、その工程を本当に終えてよいのか？のチェック・検証をする工程を入れる、もしくは工程を完了して良い要件を定義することで、確実な品質を保証するための工程の定義が実現できます。

例えば、工程に対して成果物を明確にする、その成果物に対するレビュー工程を入れる、といった具合です。

②コストを事前に明確に

工程管理におけるコストの観点は主に人件費です。
人件費を算出するために決めなくてはならないことは、どの工程にどの担当者をアサインし、その人がその工程に何時間・何人月かけるか。
担当者の工数を積み上げれば、その工程、ひいてはプロジェクトにかかる総工数、総人件費が明確になるでしょう。

一方、アサインという観点では、作業者は、必ずしも一定期間その工程だけに集中し作業できるとは限りません。同時期に複数の工程を処理しなければならない場合もあるため、アサインする側は作業者のマネジメントを適切に行う必要があると言えます。

③納期

工程表を必要ベース、見積ベースで立ててみたら、指定納期をオーバーしていた、ということもザラにあります。納期を延ばすことができれば良いですが、できないことの方が多いかもしれません。プロジェクトには不測の事態やリスクも想定されます。

このような場合の対策としては、メンバーの追加等による納期の圧縮を考えなければなりません。すると、作業員の追加による作業の分割、コミュニケーションの増加により、作業は間違いなく当初の案より非効率になります。

納期を短縮するために、より追加コストがかかるのです。いわゆる特急料金です。
こういった極めて実務的な問題を、工程管理を実践することで明確化することができるのです。

一方、プロジェクトマネジメントの世界では、より深く広いスコープがPMBOK（Project Management Body of Knowledge）という世界規格により整備されています。リスクマネジメントやリソースマネジメント、ステークホルダー・マネジメント等、世界中のプロジェクトマネージャたちが自分たちの経験則等を元に、プロジェクトを無事完了させるための重要な観点を10の知識領域として集大成させたものです。
これらも、プロジェクトを無事完了するためには必要な行為ですが、工程管理という観点では少し外れる部分も増えますので割愛します。

工程管理ツールの選定基準

プロジェクトの工程管理を支援する具体的なツールは多数あります。
Excelで工程表を作成し管理する方法から、無償ツールや有償ツール、工程管理に特化したWebサービス、ZACのようにERPと連動したEnterpriseな工程管理まで、非常に多数の製品があり、それぞれに強みや弱みをもっています。工程管理ツールの市場はもはやレッドオーシャンと言えるでしょう。

なぜレッドオーシャンなのか。それは、具体的なツール数というよりもむしろ、その特性にあります。まずExcelやスプレッドシートにより、自分の好みに合わせてそれなりの工程管理ツールが作成できてしまうこと。また有名な無償ツールの存在。そして工程管理という機能自体が比較的簡単なものであるため、参入障壁が低いことです。
一方、ユーザーの立場では工程管理ツールを選びたい放題です。むしろたくさんありすぎて選ぶのが難しいかもしれません。

ですが、あくまでこれらのツールは、プロジェクトを無事完了させるための便利ツールにすぎないということを覚えておきましょう。本質はあくまで、プロジェクトを無事完了させることに尽きます。何を選択するべきかは、プロジェクトの性質によっても異なります。また、一般的には個人の好みで選ばない方がいいのでしょうが、プロジェクトを無事完了できるイメージが描けるものなら、成功実績豊富なプロジェクトマネージャ自身が使い慣れた好みのツールが良いこともあるでしょう。

この世に100％完璧な工程管理ツールなどはありません。工程管理という概念はプロジェクトという形で仕事が進むあらゆるものや業種に通用するため、工程管理が持つべき機能観点は極めて多くあるためです。そこで、数多あるツールを選定する上で、重視したい7つの観点を紹介します。

1. 開発手法に対応しているか
2. 課題管理(チケット管理)に対応しているか
3. ソースコード管理に対応しているか
4. ガントチャート、WBS、工程表(いわゆるスケジュール表)に対応しているか
5. UI(ユーザインターフェース)/UX(ユーザエクスペリエンス)
6. 進捗管理をスムーズに行えるか
7. 拡張性、他システム間連携

開発手法に対応しているか

上述のとおり、ウォーターフォール型なのかアジャイル開発なのか、という大きい枠組みにより、選ぶべきツールは変わってきます。ZACのようにウォーターフォール型が得意なツールもあれば、アジャイル開発が得意なツールもあります。

課題管理(チケット管理)に対応しているか

プロジェクトを実行していると、多くの課題や検討事項が途中で発生します。これらは工程自体ではありませんが、工程を実施している最中に発生した問題であり、工程を終えるためには解決しなければならない課題とみなされます。これを工程管理ツールで管理できるかどうかも大きな観点です。

ソースコード管理に対応しているか

主にシステムやソフトウェア開発業による内容ですが、開発したソースコードを工程管理ツールとセットで管理できるかどうかも、特にエンジニア主体のプロジェクトでは重要な観点です。

ガントチャート、WBS、工程表(いわゆるスケジュール表)に対応しているか

立てた工程がスケジュール表として視覚的に見やすく、操作できることは、極めて重要です。全体の工程表は当然ながら、各作業者が自分のスケジュールとして自分の工程だけの表が見えることで、作業効率もアップするでしょう。

UI(ユーザインターフェース)/UX(ユーザエクスペリエンス)

見栄えと使いやすさも重要です。あくまで、工程管理の目的はプロジェクトを無事完了させることですが、使いづらいツールを導入し、QCDのC(コスト)にあたる、生産性が下がってしまっては本末転倒です。

見栄えや使いやすさは、一見するとそれほど生産性との因果関係が見えないかもしれませんが、工程管理ツールはあくまでも便利ツールであるという位置づけを思い出していただくと、使い勝手が良いこと、かゆいところに手が届くことがいかに重要であるか分かっていただけるでしょう。

例えばExcelであれば、それ自体は工程管理ツールではないものの、誰もが使い慣れたツールであり、個人が自分の使いたいようにメンテナンスできるという点、これ以上使い勝手の良い工程管理のツールはないように思えます。しかし、10人20人もの関係者がおり、何十人月もの工数のかかるプロジェクトの工程管理をExcelで行うという選択肢は非現実的でしょう。Excelはファイルの共有化はできるものの、複数人が同時に入力や保存をすることができないたため、複数人での管理には向いていません。

もう一つ例をあげますと、工程表を親子関係しか作れず、孫工程やその更に下の工程が作れないツールもあります。大きい意味ではこのツールも「ガントチャートで工程管理ができます」と言えるかもしれませんが、3階層も4階層もある大きなプロジェクトはザラにあり、そういったプロジェクトにはこのツールは適切ではないでしょう。
選定時には実現できると聞いていたのに、蓋を開けたら到底要求レベルに達していなかったということもあります。可能な限り、テストトライアル環境やデモ環境を使うなどで事前確認をしましょう。

進捗管理をスムーズに行えるか

工程管理の本題です。工程管理ではプロジェクトの進捗(計画に対する進行度合い)を随時適切に観測することが肝になってくることは、「工程管理とは」の章で述べました。
ツール選定では特に

• そもそも正確に観測できるか？
• 観測しやすいか？
• 進捗のメンテナンスは楽か？

ということが重要なテーマとなってきます。

ちなみに工程管理における進捗には大きく3つの切り口があります。

1. 原価進捗
2. 工数進捗
3. 成果物進捗

これらはすべて、全く異なる側面を持った進捗指標です。

原価進捗

プロジェクト計画を立てる際、仮に売上の立つ受託案件だった場合に、その売上に対して、どれだけの人員をいつからいつまで何人月投入するか、外注業者にいくらで発注するか、と、すべての原価を予測するでしょう。その予定総原価に対して、プロジェクト進行中のある時点で、いくら消化しているのか、が原価進捗です。
建設業などでの工事進行基準における進捗率と同様の考え方です。

工程管理のツールの中で、原価進捗ベースで管理できるツールはかなり稀です。それこそ、ZACのようにプロジェクト収支管理ツールやERPの領域をカバーする製品でなければ、まず対応されていないでしょう。一方で、その領域までいくとシステム導入コストも比較的大きくなる可能性があるため、そこまでの管理が本当に必要なのか？という点が選定ポイントです。

工数進捗

工数進捗は、後述する成果物進捗と並んで、工程管理の一般的な進捗指標です。
工数進捗は、作業者がその工程の消化にかける工数を見積り、その見積工数に対する消化時間(消化工数)を観測することで進捗率を図る手法です。

工数進捗に関し、多くの場合課題となるのが、工数実績の二重入力問題です。自社の勤怠管理システムで就業管理を実施し、場合によっては「この日はこの案件に何時間稼働した」と入力するケースはよくあると思います。
しかし、その工数の多くは、別システムとして管理している工程管理ツールにはまず連携されません。それにより、勤怠管理システムでも工数入力し、工程管理ツールでも工数入力するという非常に手間のかかる作業をされるケースも散見されます。

さらに、せっかく二重入力をしたにも関わらず、案件損益に直接反映されない場合があるというのですから、そこまでいくと三重入力の世界です。

重複入力の解消の手段のひとつとして、ZACが役に立つでしょう。ZACは勤怠管理機能および工程管理機能の2つを併せ持っています。日々の勤怠入力と工程入力を一度に、つまり案件と工程に同時に打ち込むことで、損益管理と工程管理へ同時に即時反映するのです。極めてシンプルにこの三重苦から解放されます。

成果物進捗

ここまでの説明を読むと、プロジェクトの進捗管理は、原価進捗と工数進捗だけで十分のような気がしませんか？この2つは極めて客観的な指標であるため、分かりやすく取り入れやすいと思います。
しかし、プロジェクトマネジメントの世界では主観的な指標も重要。統括するプロジェクトマネージャによる感性・直感・経験というものが多分に重要視されるのです。
その経験を活かせる工程管理での要素が成果物進捗です。
成果物進捗とは、工程毎の成果物もしくは完了要件が予め定義されている前提で、その成果物が何％完了したのかを示す進捗指標です。

ツールを上手く使いこなせるだけでどんなプロジェクトも無事完了できるのであれば、誰も苦労しないで済むのではないでしょうか。適切なツールを選択し、原価進捗と工数進捗を正確に観測したとしても、いわゆる失敗、炎上するプロジェクトは未だにあとを絶ちません。そこで、客観的な指標だけではない、主観的な指標として成果物進捗が活躍するのです。

成果物が何％完了したのかを観測するのは困難です。成果物進捗を運用上どう定義し、プロジェクトマネージャが目を光らせてどうマネジメントするかが、進捗管理最後の肝であり、プロジェクトマネージャの手腕の見せ所とも言えます。

これら3つの進捗指標がツール上でどのように実現されているのか？そもそもあるのかないのか？という部分が重要な選定ポイントとなるでしょう。

拡張性、他システム間連携

最後の選定ポイントは拡張性に関してです。先に述べた通り、工程管理ツールの市場はレッドオーシャンです。ZACも含め、既存のメジャなツールも今後の機能追加には二の足を踏んでいると言っても良いかもしれません。

つまり、ベンダーが自社製品への機能追加に費用対効果などから限界を感じているケースも多くあるのではと個人的には思っています。

プラグインによる拡張開発は有名ですが、一方で、他システムとの連携に活路を見出している製品も増えはじめているようです。

外部システムとの連携はホットなテーマですので、各社製品がこぞって情報を発信しています。選定の際にはこの点をキャッチアップするのもポイントです。

工程管理の事例：アプリ開発・Web制作業　株式会社カヤック様

ここからはZACの導入事例に沿って、工程管理の実現方法ご紹介します。

導入背景

ソーシャルゲーム・アプリ開発のリーディングカンパニー、カヤック様。ZAC導入以前はExcelでそれぞれのプロジェクト管理をしていたが、労務時間データとそれを金額換算するために必要な会計データがバラバラに管理されており、集計作業に膨大な工数がかかっていたそうです。また、成長企業ならではの問題ですが、社員が一気に増え経営環境もガラッと変わったとのことで、Excelでプロジェクト管理をすることが難しくなったため、ツールの導入を検討され始めたとのことでした。

ZAC導入後の効果

• 従来バラバラだった労働時間データを1ヵ所に集めて一元管理できるように。集計作業がスピーディーかつ楽にできるようになった。
• アプリ開発やWeb制作などの案件を受注する前の段階から、案件ステータスの管理や予定売上の管理ができるので、いつ頃どんなプロジェクトが動き出すのかがあらかじめ把握できるようになり、誰をアサインするかの予定が立てやすくなった。
• 先々の業務状況を「見える化」できたことで、リソース管理や経営予測の精度も高まった。
• ZAC内で使用されている案件管理の進捗ステータスや、工程用語が社内で浸透し、言葉や意識が統一されたことでコミュニケーションが円滑になった。

カヤック様の導入事例はこちら

ZACは基幹システムとしての側面だけでなく、グループウェアとしての予定表や工程管理モジュールも有したシステムです。安価にZACの工程管理モジュール単体で利用することもできますが、ERPに工程管理がオーバーライドすることで、相乗効果を実現した製品です。
工程管理の3つの指標、原価進捗・工程進捗・成果物進捗の全てが管理できることも魅力の1つです。
また、ウォーターフォール型に親和性が高く、ガントチャート上だけでほぼ全ての工程メンテナンスができる使い勝手の良さを追求しています。

終わりに

工程管理はあらゆるプロジェクトを無事完了(いわゆる広義での成功)させるために必須です。工程を管理しないプロジェクトはありません。

ですが、実情はというと、プロジェクトをただ完了するだけなら、損益度外視、赤字を垂れ流しても、納期が遅れても良いのであれば、工程管理ツールは不要と言えます。また、実際そうしたプロジェクトが世間にはまだ存在することもわかっています。

工程管理ツールは残念ながら、あくまで便利ツールにとどまっています。運用ルールを決めて、プロジェクトメンバーみんながしっかりと運用しようと決め、さらにそれが守られなければプロジェクトの成功は絵に描いた餅で終わります。
何度も言いますが工程管理ツールは所詮便利ツールです。損益管理に対応していないことも多く、プロジェクトマネージャだけがツールに振り回されて疲弊するといったことも少なくありません。

筆者の経験では、あるSIerで、自社製の工程管理ツールを使いながらも、同時にExcelでも詳細なWBS（※Work Breakdown Structure=作業分解構成図）を使って管理するという事例も見てきました。工程管理ツールは進捗を管理するための便利ツールであるにも関わらず、これでは便利であるどころか管理する時間が増える一方です。工程管理ツールの選択を誤ったがゆえに、自分たちがやりたい管理を1つのツールだけでは実現できなくなり、2つのツールに頼ってしまうという事例ですね。

誤解しないでいただきたいのは、複数のツールを併用するのが悪いと言いたいのではありません。上述の事例は、明らかに二重管理であり、私には生産性度外視の「管理のための管理」に思えましたので、それは避けてほしいということです。なるべくしてツールを分割することは決して否定はしません。それほど工程管理が関与する業務領域は広く、完全なシステムなどないというのが私の見解です。

ただ、管理のための管理が必要となるような残念なことにならないよう、プロジェクトの性質にあったツール選定をし、合理的で的確かつ簡便なプロジェクト運営をしていただきたいと思います。

昨今、ベンチャー企業でなくともプレイングマネジメントは珍しくない時代です。管理だけに時間を使うのはもったいないですね。そうならないように、生産性を高める工程管理ツールの選定、そして運用決めが重要なのです。

本記事が貴社のプロジェクトの真の成功に貢献できることを願っています。