<   2016年 02月 ( 5 )   > この月の画像一覧

同じモノか、違うモノか? - マテリアルの同一性問題をめぐって

前回、「E-BOM(設計部品表)とM-BOM(製造部品表)の関係を考える」 を書いた後で、この分野の専門家の方々と少しやりとりがあり、わたしのつかったBOMという言葉に分かりにくい点があったかな、と気づかされた。そこで今回は補遺として、用語を明確にすることからはじめたい。

一般に、『BOM』という言葉は、三つの意味を持っている。それは「BOMデータ」「BOMデータベース」「BOMソフトウェア」だ。同じ一つの問題の、三つの側面といってもいい。

BOMデータとは、部品表(業界によっては「材料表」)の内容そのものである。データというのは、数字や文字の規格化・定型化された並びのことである。BOMデータとは、マテリアルの数量的な関係を示した一覧表で、たとえそれが手書きでも、Excelの表の形でも、きちんと業務でハンドリング可能な形になっていたら、BOMデータと呼べる。ただし、誰かの頭の中にあるだけで、形式化されていない状態では、まだデータとはいえない。(なお、データと情報の違いについては『ITって、何?』の「質問2: ITを理解している人を見分けるにはどうしたらいいの?」 を参照のこと)

BOMデータベース」とは、コンピュータの中に形式化されて保存されているデータを指す。データベースは、ご承知の通りマスタ・データと履歴(トランザクション)データに、さらに区分することもできる。BOMデータベースは、その両者の形態があり得る。

BOMソフトウェア」とは、主に上記BOMデータベースを処理する情報システムのことだ。製造業ではBOMはいろいろな業務に関係するから(設計・購買・製造・保守・原価など)、いろいろな業務系システムがBOMソフトウェアとなり得る。とくに、BOMデータベースの維持管理を主目的としたソフトウェアをつくる場合、それは「BOMプロセッサ」と呼んで区別することにしている。

このサイトでは今後、上記の三つを、可能な限り区別して使うことにする。たとえば前回「どんな製造業でもBOMはある。ただし、BOMをきちんとマネジメントしている企業は少ない」と書いた。これは、より正確には、次の意味である:
どんな製造業にもBOMデータはある。だがBOMデータをマネジメントしている会社は少ない。

たとえば、製品を自前で製造している会社なら、ふつうは必ずP-BOM(購買部品表)データをもっている。これがなければ部品材料を仕入れられないからだ。もしもその会社が、よくセットメーカーにあるように、部品は全て外部から購入し自社では最終組立・検査のみを行う業態の場合、
 P-BOMデータ=M-BOMデータ
でもある。自社内で加工・製造を行う業態の場合、工程ごとに展開されたM-BOMデータをもっているはずである。そうでなければ、各工程に製造指図書(製造オーダー)を発行できないからだ。ただし、その企業が構造型の「BOMデータベース」を持っているかどうかは不明だが。

また、設計機能のある会社なら、必ずE-BOMデータはある。それは組立図面の上のたんなる表かもしれないが、データではある。

(小うるさいことを書くようだが、念のために注釈。製造業の裾野は非常に幅広い。製品を自前で生産しないメーカーというのも存在する。製造を全て外部委託している会社だ。具体的には、一部の電子機械メーカー、開発型医薬品メーカー、そして多くのアパレルメーカーなど。出版社もこれに近い。また、自社で設計をしない製造業は、中小下請け部品メーカーに非常に多い。それから、化学・食品産業などではBOMという言葉はあまり使わず、「レシピ」概念がそのかわりにある。ただ、混乱を避けるため、わたしの話はデフォルトで「組立加工型・繰返し生産形態・生産管理中心」で書いている。日本ではそういう企業の裾野が一番広いからだ。読者諸賢は、ご自分の業種業態にあった形で翻案しながら、お読みいただきたい)

さて、BOMデータをきちんとマネージするためには、普通はBOMデータベースが必要だ。他方、上述のようにBOMソフトウェアは業務目的別に複数持つ場合もある。たとえば設計業務用ソフトと、生産管理用ソフトのように。もちろん両者が一つのソフトウェアで済むなら、それに越したことはない訳だが、現実にはなかなか難しい。そういう意味で、E-BOMソフトウェアとM-BOMソフトウェアが別々にあるケースは珍しくない。同一のBOMデータベースから、異なる表現形式としてE-BOMとM-BOMを取り出す例もあるだろうが、あるいは物理的に別々なDBかもしれない。

では、わたしが前回述べた、「E-BOMとM-BOMの乖離問題」とは何のことなのか? それは、データ内容の乖離の話である。設計部門と生産部門が維持・参照しているBOMデータの中身が、だんだんと食い違ってくる。それが社内で様々な問題を引き起こしているのである。たとえばユーザからクレームが入った。保守部門が対応すべくアクションを起こす。ところが調べてみると、設計図面とは別の部品が使われている。あるいは、工場内で部品の欠品が起きる。本社資材部門は正しく手配済みのはずだった。だが工場では当該部品とは別の部品を使用することが恒常化していた・・。こうした不便がいろいろと起こりうるのだ。

