作業(タスク)が相互に関連しながら,ある決まった期間の中で一つの目的を達成するための仕事を,一般に「プロジェクト」とよぶことはご存じだと思います。製品開発における一つの開発案件の遂行,受注生産における一つの製番の設計から製造出荷までの作業,あるいは展示会によるセールスプロモーション活動などは,いずれもプロジェクトです。複数の人間が協力しながら進める仕事のスケジューリングとは,プロジェクトのスケジュールを計画することにほかならないのです。このプロジェクト・スケジューリングにおいて重要な考え方が「クリティカル・パス」です。日本語では「隘路(あいろ⁠)⁠」とよびます。Method=CPMです。CPMは1950年代に米国のデュポン社で開発され,以降半世紀にわたりプロジェクト管理の主要な道具となってきました。CPMでは,プロジェクトをネットワークの形に図で表現することからはじめます。プロジェクトを構成するWBSの全タスクをリストアップし,その順序関係を定め,さらに所要時間を推定して,スケジュールのネットワーク表現を作成するのです。これによって,スケジュール全体を見通しよく把握できるようになります。図的表現はいくつかの流儀があるのですが,ここではプロジェクト・ネットワーク・ダイアグラムをご紹介します。この方法では,タスクを四角で表し,タスク間の依存関係を矢印で表現します(なお,ネットワーク図ではタスクのことを「アクティビティ」とよぶ慣習もあります⁠)⁠。このとき,タスクの四角の中を,さらに7つの小さな区画に分けておきます。真ん中の区画に,タスクの内容を表すわかりやすい名称を書きます。その上の区画には,WBS番号を,またその下の区画には,推定所要時間を書いておきます(図1⁠)⁠。図2は,前回(第7回「仕事の工程表をつくる⁠」⁠)で例として出した新製品開発プロジェクトを図示したものです。プロジェクト・ネットワーク・ダイアグラムクリティカル・パスさて,プロジェクトの最初のタスクから,最後の終了タスクまでをつなぐ経路は,ネットワークの中でいくつもあります。5.2など,いろいろ考えられます。これらの中で,所要時間合計が最も長い経路をクリティカル・パスといいます。プロジェクト全体の所要時間は,クリティカル・パスの長さに等しいのです。逆に言うと,クリティカル・パスの長さがプロジェクトの納期を決めることになります。プロジェクトの納期を,クリティカル・パスよりも短く約束してしまったら,最初から実行不可能な計画になるわけです。先行タスクが複数存在するときには,先行タスクの終了日の中で最も遅い日を,そのタスクの最早着手日とする。この計算を,プロジェクトの開始点から順番に終了点まで行なう。最後のタスクの最早終了日が,プロジェクト全体の完了日である。プロジェクトの終了点に達する複数のタスクのうち,所要時間の最もかかるタスクを選ぶ。この操作を順次さかのぼると,クリティカル・パスが得られる。順に求める(⁠4)最早開始日=最遅開始日の経路をたどって,クリティカル・パスを特定する図3の赤線で示した経路がクリティカル・パスであり,オレンジ色のタスクが,そのパスを構成するタスクです。「フロート日数」を知るさて,クリティカル・パスがプロジェクトの納期を決めるわけですから,納期短縮を図りたいときは,まずクリティカル・パス上にのっているタスクの短縮をはかる必要があります。言いかえると,クリティカルでないタスクを,いくら短縮しても全体の納期は縮まらないのです。クリティカルでないタスクには,すなわち作業上の余裕日数があるわけです。これを「フロート日数」といいます。ここではその計算方法を示しましょう。LF)とは,それに後続するタスク群の中で最も早い最遅開始日に等しい。プロジェクトの最終タスクからさかのぼって,すべての先行タスクの最遅開始日を順次計算する。各タスクの「最遅開始日-最早開始日」の日数が,そのタスクの「フロート日数」です。2.2「市場調査」のフロート日数は8-5=3日ですし,2.3「要素技術の検討」のフロート日数は15-5=10日となります。,「⁠要素技術の検討」の完了が数日遅れても,それがフロート日数の10日よりも小さければ,プロジェクトの全体スケジュールには影響を与えません。これが10日以上遅れると,今度はクリティカル・パスがこちらを通る経路に移ってしまうことに注意してください。クリティカル・パス上のタスクは原理上,フロート=0日であり,とうぜん遅れは許されません。大規模プロジェクトでは一般に,クリティカル・パスにあるタスクは全タスクの20%以内であると言われています。プロジェクトの納期を守りたければ,全体の2割程度の重要なタスクをしっかりと着目していればいいということになります。これが,プロジェクトにおけるタイム・マネジメントの要点なのです。クリティカル・パス著者プロフィール佐藤知一(さとうともいち)プロジェクト・アナリスト。エンジニアリング会社に勤務し,国内外の製造業向けの工場設計および生産システムづくりに従事するかたわら,執筆・講演活動などを行っている。専門はプロジェクトマネジメント・スケジューリング・生産計画・リスク分析など。海外におけるプロジェクト事情にも詳しい。2019」を開催しました。DAY1・DAY2の様子を注目セッションとともにお伝えします。LINEのエンジニア3名がイベントに先駆けて見どころを紹介します。コードの安全性・安定性を高める開発サイクル~テスト管理の効率を上げ,脆弱性診断を自動で行う~本連載では,連載「業務を改善する情報共有の仕掛け」を受けつつ,安全性・安定性を加えた開発サイクルについて考えていきます。若者世代から圧倒的な人気を誇るライブ配信&動画投稿コミュニティアプリ「MixChannel」(ミクチャ)の裏側(レコメンドシステムやサーバサイド開発など)について解説していきます。......押さえておきたい輻輳制御アルゴリズム連載一覧No12(2009.04)今回のSoulHackで主に取りあげるのは,梅田望夫の「ウェブ時代をゆく」という本です。No11(2009.03)今回のSoulHackで取りあげるのは,阿部謹也の「世間学への招待」と他1冊の本です。No10(2009.02)今回のSoulHackで取りあげるのは,山本七平の「空気の研究」という本です。No9(2009.01)今回のSoulHackで取りあげるのは,アーノルド・ミンデルの「紛争の心理学」という本です。No8(2008.12)今回のSoulHackで取りあげるのは,河合隼雄氏の「カウンセリングを語る」という本です。Ltd.ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。