そしてBOMデータ内容の中心は、マテリアル・コードである。マテリアル・コードとは部品材料を特定するキー・コードのことで、会社によっては部品番号とか品目コードとよぶ場合もあるだろう。ある部品のマテリアル・コードは何か、その子部品のコードは何か、がBOMデータの中心部分である。BOMデータの乖離とは、同じ製品を構成するはずのマテリアル・コードが、設計部門と生産部門で次第に食い違っていく事態を意味する。甚だしい場合は、両者でまったく異なるコード体系をもっている。まあ、仮に異なるコード体系であっても、その間に1対1の対応関係があるなら、まだいい。その対応関係が次第にずれて1対NやN対Nになっていき、機械的な変換ができなくなるから、こまるのだ。

なぜそのような乖離が起きるのか? それは、異なる部門間で、ある品目が同一であるか、違うモノかで意見が異なってしまうからなのだ。

例を挙げよう。ここに、「岩手産の牛乳1ℓ瓶」と、「十勝産の牛乳2ℓパック」 があったとする。この両者は、同じモノなのか、違うモノなのか?

仮にあなたが、ある食品メーカーで、マテリアル・マスタの管理者だったとする。お好みなら、SAPのMMかなんかでもいい。そこにユーザから、上のような質問があった。どう判断するべきだろうか?

見た目に明らかに違う物品だから、別のコードで登録すべきだ、などと結論にジャンプしてはいけない。慎重なあなたは、ためしに、社内の関係者に質問してみることにした。

あなたの会社にはチーズ製造部門がある。そこの購買課に見解をたずねると、こう答えた。
「乳脂肪含有率が重要だ。産地が違えば区別が必要だ。いや、季節によっても品質は変動する」。
一方、あなたの会社はレストランもチェーン経営している。そこの仕入係の見解はこうだ:
「コップに注いでしまえば産地も容器も関係ない。要冷蔵かどうかだけが重要だ。」

片方は別のモノだと答え、もう一方は区別の必要はない、という。

二つのものが同一物かどうかは、会社によって違い、部署によっても違う。つまり、ものの見方によって違うのだ。そこには、第三者が客観的に決められる厳密な基準はない。では、『モノの見方』を規定するカギは何なのか?

こたえは単純だ。同一と見なせるかどうかは、「キーとなる属性」が同一かどうかで決まるのだ。キーとなる属性とは、業務上の要求仕様のことであり、マテリアルの使用目的によって決まる。チーズ製造部門にとってキーとなるのは乳脂肪含有率であり、レストランにとっては保管方法だった。だから、使用する企業・部署ごとに見方は変わるのである。どちらが正しい、どちらが間違っている、ではない。ただし、企業として統一したマスタを持つのなら、そこには基準が必要だ。そして、それは区分がむやみに増殖しないような基準であってほしい。

たとえば、「設計上は同じ仕様だが、サプライヤーが異なる物品」はどう扱うべきか? もしも製造組立でまったく互換性がある場合は、両者は同一のモノである。 でも、価格や納期が異なるとしたら? その場合、サプライヤーに依存する属性は、品目マスタではなく、「購買情報マスタ」に登録するのが定石なのだ( 「購買情報マスタ」は、マテリアル・コードと取引先コードを複合キーとするマスタである)。

あるいは、「設計上は同じ仕様だが、荷姿や入り数や保管方法が異なる物品」は?  その場合、物流側の情報システムで、SKU(Stock Keeping Unit)として区別するのが定石だ。

そのような形の工夫を重ねることで、マテリアル・マスタの品目数がずるずると膨張し、類似したデータが増えて1対N風の状態になることを防ぐことこそ、BOMデータをマネジメントする際の要諦なのである。

わたしの接してきた経験では、残念ながら多くの企業が、このような判断基準を社内的に確立していない。そもそも購買情報マスタだとかSKUだとかいうことさえ、理解されていない。こうした事情の背景には、部門同士の距離感があるのだろうと感じる。各部門がサイロのようになって、部門単位で最適化された業務フローを持ち、それに応じて情報システムを作ってしまう。結果として、本社設計部門の管理する部品マスタと、工場の製造部門のつかう品目マスタの対応関係が、乖離してくるのである。これを称して、E-BOMデータとM-BOMデータの乖離という。

これを防ぐためにはどうしたらよいか? 原因が単純である以上、解決法も単純だ。社内の複数部門を横断する「マテリアル・マネジメントのためのコミッティー」を形成し、そこで基本指針を定め、各種情報システムの要件にも口をはさむ。個別の事案の判定は、実務担当チームを任命してあたらせる。このようにすべきだろう。

拙著「BOM/部品表入門」では、社内の10以上の部門が横断的に集まるBOM検討ワークショップによばれた、外部アドバイザーの矢口先生が、各部門の担当者に順番に質問を発していくという形式で書いた。それは、上に述べたような問題意識があったからだ。マテリアル・マネジメントは、非常に多くの部門にまたがる課題である。だから、部門の垣根を越えて話し合う仕組みがどうしても必要なのだ。

単純だ。だが、難しい。単純なことほど実現の難しいのが、会社というものだろう。そしてそのために、マネジメントという機能が存在するのである。


<関連エントリ>
 →「E-BOM(設計部品表)とM-BOM(製造部品表)の関係を考える」(2016-02-21)
 →「『ITって、何?』質問2: ITを理解している人を見分けるにはどうしたらいいの?」 (2010-10-07)
by Tomoichi_Sato | 2016-02-28 15:56 | サプライチェーン | Comments(1)

お知らせ: 東工大ストラテジックSCMコースで講演します(3月6日)

直前のお知らせになり恐縮ですが、来る3月6日(日)午後2時から、東京工業大学で

 「海外プロジェクト・マネジメントへのシステムズ・アプローチ − その理論と技法」

と題して講演します(無料・事前登録必要)。
これは東工大イノベーションマネジメント学科が主催する、キャリアアップMOT(技術経営)コースの「サプライチェーン戦略スクール・ストラテジックSCM講座」今期(第12期)修了発表会での事例講演です。
(→詳しい案内) http://www.mot.titech.ac.jp/cumot/sss/scm/

開催場所は、東京工業大学 大岡山キャンパス 西9号館2階 デジタル多目的ホールです。
 東京都目黒区大岡山2-12-1(東急目っっっっf黒線大岡山駅前)

本講演では、10月に出版した『世界を動かすプロジェクトマネジメントの教科書 〜グローバルなチャレンジを成功させるOSの作り方』の内容とも連動し、以下のような内容をお話しする予定です:

「現代のプロジェクト・マネジメント理論は、1950年代のクリティカル・パス法に始まる。それはプロジェクトを、Activityからなる『システム』と捉えたアプローチの産物であった。本講演では、なぜ海外プロジェクトではシステムズ・アプローチが特に重要になるかを類型論から分析し、現代PM理論の中心技法を概観する。その上で、日本企業が準備すべき組織体勢・行動習慣を解説するとともに、プロジェクト評価に関する最新の研究について紹介する。」

日曜日の開催ですが、ご興味のある大勢の方のご来聴をお待ちしております。


日揮(株) 佐藤知一
by Tomoichi_Sato | 2016-02-24 12:29 | プロジェクト・マネジメント | Comments(0)

E-BOM(設計部品表)とM-BOM(製造部品表)の関係を考える

拙著「BOM/部品表入門」(日本能率協会マネジメントセンター・刊)が、再び増刷になった。おかげさまで、累計8,900部である。本書は2005年1月の発刊だから、11年間にわたり現役のビジネス書ということになる。読者の皆様にあらためて感謝もうしあげたい。

ところで、この11年間、BOMをめぐる状況は変わったのだろうか?

正直に言うと、あまり大きくは進展していない印象である。相変わらず、いまだに多くの企業がBOMについて悩んでいる。いや、むしろ悩みは深まっているとさえ、いえよう。海外生産の進行やアジア市場への販売展開などで、サプライチェーンが海外まで確実に広がった。しかし、その現実にBOMの方がついていけていない。むしろBOMが、生産のグローバル展開の足かせにさえなっているようだ。

それだけではない。どうやら、BOMに関する基本的な認識さえ、まだあまり進んでいない気がする。たとえば、“ウチの会社にはまだ「BOM」がありません”、などと、かなりの大企業でも口にする。

BOMはBill of Material、すなわち部品表である。部品表のない製造業など、存在し得ない。部品表がなければ材料を調達できない。どうやって材料なしで製造するのか? 部品表がなければ材料費も計算できない。どうやって販売価格を見積もるのか?(個人営業の飲食店や職人の工房ならいざしらず)

こうした発言をきくと、世の中では、BOMを何か特殊なデータベースみたいなものだと、誤解しているらしい。BOMは製造業の中核データである。どんな製造業でもBOMはある。ただし、BOMをきちんとマネジメントしている企業は少ない。だから小著が11年間も現役で読まれ続けているのだろう。

かつてこのサイトで、「生産革新のためのBOM(部品表)再構築入門(2)」として、<設計部品表(E-BOM)と製造部品表(M-BOM)の乖離>問題をとりあげた。今回は、このテーマについて再度論じてみようと思う。これもひどく誤解の多いテーマだと感じるからだ。

乖離どころか、世の中には、「会社はE-BOMとM-BOMを二つ持つ必要がある」と信じ込んでいる人たちまでいる。「ウチの会社はいまM-BOMしかなくて、これからE-BOMを作らなくちゃなりません。」などとおっしゃる。冗談抜きで、きいて思わず頭がクラクラしてしまった。BOMが一つで済むなら、それで十分なのに。

上の記事では、設計部品表(E-BOM)と製造部品表(M-BOM)の乖離が生じる理由として、
(1)品目コードの不統一
(2)代替部品の使用
(3)副資材や包装材料の追加
(4)設計変更の発生と在庫切替タイミングの食い違い
の4つをあげた。このE-BOM, M-BOMの分断の背景には、設計部門(本社)と製造部門(工場)の組織的乖離が遠因にある。

もともと現代的なBOM概念、つまりストラクチャー(構造型)BOMの概念は1960年代にあらわれた。この概念はMRPという生産管理手法と一緒に確立された。つまり製造を強く意識したもの、今でいうM-BOMに相当するものである。

ではE-BOMの原型は、というと、機械組立図における材料表にさかのぼる。組立図には部品それぞれに引き出し線と、丸で囲った①②などの数字(俗に「風船」とよばれる)がついており、かつその図面の端っこに表が書いてあって、そこに①の品名と数量、②の品名と数量・・が並んでいる、あれである。製品を最終的に組み立てるにあたって、必要な部品の種類と名前と数量、位置を記した表だ。昔はB/Mと表記されることが多かった(今でもエンジ業界はB/Mとよんでいる)。これは親と子が一階層だけの、フラットなサマリー型が普通だ。

さて。会社組織では、誰が(どの部署が)BOMを登録、維持するのか? という問いが、しばしばついて回る。たとえば今、図のような製品があったとしよう。
(1) 製品SはアッシーXと部品A, Bとからなり
(2) アッシーXはサブアッシーYと部品Cからなる
(3) 部品Bは材料dを切削、研磨し表面加工したものである

e0058447_17582896.jpg

          <BOM(M-BOM)の全体像>

当然だれかが、製品S→アッシーX、アッシーX→サブアッシーY、部品B→材料d、という紐づけをBOMマスタに登録していかなければならない。なお、「アッシー」というのはAssemblyの略で、途中まで組み上がったアセンブリー(モジュール)のことを指す。

ところで当たり前だが、製造業では製品開発→量産準備→生産、という順序で仕事が進む。製品、アッシー、子部品は設計部門が図面を書く。製品やアッシーの組立図面には、品番の親子関係の表がついているだろう。つまりE-BOMが先に生まれる。製品S→アッシーX、アッシーX→サブアッシーY、はそれぞれ製品S・アッシーXの組立図に付随した「E-BOM」情報である。

別の言い方をすると、BOMの親子関係のうち、上位の階層は設計部門が定義する訳だ。

しかし、たとえば購入部品(汎用部品やボルト・ナット等)や、材料(たとえば丸棒)などは通常、図面は書かない。つまり、E-BOMの親子関係は途中で途切れてしまう。その先、外部購入品までの親子関係を定義するのは、工程設計を担当する部門(普通は生産技術)の仕事だろう。つまり、E-BOMは製造側の技術部門によって展開され、肉付けされることで、M-BOMとして完成するのだ。
e0058447_1805874.jpg


ところで、たとえば上記の例で材料dから部品Bまでは、切削→研磨→表面加工と複数の工程が必要だったとしよう。では、その間の中間状態の部品はすべてBOMに登録すべきなのか? 切削後段階の部品d'、切削研磨後の段階の部品D、そして切削・研磨・表面加工後の部品B、という風に。

答えはNOだ。

じつは、BOMに登録すべき品目には原則があるのだ。BOMに(いいかえればマテリアル・マスタに)登録するすべき品目とは、在庫管理の対象となるマテリアルである。

もしも、切削→研磨→表面加工がつねに一貫した工程なら、途中段階の品目登録は不要である。途中段階の品目は一時的に出現しても、すぐに次工程に消費されてしまうからだ。だが、材料dを切削→研磨した後、用途別にいろいろな表面加工で品種が別れたりする場合には、研磨後の中間部品Dをいったん保管したくなるだろう。ならば、中間部品DをBOMに登録するべきである。

こうした製造工程上の都合は、設計部門では分からないのが普通だ。だからBOMの定義も、生産技術や製造部門の判断になる。

業務系の情報システムでは、データの作成者がそのデータの登録者となり、オーナーシップをもって管理すべきだと一般に信じられている。この原則にしたがえば、BOMのマスタデータの登録作業は、複数部門によって分担されることになる。もっとも、情報源(作成者)と、マスタへの登録者を誰にすべきかは別問題という考え方もある。だから設計部門からのデータを生産技術部門が受けて、BOM全体の登録は生産技術がまとめて担当する、という取り決めだって可能ではある。

ただし、ここに一つの問題が生じる。多くの企業では、製品開発・設計部門が本社にあり、生産技術・製造部門が工場に所属する。場所が離れているのだ。両者は、別々の情報システムを使っていることが多い。サーバもデータベースも、物理的に別である。

こういうケースではどうしたらいいのか? E-BOMとM-BOMは統合不可能なのか?

答えは、単純だ。システムは物理的に別々でも良い。しかし、同じマテリアルは同じコードでよばれなければいけない。これが「BOM統合の原則」である。本社と工場が、同じモノを別々のコードでよんだり、モノの同一性について意見が分かれたりする状態があってはいけない。同じマテリアルの親も、同一でなければならない(そうでなければ構成管理の一貫性が崩れてしまう)。

このような形で、複数のシステム間のマスタデータ整合性が担保されているなら、BOMは統合されているといっていい。少なくとも、E-BOMとM-BOMの乖離問題は起きていない。

ちなみに設計用CADシステムの発達により、図面管理や構成管理など、設計用ツールにはPDM(Product Data Management)的機能が増えている。設計部門はその中で、「E-BOM」を管理維持したいと考えるだろう。部品共通化や設計情報の再利用などをはかりたい、とも望むだろう。それは当然である。しかし、E-BOMに登録される品目コードは全社共通のものを使うべし、が原則だ。

ただし、この話を推し進めていくと、異なる部門間で、モノの同一性について意見がくい違い、論争が生じるケースが出てくる。設計部門は、「これは内径X、外径Yの○○部品じゃないか」といい、製造部門は「いや、同じ形状の○○部品といっても、材質強度的に区別が必要なものが2種類あるんですよ」とか「仕入れ先が3社あって区別したいんです」とかいう要望が出てくる。この種の論争をどう解決するかが、じつはBOM統合にとって大切なのだ。だが、ちょっと長くなりすぎたので、この問題は項を改めて論じよう。


<関連エントリ>
 →「生産革新のためのBOM(部品表)再構築入門(2)」(2013-11-10)
by Tomoichi_Sato | 2016-02-21 18:12 | サプライチェーン | Comments(0)

Introduction to the basic of scheduling, and DRAG as the metrics for project delays

Why do our time schedules always become longer? In order to make the final delivery date earlier, which part of the schedule should we tackle ? - These are common questions we face in the schedule planning.

There are some basic principles in the scheduling we'd better learn. Plus, there is a metrics that tells us specifically which part to tackle for shorter schedule. Let me explain in this article.

Suppose we have to deliver a system product. This work is comprised of just six (6) activities to be done.

1. Basic design (estimated duration = 20 days)
2.1 Hardware purchase (estimated duration = 35 days)
- preceding activity: Basic design
2.2 Hardware Installation (estimated duration = 5 days)
- preceding activity: Hardware purchase
3.1 Detail design (estimated duration = 10 days)
- preceding activity: Basic design
3.2 Software development (estimated duration = 20 days)
- preceding activity: Detail design
4. System test (estimated duration = 15 days)
- preceding activity: H/W Installation, S/W development

Now, how many days will it take to accomplish this work? It may help us to create a network chart that depicts activities and their relationships. There are a few styles to draw such network diagrams. We here choose the Precedence Diagram which uses boxes for activities and arrows for preceding relations.

(Fig. 1 Precedence diagram of the activity network)
e0058447_23443368.jpg


Within each box we write down activity name in the center and necessary duration at the bottom. There are also four small spaces in each box at top-left, bottom-left, top-right and bottom-right. We have to fill in following dates.

top-left: Early Start (ES)
top-right: Early Finish (EF)
bottom-left: Latest Start (LS)
bottom-right: Latest Finish (LF)

These four dates represents “earliest possible start date”, “earliest possible finish date”, “latest possible start date” and “latest possible finish date”. Please remember these terms as they are the four basic parameters used in the scheduling.

If you are smart enough, you may be able to calculate the entire duration after looking at the Fig. 1 just for a few seconds. However, I would like to explain calculation procedure step by step here. Even for very smart persons, it would be not easy to calculate duration of a network containing 100 or more activities.

We start with the first activity “Basic design”. Its ES (earliest start date) is the day 0. Its EF (earliest finish date) is day 20. Then, ES of the following activity “Hardware purchase” should be day 20. And its EF = 20 + 35 = 55. In this manner, we calculate ES and EF of all the activities in the order of precedence. This procedure is called “Forward scheduling”.

By the way, the last activity “System test” has two preceding activities: H/W Installation and S/W development. They have different EF dates (60 and 50). Then which number should we take as the ES value of “System test”? — Needless to say, the system testing cannot start unless the both preceding activities finish. Therefore, we have to take the later date (greater value) of EF as the ES of the next activity. In this case, it is 60.

Rule 1: If there are more than one preceding activities, their largest (latest) ES date becomes ES date of the following activity.

Here we can fill out ES and EF of all the activities. Please see Fig. 2. It tells us that System test will complete in day 75 at earliest. This is the delivery date of this work. However, we have to go on further.

(Fig. 2 Earliest start and earliest finish dates)
e0058447_2349663.jpg


Next, we calculate the LF (latest finish) and LS (latest start) date of the final activity, System test. Its LS date is 75. Subtracting the activity duration from EF date gives ES date (75 - 15 = 60). This number should be LF dates for the two preceding activities, H/W Installation and S/W development. In this manner, we can fill in LF and LS of all the activities. It is called “Backward Scheduling”.

Basic design activity has two following activities; H/W purchase and Detail design. LS of H/W purchase is day 20, and LS of Detail design is day 30. This case means H/W purchase has to start at latest on day 20. Therefore, Basic design should finish at latest day day 20.

Rule 2: If there are more than one following activities, their least (earliest) LS date becomes LF date of the preceding activity.

Now, four spaces of all the boxes are filled in. So, let’s pick up activities whose ES equals to LS. It means its earliest possible start date is exactly the date it should start at latest. We call an array of such activities as “Critical Path”. In Fig. 3, the critical path is marked in red.

(Fig. 3 Schedule dates and the critical path)
e0058447_2350514.jpg


If ES is less than LS for an activity, it means that the activity have a certain slack in starting date. For instance, Detail design is possible to start on day 20, but it is okay to start even on day 30. This slack is called “Float” in the scheduling theory.

Rule 3: Difference between LS and ES shows schedule float of the activity starting date.

Critical path is a series of those activities whose float days equal to 0. Furthermore, duration of the entire work equals to the length of the critical path. Unless we can make the critical path shorter, we cannot deliver work earlier. In other words, even if we work harder to attain shorter duration of an activity with positive float days, such effort does not contribute to earlier delivery date at all. Therefore, managers has to recognize there the critical path resides and concentrate his/her control efforts to it.

The most unique characteristic of schedule control is the fact that there is a clear distinction between “important” and “non-important” activity. This is quite a different situation from the cost control. Cost control is based on the logic of addition. When we can save $1 for an activity, total cost would be saved by $1. In the schedule control, however, making shorter duration for an activity with positive float does not contribute to earlier delivery of the work.


Up to this point is a basic explanation of the critical path method (CPM). Now, we face a question about the "important activity” - how much is it important? A metrics called DRAG is needed to answer this question.

DRAG is a measurement that shows how many days an activity pushes down the entire delivery date. For instance, DRAG of an activity is zero if that activity has float. In the above example, DRAG = 0 for Detail design and S/W development. On the other hand, for an activity on the critical path that has no parallel activity (like Basic design and System test), its duration becomes DRAG value. This is because existence of such an activity pushes down the final delivery date by its duration. Clearly, the shorter the activity’s duration becomes, the earlier the final delivery date comes.

Some consideration is needed for an activity that is on the critical path but has parallel activities running with. H/W purchase and Installation are these kinds. There is a parallel path: Detail design and S/W development, which has 10 days float. If we shorten H/W purchase by 5 days, then final delivery date becomes 5 days earlier. If we shorten by 10 days, delivery date is 10 days earlier, respectively. However, if we shorten H/W purchase by more than 11 days, then the other path becomes now a new critical path and no effects on final delivery date any more. 10 days are the limit. Therefore, DRAG of H/W purchase is 10 days.

H/W installation has only 5 days duration. It is shorter than float of the parallel path, 10 days. Thus, if we can shorten its duration by 1 to 5 days, then delivery date becomes earlier by the same days. DRAG = 5 days for H/W installation.

Let me summarize the rule with DRAG.
(1) For activities with float days: DRAG = 0
(2) For activities on the critical path with no parallel activities running: DRAG = duration of the activity
(3) For activities on the critical path with parallel activities running: DRAG = float of the parallel activity
(4) Nevetheless, in case its duration is shorter than the parallel activity’s float: DRAG = duration of the activity

Fig. 4 shows this results.

(Fig. 4 DRAG values)
e0058447_23543164.jpg

Is there any benefit if we know DRAG values? Yes, there is. DRAG indicates how many days the activity pushes down the final delivery date. If you wish to attain earlier delivery date, then you should tackle activities with larger DRG values. Priority is very clear.

DRAG value also measures how the entire work is out of parallelism. If you would like to make the entire schedule shorter, then you had better break down your work into pieces that can be run in parallel. This parallelism principle applies to any kinds of work, even applicable to construction of pyramid or calculation process in the computer. DRAG clearly shows which activity is out of parallelism.

The above example is made up of only 6 activities, so you may easily find out which one to tackle without computation of DRAG. However, you cannot do it easily with 60 or 600 activities. (As to my business field, engineering projects, 600 activities are not a big number)

Of course, there are certain limitations for the critical path method or DRAG. You can criticize that, say, they are no more than static analyses, or, it is difficult to estimate activity duration precisely by one value, or no resource constraints are considered. But here is one point to keep in our mind. The scheduling is a practice to build approximation models based on various assumptions. Modeling always accompanies with simplification. Still, simplification enables us to see structure of time schedule. “Models are all wrong, but they are useful.” Simple tools are powerful as far as we are know its usage in a simple manner. Scheduling is the same. What matters is how and when to use models and methods.

DRAG metrics was first developed and proposed by Steven Devaux in his textbook “Total Project Control: A Practitioner's Guide to Managing Projects as Investments, ” (1999, 2nd Edition 2015). It will be more useful when applied together with costs. However, this article is already long. So, I would like to write it in next occasion.
by Tomoichi_Sato | 2016-02-13 23:56 | English articles | Comments(0)

書評:「アプリ開発チームのためのプロジェクトマネジメント」 稲山文孝・著

アプリ開発チームのためのプロジェクトマネジメント ~チーム駆動開発でいこう!~」 稲山文孝・著
(Amazon.com)

なかなか面白い本である。著者の稲山文孝氏は大手SIerの(株)エクサで、プロジェクト監査・推進部門におられるベテランで、わたしが主査を務める「プロジェクト&プログラム・アナリシス研究部会」にもしばしば顔を出される。PM手法の展開と普及に熱心な方で、だからIT業界向けに本書を執筆されたのだろう。

世の書店にはPM関係書はすでにかなり充棟しており、拙著「世界を動かすプロジェクトマネジメントの教科書」もその末席につらなっている訳だ。だが、その多くは米国発「グローバル標準」であるPMBOK GuideⓇの解説を中心にしている。

一方、PM本の主要な読者層はIT業界人であり、PM関連団体・学会のイベントなどに行ってもたいてい参加者の8割方はIT業界だ。だが、日本のIT業界人、とくにSIerの求めるものと、米国PMBOK Guideが与える記述との間にはギャップがありすぎて、正直戸惑っている人も少なくないと思う。本書は、そのギャップを埋めようとする数少ない本の一つだろう。

本書はストーリー的な構成になっている。元々、プロジェクト・マネジメントはフェーズが進むごとに違う道具立てが必要なので、小説的な構成に向く。おまけに、図表だけでなくイラストが多い。イラストは、かわいいキャラ(全員女性)である。ちょっとラノベ風テイストともいえる。こういう本は、わたしにはとてもかけない。すごいなあ。

登場人物は4人。主人公は「ボク」こと、新入社員のシンコちゃんである。彼女を含むプロジェクト・チームは3人(他にインフラ関係のチームがパートタイムで支援することになっているが、本には登場しない)。まず、プロマネのレダさん。レダといえばギリシャ神話に登場する美女なので、後で双子の卵でも産むのか、と思ったのだがそうでもない(笑)。どうやら「リーダー」なのでレダさんという名前らしい。

もう一人は技術リーダのアキさんで、こちらの名前はアーキテクトだからアキさんなのだろう。ということは、主人公は新人の子だからシンコなのかな(登場人物の名前というのは、意外と書き手にとって悩ましいものなのである)。そして4人目は、プロジェクトを後見人ふうに見守る、優しい「先生」。先生というのは、社内研修の講師やレビューアーを務めるからで、まあPMOのメンバーとも思われる。

取り組むプロジェクトの設定は、流通業向けWeb開発である。それも、ウォーターフォールではなくアジャイル風だ。ソフト開発だけで、ハード構築は入らない(らしい)。契約形態は準委任。期間は6ヶ月間で、2ヶ月単位のイテレーションを3回、まわす計画である。

本書の解説の最大の長所は、プロジェクトを回していくために必要な知識を、4つの知識層に区分していることだ。4つとは以下の通りである(p.107):

(1) マインドセット層
・運営ルール、朝会、対人関係能力、概念化能力など
(2) ツール&テクニック層
・チケットシステム、カンバン、構成管理ツール、開発環境
・テスト実行ツール、エビデンス整理ツールなど
(3) システム開発手法層
・ウォーターフォール/反復/(アジャイル)スクラム/XP
(4) プロジェクトマネジメント管理層
・プロジェクト計画書、各種管理要領
・PMBOK/PRINE2/P2M

ちなみに、わたしがこのサイトで使ってきた区分では、プロマネの仕事の領域は下記のようになる:
A 「固有技術」の領域
- これは、ソフト開発では、ソフトウェア工学に相当する。プラント分野では化学工学とか機械工学、建設プロジェクトなら建築学や土木工学など。
B 「管理技術」の領域
(管理技術は、さらに二種類に区分できる)
- ハード・スキルとしての「マネジメント・テクノロジー」(WBS, CPM, EVMSなど)
- ソフト・スキルとしての「OS」層 (計画重視、言葉を大切に、契約責任制など)
両者の対応関係を整理してみると図のようになる。用語や概念は異なるが、マッピング可能になっている。
e0058447_14393449.jpg

従来のIT分野のPM論の問題は、この4つの層がごっちゃに議論されがちだったことにあったのではないか。つまりアジャイルかウォーターフォールか、チケットシステムやカンバンは有効か、朝会は是か非か、プロジェクト計画書づくりに意味はあるのか、等々。これらは(互いに関係はあるが)別のレイヤーに属することだ。とくに、開発方法論はソフトウェア工学に直結している。

そして、どの開発方法をとるかによって、プロマネが重視すべきPM技法の組み合わせが変わってくる。だが、だからといって、プロジェクト・マネジメントが独立した技術領域をもっていることにかわりはない。

逆にPMBOK Guideの様な標準書は、汎用性を重んじるため、固有技術の領域には立ち入らない。しかし、それはプロジェクトマネジメント計画書が固有技術にふれなくてもいい、という意味ではない。逆である。プロジェクトの基本的な手順は、どのような固有技術を適用するかに依存している。橋の建設プロジェクトは、橋梁の工法に依存している。当たり前の話だ。固有技術と管理技術は車の両輪なのである。

ところで、本書のサブタイトルは「チーム駆動開発」である。最初わたしは、「計画駆動開発」への反語なのかと思った。だが著者によると、従来型の「指示と統制」による開発プロジェクトと対比したい、という意図だとのことである。つまり、オーケストラ型ではなくジャズバンド型を目指そう、とのメッセージが込められているのだろう。

もっとも、これはチームの人数にもよると思う。チームがたった3人なら、PMの目がすみずみまで届くし、互いに意見も言いやすい。しかしこれが300人だと、PM一人では見切れない。その結果、中間管理層が増えて、上意下達的になりがちだ。PMBOKはどうしても米国のトップダウン文化を反映して上意下達的だが、規模の大小を無視して、同じプロジェクト・マネジメント手法を使ってはいけないと、わたしは考えている。

本書では、プロジェクトチームの目標と、メンバー個人ごとの目標を立てているのもとても良い。ちなみにシンコちゃんの目標は、「自立した一人前のエンジニアになること」だ。そして、半年後には『高い目標だった』と肯定的にふりかえっているところを見ると、随分と潜在能力の高い新人なのだろう(笑)。

この種の本を書いた者の立場から見て、ストーリー作者が迷ましいのは、「どこまでプロジェクトにトラブルを起こすべきか」である。トラブルは読者を引きつけるサスペンス要素の源だ。プロジェクトがあまり平坦だと、読者はあきてしまう。しかし、問題が大きすぎると、解決方法がウルトラC的になり、リアリティが減ってしまう。おまけに書き手には、自分の登場人物は、あまりひどい目には遭わせたくない、という心理が働く(プロの作家は別かもしれないが)。難しい点である。本書ではプロジェクトは「ある意味異常な」くらい(p.211)うまく進んでいく。ここは著者の優しさなのかもしれない。

本書は文中で引用されている参考図書が多く、非常に幅広い点にも感服した。たとえば、「学習スタイルには、分析型、行動型、そして観察型の三つのタイプがある」という、Marcus Backinghamによる説(p.138-139)。これによると、
- 分析型は事前の学習時間を十分とる
- 行動型は早く未経験の環境に置く
- 観察型は手本になるベテランの傍らで仕事を俯瞰的に見ながら模倣させる
が適切らしい。

また、ふりかえりを、プロジェクト進行中の要所要所でも、また完了時にも行っている点もすばらしい。これは受注型ビジネスではおろそかにされがちだからである。とくに、「ふりかえりはプロジェクトの物事に対して行い、人に対してはしない」(p.213)という注意点も的確だ。ふりかえりには、KPT(ケプト)というチャートで表現する方法を書いている。KPTとは、Keep. Problem, Tryの頭文字で、この三つに分類してまとめるのである。

なお、本書ではアジャイル風開発のプロセスと、それに特有なマネジメント手法を学ぶことができると期待したが、それほどは感じられなかった。

最後に、本書を読んで感じた疑問点を、二つだけあげておきたい。

第一の点は、「プロジェクトマネジメント管理」という用語である。マネジメントと管理では、言葉が重なっていないだろうか? なんだか個人的にはしっくりこない点であった。

二番目の疑問は、準委任契約なのに、PMのレダさんはなぜ一括請負風のコスト管理やスケジュール管理をしているのか? であった。準委任契約とは、レストランで、コースはでなくアラカルトで食べるようなものだ。総コストが予算内に入るかどうかは、発注側が責任を持つのが原則ではないか。

この点について著者にたずねたところ、
「アジャイル開発ではプロジェクトの中で開発テーマを決めて、ワークロード内で優先順位の高い機能を実装します。このとき、テーマは予算内で収まるように委託元と委託先で合意しながら選択していくので、(発注側と受注側の)双方でコスト管理をしていると言えます」
とのことであった。

ともあれ、IT分野でのプロジェクト・マネジメント入門書としては、とても親切で分かりやすい本だと思う。初学者のSEの皆さんにおすすめしたい。
by Tomoichi_Sato | 2016-02-07 14:43 | 書評 | Comments(2)