2015年1月16日 (金)

PM学会 ISO報告会 ガバナンスなどの動向

今日は、プロジェクトマネジメント学会の「2015年新春PMセミナー・ISO報告会」へ。

http://spm-hq.jp/event/detail.php?id=106

ISO 21500関連の動向。PM学会が審議団体を務めるISO TC258での、ポートフォリオマネジメント、プログラムマネジメント、
そしてガバナンスの進捗状況などをTC258の各エキスパートから話があった。PMI系の話との対比では、ガバナンスが多少耳新しいかもしれない。(ヨーロッパでの規格では、それなりに言われていたことではあるが。)

多少他の会合で断片的に聞いていたこともあったが、整理してしゃべってもらってフムフム。やはり勉強になった。

ガバナンスでは、スタディレポートでの討議ポイントとしてガバナンスの対象範囲をどうするかで各国の意見の相違も話されて参考になった。

そしてセッション2では、「ガバナンス」を考えるとして登壇者でのディスカッション。こちらが今ひとつ。ITプロジェクトに関する各自の成功事例や世間での失敗事例の話が続いた。エンジ系の人もいてIT系との比較の話が参考にはなったものの、話の流れが成功/失敗。

終盤というか締めくくりで、登壇者の一人が、ガバナンスとマネジメントは違うだろうけどセッション2では...との話が出て、個人的に「うーん、ちと遅いな~」。セッション1で、ガバナンスとマネジメントの相違に関して話は出たのに。個人的には、セッション2の方向性は少し残念だったし、別の会合などで意見聞こうかなとの思い。

逆に、ガバナンスってまだまだかな~とか、個人的にプロジェクトに結びつけるよりも企業経営の枠組で考える方が良いのにとの思いが強まった。もちろん、規格としては多少は抑えておくけど。


なお、近くに座った人。途中から来るし、せわしなく体動かしたり、パソコン操作でネットサーフィンみたいな感じだし、、、。体動かすのも横柄というかふんぞり返るのに近い、、、。終盤には途中退席。ちなみにPDUは会の終了後に渡すとなってたけど、不要だったんだろうか。あるいはごり押しで入手? ノートパソコンは富士通製だったけど、なんか前のPM学会でも富士通パソコン持った似たような人を目にした気がする。うーーん。


AmazonでのISO 21500書籍(洋書)


Amazonでの書籍「ISO」

    

1月 16, 2015 プロジェクトマネジメント, プロジェクト管理 | | コメント (1) | トラックバック (0)

2014年10月19日 (日)

ITプロジェクト成功率 30%→75%にアップ?

日経コンピュータ2014年10月16日号を読んでいて目に飛び込んできたのが、”高い成功率も油断は禁物”、”プロジェクト成功率は75%”。の文字。特集「3069人調査で迫る 情報システムのリアル」での、タイトルや見出しだ。

以前の日経コンピュータでは、成功率が30%程度だった。2008年12月1日号と2003年11月17日号での記事で、それぞれ31.1%と26.7%。以前”日経のプロジェクト成功率”としてブログに書いている。

つまり、ここ数年で成功率が30%→75%にアップしている。喜ばしい事だ。(ただし内心では、以前のブログの行間で述べたつもりだけど、数年前などでは回答側も分析側も失敗の方にバイアスがかかっていた気もする。)

数年前などでの日経の調査は、第1回と第2回の「プロジェクト実態調査」と題するものだった。5年ごとで、次は2013年と気にかけていたが雑誌には掲載されてない。なので今回の10月16日号が、それに代わるものと考えて良いだろう。ちなみにサンプルは全く同じかは不明だが、有効回答数は、2003年が1746、2008年が814、そして今回の2014年が3069なので、回答数自体は増えている。

個人的には、今回の方が実態と合致しているように思える。なお、工程での失敗率の分析や商習慣に対する回答、アジャイル導入比率などの分析も行われていて、参考になると思う。一読をお勧め。


ちなみに日経コンピュータ2014年10月16日号の目次ページは以下、
http://ec.nikkeibp.co.jp/item/backno/NC0871.html

日経コンピュータ2008年12月1日号の目次ページは以下である。
http://ec.nikkeibp.co.jp/item/backno/NC0718.html

10月 19, 2014 ソフトウェア, プロジェクトマネジメント, プロジェクト管理, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2014年8月 9日 (土)

マルスを振り返る

ここでのマルスは、国鉄時代の予約システム。MARS。

Facebookで知り合いが、急に昔の予約システムの”ピン”のことを述べたので、それはマルスだろうと2,3のURLをコメントした。

で、ふと、手元にマルスのことを書かれた本があったので読み直してみた。

マルス(正確にはその中での105というシステム)の開発プロジェクトで中心的な役割を担った名内氏の著作。

補論として31ページに渡って、マルス105プロジェクトのことが述べられている。

ちなみに名内氏は、その後日立製作所→日立システムアンドサービス(現:日立ソリューションズ)取締役社長に就任され、顧問を経て平成17年退任。


"業務機能仕様書"なるものが国鉄(発注側)から提出され、曖昧な所を日立側が指摘したそうだ。本には「システム稼動後、『こっちは客ではないか。なんで業者の担当からこき使われるかと思った』と懐かしげに話していただけたが、多分その時点では腹も立てられ、戸惑われたことと思うし、申し訳なかったと思う。」と記してある。

”線仕様”という言葉を用いているが、”**の時にどうする”は点仕様で、”**でない、@@の時”、”**でない、%%の時”のように非該当(非正常)の時の挙動を述べていくのを線仕様と称して、その記述を掘り下げたいったそうだ。(用語化してることや、その用語がなんかすんなり受け止められて、改めて驚いた。)

なお読み直して少し新鮮に感じたのは、スパイラル方式の方が優れていると言われているけど、一括請負などでは仕様を決めドキュメントを固めてから開発に入る方がよいとの記載。スパイラル方式→アジャイル方式と、置き換えて考えてみるのは良い事と思う。


一部は「国鉄との共同責任」という契約にしたそうだ。請負契約でもなければ、、、、。なるほど!と、ちょっと感心。ちなみに国鉄との共同責任という契約は、これっきりだそうだ。(逆に言えば、他のユーザーとはこのような契約もあったということ。) 

よくアジャイルなどで契約のことが話題になったりするけど、話題になるだけど、どう解決するとか前に進まない場合が多い。大昔に既にそんなことを解決してるのだから、現代人も自分たちで解決すればすむだろうにと思ってしまう。

あと”下ごしらえ”という言葉が登場する。結合テスト前に結合テストの項目が準備済み、そんな話。今だと、当たり前と思う人とそうでない人、後者の人がいるから厄介だ。なお、こっちの”下ごしらえ”という言葉もなかなか良い。

ほかに、ログのテストでの利用や「疎通」で喜ぶんじゃなくて「完通」で喜びなさいなど、実際実行してることが多いだろうが、確認する意味で役立つことがポツリポツリある。


ちなみに、日立ソリューションズのサイトに名内氏の特集ページがある。結構たくさんの種類の情報が掲載されている。(ただし、全部の回の閲覧のためには会員登録が必要。)
 http://www.hitachi-solutions.co.jp/psw/feature_list/nauchi.html


マルスは結構以前のシステムだし、その開発は文献やテレビ(特にプロジェクトX)に取り上げられている。温故知新で、他を含めて昔のプロジェクトを勉強してみるも悪くないと考える。なんか昨今は、プロジェクトは失敗するとのマスコミ記事を鵜呑みにしすぎてて、色んな過去の創意工夫を封じ込めてるような気がしてならない。マルスを振り返って、ふとそんなことを思った。

8月 9, 2014 プロジェクトマネジメント, プロジェクト管理, 書籍・雑誌, 電車 | | コメント (0) | トラックバック (0)

2014年7月20日 (日)

ゴジラ映画 製作プロジェク

昨日はついでもあって、六本木ミッドタウンのゴジラを見学。ハリウッド版ゴジラ公開にあわせたイベントで、広場に6.6mの上半身ゴジラが登場。

 http://www.tokyo-midtown.com/jp/summer/2014/godzilla.html

P7194833P7194837P7194843その時に撮影した写真。

そのうち真ん中のは、ゴジラの顔が結構リアルだ。ただし雑誌や予告編でのハリウッド版ゴジラは、頭や鼻が平べったい気がするし、首も含めてずんぐりしてるように思う。あと、目が映画の方が黒っぽいと思う。なお、写真の下のほうに目をやると格子模様が見えて、人によっては好き/気にならないかもしれないけど、自分としては工夫が欲しかった。

そのうち右の写真での、ゴジラの左の方にゴルフでのグリーンのような模様が見えるが、それがハリウッド版のゴジラの場合の足跡とのとこ。ちなみに6.6m版ゴジラに相当する足跡も、フィギアの周りにいくつか書かれてる。


以前自分のブログに"ゴジラ特集 雑誌「pen」など"を書いたけど、最近ゴジラ関係をポツリポツリと目にしたり読んでる。そこで述べたように、プロジェクト遂行という観点でゴジラ映画作成のことを読むと、結構参考になった。

まず、的確にまとめられてるウィキペディアでの映画一覧
http://ja.wikipedia.org/wiki/%E3%82%B4%E3%82%B8%E3%83%A9%E6%98%A0%E7%94%BB%E4%BD%9C%E5%93%81%E3%81%AE%E4%B8%80%E8%A6%A7

ウィキペディアでの「ゴジラ (1954年の映画)」
http://ja.wikipedia.org/wiki/%E3%82%B4%E3%82%B8%E3%83%A9_%281954%E5%B9%B4%E3%81%AE%E6%98%A0%E7%94%BB%29

ウィキペディアでの「ゴジラの逆襲」(第2作)
http://ja.wikipedia.org/wiki/%E3%82%B4%E3%82%B8%E3%83%A9%E3%81%AE%E9%80%86%E8%A5%B2

これ以外の各映画も、ウィキペディアでは結構細かく映画作成の様子が書かれている。


断片的だけど、ウィキやpenなどを読んでプロジェクト遂行として参考になりそうなことを書いておくと、、、。

・当初(企画段階)は「G作品」。

記号やコードネームにするのは製品開発の時がそれに近いけど、最終的な商品名や細部に関しては誰もわからないことは多い。

・田中の企画は、上層部会議(経営会議?)で森岩雄以外には反対される。

まっ、結構良くあること。ただ、その後の打ち上げなどの話などから、Goになった後には妙な足の引っ張り合いは無かったと思える。その辺りは、決まったら協力する/少なくとも足の引っ張りはしない意識にはなっていたんだろう。組織体によっては、妙な足の引っ張り合いというか追い込んで愉しむ連中がいるように思える。

・香山滋の原作。

プロジェクトでも、やはり叩き台台はあったほうがいい。それにしても、1週間で完成させたのには驚き。

・プロデューサー・田中友幸、監督・本多猪四郎、特撮・円谷英二などの以前のつながり。

前の作品で一緒に組んだとかで、多少気心が知れていたと思われる。プロジェクトでのキーマン達をゼロから掻き集めるのは注意が必要だ。あるいは、キーマンにはある程度の人事権なり人集めの権限を与えた方が良い。

特撮部分については円谷は、当初本多にすら撮影したフィルムを見せなかったという。それでも上手くいったのは、原作や脚本などで基本部分を共有していることと、相互信頼があったからと思われる。

・本多猪四郎と円谷英二の、ゴジラスーツアクター中島への「お前が動いてみないと分からない」。

スーツアクター中島が動作のことを聞こうにも、分からないとの返事。微細な細部は、進めながら決めてくのの典型。

・プロデューサー・田中は、その後東宝映画社長へ。

会合などでプロジェクトマネージャーのキャリアパスのことが話題になるけど、ふとIT業界だけが秀でたプロジェクトへの見返りが無さ過ぎなのではないかと思えてしまう。(田中の後にプロデュースを務めた富山省吾も、東宝映画社長に就任。)

・円谷英二の蛸(タコ)案のエピソード(当初は円谷案と、恐竜の田中案が対立)。

プロジェクトの当初は、大なり小なり意見対立は発生する。むしろそれが普通。もちろん決定後は、円谷も恐竜前提。(シリーズ第3作の「キングコング対ゴジラ」では、大ダコが登場する。実物と人形アニメによる。)

駄目もとを含めて、意見交換の際には自分の意見を言っておいた方が良い典型。その時は不採用でも次に採用されるかもしれないし、思わぬことが発生して代替案として採用されることもある。特に製品開発の場合は、(特に他社からの申請をつぶす意味で)特許ネタとして特許出願しておくなどが考えられる。

・ゴジラシリーズの俯瞰での、監督や特技監督、音楽担当の違い。

ゴジラの形状や作品の仕上げ方などが結構違っている。(松竹の「寅さん」とは好対照かもしれない。) 製作記を読むと監督間の考えの違いなどもあって面白い。製品開発で言えば、シリーズでの違いや、ここの製品での微妙な違いと似てはいる。


ゴジラ映画が、BOKで描かれているようにとか理想のような状況で作られたわけではない。総じて、色んな意見の相違がありながらも、予算や上層部による制限の中、作品(商品)に仕上げて行った過程は、大いに見習うべき所があると考える。というか、今回ゴジラ映画のことを調べて、改めて参考になることが多いな~と感心してしまった。

7月 20, 2014 プロジェクトマネジメント, プロジェクト管理, 映画・テレビ | | コメント (0) | トラックバック (0)

2012年11月 9日 (金)

プロジェクトポートフォリオって、、、

プロジェクトマネジメントの講演や勉強会で、時々話題となる単語が”ポートフォリオ”。

代表的なPMIの日本語訳の本が、左の「ポートフォリオマネジメント標準」。既に第2版で、手元にある第1版(第3刷)は2008年9月発行されている。

プロジェクトマネジメントの規格化などでもポートフォリオの議論は行われているように聞くので、PMI関連(特にPMPメンバー間)だけでの話題ではないと思う。なお、ここではプロジェクトポートフォリオと書くが、各プロジェクトの継続や中断を判断するのだから、組織的にはプロジェクトの上位クラス(部とか事業部など)がマネジメントすることが普通だろう。

思うに、会合等で「ポートフォリオマネジメントが重要です」との意見などにはなるが、プロジェクト視点での突っ込んだ話が少ないような気がしている。(これは自分がポートフォリオ研究会などに属していないかもしれないが、、、。)

そもそも”ポートフォリオ”は、適切な日本語訳が無いようで、カタカナ語のままというのも突っ込んだ議論が少ない理由かも知れない。ただし、昨今は株式投資での銘柄の組み合わせとか、そもそもいくつかの金融資産の分散投資で言葉としては馴染みが出ている。あるいは企業経営での、製品ポートフォリオとか事業ポートフォリオという用語は使われることが少なくない。

研究開発に関連した製品ポートフォリオでは、市場規模が小さくなったりや利益の見込みがない製品の開発を止めたり、自社の商品ラインナップから外す事が検討される。プロジェクトポートフォリオでも、それを基にしたような同様の話が少なくなくてどうも腑に落ちない。

一方で、「一度走り出したプロジェクトは止められない」との意見も人もある。極論すると、プロジェクトポートフォリオを考える意味がないということだ。


それらを踏まえてポートフォリオを考えると、そもそもITプロジェクトとか建設などのプロジェクトでは、(一括)請負での作業が多い。契約を締結している場合がほとんどだろう。となると、プロジェクトの中断や廃止は、基本的に契約解除を意味する。プロジェクトポートフォリオを考えるという事は、契約解除(状況によっては、契約違反や損害賠償)での損得を考えることと同様だ。どうもその辺りの損得勘定の議論が少ない(皆無、あるいは聞いたことがない)のが、自分の突っ込んだ議論が少ない印象に結びついてるような気がする。

昨今のソフトウェア開発での請負契約では、セキュリティの関係等で損害賠償の上限を契約に盛り込もうとする動きも少なくない。注意して作成して納品しても、その後セキュリティホールが見つかってトラブルになる可能性を危惧してのことである。上記で一括と書いたが、プロジェクトのリスク回避のためなどで契約を多段階に分けることも行われている。従って、契約自体に賠償の上限を記載したり、それらが多段階になっているなど複雑になって事が多いと考えられる。実際の契約解除では、それらを踏まえての判断が必要だ。


ちなみに、ここ2,3年、IT系で話題となったのに、スルガ銀行の勘定系システム開発に関する裁判で約74億円の賠償を日本IBMに命じる判決があった。ネット上の記事としては、例えば以下。

http://www.nikkei.com/article/DGXNASFK0902S_Z00C12A4000000/

上記での発注側の視点では、概算で支払った分しか損害賠償として認められなかったことになる。なお一般的な工事請負では、工事着手してからの著しく工期の遅れなどが発生しない限り、一方的な契約解除は不可である。(手付けの場合に、買い主の倍返しでの解除などが可能。)


プロジェクトポートフォリオでは、より契約や発注側/受注側を意識した検討が必要と考える。また、プロジェクトポートフォリオマネジメントの事例として、スルガ銀行の勘定系システムの開発中断や中止をどこで判断すべきだったか考えるのは有益と考える。

11月 9, 2012 プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2012年8月 1日 (水)

PM学会講演会 野中郁次郎氏「場とスクラムのリーダーシップ」

今日は、PM学会の講演で、大井町の「きゅりあん」(品川区立総合区民会館) へ。野中郁次郎氏の「場とスクラムのリーダーシップ」。会場は「きゅりあん」の小ホールで、席はびっしり埋まって300人くらい?

講演自体は野中先生の知識ベースの話が主で、”場”やSECIモデルなどを最近の書籍/雑誌やトピックスを交えながら紹介。また講演の後に、学会メンバー2名とのQ&Aも行われて、プロジェクトマネジメントやIT業界、日本の競争力などに関する部分の掘り下げが行われた。(質問と回答の時間が長くて、多少講演の延長に近いイメージになった。また多少残念なことに、会場とのQ&Aは無し。)

断片的になるが列挙すると、、、。なお聞き違い等はご容赦。

・知識の源泉は主観。(主観の客観化は行われるが。)

・モノよりコトで考えることが重要。コトで考えるということは動詞で見るということ。例:インターネット”化”

・”賢慮”(フロネシス)のリーダーや「判断」が重要になってきている。

・賢慮のリーダーは、善、場(プラットフォーム)、現実直視、本質の概念化、概念の実現、政治力(組織化)への意識が必要。

・プロジェクトの例として、自動車ホンダのLPLやダイハツのミライースプロジェクト。後者の転籍している話や、トヨタの技術管理本部の人事権など、人事権を絡めた話が出た。

また個人的な受け取りでは、マトリクス組織よりも、転籍とかハイパーテキスト型の組織がこれから必要になるのだろうと感じた。

・シスコの全社員7万人の社内SNSなどにも触れた。

・Q&Aでは、ヨーロッパでの”リビングラボ”の取り組みの話しも。日本では藤沢での取り組みがあり、ノキアから指導を受けてる? ただし、”リビングラボ”の方法には課題もあるとの意見だったように思う。

・Q&Aで、プロマネ(リーダーシップだったかも)として、”教養”が重要である旨の話が出た。HBRの2009年4月号を引き合いに。そこでは神学なども含まれているとのこと。

・Q&Aでは、暗黙知を得意とする日本だったのに、日本国内で閉じていたのは敗因との意見だったと思う。シャープ亀山など。それに対して、韓国などは現地化や多様化への対応を行っており、それが差になった。


幅広い話だったこともあり、その分事前資料がないのは少しきつかった。後日資料は会員に公開されるので、そちらで復習するつもりだ。


なお、今回のイベント運営では、スムーズに行かなかった部分が少なくないと感じた。応募に対する受理連絡が当初無かったり、受理連絡への返信でメール配信が起きた。当日では本来2階席を利用できない事になっていたが、案内や掲示が無くて、2階席に着席する人達が発生した。その人達は、講演直前で1階に移る羽目に。

また、会場でデジカメやスマフォで写真撮影する人達がいた。前の方の列だったこともあり目立った。講演前に案内があったり係の人の制止があるかと思ったけど、それも無し。ちなみに撮影した人の一部は知った人で、学会の作業として行っていたのかも知れない。ただそうなら、腕章付けるとか混乱しないような措置が必要だったろう。

ちなみに参加受理のメールでは、”※会場内での録音,写真撮影,ビデオ等の録画及び無断で記録したものを第三者に配付する行為をお断りします。”との表現。撮影者が少なくなかったので、もしかしたら第三者への配付のみの禁止だったのかなと会場で考えた。帰宅して読み直すと、撮影そのものもNGだ。文章が少し分かりにくくて撮影に及んだのか?? 少なくとも会場で説明や対処がなかったのは良くないだろう。

なお、講演開始後に自分たちの列に着席する女性がいた。通路で少し立ち止まるとか、ゆっくり目に席に着いてくれればいいのに、他の人のバッグと接触して無理に引きずるように着席。特にごめんなさいも無し。この前のPMI日本フォーラムでも似たようなことに遭遇。押しが強くないとPMになれないのかもと苦笑しつつ、何で自分の回りでは不快なことが少なくないのかちょっと気になった。


多少運営や近くにいた人への不満はあったにせよ、講演はプロジェクトマネジメントを考える上で大きな示唆に富んでいたと言える。自分のメモや今後会員公開される資料で、復習や深掘りしていこうと思う。

8月 1, 2012 プロジェクトマネジメント, プロジェクト管理, 日記・コラム・つぶやき | | コメント (0) | トラックバック (0)

2012年7月 8日 (日)

PMI日本フォーラム2012

昨日と今日は、PMI日本フォーラム。学術会館。

今年は事前に講演プレゼンをダウンロードしてiPadで持参。受講する講演部分のみ、事前ダウンロード可能だった。(フォーラム終了後に他の講演もダウンロード可能とする対応。)  便利だったけど、今回事前資料と発表資料が異なったり資料にメモを取っておきたい講演が、少なくなかった。ダウンロードは保護のかかったPDFファイルで、(直接書き込めなくても)メモの書き込みとかを工夫すれば良かったと少し反省。

また、各講演への申込みは、開催通知しばらくで満席になるところも少なくなかった。ここ2,3年、分かってはいるんだけど、つい申込みを先送りして反省。先送りというか、検討の日が結果的に長いんだけど。また、集計の関係なのか、急に満席と判明するため対応しにくいとも言える。知り合いも同様と言っていたので、自分だけじゃないと、多少気が楽ではあるが。


昨日初日には、電車の乗り継ぎが良くて、(自分の感覚じゃ)結構早めに会場に着いてしまった。ただ、受け付け開始時刻は過ぎてたためか、席が埋まっててビックリ。最後列の真ん中辺りに座った。それにしても、休憩後、後から椅子をまたいで席に着く人いてビックリ。両脇既に人が座ってるんだよな~。多分PMPなんだろうけど、うーーーーん。

2日間の講演で印象深かったのは、スパコン「京」、B787と東京スカイツリーに関する講演。東京スカイツリーの講演はダウンロード資料無くて、ちょっと残念ではあったけど、逆にフランクな話も出て良かった。

スパコン「京」での話は、チーム形成の話が面白かった。優秀だけど、とげのある人とか、、、。工事での大変さなどは、例えばDay2プロジェクトの時などでも聞いた話が少なくなかった。トイレとか食事のこと。PMIJフォーラムなどで訊いていたら、より早期に対応できたろうにと、案外PMIJ内などで情報共有して他の業界などとも共有することも重要そうに思えてきた。

B787の話は、案の定ウォシュレットトイレの話しも。トップの会合でも、昼食時にその話が出たそうだ。それを、多少面白可笑しく紹介してた。

東京スカイツリーの話は、多少の無理を承知での営業サイドと設計サイドとの、バトルというか対比も実際的で良かった。構造上のことやコンクリートの速乾のための工夫の話も出て、ある意味、ぎりぎりセーフ。まっ、世界一なり日本一のプロジェクトには、ついて回る話だと認識を新たにした。

他に面白く感じたのは、「J-1 PMの早期選抜 ポイントの検討」。ただし、講演後にちょっと質問したけど、即自組織に適用するようなツールというかチェック項目になっているようにも思えなかった。自分が、安直に解を求めすぎたか。

PMIJでの組織成熟度研究会の講演も1つ聞いたけど、会場からはどうしてもCMMとの関連というかその前提を意図した質問があったように思う。”成熟度=CMM”と固定化されてしまっている人が少なくないのかも。せめてQ&Aでは、日本なり各自の考えなどを発するとか想像してたので、ちょっと意外。あるいは、そんなもんだと割り切るべきなのか、、、。

プログラムにはメンタルヘルスや失敗プロジェクトの文字も見てちょっと興味がわいたけど、他の講演との関係で聞けず。

蛇足だが、このフォーラムでは知人と会うことが少なくない。今年はTwitter絡みで、急に昼食時に集まったりも経験した。また大学での同窓生とは、終了後に神保町で一杯。楽しかった。


補足:フォーラム後に資料公開されて受講以外の講演資料も見ることが出来た。メンタルヘルスなどタイトルで興味持ったのを読んだけど、資料内では大きく興味をそそるものはなし。やはりこの類は、実際講演を聴いた方が有意義なんだろう。

7月 8, 2012 プロジェクトマネジメント, プロジェクト管理, 日記・コラム・つぶやき | | コメント (0) | トラックバック (0)

2012年7月 1日 (日)

山開き スケジュールの依存と非依存

今日(7月1日)は富士山の山開き。夏になると、富士山をはじめ、山開きや海開きの様子がニュースになることが少なくない。

昔は、単なるイベント位に思ってた。海だと遊泳許可になる程度かと。ところが、少し登山に興味が出た事もあって、富士山に単独で登ろうとして判明した。7月1日で、バスの運行ががらっと変わる。7月1日からを夏季平常期と呼ぶようだが、言い方が微妙かも知れないけど、かき入れ時の運行スケジュールへ。思えば、海開きでも、海の家が営業を開始したりする。監視員の配置も、海開き以降だろう。

海や山でのバスなどの交通機関や宿泊や休憩の施設、それらに伴う色んな活動が、大きく変化するわけだ。設計とか開発だと、フェーズが変わるみたいなもの。


なお、今年の富士山山開きは、残雪の関係で延期になるかもとの情報もあった。しかし、雪かきなどで連年どおりだった。雪解けを待っての山開き日決定ではなく、一応7月1日を山開きと決めておいて、状況によっては延期するとの考えだ。(富士山の全ルートが、そうなのか/そうだったかは自信ないけど。)

プロジェクト管理でのスケジューリングには、タスク間の関係として、依存のあるものとそうでないものと考える。依存には前のタスクが終わってから次を開始するなどがある。非依存だと、開始日がばらばらで良い、あるいは該当タスクは予め決まった日に開始とのことになる。

富士山の山開きは、プロジェクト管理でのタスクと考えると、基本的に非依存となる。バスにしろ山小屋にしろ、7月1日開始。ただし、もし残雪が多ければ、雪かきがうまく行ってから、山小屋を開くのだろう。残雪が多いときには、雪かきなどのタスクが発生して、山小屋関連の大抵のタスクがスライドする。(バスの方の残雪との関係は、良く分からない。残雪が多くても夏季平常期のダイヤに移行するかも知れないし、雪かきを待って夏季平常期のダイヤになるのか? 個人的には、前者のような気がするが。)


プロジェクトのスケジュールでは、イベントを特定の日にすることは少なくない。展示会のような外部の日程によるものもあるし、判定会議や記者発表のようにある程度融通できるものもある。スケジュール表では、どちらも特定の日にしてあるが、変更する/変更できる可能性があるものがあるというわけだ。それらを別文書にしておくとかスケジュールのタスクの情報に付記しておくことは有効と言える。

思うに、プロジェクトのスケジュールを期日一覧にして、タスク間の依存がほとんど分からない運用の所が多いようにも聞く。個人的には論外で、タスク間に依存関係があれば、それをはっきりさせておくべきだ。そうしないと遅延した場合の対応が効率悪い。また、他のタスクも遅延する旨の連絡や周知徹底の手間も、馬鹿にならない。

逆に、日にちの設定に幅がある場合は、それが分かるような情報を共有しておく方がよい。リスク対応としても非常に有効だ。暗黙知でも良いだろうが、重要な事は明文化していた方が良いだろう。今回の山開きなら、残雪が多いケース。

富士山の山開きで、ふとそんなことを考えた。

7月 1, 2012 プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2012年4月24日 (火)

建設での品質管理

建築での品質管理に関しては、断片的には知ってた。資材の確認とかメンテナンスでの検査、、、、。ただし、断片的な情報で、どこかにまとまってないかな~というのは気になっていた。建設会社のホームページなどにも掲載されているが、より細部が分かると良いなと思っていた。今朝、何気にいくつかの検索で調べたら、結構良いページ/資料を発見。

「建設事業の品質管理体系に関する技術開発」報告書

http://www.kenken.go.jp/japanese/research/prd/list/topics/hinshitsu2/Q00.htm

国交省のプロジェクトで、建築部分が上記”建築研究所”に置いてあった。平成13年の発行なので多少古いかもしれないけど、自分の場合は十分。逆に結構なボリュームで、(建築外の自分では)必要な時に読む程度かもしれない。

第3章が自分には参考になりそう。また2章の木造建築は、中小の会社への品質管理普及も意図しているようで、その観点で参考になるかもしれない。(中小ということよりも、品質管理の意識が乏しいところへの普及との意味で。)

各フェーズで主体が違うことへの対応や個別の性能要求に対する管理方法など、今まででも余り意識しなかったことが書かれているようで、ちょっと読んでみる。あるいは、読んで芋づる的に参考になりそうなことが出てくるかもしれない。

建築での品質管理の良い資料がないかは頭の隅に長くあったので、今朝は結構すっきり。

4月 24, 2012 プロジェクトマネジメント, プロジェクト管理, 品質 | | コメント (0) | トラックバック (0)

2012年3月28日 (水)

映画「黒部の太陽」感想

「裕次郎の夢~全国縦断チャリティ上映会」のチケットをゲットして、今日はその鑑賞。チケットゲットのいきさつは、既にこのブログで紹介済みだ。

会場は、有楽町の東京フォーラム。フォーラムの屋外とか、地下の連絡通路に係の人が立ってて、会場へはスムーズ。天気予報に反して?、小雨が降ってた。(蛇足ながら、東京フォーラムばかりじゃなくて他でも気になってるが、タイル張りが増えて勾配があることが多いこともあって雨だと滑りやすい。タイル素材を考えるべきなのか、自分自身で防衛するように今から検討した方が良いのか悩み所。)

開場の9時半少し前に着いたけど、既に入場門の前にはそこそこの人。少し回りをブラブラした後で、再度入場門へ。少し前に開けるかと思ったら、30分丁度。感心するやら、そこまで正確にやるのかな~とか思ってしまった。ちなみに、入り口には、熊谷組とTV朝日、あともう一つからの花が飾ってあった。(TV朝日との関係は? ただし、以前「黒部の太陽」のほんの一部分が、テレビ朝日でTV放送されたことがあった。以前からコンタクトがあったからだろうか。ちなみに、自分のDVDを探したら、その放送一部を録画してた。)

パンフレットを販売してたら買うつもりだったけど、それは無し。

自分の席を確認して、トイレに行ったり、通路などを散策したり、メールの確認などをしたら開演に近づいた。2階席なんだけど、階数的には5階。”2階席”という言い方をしてフロアの階と区別するようにしているみたい。自分の席は、後から2列目。思ったよりもスクリーンは見やすかった。しかも最後の列は全部人がいなかったし、最初は両脇にも人はいなかった。なので気分的にも楽。(ただし開演直前に、左の人が来たけど。)

2階席での少し飛び出したところに荷物や傘を置く人がいて、係の人が何度かお願いしてた。他は携帯電話の件。なお、開演してしばらくしてきた人は、階段で転んで怪我をしたみたい。逆に、自分の所からは、非常灯が結構目につき、最初少し気になった。


ほんの1週間ほど前に、BSプレミアムで「黒部の太陽(特別編)」が放送されたので、その違いを中心に述べる。

最初の方にチャンネル銀河などの画面。また、映画そのものでの「この映画は敗戦の、、、、」の文言。建設会社の社名なども出たように思う。

オープニングでの配役の所が、”五十音順”。ついこの前、BSプレミアムで放送された「黒部の太陽(特別編)」と違うので、早速メモ。冒頭からして違うのか~と、焦ると同時に、集中せねばと心構えた次第。

オープニングの音楽の時に気になったし、TVの時もそうだったけど、モノラル録音だと思う。(席の関係じゃないと思うけど。) 逆に、登山でのアイゼンの音や滑落の音などは、結構音に注意した作りにしている気がする。またフィルムがそれなりの物なのだが、冒頭の辺りでも所々にシミのような画像が。今回のためにデジタルリマスター化する手間ほどではないにしても、DVD化などの時には画像修正とか、音響のステレオ化を行って欲しい気がする。(できれば、洪水シーンでの発泡スチロールらしき白い部分の修正もやって欲しい。)

なお、特別編と今回の完全版の違いを確かめようと、以前購入した原作をさらっと見てみた。すると、そもそも、登場人物名が違う。三船俊郎演じる北川覚は、原作では芳賀公介。石原裕次郎演じる岩岡剛は、原作では笹島信義といった具合だ。

さらに映画では伏線として、岩岡剛と樫山文枝演じる北川由紀の恋愛がある。しかし原作での芳賀の長女・由江は、冒頭に近い辺りから既に見合いをしている。多少映画と似ている点は、相手が間組の土木屋であったり最終的には結婚する点である。

ちなみに、多分この本はフジテレビによるテレビドラマ放送の際に気になって購入したもの。積ん読状態だった。


黒部の太陽(特別編)では、どうも腑に落ちなくて悩んでたのが大きく2つあった。

1)岩岡剛(石原裕次郎)と北川由紀(樫山文枝)が最初に出会う前後

2)岩岡剛(石原裕次郎)が、いつの間にか父親の岩岡源三(辰巳柳太郎)の跡を継いでいて、その理由や背景

岩岡剛と北川由紀のために、加藤武演じる男性が”ハザマグミのクニキダ”と名乗って、岩岡剛へ父危篤の偽電話をする。偽電話だったので”ハザマグミのクニキダ”も嘘かと思ってしまった。しかも余り良く聞き取れなかったし。さらに最初に出会ったのが北川の自宅だったが、酒はなんでも良いという剛の言葉に対して、回りに「養子向きじゃない」との言。いきなりだったので、北川の親族かと思ってしまった。

ところが実際は、本当に間組の国木田(加藤武)。完全版では、工事現場で工夫らに訓辞するシーンもあった。岩岡剛と北川由紀が出会う直前では、北川の子供が三姉妹のみであることを話題にして、北川らと相手として岩岡剛はどうだろうかと会話する。完全版で、これらを見ていくつかの疑問が氷解した。

2つ目の岩岡の親子関係は、当初険悪だったので理解しにくかった。北川の自宅で、剛は破砕帯の危険性を国木田らに説明する。またその時の話し合いでも、親子で取っ組み合いになる/なりそうになる。剛には父親が金の亡者としか思えないし、そもそも弟が父親のために事故死したことを恨んでる。工事の際にも会うが、その際も口論。またどう考えても、剛は別の建築設計事務所の社員だ。それがいつの間にか、父のトンネル工事を引っ張るようになっていく。

完全版では、工事現場の宿での親子激論の後で、剛が北川と会話する。北川との会話から、剛が工事現場に留まるようになって少し理解できた。それでも引っかかる部分もあったが、由紀との会話か何かで納得できそうなレベルになった。


特別編には登場しなくて、完全版で目にして印象的だったのは、、、、。

・樫山文枝のスキーウェア姿

・佐藤工業の森(宇野重吉)と息子(寺尾聡)の実親子シーン

・岩岡剛と大学で登山部だった人の登場 概述の工事中に父親の工事現場に向かう時やラストでのダムシーンなどで剛(石原裕次郎)の登山姿が気になってたけど、昔登山部だったとのことで理解できた。また、貫通する前後での企業間の電話のやり取りなどの背景が理解できた。

・佐藤工業の森(宇野重吉)の奥さんとして登場する北林谷栄 老け役、特に「ビルマの竪琴」での老婆役といえば分かりやすいか。完全版での登場も短い時間だったが、特別編では登場しなかったと思う。

・終わりの方で、北川覚(三船俊郎)がトローリーバスを降りて破砕帯を歩くシーンが、特別編ではカットされていた。他にも、特別編でのカットを勿体なく感じる部分が少なくなかった。

ちなみに、下條正巳が工夫役で出てた。下條正巳は、映画「男はつらいよ」でのおいちゃん役第3代。岩岡源三と工夫との大喧嘩の場面での登場で、特別編では声とかちらっと姿が見えていた程度だった。

他でも細部を含めて、完全版の方が理解しやすいと思う。工事の作業方法とか、建設会社間の違いや思惑なども特別編では消化不良状態に近かったと感じた。また発注社と元請けと下請けとの関係とか意見の衝突は、完全版の方がよりストレートに思えた。(ただし、ネットでの特別編と完全版を別物と考えた方が良いとの意見も見たが、個人的にはそこまでの大きな違いは感じなかった。)

なおトンネルの貫通は、一休みの号令の後に、岩岡剛(石原裕次郎)だけが煙草を一服した後でドリルを手にして行われる。現場での煙草は、当時でもちょっと考えにくいかとふと思ったがどうなんだろう。


上映は、休憩を含んで3時間半程度。終わる時には、拍手も起きた。観客の方は、結構年を召した人が少なくなかった。年を召した方は子供さん(と言っても団塊の世代に近い)と一緒にといった人が多いと感じ。大なり小なり当時の工事に関係した方々もいらしたのだろうか。

岩岡源三(辰巳柳太郎)らの言動は今となっては時代遅れかもしれないが、共感できるシーンが少なくなかったように思える。共感とまでは行かないにしても、多少笑みを含めながらも理解できるような反応が時々あったように思う。自分がそうだったからかもしれないが、、、、。あるいは、剛(石原裕次郎)が途中まで余りに淡々としてて、それに対する意外性や反発が、岩岡源三(辰巳柳太郎)を好感していったのかもしれない。

P3262028写真は、鑑賞記念として頂戴したもの。

裕次郎のカレンダーや、焼き肉のたれ。そして、黒部などの観光案内。自分は裕次郎の熱狂ファンと言うほどでも無いが、ファンにとってはカレンダーなどで超お得だったのではないだろうか。


個人的には、プロジェクトマネジメントの人間的側面を知るには絶好の教材でもあると考える。発注社/元請け/下請け、各自の家庭や背景の事情、リスク遭遇への心理やそれに対する対応、、、、。完全版の方が、より肉薄する印象なので、DVD化とかに期待したい。


ちなみに以下のページでは、「黒部の太陽」での俳優さんが結構細かい人まで列挙されている。名称こそ特別編となってるけど、完全版のことにも触れていて参考になると思われる。

 華麗なる日活映画の世界 1968年『黒部の太陽』(特別編)

3月 28, 2012 プロジェクトマネジメント, プロジェクト管理, 映画・テレビ | | コメント (0) | トラックバック (0)

2012年3月16日 (金)

ソフトウェア開発での進捗の可視化

昨日の「プロジェクトマネジメント学会 2012年度春季」で触れた、ソフトウェア開発でのスケジュール進捗の可視化の件。

プロジェクト管理でのイナズマ線や達成率で進捗を示すことは行われているし、バーンダウン・チャートを用いることも多いだろう。ただし、ここで考えたいのは、ソフトウェア全体でのどの部分が終わってるかの図示化。一昨日の学会での講演だと、配管の3次元表示がスケジュールと一緒に示されたが、ソフトウェアが2次元とか3次元で示されれば言うこと無し。

2次元表現としては、クラス図などが考えられる。ただ、スケジュールでクラスをどう表現するかとか、ツール間の連携が気になった。色々調べたりしたけど、良い考えが思いつかない、、、、。

でふと、スケジュール→チケットと考えると、すっきりしてくるように思えてきた。チケット系のツールと、リバースエンジニアリング系(も機能に持つ)のツールで、連携できるものがある。

なお、全体をプロジェクト管理ツールで行っている場合は、WBSレベルでの情報をチケット情報から引っ張ってくる/作成するやり方が良さそうに思う。つまり主体をチケット系ツールにする。機能実装やテストの進捗とかバグ対策の進捗まで含めた可視化では、チケット情報の方が的確だからだ。(ただし、工数検討などではプロジェクト管理ツールの方がメリットあるだろうから、使い分けを行うだろう。)


結構すっきりして、一人ご満悦状態。

3月 16, 2012 ソフトウェア, プロジェクト管理, 出荷判定 | | コメント (0) | トラックバック (0)

2012年3月15日 (木)

プロジェクトマネジメント学会 2012年度春季

昨日(14日)と今日は、プロジェクトマネジメント学会2012年度春季研究発表会に参加。

http://www.spm.or.jp/pm2012_spring/

キーノートで「坂の上の雲」や「信長」の文字を目にして興味を覚えたのと、開催場所が東洋大学とのことで今年の箱根駅伝優勝の学内掲示があれば見てみたいと思ってのこと。

なお、電車の関係もあって、少し遅刻してしまった。会場へ小走りしてたら、偶然知り合いと遭遇。メイン会場までに、近況を聞いたりした。人生、色々ある。彼は懇親会へは不参加だったし今日は見かけず、色々話ができれば良かったんだけど、、、。


以下思いつくままのメモ。ちなみに〔〕内の番号などの記載は、セッションの番号。

・キーノート

(1)キーノート1 「『坂の上の雲』に学ぶこれからの人づくり」
(2)キーノート2 「もし信長がコミュニケーションエンジニアリングを知っていたら」
(3)キーノート3 「人を繋ぐ」
(4)キーノート4 「復元力を生むリスクマネジメント思考」

上記での2と4は、自分には余りメリットを感じなかった。2は教材が流れる時間が長かった。4は身近な具体例に乏しかった気がするし、予稿集に書かれている震災のことにもう少し触れてもらっても良かった気がする。4は時間オーバーで、次の講演への移動や資料確認にちょっとアタフタしてしまった。

1は、遅刻で冒頭を聞き逃したけど、面白かった。西郷頼道と山本権兵衛の六・六艦隊のための資金流用に触れ、現代のコンプライアンスとの対比の話が印象的。つまり、文面にこだわりすぎて、コンプライアンスの本質を忘れるのは本末転倒。ちなみに、席に座ることも可能だったけど、結局立ったままの受講した。

3は、会場を3グループに分け手拍子での合奏などを行い、楽しい一時でもあった。消費税5%と3万人の自殺者の経済効果/損失が同じ(だったはず)とか、被災地での催しや使い古しの楽器を贈る活動の紹介もあって、考えさせられる部分も。合奏の様子を言葉では表現しにくいけど、係の人が結構写真撮影してたので、学会のページなどで紹介されると思う。

・全体的に日立や富士通など国内メーカーの人が増えた感じがした。予稿集では富士通はさほどでもないけど、サポートの人が少なくなかった?

・震災の関係なのか、「リスク」が口にされることが少なくなかったと思う。ただし、本来行うべきプロジェクト上の作業が不十分なこともリスクと述べることが少なくなかったと考える。要求分析が不十分とか、品質を確保できないとか。ちょっと違うよな~との印象。キーノートだと、学外の人なので頷けもするが。

この辺りを気にするのは細かすぎるかもしれないが、述べたような項目をリスク一覧にして、それでリスク分析を行ったとするようなことを危惧している。つまり、本来のリスク検討が、実質行われなかった状況になってしまう。

・テーマを見て会場に行っても、メリットとか新規性に疑問を感じる物がいくつか。予稿集では差し障りがあって書かないのだろうと思ってたら、予稿集よりも概念的に思えるプレゼンの時も。自分の読解力が乏しくなったせいか、、、、。

・影響要因を考慮した試験フェーズにおける品質分析手法〔1203〕

軸を試験密度と誤り検出率として、どこにいるかをプロット。領域をゾーンで区分して、テストが非効率かとかを判断する。

プレゼンでのプロットの単位が”機能”だったので、講演後に確認。モジュールとかプロジェクトではなく、やはり”機能”とのこと。(もちろんモジュールやプロジェクトにすることは可能。) 誤り検出率は千行あたりのバグ数とかなので、対比などまで考えると、”機能”にするためには多少工夫が必要だ。結合テストなり、システムテストの前段階でに、脆いところを知ることにも有効だろう。個人的には、こちらの方が良いヒントになった。

・大規模電力プロジェクト向け建設マネジメント〔1405〕

紹介されたツールで、スケジュールのクリックで、どの配管部分の工事かを示すのが印象的だった。別の講演後に直接聞いて、プロジェクト管理ツールとの連携も多少教えてもらったが、やはり表示のための課題が残ったりするみたい。(ソフトウェアでも同じようにできないか思いを馳せ、別項目として書いてみる。)

・エンタープライズ系と組込みソフトウェア開発の品質メトリクスの比較分析〔2209〕

個人的に興味あった講演。例えば、バグ1件発見するのに、エンプラだと8.28H、組込みだと19.83Hなど。また、エンプラの方が後で発見される割合が増える。

講演後に少し話をさせてもらったが、顧客で深く興味を持ってもらえるところは少ないとのこと。クラウド等でエンプラ+組込みのシステムが増えつつあるんだろうが、絶対数はまだまだなのかもしれない。また、バグ数が少ないというかバグ発見時間が長いとの印象だったが、発表者での実測ではそうだったとのこと。どちらも、(出荷直前の回帰テストなどではなく)システムテスト全体相当と言ってた。

・プロジェクト有識者支援〔2210〕

NTTデータ本体のOB(グループ会社在籍)の言わばスーパーSEをプロジェクト支援者として活用したとの事例。2つのプロジェクトでの対比もあって、興味深かった。前の講演から急に人が増えた感じもして、企業でも気にしている事項のように思えた。

事例が少ないし、Q&Aで人事的な扱いを確認への返事でも模索的なことが少なくない感じ。また、2つの対比では、関与の仕方とか、支援者や支援される側の人柄に大きく左右されそうだ。スーパーSEが出しゃばりすぎるのも良くないし、かといってPMOに徹するのも効果が生まれない。発表者も述べていたと思うが、その辺りを上手く調整する役目の人が必要だし重要。


なお、昨日(14日)の懇親会会場は、16階のスカイホール。展望が素晴らしく、東京スカイツリーなども見えた。また懇親会では、箱根駅伝で活躍した柏原選手が富士通に就職することなどの話も出て、個人的には和やかな印象。ただ、キーノート1「坂の上の雲」の講演者津田氏を見かけず、ちょっと残念。考えたら、早朝の講演だったかので懇親会への参加は難しい。少し用事もあって、40分くらいで引き上げた。


蛇足:携帯電話での撮影だけど、いくつか写真を紹介。

2012031412550820120314124731箱根駅伝優勝の垂れ幕。記念ホールの外壁の方でも見かけた。右は、事務室とか食堂への階段の辺りの室内の垂れ幕。自分もマラソンなどで早く走れるようにと、願をかけてしまった。^.^; 

20120314165651スカイホールから見た東京スカイツリー。懇親会が進むと、夕暮れ、そして日が暮れて夜景になっていった。

201203160639112_220120316064008学内に置いてあったもの。

最初、報知新聞などの新聞を利用させてもらった物だと思った。さらっと中の紙面を見た時も、そこまでコピーはまずいんじゃないのと思ったくらい。裏面とか見ても、何々新聞の協力でとか書いてないから、なおさら。

じっくり見たり特に中の紙面を読んでくと、実際の新聞ではなくて、東洋大学の発行新聞と判明。52号と書いてあるから、結構年数を重ねているんだろう。それにしても種目も多彩で、本格的な記事だ。そんなに多くの大学へとか頻繁に行ってないからだろうが、スポーツでの新聞でこのレベルを発行している大学は他にあるのか?? 


今回の学会は、個人的には、キーノートや講演で参考になったものとそうでないものの差が激しかった気がする。学会内容以外では、箱根駅伝の関連/関係で、楽しい一時が多かった。

3月 15, 2012 プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2012年3月 3日 (土)

映画監督の責任範囲は「映画作品としての品質管理」

Facebookで、知り合いと探査機「はやぶさ」に関する映画のことが話題となった。プロジェクトマネジメント目線での話や、半年に3つも公開されて良い比較になるとか、映画に於けるスタッフの作業関連など。で、ふと思い出したのが、タイトルの文言。正確には、”映画映画監督の基本的な責任範囲は「映画作品としての品質管理」”。ウィキペディアの「映画監督」での記載だ。

http://ja.wikipedia.org/wiki/%E6%98%A0%E7%94%BB%E7%9B%A3%E7%9D%A3

ご存じかと思うが、映画制作には監督以外にも、プロデューサーとか映画会社のスタッフとかカメラマンといった作業のメンバーがいる。(プロデューサーは、作品の企画という立場。テレビの番組制作だと、映画監督と似た立場をディレクターとか呼んだり、さらに補助的なアシスタントディレクターという役目があることが多い。)

プロジェクトマネジャーやプロジェクトは、映画制作やオーケストラ演奏と対比されることがある。映画監督や指揮者が、プロジェクトマネジャーに相当するとの書き方が多い。ただし、個人的には、プロデューサーや脚本家の事などを考えると、映画監督をプロジェクトマネジャーと考えるには少し違和感を覚えていた。テレビでの制作を考えると、さらにそうだ。

で、ふと目にしたのが、タイトルにもあるように、映画監督と”品質管理”を結びつけた表現。映画関係の書籍には書かれれている事なのかもしれない。演技とか殺陣/擬闘やCGとか、どこかでOK/NGを判断する必要があるが、それが監督の基本的な責任範囲というわけである。

ちなみに、アメリカのアカデミー賞と日本アカデミー賞を対比してみた。勘違いがあるかもしれないが、似たものをグルーピングとかしている。なお、アメリカのアカデミー賞での”脚色”は、原作があってそれを映画化するケースが多かったので最初は脚色賞としたようだ。(原作などのない映画のための脚本への賞を脚本賞として、後になって制定。)

アカデミー賞 日本アカデミー賞
作品賞 作品賞
監督賞 監督賞
美術賞 美術賞
撮影賞 撮影賞
脚色賞/脚本賞 脚本賞
録音賞 録音賞
歌曲賞/作曲賞 音楽賞
編集賞 編集賞
視覚効果賞
衣装デザイン賞
音響編集賞
メイクアップ賞
照明賞
主演男優賞 主演男優賞
主演女優賞 主演女優賞
助演男優賞 助演男優賞
助演女優賞 助演女優賞
短編アニメ賞/長編アニメ賞 アニメーション作品賞
外国語映画賞 外国作品賞
短編映画賞
長編ドキュメンタリー映画賞
短編ドキュメンタリー映画賞

プロデューサーに対する賞はないけど、作品賞が該当するとも言える。また、この表に記載されている以外にも、映画・テレビ番組での冒頭や終わりのテロップに掲載される作業は少なくない。記録とか、特にテレビだと時代などの考証とか方言指導とか。調べたら、「演技事務」という仕事(の名前)があって、映画などで俳優さんの事務所などとスケジュール調整を担当するらしい。


ここでは簡単にプロデューサーと映画監督などと書いたが、役割や作業分担そして立場が作品毎に結構違うことがあるようだ。良い例か分からないし直接は見てないが、最近の映画「キツツキと雨」に登場する映画監督は、現場でおどおどする若い監督らしい。特にテレビ番組制作では、その作品(番組やチームと呼ぶべきか)で、脚本に忠実なケースもあれば柔軟に対応するケースもあるらしい。

詳しくは知らないが、映画のための作業がいくつかあって作業がオーバーラップしたり分担している映画やテレビ制作の方が、自然に思える時がある。対比的には、プロジェクトマネージャーが見積りや進捗管理をやったり、場合によっては細かい契約まで実担当する。知識としては必要だろうが、なんか社内から丸投げされるケースも。あるいは、PMOという名称のチームを用意すればプロジェクトが回るとの錯覚があったりする。

主な責任が品質管理となると、映画監督とプロジェクトマネージャーは似てる気もしてくる。担当しているプロジェクトでのプロジェクトマネージャーの責任範囲は何かと考えたり、ほかの作業範囲は誰が担当しているのか考えるのは、良いことだと思えてきた。

3月 3, 2012 プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2012年2月14日 (火)

秋山参謀はPMOメンバー?

暮れに、NHKスペシャルドラマ「坂の上の雲」(正確には第3部)が放送された。その際に、Facebookで知り合い(PMP資格保有)とやり取り。日本海海戦などをプロジェクトと考えれば、海軍の秋山参謀はメンバーとしてどんな役割だろうか?というもの。PMO(Project Management Office)のメンバーと考えるのが良さそうだけど、若干別の意見や考えもあった/浮かんだ。

そのきっかけもあり、ぽつりぽつりと追加的に調べたことなどを含めて、今回まとめてみた。ただし、ドラマ「坂の上の雲」の細部を注意して見ていた訳じゃないし原作を読んでる訳じゃないので、勘違いなどがあっても悪しからず。

また、ウィキペディアでの「日本海海戦」や「日露戦争」など、以下の「NHKスペシャルドラマ・ガイド 坂の上の雲 第3部」「NHKスペシャルドラマ・ガイド 坂の上の雲 第2部」「人間東郷平八郎と乃木希典」「統帥権と帝国陸海軍の時代 」を参考にした。当然、PMIによるPMBOKやプログラムマネジメント標準なども参考にしている。


今のうちにイメージしやすいように、スペシャルドラマ「坂の上の雲」での登場人物と俳優さんを記載しておく。敬称略、順不同。役職はドラマ3部ガイドでのそれとした。(複数ある場合はガイドでの最後のもの。ただし加藤友三郎は、ガイドとは異なり連合艦隊参謀長とした。)

 秋山真之(本木雅弘) 連合艦隊参謀
 東郷平八郎(渡哲也) 連合艦隊司令長官
 島村速雄(舘ひろし) 第2艦隊司令官
 加藤友三郎(草刈正雄) 連合艦隊参謀長 
 山本権兵衛(石坂浩二) 海軍大臣
 山県有朋(江守徹) 参謀総長
 児玉源太郎(高橋英樹) 総参謀長
 大山巌(米倉斉加年) 満州軍総司令官
 乃木希典(柄本明) 第3軍司令官
 明治天皇(尾上菊之助)
 小村寿太郎(竹中直人) 外務大臣


まず、明治元年が1968年で、日本海海戦は明治38年(1905年)5月27日・28日。40年近く前はちょんまげのサムライの時代だった国が変貌。倒幕や西南戦争などの士族反乱といった内乱を経ながら、”軍”の近代化が進められていった。1889年には大日本帝国憲法が発布されると共に、同じ年に徴兵令が大幅に改訂され国民皆兵となった。また、1894年に日清戦争が勃発する。その関係で、広島に天皇が移ったり、国会を広島で開催したりしている。

なお、帝国陸軍と帝国海軍は1872年に設立されるが、西南戦争が薩摩・西郷隆盛の蜂起だったことから長州メンバーが主の陸軍に重きを置かれた。しかしその後は、次第に海軍も組織的に陸軍並みに整っていく。(日本海海戦での主な戦艦の竣工は、1987年~1902年。いずれもイギリスでの建造。)

台湾や朝鮮半島への派兵も行われ、1894年~95年の日清戦争勝利で清から領土(特に遼東半島)と多額の賠償金などを得た。しかしその後の、ロシア、フランス、ドイツの三国干渉により、遼東半島を清に返還する。清は日本に返還のための賠償金を支払ったが、その穴埋めに遼東半島を各国に租借した。ロシアは遼東半島の先端の旅順に軍事基地を作ったり、義和団の乱での派兵などを通じて、日露の対立が深まる。租借に際しては金銭の授受も行ったが、せっかく手に入れた油揚げを鳶(トンビ:ロシア)にさらわれ、糞か何かを掛けられたような気持ちだったろう。


日本海海戦当時の組織図を書いてみた。連合艦隊は日本海軍が二個以上の常設艦隊の非常設の艦隊であるし、”軍”(特にここでは第3軍)は日本陸軍の戦争時に編成されるものである。また軍政(陸軍省、海軍省)と軍令(陸軍参謀と海軍軍令部)は、分かれていた。 ※図などで間違いがあれば、コメントなどでお願いします。

Photo

上の図は、ダブルクリック等でもっと大きな図で見ることが可能である。また、Googleドキュメントで作成しており、元ファイルは以下なので、興味があれば参照のこと。

https://docs.google.com/spreadsheet/ccc?key=0At5_RJyc2TPhdElPZDZ3OVRac1lUQWJRWFhTZFliamc

なお、組織図は任命権の関係で、明治天皇をトップとしている。連合艦隊司令長官の任命に関しては、大日本帝国憲法そのものに明記されているわけではない。大日本帝国憲法第10条での文武官を任免による。本来、陸海軍では陸海軍大将のみで軍内の組織は含まないが、大将に次ぐランクとして「親補職」が設けられ、親補職の1つが連合艦隊司令長官である。ウィキペディア「親任官」などを参照のこと。なお、大日本帝国憲法第10条での文武官には官吏が含まれ、今で言う上級の国家公務員が該当したと考えて良く、天皇の任命権は結構幅広かったと解釈すべきだろう。(“上級国家公務員”という言葉は使わなくなったようだが、イメージ的にはそれに近いと言うことで。)


日本海海戦に関する時系列的な事を示す。ロシア帝国海軍第2太平洋艦隊のみをバルチック艦隊と呼称しているページなどもあるが、ここではウィキペディアなどと同様に第2太平洋艦隊と第3太平洋艦隊を合わせてバルチック艦隊と呼ぶ。

1902/03/01 戦艦三笠竣工 (同年5/18横須賀到着、7/17舞鶴到着)
1903/12/28 連合艦隊編成 司令長官に東郷平八郎 (満55歳 ちなみに当時秋山参謀は満35歳)
1904/02/08・09 仁川沖海戦
1904/02/10 ロシアに宣戦布告
1904/02/23 日韓議定書締結
1904/02/24~、03/27~、05/02~ 旅順口閉塞作戦
1904/08/10 黄海海戦 ロシア第1太平洋艦隊(旅順艦隊)との戦い
1904/10/15 ロシア第2太平洋艦隊がリバウ軍港を出港
2004/12/04 日本軍が203高地を占領し、その後支配
1904/12/16~1905/02/21 一旦日本に帰還
2005/05/09 ロシア第3太平洋艦隊がインドシナで第2艦隊と合流 (バルチック艦隊形成)
1905/05/27・28 日本海海戦
1905/08/09~09/05 ポーツマス講和(会議開催~条約締結)
1905/12/20 連合艦隊解散(翌21日に解散式)

1903年の暮れにチーム編成が発表され、一・二ヶ月ほどして宣戦布告や実戦を行っている。東郷平八郎自身常設の司令長官だったが、3つの艦隊(数え方によっては5グループ)を早急に連合艦隊としてまとめ上げる必要があった。つい考えてみれば、洋上で搭乗員全てを1つの艦に集めるわけにも行かないし、テレビ会議などライブ映像配信のある時代でもない、、、、。

ちなみに、ロシアへの宣戦布告前に仁川沖でロシアとの海戦を交えている。また日韓議定書やその後の日韓協約により、朝鮮半島での日本軍事施設が建設される。特に鎮海湾(釜山要塞)の施設は、その後の日本海海戦などで日本軍にとって有利に働く。鎮海湾(釜山要塞)については、以下など。(仁川沖海戦や日韓議定書・日韓協約に関してその後も含めていろんな解釈があり、ここでは言及しない。)

http://ja.wikipedia.org/wiki/%E9%87%9C%E5%B1%B1%E8%A6%81%E5%A1%9E


日本海海戦での兵力の比較は、以下などが参考になる。

http://www.page.sannet.ne.jp/tsekine/nihonkai.htm

戦艦以外の船舶数や総トン数は、日本の方が上回っている。(ただし、細部を後述。)

日本 ロシア
戦艦 4 8
装甲巡洋艦 8 3
巡洋艦 16 6
装甲海防艦 2 3
駆逐艦 21 9
水雷艇 41 0
総トン数 25万t 16万t

プロジェクト目線で日露戦争連合艦隊(ここではチーム東郷と呼ぶことにする)を考えてみようとしているが、そもそも連合艦隊をプロジェクト的と考えるのが妥当か? プロジェクトマネジメントを多少学ぶ/学んでないでプロジェクトとして意識するかが大きく異なると言えるが、ここではプロジェクト的と考えた方がすっきりするとの立場を採りたい。

連合艦隊は、編成開始と解散などがあることで、定常業務とは異なる。プロジェクトにはPMBOKなどでの定義のように「独自性」と「有期性」が必要である。連合艦隊の場合、前者はよいとして、後者の有期性に合致するかの疑問があるかもしれない。プロジェクトマネジメントでの有期性は、”明確な始まりと終わり”であり、明確な開始日と終了日ではない。明確な終了としては、戦争に勝利しての解散、戦争での全滅、政治力などによる戦争終結など、複数のケースが上げられる。

次に、チーム東郷はプロジェクトとプログラムのどちらだろうかとの疑問が涌く。ちなみにPMBOKでのプログラムの定義は「調和の取れた方法でマネジメントする、関連したプロジェクトのグループ。個別のプロジェクトのマネジメントで得ることのできない利益が得られ、コントロールが可能となる。プログラムは、プロジェクトに含まれる個別プロジェクトのスコープに入らない関連作業の要素を含む場合もある。」としている。またPMIのプログラムマネジメント標準では、複数のプロジェクトのベネフィットをまとめられる場合や、個々のプロジェクトマネジメントではコントロールできない場合の活動をプログラムとしている。

一般的にも”サブプロジェクト”という言葉も使われており、対象とするグループをプログラム、プロジェクト、サブプロジェクトのどれと考えたら良いかは悩ましい事が多い。今回だと、国全体の日露戦争への取り組み、海軍の連合艦隊、各戦隊、各戦艦といった階層が考えられる。それらの各層や、その中のグループをどれに相当すると考えるか、、、。日露戦争での連合艦隊をプログラムと考えた方が良いとの意見もあるかもしれないが、ここでは連合艦隊自体をプロジェクトと考えることにする。艦隊がグループとしてまとまっていることや行動も一致していること、そしてそもそも開始と終了が一致しているためである。

次に、秋山参謀のプロジェクトでの立ち位置について考えてみる。プロジェクトマネージャーだろうか? あるいは、プロジェクトメンバー? 実際に操舵したり、射撃しているわけでもない。かといって、プロジェクトマネージャー(あるいは、プロジェクトの管理者層)とは一味異なる。連合艦隊参謀がプロジェクトマネジメントオフィスであり、秋山参謀はそのメンバーと考えた方がすっきりすると考えた。

ちなみにPMBOKでのプロジェクトマネジメントオフィスの定義で”所轄する複数のプロジェクトを一元的にマネジメントする”と述べているが、プログラムマネジメント標準でのプログラムマネジメントオフィスの説明はプログラムそのもの/プログラムマネージャへの働きかけとしている。つまり、PMIでの定義では、プロジェクトマネジメントオフィスは複数のプロジェクトの面倒を見るイメージであるが、プログラムマネジメントオフィスは該当プログラムの面倒を見るイメージだ。ちなみに、プロジェクトマネジメントオフィスをPjMOと、プログラムマネジメントオフィスをPgMOと表記する人やグループもある。

ただし、プロジェクトマネジメントオフィスを該当プロジェクトの面倒を見ることを指す人やグループもあり、プロジェクト内PMOと呼んだりする。したがって、プロジェクトに紐付くPMOもおかしくはないと言える。ここでは、それに近いPMOと考え、以下ここでのPMOは、プロジェクトマネジメントオフィスのことを示すものとする。


チーム東郷をプロジェクトチーム、秋山参謀をPMOメンバーと捉えると、我々の身近なプロジェクトにも参考になりそうな点がいくつか見えてくる。軍隊という特殊性や時代的なことなどで現代の組織体には取り入れない方が良いものもあるかもしれないが、対比的な検討は悪くないと思うので列挙してみる。


・プロジェクト化

チーム東郷の発足や解散は明確である。発足は司令長官の任命だし、解散式も行っている。身近なプロジェクトの発足/解散と近いのではないだろうか。ただし発足時は、常設の艦隊を言わば寄せ集めてのチーム編成となっている。また解散は、海戦直後ではなく条約締結後である。大きなブロック単位でプロジェクトチームに組み入れるケースは昨今のプロジェクトでは少ないかもしれない。また解散までの終結プロセスに時間をかけた点は、参考にしても良いと考える。(例えば、保守メンバーへの引き継ぎや保守メンバーでの保守作業確認まで行って解散するようなパターンに近い。)

ちなみに、初代三笠艦長早崎源吾の任命は1901/05/01(~1903/01/12) であり、二代目艦長が日本海海戦時の艦長でもある伊地知彦次郎で任命は1903/09/26(~ 1905/09/29)である。三笠の初代艦長早崎は製造のイギリスで引き渡しを受け、日本横須賀に1902/05/18到着した。恐らく乗員の多くは日本人で、イギリス→日本の航海をこなしたと思われる。

http://www.jacar.go.jp/nichiro2/topic/topic01_01.html

寄せ集めとは言え、各艦隊・各艦の能力や搭乗員のスキルもばらつきがあった。常設の艦隊メンバー以外の、連合艦隊直下のメンバーは限られている。

http://www.z-flag.jp/suigun/tsushima_war/forces.html

上記によると、司令長官以外は、参謀、副官、機関長、軍医、主理程度である。プロジェクトマネージャーのスタッフやPMOのメンバーと言える。これらのメンバーが主となりチームとしての形成やプロジェクトとしての問題対策も行っていったと考えるべきであろう。(ちなみに主理は法律の専門家で、ネットでは現在の司法修習生レベルと記載してあるが、修習生レベル以上と解すべきかもしれない。)

東郷司令長官、島村・加藤の両参謀長、秋山参謀の就任を主とした時系列は以下。

1903/10/27 島村:常備艦隊参謀長
1903/10/27 秋山:常備艦隊参謀に異動し、第1艦隊参謀を併任
1903/11/10 加藤:軍務局先任局員
1903/12/28 東郷:連合艦隊司令長官
1903/12/28 島村:第1艦隊参謀長、連合艦隊参謀長(兼任)
1903/12/28 加藤:第2艦隊参謀長
1905/01/12 島村:第2艦隊第2戦隊司令官
1905/01/12 加藤:第1艦隊参謀長、連合艦隊参謀長(兼任)
1905/05/27・05/28 日本海海戦
  :
1905/12/20 連合艦隊解散

(加藤友三郎の経歴は http://www007.upp.so-net.ne.jp/togo/human/ka/tomosabu.html より。他はウィキペディアより。)

結果的には、東郷が司令長官に任命される前に島村・秋山を近くに配属したことになる。1905/01/12の島村から加藤への参謀長交代は、旅順口閉塞作戦や黄海海戦の失敗も原因と言われている。ただし個人的には、多少期間が過ぎており、作戦や体制の見直しを行った後の交代としたようにも思える。

次に兵員の確保であるが、どうやら(陸軍と異なり)海軍は基本的に志願兵を主としてきたようである。つまり、開戦により兵を招集して大幅に増やした訳では無さそうである。詳しい文献に当たれば日本海海戦時の連合艦隊の兵員(乗員数)が判明するかもしれないが、以下のように概算してみた。

まず、日露戦争連合艦隊の戦艦は、日本海海戦時は三笠、朝日、敷島、富士である。これらは、常備排水量が1.2万~1.5万t。乗員数が726~859名。

他に戦艦は、初瀬、八島があったが、この2隻は旅順口閉塞作戦で沈没してしまう。常備排水量や乗員数は上記4隻とほぼ同等。さらに2等戦艦と呼ばれる戦艦があるが上記戦艦の半分程度の規模だったり、巡洋艦は2等戦艦よりは少し大きめ。

水雷艇は、以下の場合、152tで乗員30人となっている。
http://ja.wikipedia.org/wiki/%E9%9A%BC%E5%9E%8B%E6%B0%B4%E9%9B%B7%E8%89%87

概算のために、4隻の戦艦で総トン数1.5万t*4、3000人とする。残り25-6=19万tに対して、1tあたり0.1人とすると1.9万人。0.3万+1.9万=2.2万で、トータル2~3万人規模だったと考えていいのではないだろうか。

ちなみに、以下のページでは4万人としている。また2011年3月末の海上自衛隊の定員は4.5万人であり、チーム東郷は現在の海上自衛隊の半分から同数に近い規模だったことになる。
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1440085914

近代でも同様だろうが、日露戦争時の海軍戦力は戦艦等の装備や事前の訓練に大きく依存し、開戦直前や戦時中の徴兵などでの増員は大きな意味を持たなかったと言える。これは現代でも似ていて、海軍の戦争/戦闘の長期化による大規模な乗員補充は、非現実的と考えて良いのだろう。

チーム東郷は、2ヶ月で実戦を行っている。バルチック艦隊は合流という事情はあるが、半月で実戦。ドラマでは海外からの特派員がちらっと登場するが、相手のあることなので準備等に余りに時間を掛けるのは良くない。かといって、時間が短すぎるとチーム形成や訓練が不十分となる。日本海海戦の実戦までの、2ヶ月 Vs. 半月は大きく影響したと考えられる。(ちなみに太平洋戦争時、山本五十六長官就任~真珠湾攻撃と考えると実戦まで4ヶ月である。ここでの長官就任は、2度目の1941/08/11。)

チームの規模などで汎用的には言えないにしても、大規模チームの実行/実施までには月単位を意識しておくべきということなのかもしれない。それ以前には、作戦検討や訓練(ITやソフトウェア開発なら仕様検討などに相当やプログラミング等の教育)の期間を必要であるが。


・マトリクス組織との関係

常設艦隊の寄せ集めてチーム編成でありながら司令長官の権限を考えると、一般的に言われる「強いマトリクス組織」と言える。ここでの”強い”は、プロジェクト型組織に近いといった意味。

しかし、作戦(特に日本海海戦)での統一的な行動実践のためには、砲術、航海術、水雷術などのレベル合わせや統一行動のための戦術確立が必要だったと思われる。

現代の(ITなどの)プロジェクトで、ややもすると統一感に欠けてしまう問題も少なくない。その際のルールの形成や適用とか、そのための工夫などでチーム東郷の組織形成は参考になる。


・海軍省などとの関係

連合艦隊の艦船やその装備を考えると、海軍省による軍備拡張や技術開発などが勝因の背景になっていることは明らかである。連合艦隊と海軍、軍令部、大本営の対立はあっただろうが、協力しあったと考えるべきだ。(少なくとも、第二次世界大戦での陸軍と海軍や軍内部等での対立よりはましだったのではないだろうか。)

参謀らの海外留学の実施したのも海軍省である。参謀らの海外からのレポートや学校での作戦案などの記述も少なくなく、これらは海軍省が保管や必要に応じた配布を行っていたと思われる。

加藤参謀長が海軍省軍務局の局員だったことでスムーズに進んだこともあったのではないだろうか。ちなみに、加藤参謀長は、連合艦隊参謀長の後に海軍省軍務局局長になっている。(蛇足だが、日本海海戦当時の軍令部長は伊東祐亨で、(日清戦争の頃の)初代連合艦隊司令長官。東郷と同じ薩摩出身。東郷平八郎は連合艦隊司令長官の後は軍令部長になっている。)

大本営は連合艦隊と同様に戦争を意識した臨時的な組織であり、戦時での最高統帥機関である。日露戦争では、1904/02/11に設置され1905/12/20に解散した。チーム東郷の設置に対して2週間ほど遅れ、解散は同時である。大本営はとかく大東亜戦争でのイメージが悪いが、戦争の継続や中止を指示できる組織体としては必要だったと考えてもよい。(だだし陸軍大臣や海軍大臣発言権や文官参加の扱いなどが、その後、歴史的には問題となったと言える。) また現代プロジェクトにおいて、継続や中止といったポートフォリオ的な判断を行う組織体をどうするかは課題だが、個人的には(PgMOや)恒常的な組織体で行う方が良さそうに考える。

ドラマでは、海軍大臣山本権兵衛と常備艦隊司令長官日高壮之丞(中尾彬)との”取っ組み合い”や大本営の口出しを諫めるのシーンが印象的だった。前者は我の強い日高を嫌ったとされる。後者は東郷らが津軽海峡に移動しようとしたのに対して、大本営側は対馬に留まるべきと命令しようとした。結果的には大本営側の予想が正しかったことになるが、もし大本営が口出していたらより大きな混乱が発生したと思われる。(津軽海峡への移動の件は後でも述べる。)


・微妙な人的バランス

山本と日高との関係や島村と加藤など、ライバルだったり、同期や親友だったと人間関係が微妙なバランスの上に成り立ってる。作戦や軍拡などについても考えの相違があるし、性格の違いも大きい。同じ薩摩閥/長州閥でありながらもエピソードなどでは、子供の頃も含めた喧嘩が書かれているし、相手を気に入らなかったとの懐述などもある。逆にお互いに仲が悪そうながらも、状況では共同したり信頼しあっているケースもある。島村と加藤の関係はドラマでは余り触れていなかったように思うが、同期で主席と次席。参謀長の交代がありながらもチームメンバーとして共存していった。

日露戦争関係でより端的なのは、陸軍の児玉源太郎と大山巌の関係だろう。児玉は、内務大臣から参謀次長や満州軍総参謀長へという降格人事を受け入れている、あるいは自ら願い出ている。

さらには長官や参謀には、秋山の奇行を含め一癖も二癖もある人が少なくない。秋山の奇行はドラマでもいくつか登場したが、本やネットでの記載は非常に多い。秋山好古の風呂嫌いなども含め、現代で実際に席が近くだったら総スカンだろう。当時は基本的に意見の衝突はありながらも、プロジェクト遂行時には奇行や性格などの点は気にしなかった/気にしないようにしていたのかもしれない。

ただし、ある程度のガイドラインを持って望んだと考えられる。ドラマでの端的な例は、島村の秋山に対する行動だろう。秋山の就寝に無頓着な事は大目に見たが、陸軍に掛け合うと小舟を出そうとした際には相手を間違っていると投げ飛ばした。

また、日本海海戦での東郷の判断ミスを第2艦隊が救った逸話も面白い。第2艦隊の司令長官上村と参謀佐藤。しかも、それを死ぬまで二人とも口外しなかったらしい。明治人の気質でもあったのだろう。

http://ww1.m78.com/russojapanese%20war/8%20point.html
http://www.nichiro-sensou.com/person/satou_tetsutarou.html

これらが、ダイナミックかつ俊敏なプロジェクト遂行の一因とも言える。近代的/欧米的なプロジェクトマネジメントでは余り検討されない事項ではあるし現代では難しい面もあろうが、参考になる部分も少なくないと考える。


・権限委譲

ドラマでは山本権兵衛が大本営の口出しを諫めるシーンなど、権限委譲では参考になる部分が少なくない。ドラマの第10回「旅順総攻撃」の回での大山巌と児玉源太郎の会話も印象深かった。乃木希典の基地を訪問する直前、近くに部下もいる馬上での会話である。「満州の作戦は~、全部児玉さーに任せちょいもす」。(鹿児島出身の自分には放送用薩摩弁に思えるが、まっそこは気にしないことにしたい。) 

蛇足:ドラマで山本権兵衛に口出しをした大本営の人物は、財部彪(たからべ たけし)。秋山とはライバルで、秋山が議論で深く遣り込めてしまったこともあった。ただし、財部は山本権兵衛の娘婿。むしろ秋山が組織的には不遇だったとも言えるし、もし口出しを諫めるとしてもドラマとはちょっと違ったやり取りだったと思われる。

加藤参謀長と秋山参謀の進言による、津軽海峡への北進への進言のシーンも同様だ。日本海海戦の直前、不安になり秋山参謀は加藤参謀長と共に、東郷の元を訪れ北進の封密命令を発行して欲しい旨を進言する。東郷は加藤の意見も確認して、二人がそう言うならと同意する。なお、その後島村と秋山からのどちらかと思うかの問いには、「敵がここを通るっちゅうて通る」 。

ドラマ上は、東郷は対馬を通ると思っていながらも、参謀グループの進言を聞き入れて封密命令を発行したことになる。ふと北進への封密命令進言を却下しても良さそうに思うが、ドラマの見せ場だし、史実で封密命令が発行されているのであのような設定になったと考えられる。ちなみに個人的には、もしチーム東郷は北進を実行しても、哨戒船や海軍からの情報の入手、そしてチームの対応力でリカバーできたのではないかと思える。(封密命令に関しては、エピソードのコーナーで再度述べる。)

現代のプロジェクトでも、マネージャーとメンバーの意見相違が発生することは少なくない。意見を引き出したり、合理的な議論を行う必要がある。その上でなら、マネージャー自身の意見や考えを引っ込める覚悟も必要である。

相手に依存したり、技術的にも未知なケースもあり得る。その場合は、運を天に任すしかないのだろうが、リスク想定とかリカバリープランを検討した上でだろう。


・教育

島村は海軍兵学校での教鞭を、秋山真之は海軍大学校教官を経験している。既述の訓練や戦術確立に、これらが役立っていると考えられる。ちなみに島村は、日露戦争後に海軍兵学校の校長を務めた。

海軍大学校、将校などの教育のための海軍兵学校/海軍機関学校/海軍経理学校、術科のための海軍航海学校/海軍工機学校/海軍工作学校/海軍水雷学校/海軍通信学校海軍潜水学校/海軍砲術学校などが用意されていた。後者には、軍医や衛生の学校も含まれる。

ドラマでも兵棋演習の様子が出たが、実践的で勝敗が明確に判明する教育は効果的だったのだろう。またドラマにも登場する内筒砲射撃やロシア船種の暗記などは、連合艦隊になって(さらに)行ったと思われる。それらの訓練企画も参謀グループが行ったのではないだろうか。ちなみに内筒砲射撃は、実弾の代わりにライフルを使用して方位などが正しく設定できたかが判明する。対比的に考えれば、ソフトウェア開発で新入社員教育などを通じて一定レベルにする会社もあるが、そうでもない会社や委託先の技術レベルに無頓着なケースも少なくない。

ただ、ドラマの日本海海戦の東郷長官の右手振り下ろしのシーンが示すように、行動では俊敏さが要求される。学校での演習や議論は重要だが、実践では大なり小なり持論を引っ込めることも必要だ。具体的にドラマで出てきた記憶がないが、現地での訓練等を通じて作戦実施のための戦術議論の収斂などを行ったのだろう。つまり、教育から実践への収束。昨今はプロジェクト中の議論や検討が長すぎたり、それによる長期化を含めた弊害が少なくないと考える。


・失敗への対応

チーム東郷は、失敗への対応が有効だったものがある。代表的なものは、黄海海戦での丁字戦法の失敗とバルチック艦隊の誤報である。

前者は、黄海海戦で丁字戦法を実施したがタイミングが良くなかったというもの。そのため日本海海戦では、ぎりぎりまでターンを行わなかった。後者は、5/23に仮装巡洋艦 「佐渡丸」 からバルチック艦隊発見の報(ただし誤報)への対応がまずかったというもの。誤報に関しては以下など。

http://www.sakanouenokumo.com/setteki.htm
http://navgunschl.sblo.jp/article/48178038.html

上での下の方では、それ以外でも誤報による小さな出撃はあったようだ。また信濃丸による発見時も、情報の錯綜が発生しているように思える。

上の2つのような大きな問題では、作戦や通信設備や方式の見直しを行っている。これらはドラマ等では表現されにくいが、念頭に置くことでプロジェクト的に身近に感じることができるし、その対応の重要性を認識できると言える


・骨休み

連合艦隊自体は、発足から解散まで2年間ほど。旅順口閉塞作戦から日本海海戦まででも1年3ヶ月ほどかかっている。ただし、三笠をはじめとする第1,第2艦隊は1904/12/16、旅順から一旦日本に帰還する。修理やフジツボの除去など行うため。翌年の1905/02/21に、また朝鮮半島の鎮海湾に戻る。ウィキペディアや以下などに記載されている。

http://www.ne.jp/asahi/chronicles/map/nichiro_keii.htm

ちなみにドラマでは、一時帰還した秋山参謀が、東京で久々に家族と対面するシーンがあった。

つまり旅順口閉塞作戦から10ヶ月ほどして、2ヶ月間の一休み。その一休みの後に、3ヶ月の現地待機や日本海海戦が敢行される。

戦艦三笠の速力は18ノットであり、装甲巡洋艦の八雲や浅間のそれは20.5ノット/21.5ノットである。対するロシアの戦艦スワロフの速力は17.8ノットであり、長い航海でのフジツボ付着のことを考えると、この連合艦隊の一時帰還は有効だったと言える。(ロシアの巡洋艦ナヒモフは16.3ノットと日本の巡洋艦よりは遅い。ただし他の艦とかまで調べきってはいない。)

本来は黄海海戦後にでも帰還したかったが、旅順艦隊への備えや陸軍による203高地攻略の援護の意味もあって、203高地攻略を見極めてからの帰還になったのだと思われる。黄海海戦などでの破損部分の修復や、戦艦初瀬と八島の沈没に伴うチーム現地で行える再編成の検討なども併せて行ったからかもしれない。

実は一旦日本に帰還した際に、運動会を催している(ようだ)。以下の2つのうちで、下の方が現代訳で、第2艦隊司令長官上村彦之丞の指揮とある。

http://navgunschl.sblo.jp/article/47337730.html
http://navgunschl.sblo.jp/article/45396572.html

上記の気分転換などを含めて、これら気分転換は現代でも参考になると考える。半年とかテンション張りっぱなしでは、メンバーが持たない。


・用意周到さ

既に述べたように、連合艦隊とバルチック艦隊の戦力比較では、総トン数などで日本の方が上回っていた。バルチック艦隊が日本に近づくのを早期に発見するために、哨戒艦船73隻を対馬近海に格子状に配している。また、丁字戦法(のみ)がクローズアップされるが、作戦計画は”七段構え”としており、丁字戦法は2段目の作戦であった。

東郷は、「連合艦隊戦策」なるものを1904/01/19に、改訂を1905/04/12発行している。これには丁字戦法なども書かれていた。1904年1月はチーム東郷が形成されて間もなくである。なお、”連合艦隊戦策”で検索するといくつかヒットするが、他の改訂の発行などを記載してあるものもある。細部までは確認していないが、いずれにしろこれらのドキュメント(小冊子)を早期に配布し、メンテナンスして周知徹底して行ったことは確実だろう。

また直接連合艦隊が実施したわけではないが、バルチック艦隊に対して外交力で寄港を限定的になるようにしている。イギリス漁船を日本の待ち伏せと誤認してバルチック艦隊が攻撃したドッガーバンク事件によるロシア批判も追い風になった。(日露戦争全体では、明石によるロシア工作なども日本勝利に影響している。)

現代風に言えば、リスク管理なりコンティンジェンシープランの策定を十分に行っていたことになる。

さて、日本海海戦などを調べていくと、結構面白いネタにぶつかる。以下でいくつか紹介する。

・エルトゥールル号遭難事件

「エルトゥールル号遭難事件」は、1890年軍艦エルトゥールル号が、日本への訪問の帰路、現在の和歌山県沖で遭難したというもの。”エルトグルル号”とも。またここでは、当時はオスマン帝国だったが、現在との関係でトルコとして記載する。

587名が死亡または行方不明だったが、69名が救出され、日本海軍の「比叡」と「金剛」でトルコに送り届けた。トルコ国民はいたく感謝したとある。その関係か、日露戦争での日本の勝利を記念して、トルコのイスタンブールには”トーゴー通り”がある。また、1985年のイラン・イラク戦争の際に、在留邦人の避難がトルコ航空のお陰で行われた。

エルトゥールル号遭難事件で、トルコに送り届けた「比叡」に秋山参謀は乗船していた。当時海軍兵学校を卒業し海軍少尉候補生で、満22歳。

http://ja.wikipedia.org/wiki/%E3%82%A8%E3%83%AB%E3%83%88%E3%82%A5%E3%83%BC%E3%83%AB%E3%83%AB%E5%8F%B7%E9%81%AD%E9%9B%A3%E4%BA%8B%E4%BB%B6

http://ja.wikipedia.org/wiki/%E3%83%88%E3%83%AB%E3%82%B3%E8%88%AA%E7%A9%BA

・信濃丸 地点203

ドラマでもバルチック艦隊の発見地点は”203”。203高地の203と偶然にも一緒となった。

この番号は、バルチック艦隊の哨戒のために緯度経度をそれぞれ10分ずつ格子状に区切り、それぞれに203、204などと振ったものである。(10分は、だいたい18.5Km。イメージ的には20キロ四方といったところか。)

で、ウィキペディア「日本海海戦」などにも書かれているように、信濃丸からの発見電文を 『タタタタ(モ四五六)「YR」セ』としているものが多い。456は時刻ではなく地点、つまり203ではない。(タタタタは、モールス信号のトンツーの類のようだ。)

地点が203なのに電文が456である理由は、調べても余りよく分からなかった。以下での写真などが”456”と書かれている電文のようだ。(個人的には、部署ではなく本当に各人に回覧したのか、回覧印も気になった。) 他のサイトなどにもある。

http://yfm24651.iza.ne.jp/blog/entry/2360759/

そもそも地点456の電文は、日本海海戦の終盤での電報が残っており、それを発見時の電文として写真等が残っているとしているものがある(多い)。その意見では、そもそもの最初の電文には位置情報が無く、後の確認で203と判明したというもの。(ちなみに「坂の上の雲」では456を時刻としているとのネット記載もある。) 例えば以下のように、元々の電文は『KKKKKK…タタタタ…(モ203)〇四五〇。「YR」「AI」「AI」「AI」…』だったとする意見がある。

http://nemuihito.at.webry.info/201106/article_4.html

なんとなく個人的にも、上が妥当な気がする。つまり、日本海戦終盤での信濃丸からの456の電文が、発見時の電文として広まってしまったように思える。

なお本来このようなことが話題になれば、無線担当者やその部署からの意見があっても良さそうだが、そもそもそのような部署の人達は分かってても発言しないのだろう。また、省略などを多用して明示的に暗号に近くしたり結果的に暗号っぽくなった可能性もある。ただし個人的には、誤報や不要な出撃などの遠因にも思えるので、改めるべきだったのではないかと考える。

・信濃丸

太平洋戦争時は輸送船となり、漫画家「水木しげる」が乗船した。(ウィキペディアの「信濃丸」の項に書かれている。)

・山本五十六

日本海海戦では、太平洋戦争時の連合艦隊司令長官 山本五十六も参戦。そこで指欠損や大腿部重傷を負う。ちなみに搭乗していたのは、装甲巡洋艦「日進」。

「春日」と「日進」の2隻はイタリアの建造で、本来の納品先はアルゼンチンだった。それをイギリスの仲介で日本向けに変更してもらった。日本(横須賀)に着いたのは1904年2月26日で、日露戦争開戦後、旅順口閉塞作戦の第1回が失敗した後である。

山本五十六は2004年11月に海軍兵学校を卒業、満20歳。既に述べた連合艦隊の一時帰国での2005年1月に、日進に乗船している。そして日本海海戦を経験。言わば、ちょっとしたOJTの後に、とんでもないプロジェクトの配属になったのと似ている(かもしれない)。

・東郷と秋山の生年月日

東郷の生年月日は1848/01/27。秋山は1868/04/12。いずれも太陽暦。20歳の違いである。秋山は明治元年生まれなので、満年齢は明治の年代にするとイメージ涌きやすい。(明治5年12月に太陽歴に移行するので、あくまで概算しやすいという程度。)

・共立学校

秋山参謀は「共立学校」などで受験英語を学び、大学予備門(のちの一高、現在の東京大学教養学部)に入学した。共立学校の校長が高橋是清で、秋山や正岡子規に英語を教えた。共立学校は、現・開成高校。正岡子規の死後に妹の律が通ったのが「共立女子職業学校」。共立学校と共立女子職業学校は、設立などでの関係はないようで、横浜共立学園とも無関係。

ところがドラマでは、秋山夫人の季子(すえこ)が律と一緒に共立女子職業学校の門を通るので関連がありそうに思ってしまう。季子との引き合わせのシーンで、高橋是清や秋山が同席したように思うのでなおさら。

・北進の封密命令

日本海海戦でちょっとミステリアスなのは、バルチック艦隊が対馬に現れるかの議論やそのための封密命令発行だろう。

そもそも東郷や秋山は最初から最後まで対馬に来ると予想していたのかとか、封密命令は実際発行されたのに実行されなかったのはなぜかといった疑問である。

個人的には、以下での“秘められた密封命令”以降が説得力があると感じる。藤井較一参謀長の意見で議論が継続し、実行が遅くなったというものである。島村司令官(前参謀長)の影響も大きかったとしている。

http://plaza.rakuten.co.jp/jinburo/007003

他に以下のように、松井参謀も対馬沖との考えだったようだ。

http://www.z-flag.jp/suigun/tsushima_war/episode.html
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1273497767

・バルチック艦隊発見

バルチック艦隊発見は、1905年5月27日午前2時45分、五島列島近くの仮装巡洋艦「信濃丸」により行われた。それ以前にも上海でのバルチック艦隊の石炭輸送船入港の知らせもあった。上の“秘められた密封命令”以降での26日の記載がそれに当たるし、ネットでもいくつか記載されている。

しかし、それ以前に沖縄沖で発見した漁民がいた。いわゆる「久松五勇士」。

http://ja.wikipedia.org/wiki/%E4%B9%85%E6%9D%BE%E4%BA%94%E5%8B%87%E5%A3%AB

http://www.kinenkan-mikasa.or.jp/epi/hisamatsu.html

23日の午後10時頃に発見したとなっている。ただし、電報訳は「5月28日午前8時10分」である。100キロを5時間かけて漕いだとしているので少しつじつまが合わない。で、色々探したら、以下での「第五章 情報伝達」のPDFの一部に書いてあった。電報を出そうにも、お役人に信じてもらえず時間が経過したようだ。※ただし、2012/02/10現在リンク切れになっている。第5章以外の東日本震災関連のドキュメントもリンク切れになっている。両方とも力作だったし参考になったので、非常に残念だ。

http://tomiokatomonokai.web.fc2.com/tosho.html

以下では推測を加えてとはしてあるが、お役人などによる時間の経過という点は納得できるのではないだろうか。

http://yaeyamanow.nanpusya.com/history24.html

・技術革新

日露戦争では、科学技術での日本の優位性もあった。ウィキペディアでは、36式無線電信機、下瀬火薬、伊集院信管などを挙げている。

http://ja.wikipedia.org/wiki/%E6%97%A5%E6%9C%AC%E6%B5%B7%E6%B5%B7%E6%88%A6#.E6.96.B0.E6.8A.80.E8.A1.93

36式無線電信機は、現在の島津製作所によるバッテリーが搭載されており、その関係で東郷による感謝状が創業記念資料館に展示されている。

http://www.kinenkan-mikasa.or.jp/epi/sinano-izumi.html

感謝状(感状)の文面では軍艦「和泉」宛のようだし、上でも”寫(うつし)”とある。東郷から受け取って、軍艦「和泉」のメンバーが寄せ書きし、さらにそれのいくつかの写しを作成したと思われる。その一つを島津製作所に与えたのであろう。いずれにしろ、当時の海軍が技術創出の重要性を認識していたことは確かだろう。

なお、東郷の信濃丸に対する感状の実物が公開されたというニュースもあった。

http://sankei.jp.msn.com/region/news/111111/kng11111122480007-n1.htm

・沈没情報

既に述べたように、当初の連合艦隊の戦艦は6隻。ところがうち2隻の初瀬と八島が、第3次旅順口閉塞作戦の5/15に沈没してしまう。ただし、八島は死亡者が無く海軍自体が沈没を伏せた。ロシア軍から離れていたり沈没まで時間がかなったこともあって、ロシアに気づかれなかった。

逆に黄海海戦では、日本海軍は旅順艦隊を撃破できなかったと思っていたが、その時点で艦隊としての機能を失っていた。日本軍の203高地からの旅順艦隊への攻撃もさほど効果がなかったとも言われているが、結果的には旅順艦隊を壊滅したことになる。

http://ja.wikipedia.org/wiki/%E9%BB%84%E6%B5%B7%E6%B5%B7%E6%88%A6_%28%E6%97%A5%E9%9C%B2%E6%88%A6%E4%BA%89%29

http://ja.wikipedia.org/wiki/203%E9%AB%98%E5%9C%B0

プロジェクトもそうであるが、間違った情報が入ってきたり、少ない情報で決断すべき時がある。それらの発生を前提とした対応が必要である。(なお、事後なら情報も整理されるので、当事者の間違いを指摘しやすい。しかし当事者のプロセスの改善や再発防止の提起がないと、単なる傍観者というレッテルが貼られるので注意が必要だ。)

以下のサイトでは、ドラマの出演者やあらすじを読むことができる。歴史上の出来事とドラマ上の回数なども分かるので重宝すると思われる。

http://www9.nhk.or.jp/sakanoue/cast/

http://www9.nhk.or.jp/sakanoue/story/01/

以下の「坂の上の雲マニアックス」は坂の上の雲ファンサイトで、小説もドラマも取り上げている。

http://www.sakanouenokumo.jp/


日本海海戦を調べると、バルチック艦隊のアフリカ喜望峰経由の遠洋が、ある意味奇跡的とも思えてきた。逆にそれを敗因と考えるとすると、日露戦争以降に、なぜそこから学ばなかったか不思議な気もする。太平洋戦争でのハワイをはじめとする太平洋への進出である。机上演習などで、局所戦以外に遠洋を含めた大規模戦を行ったりしたのか、興味を覚えた。現代でも、事例研究を本や海外のそれに求める傾向が少なくない。日本の特質なのか? 組織内の事例や身近な事例の研究を行ったり、その知識共有に踏み込む必要があるのだろう。(昨今は、ITプロジェクトの失敗事例などの社内共有化を実践しているところも増えてきたが。)

また、日露戦争での賠償交渉では、ロシアは負担の少ない格好で条約を締結できたと言える。薩摩・長州はそれぞれ薩英戦争や下関戦争で外国に敗れてはいるものの、その責は幕府にあるとして賠償などは行っていない。それを考えると、日本は幕末以降でも、上手い格好での敗戦を経験したことが無いことになる。(なお薩英戦争や下関戦争の発端は天皇からの攘夷命令であり、その後の倒幕運動になることを考えると歴史の皮肉とも言える。)

東郷は連合艦隊の解散の辞で「古人曰く、勝って兜の緒を締めよ」と結んだが、勝利した原因やロシアの敗因を後世に活かせなかったとも言える。また、もし203高地を奪取できなかったり日本海海戦で敗れた時に、大本営を含めたどこが停戦を判断すべきだったかと考えるのも悪くないと考える


日露戦争をプロジェクト視点で考えることで、チーム編成やリスク管理など参考になることが多い。特に日本ではチーム編成を意識する人は少なくなく、その意味でドラマなどで深掘りできるのは良い教材とも言える。ドラマでは、意見の衝突などが生々しい。プロジェクトマネジメント上で組織の衝突(コンフリクト)は当然であるし、チーム形成では特に初期のそれは必然と言われている。そのような視点でドラマを眺め自分のプロジェクトと対比するのは悪くない。(ドラマなので、多少誇張の部分はあるだろうが。)

逆に日露戦争~太平洋戦争を俯瞰して成功の固定化と失敗と考えると、企業活動でも大なり小なり発生すると言える。昨今の日本のいくつかの産業の衰退や企業内での不採算の部門や不祥事の部門で、成功体験足枷が時々取り沙汰される。その視点での予防策の検討としても良い教材となるだろう。

蛇足:Facebookでの知り合いとのやり取りでは、日露戦争陸軍のことや、太平洋戦争(チーム山本と呼ぶべきか)のことも調べたらと言われた。しかし、大変そうなことと、個人的にはチーム東郷やその周辺の深掘りが似合ってるような気がする。ということで、悪しからず。

2月 14, 2012 プロジェクトマネジメント, プロジェクト管理, 歴史 | | コメント (0) | トラックバック (0)

2011年12月28日 (水)

日経のプロジェクト成功率

日経SYSTEMSの「さらば失敗プロジェクト」に関連して、日経コンピュータでのプロジェクト成功率を再確認した。5年毎なので、次回は2013年かと思われる。その頃にでもと思ってたけど、日経SYSTEMSの記事に誘発される格好で今のうちにまとめてみる。

日経コンピュータのプロジェクト成功率の記事は、2008年12月1日号と2003年11月17日号。ざっと表にしたものを以下に示す。

成功率 Q Q(母数比) C  C(母数比) D D(母数比) 送付数 回答数 回答率
2008年12月1日号 31.1% 51.9% -/212 63.2% 277/438 〔393〕 54.6% 239/438 〔392〕 8800 814 9.25%
2003年11月17日号 26.7% 46.4% -/1198 76.2% 1138/1493 54.9% 843/1558 〔1522〕 12546 1746 13.9%

母数比は、回答数と成功数。そこでの〔〕は、クロス集計上の回答数。2003年の11月17日号でのDの54.9%は、回答数1558に対して満足なのは843件で54.9%であったが、クロス集計上は1522件を回答としたことを示している。(なお、843/1558=54.1%であり、記事での数字はどこかが誤記かと思われる。 Qの成功数を”-”としているのは記事に明記がなかったためだけである。)

Q(品質)、C(コスト)、D(納期)で、成功としているのは以下。
Q:「計画通りのシステムが完成」しており、しかも「満足している」
C:計画通りあるいは計画以下のコストで完成 (次の選択は「2割未満の超過)
D:計画通りあるいは計画より前倒しで完成 (次の選択は「計画から2割未満の遅れ)


QCD全てをクリアしたものを成功としているし、Qはシステムに対する満足である。それを考えると、成功率3割は頷けなくはない。逆に成功の反対を失敗と捉えて、失敗率7割と言うのには違和感がある。(ちなみに良く引用されるアメリカのスタンディッシュグループでの調査も、3つともクリアを成功と定義しているようだ。ただし向こうでは放棄の%が少なくない。)

ちなみに、CQDの一部をクリアしている割合は明示されていない。あるいはQCDともクリアしていない割合が知りたい数字かもしれないが、そちらも示されてはいない。あくまで数値からの類推だが、2008年でのQCDともクリアしていない割合(駄目プロジェクトでも呼ぶべきか)は、1割程度ではないだろうか。これは各QCDのクリアが5割程度であるためである。(単純に1/2*1/2*1/2と考えると1/8。)


CとDでの計画通りに、1割程度の相違を含めるかも記事からは判明しない。回答者が判断しているのかもしれない。個人的には、1割程度の相違は計画通りに含めているような気がする。

このアンケートは、回答社での直近の1プロジェクトに関してのものである。えてして、その会社の画期的だったり大規模なプロジェクトになることが予想される。その前提で数字を考えるべきだろう。(一般的に、コストがかかったり期間が延びやすいと考えられる。)


なお、結構議論のある所に、計画時点をいつと考えるべきかがある。特に要求仕様追加などが発生した時の、”計画”時点。追加前の当初の計画時なのか、追加後の再計画時なのか。再計画時とすべきと考えるが、アンケートで明示されているのかも気になる。

アンケートの回答率が下がっていることも気になる事項である。2003年では他社との比較もあって積極的に回答したが、2008年時はプロジェクト失敗の数字が一人歩きして「IT部門は、、、」の材料になったりして、うんざりしたのかもしれない。あくまで個人的な推測。


次回のアンケートでは、CやDの成功範疇や、再計画との関係が明確になるか気になる。出来れば、CQDの一部はクリアしている割合の明示も期待したい。また、次回の有効回答率にも興味があるところである。

12月 28, 2011 プロジェクトマネジメント, プロジェクト管理, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2011年12月24日 (土)

日経SYSTEMS 1月号「さらば失敗プロジェクト」

日経SYSTEMSの「さらば失敗プロジェクト」、知り合いのつぶやきから数日前に知ってたけど、今日雑誌の方を細部で確認。

いくつかの事例が書かれたルポの方は(失敗例として)頷ける部分もあるが、問題は最初の方の数値の列挙。「プロジェクトのうちに94.5%に深刻な問題が発生して、そのうち89.9%が同じ失敗を繰り返している」としている。

0.945*0.899=0.85 で、前プロジェクトのうち85%は、同じ原因で失敗していると読み取れる。

今となってはアンケートの原文がネットにないので何とも言えないが、今回の記事の本文でも質問は「あなたが現在または直近で関わったシステム開発プロジェクトについてお聞きします。そのプロジェクトでは、右に挙げる問題が発生しましたか?」。(右に挙げる)問題として、スケジュール遅延などがある。本アンケートは、ネットのITpro上で行ったものでその記事は以下。

http://itpro.nikkeibp.co.jp/article/Watcher/20111024/371258/

有効回答は73。上のURLでの記事で分かるように、そもそも、問題意識を持った人が回答したと言える。しかも、今回の記事では、問題がある→深刻な問題発生となっている。(アンケートの設問に、”深刻な問題”とあったのなら撤回すべきだろうけど。)

プロジェクトなので、あるいは定常の業務でも、日々問題は発生する。それを解決していくのが、ある意味プロジェクトマネージャーの仕事。日程遅れなども1割程度は許容範囲だろう。最初の日程は大枠であり、段階的な詳細化などを通じて具体的になっていく。最初の大枠での”案”に対して、1日遅れたら失敗との烙印は普通は押さない。(日経での別調査でも、1割の違いは失敗とはしていないはず。これらは他でのプロジェクト失敗率などと一緒に別途調査。)

また、別の設問は「現在または直近で関わったプロジェクトで発生した問題は、以前にも繰り返し発生しましたか?」。それが、記事では同じ失敗を繰り返しているとの表現になっている。同じ問題の発生と、同じ失敗は違う。多分回答者は、”以前もスケジュール遅れが発生したな~”程度で、Yesにしたのだと思われる。

なんか今回の記事での数字は、言葉で妙にバイアスがかかっているように思えてならない。気になっているのは、この類の数字が学会などでも利用され、まるでIT業界は駄目チームのように受け取られること。就職先として人気無くなるだろうし、社内には過度に反応して非常に細かい管理で対策しようとする所が出てくる。極論だろうけど、開発ベンダーの資金調達などにもマイナスになる。ぎりぎりセーフや上手く回っているプロジェクトが、たくさんあるのに/あるだろうに、、、。

12月 24, 2011 プロジェクトマネジメント, プロジェクト管理, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2011年9月 1日 (木)

QCDバランスと三角グラフ

QCD(Quality:品質 Cost:コスト Delivery:納期)のバランスをどうするかは、プロジェクトそのものの方針やプロジェクトマネジメントで大きな課題だ。また、そのバランスの可視化は、以前から少し気にしていた。

「アジャイルサムライ」のP89に”トレードオフ・スライダー”の名前で紹介されているのがあり、調査。アジャイル系コミュで以下のサイトが紹介されていて、ちょっと使ってみた。

http://www.mountaingoatsoftware.com/tools/project-success

Photo_2Web上でできるのが、なかなか良い。ただし、自分の頭のイメージにあるのと少し異なる。

トレードオフ・スライダーを見て、自分の頭に漠然とあるものを具現化できる術がないか、ちょっと考えてみた。グラフ種になかったけ?と思って、(今はあんまり使ってない)DeltaGraphのマニュアルを見たら、すぐに見つかった。”三角グラフ”。もっと早めに気づくべきだったかも。

で、Web上で書けるツールはないか探したけど、すぐには見つからなかった。DeltaGraphなどで書けるのは判ってるけど、、、。ちょっとエクセルのアドオンなどにないか調べたら、そちらですぐに見つかった。「Excelによる統計グラフ表現法」第32回(古田 裕繁 著)を参考にしたマクロのようだ。

http://www.sinfonica.or.jp/kanko/estrela/refer/s16/index.html

マクロをインストールするというよりも、ここでの(マクロを含んだ)エクセルシートを利用してグラフを作成してみる感じ。使い方としても、その方が良いかもしれない。

Qcdそれを利用して、品質50%、コスト40%、納期10%をグラフ化したもの。マクロのためのセルがあるようで、敢えてそれらはそのままにした。

プロジェクトでのQCDバランスを可視化しておくには、このようなグラフを残しておいた方が良いかもしれない。最初は品質重視と言いながら、テスト工数などを見積もる/見積もらせることもなく日程が延びたりコストアップ。プロジェクトのさらなる上位層は、後の方になって”がみがみ”。雑誌の記事などで、そんなことが少なくないように思う。プロジェクトの開始時に、このようなQCDのバランス図を記録に残しておけば、少しはましになるのではないだろうか。

なお、ここでは作図ツールを利用したが、線の入った三角形の図のみをプリントして、マグネットか何かを上に置いてデジカメ撮影したものを残す方式でも良いだろう。あるいは、それを壁に貼っておく方法。

ちなみに、QCDバランスでは、3つの合計が100%になる必要があるが、グラフ上はそれ以外も作成できる。したがって、100%に制限するようなマクロとか操作方法も考えられる。が、余力があればかな。

また、上で書いたマグネットを置く方法では、厳密にはその中心で3つの合計が100%になるとは限らない。ただし三角形の中なら、(多分)誤差の範疇だろう。さらには、QCD以外の要素を含めるケースもあるようで、4軸なら「Jチャート」と呼ぶグラフもあるようで利用できるだろう。(個人的には3つのバランスで十分とか、3角グラフを複数用意する方式でも良さそうに思う。)

9月 1, 2011 ソフトウェア, プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2011年7月17日 (日)

PMI日本フォーラム2011

今日は、PMI日本フォーラムへ。本来は昨日と今日だったが、今回は土曜日に用事が発生したので、片方の今日のみの参加。ネットワーキング(懇親会)に出られなかったのは、少し残念。また、その関係もあって、ここ何回かフォーラムで会ってる人には会えなかったり、遠目で見かけたり、簡単な挨拶しかできなかったりした。そちらも少し残念。

ちなみに、最近都内に出向くことが少なくなったせいで、昼休みも含めて色々神保町界隈のお店を回ったりした。お昼ご飯は、やよい軒で、2.5杯^.^;、ついでにさかいやスポーツ。フォーラム終了後は、本屋さんやICI石井スポーツ、手羽先の「世界の山ちゃん」など。


聞くことのできた講演は少なかったけど、その範囲での感想。

・M-7 「日立グループのガバナンス戦略」

グループ全体としてのITの効率化の講演。個人的には面白い講演との認識。(多少具体的なこともあり)大勢を前にした講演としては、珍しいように思う。

取引コードのグループ内共通化は、是非関連する事項などを別の機会にでも聞きたいとの個人的な思い。他にも、出資率が100%未満とか50%未満のケースなども気にはなる。

・M-10 「NTTデータのオフショア戦略」

オフショア開発の話が多かったが、個人的にはNTTDは国内を含めたM&Aが活発で、その背景にある考え方に触れることができたような気がする。

・M-11 「PMBOKガイド、ITIL-V3およびBABOKの、組織における標準化についての考察」

講演者とは懇親会か何かの折りに、直接の本件ではないが、関連するような事が話題になったような気がする。そこそこの組織体だと、その組織体のプロセスを持っているので、いくつかの規格やBOKの類を統合している。その辺りの考え方を、まとめてくれたもの。後日、講演資料を深読みしてみるつもり。


なお、会場では協賛会社の展示も行われていた。個人的に今回少し目を引いたのは、「CA Technologies」のツール。アジャイル系のツールから従来のプロマネツールへのデータ(変換/)転送の機能があるツール。細部までは聞けなかったが、バックログをタスクやWBSに変換するのだろう。サービスでの供給のようで、値段も思ったよりも安かった。従来のCAのプロマネツールを導入しているところにはメリットだろうけどと思いながらも、この類の統合化が必要な所は少なくないだろうと前々から感じてはいた。


自分の聞いた講演の範囲になってしまうが、IT色が少し薄らいだような気がする。事例はITであっても、プロジェクトマネジメントの視点で置き換えての説明になっているように感じた。うまく行ってるITプロジェクトだってあるわけで、個人的には今回の方が自然に思えた。

来年も7月みたいだ。来年は、2日とも参加できるようにしたい。

7月 17, 2011 プロジェクトマネジメント, プロジェクト管理, 日記・コラム・つぶやき | | コメント (0) | トラックバック (0)

2011年4月 8日 (金)

「はやぶさ、そうまでして君は」

昨年の年末には購入して、しばらく積ん読状態。2ヶ月近く前に読み終わった。そういえば感想を書いてなかったと思い、メモのつもりで記載。

「はやぶさ」のプロジェクトリーダー、川口淳一郎氏によるもの。

多少淡々と「はやぶさ」のプロジェクトのことが述べられており、熱狂的な”奇跡の生還”みたいな書き方とは一線を画す。個人的には、この方が冷静にプロジェクトのことを知ることができて有益だった。

プロジェクトスタート時の、成功するか失敗するか判らないような状況。ちょっとしたきっかけなどでのプロジェクト承認。場合によってはハッタリ。そうはいっても、いくつもの難関とか挫折。先覚的な商品化とかシステム化や、一般的なそれらでも遭遇しそうな事が発生している。

印象的だったのは「『尻を叩く』よりも『どこで手綱を引くか』を考えることが多かったと思います。」。(P64) 一般的なプロジェクトでも、管理/監査みたいなことが主目的になってしまうことがある。現場の創意工夫に気づくことも必要だ。

サンプル採取に関するトラブル(ソフトウェアトラブル)にも、多少ページが割かれている。P145~。ニュース等で、プログラムのダウンロードミス(番号違いの類)のように思っていたが、内部の処理は複雑にできており単純なダウンロードミスとは言えなさそうに感じた。 しかも本失敗が判明したのは、直前に着陸成功の発表をしたばかり。本にはこの辺りの苦悩の様子が書かれている。さらに言えば、その後の通信途絶、その復帰のための予算獲得の活動が必要で、その対応も参考になった。。

ちなみに、通信復帰のためには周波数を網羅的に探索しなければならないが、搭載している水晶発振器の温度の予想を立てて範囲を求めたとのこと。温度は、温度制御が上手く働いてないことを想定しての範囲算出。 この類の話がこの本には多く、場当たり的な復旧作業でなかったことが判る。データに基づく作戦立案。ソフトウェアでのトラブル対策でも参考になろう。ロジックやテストデータがない状態の危険性を、肝に銘じておくべきと考える。

リチウム電池の復帰(補充電回路)の部分では、補充電回路がOnになったことが不思議と。P170~。 Onにするプログラムは入っていなかったそうだ。 当時のニュースと若干違う気もするが、まっそんな事もあるんだろう。

また帰還の際には、”太陽光圧”も利用したそうだ。P169。しかも姿勢制御プログラムの変更も対応したと。 なお、今になって詳しく調べたら、イトカワに向かう際にも太陽光圧(太陽輻射圧)のことは検討されていたようだ。

http://www.muses-c.isas.ac.jp/j/index_26.html

この本には、プロジェクトチームの洒落っ気というか遊び心にもいくつか触れている。

・イトカワの粘土細工コンテスト P117など
・はやぶさにちなんだ運用室暗証番号 P118
・カプセルに貼り付けたメンバーのカード P8(写真)、P208

自分の持論みたいで悪いが、うまく行ったプロジェクトには宴会とか上のような遊び心がつきものだ。(主要なメンバー構成で、だいたい成功/不成功は決まるように思う。) はやぶさのプロジェクトでは、「そんなことまでやったのか~」と知り、ちょっと楽しくなった。

また最後の方には、「二番ではダメなんですか?」、一番と言い続けるアメリカ(NASA)、そしてリスクとの関係についての考えが述べられており、参考になる。既に述べた事などを含め、プロジェクトのケーススタディーとして非常に有益な本と言える。

4月 8, 2011 プロジェクトマネジメント, プロジェクト管理, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2011年3月 3日 (木)

「The Software Project Manager's Bridge to Agility」

少し急ぎ足だったけど読んだ本。

英語の本で、既存のソフトウェア開発プロセスへのアジャイル手法の組込みを意識したもの。既存プロセスとして、PMBOKでのプロセスを前提としている。

非常に気に入ったのは、PMBOKでの各プロセスの番号(章/項:例えば「プロジェクト憲章作成」 4.1)が、そのまま同じ番号での章/項で使用されているところ。各プロセスで、従来の手法とアジャイルでの手法が対比的に表形式で述べられているところである。ちなみにここで記載した手法とは、PMBOKでの”ツールと技法”に近いといえる。

企業内の開発組織は、それなりの成熟度を持っているところが少なくなく、大なり小なり既に社内プロセスが確立している。そのような場合に、一挙にアジャイル手法を導入するには無理があることがある。製品の開発中とか、派生での開発で従来のプロセスを踏襲する前提の場合が、特にそうである。

そのような場合、小グループで実践するとか、一部のアジャイルプラクティスを導入するなどがよい。後者の場合、今回のような本は参考になるだろう。特に、従来の社内プロセスをPMBOK上のプロセスにマッピングしてある組織体とか、マッピングしやすい状況ならなおさらだ。

この本では、複数プロジェクトやPMOに関しても言及している。その部分も大規模プロジェクトなどには参考になるだろう。ちなみに、著者の女性2名はどちらも、PMPで認定スクラムトレーナー(CST)である。

なお、この本でベースとしているのは、PMBOK 3版。細部では4版でないことを気にする人もいるかもしれないが、3版と4版は大きな違いは少なく、各プロセス内やいくつかのプロセスの変更がほとんどである。そのため、実際に適用してみる場合に、各自でのプロセスに応じて検討すればいいのではないだろうか。

自分の回りには、PMP取得者とかそれなりの社内プロセスを持ってる人が少なくないので、勧めたい一冊である。


なお、関連して少し。

CMMIとアジャイル手法に言及した本も出版されている。書店で見かけたのが、左の本。

また、アジャイル系のTwitterつぶやきで見かけたのが、以下のサイト。スクラムでの手法とCMMIとの関連を述べている。


http://www.scrumalliance.org/articles/334-implementing-scrum-agile-and-cmmi-together

上のサイトでは概要しか書いてないが、それでも結構役立つのかもしれない。(ただし、自分の回りにCMMIを今も中心的にやっている人が皆無なので、感想などを聞くチャンスがないが。)


ちなみに、アジャイルでの手法とPMBOKを中心としたソフトウェア開発プロセスとの関連性は、結構以前から検討されている。

自分の持っている書籍の中では、この「実践アジャイル」がその代表。2005年出版。

2005年出版なので、PMBOKは2000年版をベースにしている。また、プロセスの記載順が、PMBOKでの立ち上げでの各プロセス→計画での各プロセス……となっているので、少し違和感がある。

ただし、今回「The Software Project Manager's Bridge to Agility」の紹介を兼ねて、この「実践アジャイル」を読み直したら、参考になる部分が結構あった。当時読み流していたんだろう。その意味では、今でも参考になる箇所が少なくない。

この「実践アジャイル」でも触れているが、「APMBOK(アジャイル PMBOK)」なるものがある。「実践アジャイル」著者のサイトにある。

その後オリジナルは新版発行されたが、日本語翻訳は行われていないように思っていた。しかし、オリジナル新版を探せていない。探したら、ここの部分に追記等を行う予定。


いずれにしろ、個人的にはアジャイル導入での困難さとかの議論には多少辟易している。困難だったことをどう克服したかならまだしも、弊害が多いとの意見に終始している。ここで述べた書籍などで、生産性や品質の向上を意識しつつ、現行プロセスとアジャイル手法の関連性を考えるのは良いことだといえる。


補足:当初、APMBOK(アジャイル PMBOK)が英国プロジェクトマネジメント協会(APM)によるものの日本語訳と記載していたが、どうも勘違い。APMがアジャイルを絡めている事と、ごっちゃになってたようだ。ちなみに、" APM Body of Knowledge"なるものはAPMから発行されている。

3月 3, 2011 ソフトウェア, プロジェクトマネジメント, プロジェクト管理, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2011年1月31日 (月)

CPDとPDUをやっと登録

やっと、2010年分や2009年分のCPDとPDUを登録した。どちらも資格継続のために必要なもの。ただし2つでは、登録必須とか資格喪失に直結するかは異なる。ちなみに、CPDは日本技術士会への登録で、PDUはPMIへの登録。

受講後の証明書の保管が余り良くなくて、それを整理するのに一苦労した。講演資料と一緒にしてるものがあったり、、、、。以前「これじゃいかん」とファイルを用意したけど、受講証明ってA4用紙に書かれているもの以外に、小さな領収書に代えるものが少なくなくて整理がしにくい。そのこともあって、保管整理が行き届いてなかった。領収書をクリアファイルの3ポケットタイプに入れたりしてたけど、A41枚や他の3ポケットでの講習と混在するので検索がしにくいし、日付順などに並べにくい。結局これからは、A4の1ポケットに統一することにした。

CPDの方は、日本語サイトということや以前から入力しているので慣れていた。自分でも覚えてなかったけど、2009年の途中までは入力済みだったのも気が楽になった。(当初のCPD登録は、システムの使い勝手が悪かったけど、今のシステムは個人的には満足。)

逆に、厄介だったのがPDUの登録。イベントや講習で「日本語の説明サイトがありますよ」と言われて簡単な資料なども貰ったけど、実際登録しようとすると色々不明なことが出てきた。自分の頭の整理も含めて参照したサイトを書いておくと、、、、。

・PMI日本支部での「PDUの申請について」

http://www.pmi-japan.org/pmp_license/renewal/pdu.php

以下の2つが参考になるけど、ここでの「入力ガイド」は、あくまでPMIJでのセミナー受講での例。

【最新版】PDU登録入力ガイド
【最新版】2010年10月版:PDU登録カテゴリー

・PMIの実際の申請のページ。

http://www.pmi.org/Certification/Maintain-Your-Credential.aspx

・「PMP資格更新のためのPDU申請マニュアル」

じゃ、PMIJでのセミナー受講以外の社内でのプロジェクトマネジメント活動とかはどう記載するんだろうと思って、たどりついたのが以下。教育系の会社?でのページみたいだけど、各カテゴリーでの例が書かれているのが良い。

http://pdupointget.web.fc2.com/about.html


また分かるとたいしたことないんだけど、受講時での受講証明書に、以下の2つがどっちか分かるようになってない。

 Provider number
 Activity Number

日本支部のガイドでの例に”C152”、"TK0401"って書かれているが、C152の方がProvider numberだとはすぐには分からない。自分貰った受講証明書のどれも、2つを並べて書いてるだけで、どっちがどっちか分からない。自分の場合は、2つとも数字のみというケースもあった。Provider numbe:C152とか書いてあると良いのにと思った次第。あるいは、理由があって明記してないのか??


いずれにしろ、ちょっと一段落。ただし、いくつか見つけてない受講証明書があったので、探すつもりだ。それにしても、今回は2つの継続教育のための登録だったけど、この類の資格をいくつも持ってる人達は大変だろうな~と感じた。

1月 31, 2011 プロジェクトマネジメント, プロジェクト管理, 技術士 | | コメント (0) | トラックバック (0)

2011年1月20日 (木)

「世界に誇る日本の建造物」

日本での橋、ダム、トンネルなどの土木建築物を扱ったムック本。サブタイトルとか表紙に、「現代日本を創ったビッグプロジェクト」、「石見銀山から東京湾アクアラインまで現代を映す日本の巨大建造物+土木遺産 500選」。

2008年出版で、当時もちらっと見たような気がするけど、(興味あった明治時代の建造物が少なく)現代の建造物が多いように思えて購入までは至らなかったように思う。

今日、改めて見たら、トンネル工法やダムの工法なども書かれてて、結構面白かった。明治時代の建造物も少なくない。また、地図があり、大きさの対比としてN700系のぞみや東京ドームが脇に書かれているのも,、実感が湧いて良かった。

スポットなりコラム的な話題のページもあり、戦国や江戸の時代との関連や現代でのエピソードなどが書かれていて、知らないことがほとんど。そこでの記載で”ダムカード”なるものがあるそうで、どっかの1枚くらいは手に入れてみようかなとも。近場のダムは、管理事務所でもらえるみたいだ。ダムって、道路から見たりすることはあっても、管理事務所などに出向くことってまず無い。


ここ2,3週間、「どっかの本屋さんで見たな~」と思いながら、なかなか見つからない本があった。検索や神田とかでも見つからなくて、多少諦めかけてた。今日、何気に最寄り駅の本屋さんに久しぶりに行ったら、その本が。そして近くにあったのが、この「世界に誇る日本の建造物」。どちらもムック本だったけど、探してた本の検索では少し似た内容の別の本が引っかかったりして、書店でその近くを見てたのが見つかりにくかった理由の一つ。 反省もあるけど、まっ良い本も手に入ったので、良しとする。

1月 20, 2011 テクノロジー, プロジェクトマネジメント, プロジェクト管理, 技術, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2011年1月 9日 (日)

駅伝プロジェクトでのPMOは?

正月2日と3日で時々見ていたTV番組は、「箱根駅伝」。今年は、接戦だった気がする。優勝もそうだけど、シード権争いも熾烈。見る側としては面白かったけど、出場チーム側からすると気が気ではなかっただろう。しかも、優勝の早稲田大学は、直前にエース級が故障。

スタートしばらくの団子状態や、繰り上げスタートが1チームと少なかったこと、レース中の棄権が無かったことなどを考えると、チーム力は僅差だったのかもしれない。今年の総合新記録のことを考えると、ハイレベルでの僅差だったのだろう。

棄権とかが無かったのは、タスキの重さなり、2,3年前での棄権を考えてのことと思ってた。レース前の各チームの監督の目標が結構確実なので、それも理由かなと思ってた。ただ今朝のTV見てたら、東洋大の5区柏原選手だったと思うけど、レール前の監督への電話で「つぶれたらごめんなさい」との言もあったので、結果的にそうなっただけなのだろう。


往復で、200キロ超、時間としても11時間程度。TV放送自体もさることながら、運営も大変だ。プロジェクトマネジメントの視点で、特にPMO(プロジェクトマネジメントオフィス)があれば、どんなことをするかとかを時々考えながら見てた。

まず、知っている人も少なくないと思うけど、箱根駅伝の主催は「関東学生陸上競技連盟」。運営の主体は、学生だ。

http://www.hakone-ekiden.jp/faq/index.html など。

言い方が良いか分からないが、学校での文化祭を超巨大化したような運営と考えた方が良い。陸連や国とか自治体によるレースとは根本的に異なる。(東京や神奈川の陸上競技協会は運営協力してるけど。)

他に、各チームだってTV局だって、そして協賛の会社なども、準備やレース本番での運営は大変だ。またウィキペディアなどにも出てるけど、大なり小なりの問題も発生してるので、その対応もある。


箱根駅伝でのプロジェクトチームやPMOのイメージは、関東学生陸上競技連盟のプロジェクトなりプログラムマネジメントのもとに、各チームなどのプロジェクトが”緩く”結びついてるように思える。また、出場チームによっては、”駅伝主将”を設けて通常の”主将”でのチームと別チームとしてたりして通常の運営と併用と思えるチームもあって、千差万別。

一般的な書籍に出ているPMOでの、予算オーバーや日程遅れの監視目線とはちょっと違うかと思える。各大学チームのPMOは、マネージャーが片手間で実施する感じが多いのではないだろうか。PMOとの意識はないだろうし、PMOと呼ぶべきかも疑問。各チームの練習の様子がちらほらTVで出たけど、出場チームのプロジェクトで大きなものは、監督と選手や選手間の結びつきで、ノート交換とか一緒に風呂に入る事のような気もする。

書籍上のPMOの目的や構築についての勉強も必要と思うけど、監理要素の強すぎるPMO構築って良いのだろうか。箱根駅伝の様子を見ながらそう感じたし、自分の見聞きしたプロジェクトのことを思うとそう感じた。身近の見聞きでうまく行ったプロジェクトに対するPMOって、(口喧しかったかという意味では)存在感の薄い事がほとんど。逆に、PMOがあってもうまく行かなかったプロジェクトが少なくない。


ちなみに私事だけど、元気な頃に箱根駅伝コースを走ったことがあった。数人で、大手町から結局小田原まで。ただし、私は膝が痛くなって金目川直前で棄権。その時でも、走るメンバー以外に自動車や自転車担当を決めて運営した。ちょっと懐かしい。

1月 9, 2011 スポーツ, プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2011年1月 8日 (土)

ワンダー×ワンダー H2Aロケット打ち上げの舞台裏

今日面白かったTV番組は、NHK「ワンダー×ワンダー」。”完全密着!ロケット打ち上げの舞台裏”。H2Aロケット打ち上げの舞台裏。ドキュメンタリー部分+スタジオでのゲストとのQ&A。ゲストの一人は毛利さん。

三菱重工業での製造とか噴射実験、基地までの輸送などの様子が登場した。次期ロケット開発の様子も少し。 中でも発射直前の管制担当の人達の様子が生々しくて、気象への対応のためのバタバタする様子や、逆に平常心で行こうとの心構えなどは、他のプロジェクトでも参考になる。また発射責任の方の、自分たちの失敗を次の人達に伝えることも役目との弁も結構頷けた。

発車前のトラブルで、ふと気になったのが、ホワイトボードへの情報整理。承認欄のような矩形がいくつかあり。多分ホワイトボード記述 → ハードコピー → 回送なり承認 → 保存というステップになっているように思えた。自分たちでもホワイトボードや壁のポストイットを撮影して資料化することもあるけど、他社とか他団体が関係するプロジェクトでも運用して良いのかもしれない/した方が効率よさそうと思った次第。それが全体効率アップにつながる。

なお、以下のYouTubeのNHKonlineで、本番組そのものの冒頭5分間程度が見られる。(期限過ぎて消されたらごめんなさい。)

http://www.youtube.com/watch?v=B3s3yyX5ThA


1月 8, 2011 テクノロジー, プロジェクトマネジメント, プロジェクト管理, 映画・テレビ | | コメント (0) | トラックバック (0)

2010年12月31日 (金)

2010年雑記

大晦日なので、今年2010年に読んだ本や気になったことなどを書いてみる。読んだ後とかにブログに書こうと思いながらも、書くタイミングを失ったものが多い。(一部既に書いてることがあったら、ごめんなさい。)

・プリウスリコール

1月とか2月に話題となった、ブレーキの件。あくまでブレーキの件。個人的には、今でも(本来のリコールの定義で)、当初ブレーキの問題がリコール扱いに該当するか疑問という考え。

良い勉強になったのは、まずはマスコミでの扱い。結構細部まで内容を記載するマスコミもあれば、品質問題とか安心・安全に十把一絡げの所も。同じマスコミの会社や媒体でも、記者によって扱い方が違うのも興味深かった。後は、学者先生とか業界人の意見も色々。**さんは、そんな思考だったのかと人物像なりを考え直すこともあった。なお失敗学の畑村さんなどによる講演(パネルディスカッション)は、個人的には良かったとの印象。

トヨタの「グローバル品質特別委員会」設置や、その様子のビデオ公開など、消費者や世論へのアピールの動きは、当初少し驚いた。特に後者は、そこまでやるのかな~との印象。(くどいけど、あくまでプリウスのブレーキの件。) ただし今後のこの類の対応として、大なり小なり他の製造業の会社でも必要になってくるだろう。その意味では、注目しておこうと思う。


・トラブル対応としてのポイントバック

ソフトウェアトラブルおよびその対応で今年気になったのは、ネットゲームなどネット系アプリのトラブルの対応としてのポイントバック。従来慣れ親しんだ(製造業での)商品の場合は、返品とか返金に該当する対応。

ネット系のアプリケーションの場合は、そもそも”品”が存在しないし、無料の場合が多い。ただし、ゲームの場合は、”ポイント”が溜まったり、実貨幣でポイントを購入できるものもある。その場合のソフトウェアトラブルの損害とその代償をどう考えたらよいかと思っていた。

今年、ちょっと目に付いたのは、ポイントバックとか、ネット上の仮想商品の供給。

あくまでケーススタディとしての例示だけど、3月にmixiでのゲームアプリ「サンシャイン牧場」でゲームアイテムの個人掲示板が使えないトラブルが発生した。その個人掲示板は、ある意味有料のアイテム。不具合の修正も行われたが、無料で購入できるとすると共に、既に有料で購入した人には別アイテムがサービスされた。いくつかのキーワードで検索するとたどりついたり、キャッシュを見ることが出来るはず。

システムなりサービスを設計する際には、トラブル時の対応も考えた方が良い。その対応は、そのシステム/サービス内に入れ込むものもある。予備システムなどは典型例。他に、そのシステム/サービス”外”に設けるものもあるだろう。人手での代用も一つ。個人的には、システム設計の際に、トラブル時にシステム/サービス”外”の対応や必要ならその部分の検討を行うべきだと考える。

ちなみに、危険の大きさと効用の大きさを比較することが良く行われるが、あまりに数値的のみの比較での弊害として「フォード・ピント事件」があるので、留意。(危険の大きさとしては、このサイトでは残存バグの可能性が分かりやすい。ただし、「フォード・ピント事件」での危険は、車での構造欠陥。)


・電子書籍

今年は、iPadの購入を機会に、今までのドキュメントファイルの整理や紙情報→スキャンファイル化を結構行った。本のスキャンに関しては、どっか近くのコピーショップで行えればいいな~と探したり問い合わせしたけど、実際は見つからなかった。先々スキャンサービスの利用や、離れたショップの利用なども検討したい。


P6260019P6270023左側2つの写真は、購入した裁断機と裁断結果の様子。こんなものもAmazonで販売してて、Amazon経由で購入した。

実験兼ねて本や雑誌の裁断を行ってみたけど、2つ折りの雑誌が結構難しい。折ってあるところが三角形に近くて、そのまま裁断しようとするとずれていく。広げて、真ん中で裁断しようとしてみたけど、丁度真ん中だと裁断機の刀とホチキス部分がぶつかるので出来ない。少しずらそうとするにも、位置合わせが少し難しい。結局2つ折りの雑誌は、(今のところ)従来のようにカッターナイフで切断してる。

裁断機を利用しての自炊の経験から言うと、コンビニでコピーサービスとかがあるのなら、スキャンデータ渡しもやってくれても良さそうな気がする。まっ、媒体やネット利用可能とするかなど検討が多いのだろうか。ただ、調べた限りでは、カタログとかちょっとしたプリント物はスキャンサービスで利用不可。スキャナーを購入するほどでもない人達にとって有用だろう。

お試し的に、電子書籍をダウンロードしてiPadで読むこともやってみた。しかし、ダウンロード書籍に対する栞(しおり)やマーキングなどの機能でちょうど良いリーダーがなくて、つい遠ざかってしまった。個人的には、集中して読むなら、まだ紙の書籍の方が馴染む。

多少似ているが、日経新聞電子版も会員になっているが、プリントが制限されることで利用頻度はさほどでもない。会社からの帰りに、携帯で夕刊を読んでおく利用が一番多い。

また、 図書館でコピーが可能なのだから、電子データ渡しも検討して欲しいと思うようになった。デジタルデータなのが問題なら、低解像度にするとか認証などを設けても良いのかもしれない。少なくとも、一般的な書籍ではない例えば郷土史とか古文書とかなら課題は少ないと思うのだが。


・ソフトウェア進化

知り合いと、夏に少し話題となった。「ソフトウェア進化」に関する日本語論文もいくつかあるし、大学では「ソフトウェア進化工学」と称して工学的に研究しているところもある。イメージ的には、ソフトウェアプログラムがプログラム自身を自ら変更して機能を作り出すことや、ソフトウェアの外部変化への適応性がテーマになっている(と思っている)。

ただし夏での知り合いとの議論は、生物の進化と類似するのなら、生物進化そのものよりも、品種改良のような(人間社会にとって)能動的なことを検討した方が良いのかな~というもの。進化論学者さんの話よりも、農林水産試験場の研究員や園芸家のような人達の話を聞いてみたい感じ。有益そうなら、そのネタを仕込んで成長させてみるようなアプローチ。ソフトウェア進化よりも、ソフトウェア改良とかの言葉が良さそうに思えるとの意見も。ただし、「ソフトウェア改良」だと単なるデバッグみたいなので、用語的には一工夫いりそう。

あと知り合いとの議論では、DNAでの不要部分との類似性をどう考えた方が良いかも少し話になった。ソフトウェア進化ではそのようなものは、不要とか該当しそうな部分はなさそうと考えるのかな。あるいは、少しくらいバグがあったり、無駄と思える部分を用意してる方がいいかもとの話も。あくまで、DNAや進化論と類似性があるのではとの前提での話で、合意なり結論めいた話にはならなかった。


・社内伝道師(エバンジェリスト)

今年、ちょっと引っかかったのが「○○さんは、エバンジェリスト、、、、」という言い方。もちろん会社によっては職位として”エバンジェリスト”がある会社があるけど、そんな会社の人達とのやり取りじゃない。各自の会社でのスタッフ部門の人なり専門家の人の説明でのこと。

引っかかるのは、自分の周りでは尊敬の意味でが9割くらいだけど、残りが融通が利かないような意味で使われてる点。後者は一方的な説明だったり、別の考えとの妥協点を探ろうと相談してるのにその専門分野での考えを譲ろうとしない。また、各分野の説明をする時は良いんだけど、(分野間で多少矛盾する時に)その人なりの考えの統一性に欠けることもあるとも。それらにより、ある意味、弊害になることもあるらしい。

そんなことを気にして、伝道師(エバンジェリスト)と呼ぶより、 お坊さんとか小坊主、納所坊主(なっしょぼうず)など呼んだらいいのにと思った。伝道師が一神教系での用語で、他の考えを受け入れないイメージもあるためだ。日本でクリスマスや初詣を行うように、多神教系の言葉の方が良さそうに思えた。ただし、納所坊主って寺の会計とかを取り扱うお坊さんと知って、ちょっと適さないな~と。お地蔵さんも良いんだけど、じっとしているイメージが強い。

ただし、そもそも伝道師って、正教師の資格を持たない人のことと知った。正教師は、牧師さんのこと。また、伝道師って、物事のよさを伝える人の意味もあるようだ。(本来卓越した人を会社でも”牧師”と呼んでも良さそうだけど、用語的に宗教っぽ過ぎるので使ってないのだろうと推察する。)

伝道師(エバンジェリスト)と呼ぶべき専門家なら、現場への普及で余りに強制的に/固定的な考えを押しつけるのは似つかわしくないと思うようになった。


・i○○○は日本で作れるか

今年の受講した講演でスポット的に触れられたり、懇親会で会話になったもの。iPodだったり、iPadだったりしたと思う。日本の競争力低下の原因探りみたいな面もあったのだろう。とある懇親会で、その話題になったので、以下のことを述べた。
 

①日本だって作れる。作れないのはAppStoreなどの方。
ハードは、日本でも作れるだろう。細かいこととしては、アップルと同様に中国などでの製造で、日本での製造じゃ製造価格が割に合わない。また、じゃA4のチップを設計できるかとかがある。しかし、いずれにしろ、日本メーカーは、AppStoreとか緩い著作権管理は、心理的に発想しにくい。さらに言えば、ハードウェアチームとソフトウェア(特にシステム/ITを含めた)チームが、日本企業では協力体制になることが考えにくい。

②作れても商品化に行き着かない。
特に品質部隊や関連部隊とか事業部長とかが、出荷OKと言いそうにない。自分でもiPad買ったときに驚いたけど、電源ボタンが無い、音のボリュームも無い。社内でのレビューで、こんな設計なら色々文句が出るだろう。他には、PCとの接続とかネットワーク接続が前提。PC持ってない人やネットワーク接続できてない人を考慮しないのか!と怒られそう。さらには、同梱の説明書が薄いというか紙切れ。これだってマニュアル部隊から総スカンになりそう。


・「ガラパゴス化する日本の製造業」

2008年発売で、長く積ん読状態だったもの。講演等で日本の特異性を”ガラパゴス”と呼ぶことが増えつつあった頃の出版だったと思うので、タイトルに”ガラパゴス”を題した本としては早いほうだったはず。(ただし当時、”ガラパゴス”の話とAndroidの話とを一緒に聞く機会が多くAndroid採用勧誘のような受け取り方をしたせいか、この本を含め”ガラパゴス”関連本をほとんど読まなかった。)

今年日本でも各社からスマートフォンが商品化された。そこでふと、”ガラパゴス”騒動ってなんだったんだろうかと思い、この本を読むことにした。

当初予想では、日本の特に携帯などの特異性が多く述べてあると思っていた。でも実際は、韓国や台湾の企業に関する事項が結構詳しく述べられている。また、ある意味では必然だが、エレクトロニクス業界を扱っている。第7章「世界で勝ち抜くためのビジネスモデル」では、7つの条件を挙げており参考になるが、エレクトロニクス業界に関してのもの。8章は自動車業界に触れており自動車業界の課題も書かれているが、エレクトロニクス業界との関連が主になっている。

世界で勝ち抜くための7つの条件の冒頭が、”すり合わせ”の技術が活かせる分野としている。実は以前から、”すり合わせ”と”組み合せ”の技術論での2つの違いで悩むことが少なくなかった。この本で、”すり合わせ”技術の業界として自動車や工作機械とのイメージが強まった。自分の中で、”すり合わせ”技術=自動車・機会(業界)、”組み合せ”技術=電気(業界)と捉えてすっきりした。その基本的な気づきができただけでも、結構価値があった。

なお著者は野村證券の主任研究員であり、海外の企業情報が詳しいのも頷けた。ODM売り上げランキングや、実効税率の台湾・韓国メーカーと日本メーカの比較なども記載されている。台湾や韓国を含めたエレクトロニクス業界を考える上で、参考になることが多かった。


・「『失われた十年』は乗り越えられたか」

発売は2006年と、ちょっと前。「ガラパゴス化する日本の製造業」を読むうちに、こちらも面白そうと読んだ本。

”「失われた十年」を乗り切った自動車産業”と”自ら不況を招いた家電・電子産業”とを、章立てレベルで明言している。そこが結構、小気味良い。

海外に進出した中小企業も登場したり、タイやマレーシアの動向などにも書かれている。また、この本でも、”すり合わせ”の技術に触れており、その分野でアメリカ製造業は地位低下したと述べている。

この本では、アングロアメリカン型の考えに批判的な部分も少なくない。株主価値を前提としたコーポレートガバナンスなどである。そんな部分も参考になった。

12月 31, 2010 ソフトウェア, ソフトウェアテスト, プロジェクトマネジメント, プロジェクト管理, 日記・コラム・つぶやき, 書籍・雑誌, 電子ブック | | コメント (0) | トラックバック (0)

2010年12月27日 (月)

ビジネスロージャーナル「ITベンダ対ユーザ システム開発契約をめぐる紛争」

大掃除や年賀はがき作成をしながら、休みの時などに先週土曜日に買った本や雑誌をぱらぱら読んだ。

タイトルの雑誌は、先週の忘年会前に神田の書泉に行って、システム開発関連の判例とかを探した際に購入したもの。当初、ジュリスト別冊とかにありそうと思ってたけど、(事前にネットで調べても)ぴったりそうで安いものが無かった。店内を回ってたら、”ビジネスロージャーナル”という雑誌のバックナンバーがあり、その2010年5月号の表紙に、「ITベンダ対ユーザ システム開発契約をめぐる紛争」と書かれていた。少し立ち読みして購入。

ちなみに、”ビジネスロージャーナル”のバックナンバーページは以下。

http://www.businesslaw.jp/single/

判例もそこそこ書かれていて勉強になった。2ページだけど三菱電機インフォメーションシステムズの人の執筆もあり、基本契約と個別契約(ここでは、プロジェクトのフェーズ毎の契約のような意味)の両方がある場合の、矛盾を想定した記載方法とかは具体的で「そうだよな~」といった感じ。

ちなみに執筆者の一人は「中村好伸」氏。2009年のPMI日本フォーラムで講演され、情報交換会にも出席されて色々お聞きした。掲載記事での冒頭に、相手方のアドバイザーが「PMBOKであれば、○○書面があるはず」の一辺倒で交渉にならず、結局相手方としてのアドバイザーを降ろされたとの話も。個人的にも「そうりゃーそうだわな~」。教科書のべき論だけじゃ、交渉にならないし、落としどころを見つけられない。

知り合いとかには勧めたい一冊。


ついでに。本号に日本ハム(株)の”下請取引承認フロー”が図示されてる。承認が何処で行われて、メールが行くのかどうかまで書かれてる。

2010年12月号も参考になると思って買ったけど、そっちは付録が結構面白い。法律事務所のハンドブック。会社というか事務所の写真や事務所弁護士のプロフィールなどが掲載されている。で、面白いのは(写真掲載の事務所は)、どの事務所も立派で、しかもほとんどの事務所が”書架”の写真を掲載してる。模擬法廷のスペースのある事務所もある。こんなの見ると、就職先として憧れるのも分かる気がした。  (理科離れもだけど、理科系企業離れもありそうな気がしてきた。)

12月 27, 2010 プロジェクトマネジメント, プロジェクト管理, 品質, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2010年12月22日 (水)

スクラムチームのシーズンオフ

冬なので、スポーツでのラグビーの話題や写真をポツポツと目にするようになった。 (ちなみに、社会人ラグビー大会の昨シーズンの決勝「トヨタ自動車 Vs. 三洋電機」戦は、2010年2月28日。)

ソフトウェア開発のプロセス「スクラム」の勉強とか講習のせいか、ラグビーの写真を見るとそちらの方へも頭が行く。で、ちょっと思ったのが、タイトルのように”シーズンオフ”。とにかく「スクラム」では、スピードが命。バグなどの課題が発生したら”即”処理する必要がある。(スクラム講習では、「Now!」とか「Done! Done!」という言葉が飛び交う。) チーム自ら作業量などを見積もりを実施しコミットするから、なおさら自発的な処理が必要。

なのでイメージ的には、そのプロジェクトが完了するまで、結構がんばり続けるイメージ。そうなると、完了後にどうした方が良いかが気になる。すぐに次のプロジェクトに回すのは、試合ばかりのラグビーチームみたいに思えてきた。息抜きなり、勉強に充てる時間も必要だろう。(日々仕事をしながら勉強しろばかりじゃ大変すぎ。)

ということで、ラグビーチームメンバーのオフシーズンの過ごし方をネット検索。すぐに引っかかるのは、夏合宿。菅平などを思い出す。後は自主トレ。

ラグビーチームのチームと「スクラム」のチームがちょっと違うのは、「スクラム」でのその次のチーム編成が同じとは限らないと言うことかも知れない。そのことはチーム編成の際に、そのことへの配慮とか、チーム形成のための時間も確保してやるべきだろう。上位のプログラムマネージャーなり経営層が配慮してあげるべきと思うんだけど、いかが、、、、。

12月 22, 2010 ソフトウェア, プロジェクト管理 | | コメント (0) | トラックバック (0)

2010年11月28日 (日)

山を登りながら「ザ・ゴール」想起

今日は、伊勢原・大山。紅葉のライトアップ最終日だったので、急遽登ることにした。ただ最近、高尾山とか丹沢とかを登ったり、走ったりが多くなってる。(数年前とかなら、もっと頻繁に山などを走ってたんだけど。)

急な上り坂を登って、大山下社に到着。ライトアップまで時間があったので、なだらかな登山道も少し歩いてみた。そこで、ふと思い出したのが「ザ・ゴール」での登山の様子。TOC(制約条件理論)を分かりやすく説明するのに、子供たちへの宿題として出題する。グループ内に遅い子がいて、その子の荷物を皆で分担しても遅くなるので、それを防ぐ方法を考えなさいというもの。ロープでつなぐとか、タイミングの信号を出すとかが書かれている。(ネットとかで、更に分かりやすく書かれているのもあるので参考に。)

実際の山で思い出し、えらく違和感を感じた。あるいは、「ザ・ゴール」を読んだ時に引っかかったのは、実際の登山を思い起こしたからかもしれない。

そもそも、荷物を無くしてあげても遅れる子を、登山チームに入れることが不可解。極端だけど、その子はケーブルカーとかを利用して貰った方が良い。まっ、それは極端としても、別ルートからというプランも選択できる。

ロープで結ぶのも変。雪山とかでの遭難防止なら分かるけど、ハイキングレベルだと周りから文句言われるだろうとか。例えば、高尾山。 ハイキングでの、ちょっとした岩場ならかえって危険? 

実は、我々数名で高尾山に登った時は、さほど道に迷うわけでもないので、遅そうな人を先頭にした。それも固定的ではなくて、時々真ん中辺りだったり、、、。

コンスタントに歩ける平地のハイキングとしてなら理解も可能だけど、岩場などのような予測しにくい場合には当てはまらないと思える。逆にTOCは前者のようなケースだと考えられるので、「ザ・ゴール」での例としては悪くない。 本件は、TOCをプロジェクトに応用する際に、小さな部分への応用から考えるのと似ている。TOCというよりもクリティカルチェーンの方が良いかも知れないし、小さな部分への応用を先にというのは私の周りだけかもしれないが。


なお、ふと机の上の書類を見てみたらレターがあり、1面に「登山とプロジェクト」と書かれていた。プロジェクトマネジメント学会の、@pm.Letter。発行が7月15日とあるから、結構積ん読状態だったようで少し反省。 プロジェクトマネジメントと登山の、似ている部分とそうでもない部分の対比が面白いし参考になる。特にステークホルダー関与の仕方。登山は結局現場に任せることになる。プロジェクトだと、余りに関与しすぎ。

「ザ・ゴール」での登山部分も含めて、プロジェクトと登山の類似点と相違点を考えてみるのは役立つと考える。

11月 28, 2010 プロジェクトマネジメント, プロジェクト管理, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2010年10月31日 (日)

PMI日本フォーラム2010 感想

昨日と今日は、PMI日本フォーラム2010。神保町近くの学術総合センター。昨年も参加したけど、同じように寒くて雨だったと思う。断片的だけど、感想などを。

・基調講演の「東京証券取引所株式売買システム(arrowhead)の開発について」は、非常に参考になった。

発注者側としての講演だった。特定時期からの変更に関しては、講演者(専務取締役)の承認というか決裁を必要にしたとか、契約で次段の準備を作業項目に含めたとか。

技術的な話も出て、遅延○ミリ秒達成とかスケーラブルな冗長性とか、、、、。ただし、個人的には、上の管理的な側面の方が参考になった。(どこかでarrowheadのシステムの話自体は聞いたからかもしれない。)

・iPad持参の人を、ちらほら見かけた。

参加予定セッションに限定して、事前の資料のPDFをダウンロードできる仕組みだった。(フォーラム終了後は、非参加のセッションの資料もダウンロード可能に。)

実は、自分自身もそうしようかと思ったけど、会場での本の購入などで重くなったり、フォーラム後の買い物を考えて断念した。自分のiPadの場合、カバーなどのせいもあって、ちょっとずっしり。

・日本技術士会は協賛から外れた?

昨年はCPD証明を正式発行したけど、今年は無し。まっ、各自でCPD申請するのは構わないだろうから実害はないとも言える。でも、なんか寂しい。 (個人的には、要は間に入るというか積極的に活動する人がいなくなったからとは思う。だけど、それを誰かが引き継ぐ位のことをやるべき。それくらいの組織力があるべきと考える。)

*CPD発行は、プロジェクトマネジメント学会の方だった。大きな勘違い。そうなると協賛の方も、記憶があやふやになってきた。ただし、PMI日本フォーラムへの日本技術士会の協賛って、あっても良いだろうにと思う点は以前と同じ。


・同窓生に遭遇

2日目の明日セッションの終わった後に、近づいてくる人が。同窓生と判明。大学時代から1度も会ってないので、何十年かぶり。懐かしかった。 セッションの最後で質問したために、こちらのことが分かったとのこと。

ちなみに、夕方同窓生MLにそのことが書かれてた。こちらも、しばらくしてMLへ返信。

我々の学科の同窓生MLって2つあるけど、積極的にやりとりしている方のMLにはPMPはいない。上記MLにはいるかもしれないので、何かの時に話題になるかもしれない。

・非公式な勉強

今回良かったと思ったのは、セッション後やPMIの売店などの軽い話で参考になることが多かったこと。

ちょっと悩んでいたのが、PMOなどのプロジェクトの計数処理のあり方。PMOもプロジェクトだったりプログラムだったりと階層的。また数値が経理的なことや品質的なことなど多岐。

会話のやりとりで、DBに突っ込んで、BI(Business Intelligence)で処理する視点で考えればいいと気がついた。DB構造にさえ注意すればいいし、それも行き詰まればクレンジング。またセキュリティというかアクセス制限のこともあるが、それはBIでの見せ方で考えればいいことで、アクセス制限設定を変更できるようにすれば良いだけの話。

もちろん、結構重要なデータがあり、一般データと物理的にも一緒にすべきじゃないものがあったり、機密性が高すぎるので必要部分のみをコピーして利用するなど細部での留意は起きるだろう。でも、システムの構造的な部分はすっきりしたように思う。

ちなみに、”ダイナミック戦略”という分野があると教えてもらった。そちらも参考にしたいと思う。


基調講演もだし最後の非公式勉強もそうだけど、ポイントとなる部分って案外基本的なことだと分かることがある。今回は、その意味で有意義だった。

10月 31, 2010 プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2010年10月30日 (土)

プロジェクト管理 スケジュール短縮は世の常

PMI日本フォーラム2010に参加。ネットワーキング(懇親会)での一コマを紹介しとく。知り合いとの会話で、その知り合いとは昨年のフォーラムでちょっと話した程度で、1年ぶり。

会話は、工場で製品出荷のスケジュールが前倒しになっての、ある意味愚痴。なので、所謂教科書的に、人(と金)を投入したのかとか聞いたら、それをそもそも検討してなかったみたい。「それじゃー駄目でしょうcoldsweats01」と。

自分の回りでも、目標日程に対して次第に遅れることはある。でも大抵は交渉段階があって、人の投入とか、機能ドロップとか。その交渉段階で、人を投入しても効果が出ないケースもあるけど、検討は必要。また、特に人の投入には社内/社外のコネみたいなのも必要になるので、それも能力だろう。

それなりの上層部は、そもそも実現できる(かもしれない)スケジュール短縮を言うもの。しかもPLなら、スケジュール短縮は、ある程度リスクとして頭の隅に置いておくべき事項である。 (ただ~し、世の中とんでもない上層部というのがいるのは理解してる。)


さらには、上で述べたこと以外に重要な事が浮かび上がった。本などでの自分の知ってるスケジュール短縮の事例を述べたり彼とのやりとりをしたら、そもそも、日程の情報共有ができてないと判明。前倒し前のスケジュールも、2,3人が知ってる程度で、現場にその意識がない。良い例か分からないけど、ポスターとかでの「○○出荷は、**月**日」の掲示がないイメージ。見学や出入りの人のこと考えると掲示は難しいにしても、会議とかで確認すればいいものに、それがなかったとのこと。(正確には、曖昧な情報で伝わったまま。)

なので、前倒しを前倒しと認識するのも2,3人。つまり、スケジュール圧縮のために、何処の工程がネックかなどに落とし込めない。情報共有が不十分だったと分かると、ちょっと目がテン状態。彼も言ってたけど、情報共有の入り口みたいなのが弱い。これから、ちょっと強化してみるとのこと。

そんなこともあるんだ~と、逆にこちらも勉強になった。

10月 30, 2010 プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2010年10月16日 (土)

プロジェクトファシリテーションに関してメモ

ある事情で、「プロジェクトファシリテーション」に関してメモしとく。どっちかというとプロジェクトマネジメント(PM)との関係/対比なので、細部になると「プロジェクトファシリテーション」を良く理解してなかったり、他の人の意見を聞いてみたいことも少なくない前提。

1)”ファシリテーション”自体は、結構普及してる

”ファシリテーション シラバス”で検索すると、大学での授業で扱われたりしてる。知り合いの周りでも、ソフトウェア開発(の特に若手グループ)などで利用しているケースが少なくない。

後者のことを考えると、プロジェクトファシリテーション自体も大なり小なり実践されているケースが少なくないだろう。

2)エンジ系での朝礼とかも、「プロジェクトファシリテーション」と言えなくもない

朝礼は、建築現場などで見る”あれ”。あれを、「プロジェクトファシリテーション」活動と考えれば、従来のPMとPF(プロジェクトファシリテーション)を対比的に考える必要もないだろう。

居酒屋やスーパーなどでの朝礼とか終業直後の反省会も、PF活動に含めて良いくらい。特に、例えば新規開店とか、新メニュー対応とか考えると、ちょっとプロジェクトのイメージが強まる。

3)実践者の大きな悩み PMとの整合性

問題なり課題なのが、(がちがちの)PMとの整合性。上の1)で書いた若手グループのグループリーダーの悩みといったところか。 急に早朝わいわいがやがやとか、ニコニコマークが壁にいっぱい貼られたら、びっくりして意見言われるわな~。 (←ちょっと面白おかしく書いたけど、まっ本質。)

ただし、PM研究者(?)やプロジェクト全体のリーダーの立場として、全体効率アップのためにPFを無視できるか、、、、。あるいは、有効活用しようとしたらどう考えるべきか。PFをコミュニケーション知識エリアの1ツールで書いて済ますことはできるだろうけど、現場実践者の悩み解決にはならない。

(個人的な意見。ワークパッケージ/アクティビティの識別意識がなさすぎ。WBSの話で、アクティビティを漏れなくとかアクティビティを非常に最小化までするのって、ほんとは変だよね。その辺りがキーになるかも。)

4)プロジェクトファシリテーションだって、多少のバリエーションがあっても良いだろうに

用語の定義も絡むけど、組織体の中で実践する場合の適用があるはず。儀式度(higher ceremony/lower ceremony)を意識してよい。少し緩めの儀式度のPMと、少し緩めの儀式度のPFが歩み寄れる? つうか、PFにきつめの儀式度ってあるのかは疑問だけど。

5)”成果”との関連

やっぱ経営層への説得とか理解を求めるのって必要。HBR(Harvard Business Review )の2005年 09月号 辺りの世界のこと。論拠と事例の両方があれば良いかな。少なくとも個人的な感覚としては、後者はPFはメリットありと思える。数値化とかも、どうにかなるような気もする。


蛇足:建築現場の朝礼。システム納品の際に遭遇したことがある。新社屋建設中に、納品というかシステムセットアップし現地検証。建築現場の作業員と一緒に体操したり、指さし確認。こっちはスーツ。自分たちとは別フロアでは、グラインダーによる火花。

10月 16, 2010 プロジェクトマネジメント, プロジェクト管理, 日記・コラム・つぶやき | | コメント (0) | トラックバック (0)

2010年9月 3日 (金)

進水式と棟上げ

今日の勉強会の懇親会で、話題となった件。「進水式」と「棟上げ」。

勉強会のメンバーに造船系の人もいたので、懇親会での知り合いやその周りの人への質問。「船の進水式ってあるでしょう。シャンパンをぶつけたり、紙テープが乱舞するシーンのやつ。あの時って、船はどれくらい完成してると思う?」 あるいは、進水式の直後に引き渡しというか、所有権は船のオーナーになる?

実は、自分も以前は勘違いしてたんだけど、進水式はあくまで船を海に浮かべるための儀式。進水式後に、内装工事を行ったり、運行のテストをしたりが待ち受けている。ある意味では、プロジェクトでの途中の大きなマイルストーン(でしかなく終結イベントじゃない)。なお、懇親会では業界的にも詳しい人がいて、直近に起きた事故などの話も。

で、誰とはなしに、”棟上げ”との相違点への話題へも。”棟上げ”は、民家の建築で行われる柱とかがある程度立った時に祝うイベント。近所の人などへ、屋根の上から餅をばらまくなどの風習がある/あった。”棟上げ”も途中でのイベントということで似てるという人もいれば、進水式だと水には浮くので壁とか屋根の瓦葺きが出来てないので棟上げとは違うとの意見も。個人的には、前者の立場かな。

ついでに、IT系にも「進水式」と「棟上げ」のようなイベントを設けた方が良いよねとの意見も出た。つまり、エンドユーザー側も、このままなら納入(購入)がOKそうと判断できそうなイベントを設けるべきとの考え。(柱)構造とか概要動作レベルで、OKかをある程度ユーザ側も判断できるべきとの考え。当然だけど、設計側も、OKそうかを示す術を検討すべきだろうけど。

少なくともIT系なりソフトウェアプロジェクトでも、(進水式とか棟上げほど)大きなイベントにしなくても、プロジェクトのマイルストーンとしてユーザ側の了解なりチェックを受けとくイベントを設けるべきだろう。

9月 3, 2010 プロジェクトマネジメント, プロジェクト管理, 技術 | | コメント (0) | トラックバック (0)

2010年3月25日 (木)

製造業製品開発プロセス IPD

IPD(Integrated Product Development)は、「統合製品開発」と訳され、製品開発の統合マネジメントシステムである。参加している研究会で話が出て、ちょっと本とかを読んで勉強した。

ISOやCMM/CMMIなどと比較すれば、知名度は低い。対比的に考えれば、ゼロと言っても過言ではないかも知れない。

ただ、最近非常に感じているのは、”プロセス改善”という用語はあるが、どうもソフトウェア主体になっている。つまり、改善はソフトウェア関連チームのみが行う風潮にすらなっている。これが製造業の場合は、ちょっと問題。つまり、ハードウェアの改善とか、ハード+ソフトの改善がされにくくなっている。そのため、製品開発の効率化がなおざりになってしまっている。

IPDは、IBMが開発効率化のためにプロセス開発したもので、日本IBMでも実践しているとのこと。また、その実践でのノウハウを元に、他企業へのコンサルなどもやっているようである。(その関係もあって、IPDはきっちりとしたプロセスというよりも、基本的な考えを示していると思った方が良い。)

IBMが1993年から始まった経営革新の一環でスタートした。経営革新の開始時、4週間のうちに全製品開発部門のトップに、次年度の事業計画の実現性の検証と保証を行わせた。ちなみにその4週間を、アムネスティ(懺悔)期間と呼んだそうだ。

その実現性の検証と保証が、IPDの骨幹になっていると感じた。つまり、評価指標を設けたり、チェックポイントを設けている。


ちなみに、上の2冊が手に入る/入りやすい本。左の「IPD革命」は、背景や歴史的な流れ、そして基本的な考えを述べている。右の「実践IPD」は、書名が示すように実践向きの本である。「実践IPD」には、製品開発での問題点が、それに対するIPDでの解決法とその解説等と一緒に列挙されている。


実際にIPDを導入する前提でなくとも、プロセス改善の考え方として参考となる部分が少なくない。あるいは、本書を参考に自社内のプロセスへの追加や改善を行うのは、有益となるだろう。

3月 25, 2010 プロジェクトマネジメント, プロジェクト管理, 技術, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2010年3月24日 (水)

予算と決算 監視の有り様

2010年度予算案が成立したそうだ。2,3日前から、「あれっ、決算が成立したってニュースに出るっけ?」と気になってた。

で、ちょっと調べたら、ちゃんと憲法90条に会計検査院が、国会に報告する旨が明記されてる。なお、会計検査院のページ見たけど、個別の細かい無駄遣いはそこそこ分かったが、どの官庁が予算オーバーしてるかなどはすぐに分からなかった。見つけ方が悪いのかもしれないが。

でも、そんな情報の整理も的確じゃないように思うし、中間的な決算情報は無いと思う。蛇足だろうけど、政権交代でその辺りが変わるか気になってが、どうなる事やら。まっ、今度の夏は参議院選挙だからと言われそうだが。


それは良いとして、赤字垂れ流しという視点では、国の財政”管理”のやり方は、真似るべきじゃないんだろう。先進国でワースト○位。ここ何年か続いている。

逆に、国の財政”管理”のやり方と、各自の組織体のそれとを対比するのは、有意義だろう。つまり、予算獲得の時には色々騒ぐけど、決算というかパフォーマンスの向上や低下を監視できているかどうか。パフォーマンスの向上や低下を各組織体で把握できないと、国と同じで赤字垂れ流しになっちゃう。 個人的には、まずは、ちょっとした指標での監視でも良いと思うんだが、どうであろうか、、、。

3月 24, 2010 ソフトウェア, プロジェクトマネジメント, プロジェクト管理, 経済・政治・国際 | | コメント (0) | トラックバック (0)

2010年3月 5日 (金)

Day2プロジェクトの本 システム統合の「正攻法」

言わずと知れた、三菱東京UFJ銀行でのDay2プロジェクトの様子を描いた本である。

本の帯での文言は以下。

  将来に残すべき実務マニュアルの完全版!
  ITプロフェッショナルが明かす100の創意工夫

  6000人の技術者、開発期間1000日超
  2500億円が投じられた-
  三菱東京UFJ銀行「Day2」の全記録

買ったのはずっと前で、販売された当日か翌日くらい。急いで買いに行ったら、コンピュータ関連の棚になくて少し焦った。店員さんに聞いたら在庫ありで、金融関係の棚。すぐに読んだが、こちらのブログに感想を書くのが遅くなってしまった。その間には、PMIフォーラムでDay2の講演を聴く機会も得た。また、実は、今月での別の会合でも、Day2プロジェクトの講演を聴くチャンスがある。ちょっと遅くなったが、今月の講演前に、ブログで感想をまとめておこうと思った次第。

まず、総括。この本は、Day2プロジェクトでの技術的な側面も書いてはあるが、どちらかというとプロジェクト管理、しかも品質とか進捗の管理を掘り下げている。しかも、チーム形成とかチーム一体感の維持などにページが割かれており、非常に参考になる。また、銀行頭取や会長による関与の記述もあるかと思えば、システム構築を行った開発会社の取り組みとか創意工夫についても書かれている。開発会社のそれは、開発会社自信が書いたかインタビューによるもののようで、結構ざっくばらんな記述もあって面白いし参考になった。


Day2プロジェクトの前にDay1プロジェクトがあり、Day1プロジェクトの稼働からDay2プロジェクト開始の5ヶ月間に、プロジェクトの組織作り(含む協力体制)を行っている。その際に、当初外部の開発委託のメンバー数を2500人と考えていたのが4500人必要と判明した。それから2000人の確保に奔走することになる。つまり、開発技術者6000人の構成は、銀行本体のシステム部員:600人、銀行システム部門関連会社:900人、外部委託の技術者:4500人。(P26)

6000人は、ピーク時とはいえ、銀行システム開発やそのテストを考えて素人考えでの概算見積もりなどをやってみるのは、良い訓練になるかも知れない。少なくとも、どんな作業がありそうか考えて、本書での確認を行ったりするのは良い勉強になる。(正直に言えば、私は1桁違ってた。)

また、一度決まった要員数を大幅に超える見積もりが発生した場合の対応も、身近の対比を行ってみるのも良いかもしれない。外部の委託先人数は、倍近くに増えることになる。それを責任者に言うか、言っても「元の数字でやれ」とか「何故だ~」とか言われかねない。また、上がその人数確保に奔走してくれるか、、、、。

本書では、開発要員のために海外を含めた人材確保が書かれている。ただし、今回のプロジェクトが素晴らしいのは、「スキルポートフォリオマネジメント」を実施し、必要な技術レベルや開発経験などを一元管理した点であろう。そのマネジメントがプロジェクトの前から恒常的に行われていたことが幸いしたが、むしろスキルポートフォリオを行っていることに感心した。(P28)

グループの責任者を明確にしたり(P31)、ゴール設定(P39)なども明確に行われている。進捗管理なども具体的な事が書かれており、「そこまでやるかな~」と思えるほど細部にわたっている。また、開発ばかりではなく、移行テストのための工夫(P92など)などにも触れており、参考になる。

ページは少ないが、構築での海外製品(P69)やシステム構成(P71)も書かれている。また、データ移行の際のトラブルで、海外の開発本部への連絡と対応で乗り切った話なども紹介されている。(P206)

士気向上のための施策(P95~)が、結構面白い。はちまきを巻いた結束式兼出陣式の写真などがある。スクリーンセーバーやボールペンなども作成したとのこと。ちなみに、大漁旗の”統合丸”は、P149に掲載されている。

士気向上と関連するが、開発メンバーが増えたことでトイレ工事を行った話や弁当への配慮も行ったそうだ。トイレ工事は、床を上げて配管工事をして確保。1つのビルで男子用のトイレの便座45台を設置した。(念のためだが、この類は言うが易し行うは硬し。多少なりともファシリティが絡むことを交渉を経験したら分かる。)

上記も、”Day2では、そこまでやったのか~”の類と言えるが、テストや関連する作業にはさらに多い。旧データのデータ移行が必要となるが、そのための回線として、2社の主と予備の計4本を確保した。(P143) 現場のためのマニュアル作りなども細かく行っている。(P121) またデビットカード関連のテストでは、切り替わりの丁度午前6時を狙ってタクシーを利用してテストするなども行っている。(P141)

ちなみに進捗管理(テスト結果)の類がP58~。文字としてテスト密度やテスト実施率などが読み取れる。また、通常のシステム開発では、接続テストとして”ITb”と表記するが、Day2プロジェクトでは、接続テストを2回行い、ITb1、ITb2のテストを行っている。(P28) 


この本では、開発会社毎の記載が面白い。見積りやプロジェクト管理など技術系を主として記載してある会社もあるが、プロジェクト参加によるチーム形成の話が多い気がする。特に面白かったのは、ある開発会社での話。週2回の飲み会を行い作業の効率化が図れたが、一部のチームは毎日飲み会実施して回覧で”飲み過ぎ注意”が書かれたとの件。(P202)


ソフトウェアそのものの技術的な記載は少ないが、プロジェクト、しかも日本的なプロジェクトマネジメントとして非常に参考となる本である。ソフトウェア工学の観点では、細部のデータまでは識別できないとしても、ソフトウェアプロジェクトでの各種メトリクスや基本的な数値の実例、ドキュメント種なども書かれており好実例である。

思うに、Day2に多少なりとも参画した、日本の情報処理関係者が数千人レベルでいるということ。これは日本にとって、貴重な財産になるとも言える。皆さんの回りにもいるのかも知れない。いたとして、プロジェクトそのものを教えてもらうことは守秘義務などで難しいことが多いだろう。でも、自分のプロジェクトのことを話して「○○と思うけど、どうでしょうかね~」と、自分の考えに対する意見をもらうことは構わないだろう。そんなことのためにも、例えば本書のようなもので情報を仕入れて、よりハイレベルな会話が成り立つのは良いことである。それが日本のプロジェクト遂行能力の向上にも役立つことになる。

3月 5, 2010 ソフトウェア, プロジェクトマネジメント, プロジェクト管理, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2009年12月30日 (水)

プロジェクトの成功/失敗での、コストや期間の誤差

休みでの”積んToDo”対応その5。よく言われる、プロジェクトの成功率3割での、成功の判断基準の件。

成功率3割と書かれているけど、期限が1日でも延びたら失敗というのかとか、その期限の基準は計画の早期なのか終盤なのかを気にしていた。今年10月に開催されたPMIフォーラムで、ちょっと関連する話題が出たので、再確認しよう思っていた。

一番引用されるのは、「日経コンピュータ」の調査かと思われる。直近では、2008年12月1日号。それによると、成功率31.1%。また、本号での指摘は定量管理している方が成功率が高い点で、これはネットニュースなどでも書かれた。(ちなみに、直前の調査は2003年で、2008年は第2回目。)

そこでのコストと納期での成功と考える範囲が書かれており、2割未満とみて良い。(クロス集計とのことなので、ちょっと表現としては不正確だけど。) これは、色んな現場での尺度としても良いと思う。ある意味「2割の誤差はOKとみなそうよ」「1割の誤差は御の字」とか。

なお、品質の成功尺度は、ユーザ側が”計画通りに利用しており満足”を判断基準としているようであるが、満足という部分が主観的なために不正確と感じてしまう。ただし、本件は満足度の方が重要との考えもあって、絶対的な尺度が良いかは色々意見あるところ。また、バグゼロを成功とはしていない点は、肝に銘じておくべきである。


コストと納期の基準とした計画時点がどこがは、気になったまま。いわゆる計画当初かどうかなど。売買契約とかの話しが出るだろうが、昨今は基礎的な仕様検討の段階と実装段階とを別契約にすることも少なくない。そのような場合の基準時期をどう考えた方が良いか、、。

あと一つ気になったのは、本調査での有効回答数の激減。感覚的には3分の1に。例えば、定量化手法を導入しているかの有効回答数は、2003年が1537件に対して、2008年は438件。景気のせいなのか、プロジェクトの成功かどうかの調査や定量化手法の導入を遠ざけようとしているのか?? もし後者とかだと、回答企業も少し考え直してもらった方が良いかと考える。

12月 30, 2009 ソフトウェア, プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2009年12月19日 (土)

ベストプラクティス集よりも、ワーストプラクティスから学べ

今日の勉強会運営会議での帰り道の会話。「ベストプラクティスって、全部実施するの大変かも」「へぇ~。その組織体の『ワーストプラクティス』って残ってないの? あるいは、その組織体での限界見本みたいなとこははっきりしてないの?」

本とかに、ベストプラクティスを集めてるのは分かる。しかも、それらでも、各組織体で必要なものを選択すべきと書いてある。問題は、現場に色んな部署のプラクティスをマージしたものが渡るとき。しかもタイトルに”ベストプラクティス”って書いてある。

実は、うまく行ったチームって、必要な項目以外はバッサリ止めてるケースが少なくない。なので、別のチームがそのまま真似てもうまくは行かない事が多い。よほど外の状況や、内部の状況や体制が同じでない限り。

例えば、
Aチーム:a,b,cを実施
Bチーム:b,d,eを実施
”ベストプラクティス”:a,b,c,d,e

a~eはプロセスだったり、ソフトウェアメトリクスの計測種だったり、、、。それを全部やるための勉強、追加的な作業を考えると、全体効率は落ちるばかり。

しかも、運の悪いことに、そのマージを実施した連中が、そのマージしたプラクティスが絶対と思うようになってること。悲劇の発生。なのでベストプラクティスは、生に近いようなデータを、マージすることなく実施部門毎に列挙する程度にしておく方が良い。

あるいは、その組織体にとんでもない部署があれば、そこのプラクティスを紹介する方が良い。つまり、ワーストプラクティス。その組織体での最悪チームはあるだろうから、そこから学ぶ方が早いだろう。

12月 19, 2009 ソフトウェア, プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2009年12月12日 (土)

日系企業のドバイ債権 未回収6600億円

今日の日経新聞。それにしてもすごい額。

実は、ここ2,3ヶ月間に頭の中ですっきりさせようと思っているのが、アジャイル開発での損益分岐。本当はアジャイル開発とは限らないんだけど。 

会計処理は、言わば開発が完成したりとか、年度単位の処理。工事進行基準が少し似てるかもしれないけど、どちらかというと気にしてたのは開発内部でのコスト管理みたいな世界。また、○○の機能を入れると**円儲かりそうだから入れようとかの、予測的な管理をどうしようかとの問題意識。

で、その前提には、プロジェクト管理での調達管理が結構完璧との思いがあった。PMBOKなどでの調達管理は、法的な処理やその対応にまで言及している。

今回のドバイの債権って、言わばエンジとかプラント系が多い。それがこの始末。結構考えさせられた。つまり、エンジでのプロジェクト管理はそれなりに進んでいるんだろうけど、今回のについて言えば、肝心のお金の徴収が甘いということ。あるいは契約なども甘かったのだろうと言うこと。

ドバイでの建設ではなかったと思うけど、TVで中東へのアプローチを見たことがあった。インドだったかパキスタンだったかの人を使い、重役の奥さんたちが向こうの人達に手作りのお寿司を振る舞う姿。(それとは物件的に違うだろうけど)何かそんな努力が、無駄になるようなイメージ。


紙面の一覧では、総事業費の半額以上が未回収債権のものがざらにある。知識体系と実践とは違うと言うことかもしれない。また、各社での一部限定なのかもしれないけど、教訓にしていく必要がある。

12月 12, 2009 プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2009年12月10日 (木)

「要求工学」と「アクションラーニング」のどっちを先に読む?

今日は、少しフランクなメンバーで馳走になりながら中華。その会合って、うまく表現しにくいけど、今から述べることは、営業獲得できたお祝いの席みたいに読んでもらえると良いかも。

顧客立場のメンバーを含めて打ち合わせして、機能面で削ったり追加したり。今日で概要確定して、合意形成。その後の馳走。知り合いは、どっちかというと構築側。

知り合い:「そう言えば、私『要求工学』の本読んでるんですよ」

私:「ふーん」

知り合い:「......」 

(何か言葉待ってる感じだったので)
私:「勉強するなとは言わないし、基本は知っとくべきだけど、今日のに役に立った?」

知り合い:「......」 

私:「お客さんが言ってる事って、超希望だったり、間違ってることあるんだから。」

知り合い:「そう言えば、お客さんが間違ってるという意識はあまりなかったな~。ちょっと作ってみて、後になって違うと言われることはあるとしても。」

私:「そんなのは、ある意味、最初のお客さん要望が間違っているから。」

「多分だけど、『要求工学』の本読んでも、お客さんを疑えとは書いてないよ。」

「しかも、現代でネックなのは、無料で使えてるシステム多すぎ。自分の所で構築する場合に、コストがかかるという意識がない。」

「なので、最初はお客さんが間違っているとの前提に立った方が良いくらい。」

「結構多いのが、要望として書かれているのが、新しい受注の人の知らない旧システムのこと。お客さんは、ほんとはそのシステムでの、使いたくない部分は少なくない状況。でもシステムを文書にしにくくて、旧システムのコピー&ペーストで渡される。」

知り合い:「じゃ、どうすればいいんですかね~」

私:「心理学系とか、話術や交渉の本かな。でも、深層に描いているものを引き出すには”アクションラーニング”がいいかも。」

知り合い:「”アクションラーニング”っすね。読んでみようかな。」


うん、ネットでも良いから読んでみてと。あっ、ネットでも良いと明言したかは、紹興酒を結構頂いたので記憶が定かじゃない。また、”アクションラーニング”自体は会議などでの使い方なので、対人で使うにはちょっと応用すべきだろう。

要求(分析)→要求工学の本が解決してくれそうに思う人が少なくないような気がする。要求工学も、ある意味ではツール。そのツールを使う前に、考えとくべき事は少なくない。

知り合いさん、頑張ってね。

12月 10, 2009 ソフトウェア, プロジェクトマネジメント, プロジェクト管理 | | コメント (1) | トラックバック (0)

2009年12月 2日 (水)

誰かが、仕様書/テスト項目の全体をチェックしないと

今日は、気のおけない人達と飲み会。簡易忘年会といった感じ。

その場で、ちょっと話題となったのが、メンバーの中の一人とで「○○○マジック」と呼ばれているもの。○○○は、私の名前というかニックネーム。2,3時間(とか1,2時間)で万件レベルのテスト項目を読むというもので、その人の仲間の間でも、そう呼ばれているみたい。

多少説明はしたけど、色んな他の話題が出たので、うまく伝わったか? また、その細部の手法よりも、以下の件が重要。

つまり、ソフトウェア開発には色んな文書があるけど、誰かが全体を把握する必要があるということ。文書で大きなのが、設計系だと”システム仕様書”や”製品仕様書”といった、設計上の一番上位としてまとまった文書。またテスト系も、それに対応するテストの仕様書。

まず、これがある所と無い所とでは、雲泥の差。というのも、各ブロックとか各ボード、各サブシステムといった類の文書が揃っていても、全体を理解できない。全体の整合性確認のためには、多量のチェックが必要となる。したがって、個人的には、全体の文書作成が難しかったら、各ブロック等の文書作成を犠牲にすべきとの意見。

次は、その全体的な文書のチェックを、誰がやるかということ。多少、誰が作成するかという問題もあるけど。

実は、ソフトウェア規模が大きくなると、この文書作成自体が相当面倒。初級的なプログラマだらけだと、ちょこっとプログラム作成することが楽しいから、そちらに走りがち。というか、初歩的プログラミングしかしてないと、そもそも文書を書く必要性が理解できない。(そんな連中が、外注とかオフショアに作業やらしても、文書がないのを平然としたり、そのチェックを実施できない。破綻原因の一つ。) 書いたりチェックが、各ブロック等どまりになるケースがほとんどである。

全体チェックの必要性が分かれば、後は、それを誰がやるか。複数人で作成したとしても、できれば別の人のチェックが望ましい。そう考えると、リーダー格が実施する方が効率良い。統一性も確保できる。つまり、全体チェックは誰かがやらなくてはならないし、それはリーダー格がやるべきである。

その必要性が理解できれば、後は、どう実施するかを考えればいいだけ。例えば、小説を含めた書籍は、それなりの情報量だけど、理解できる。良い例は、法律書かな。

人は個別の関連性のないものをたくさん並べられても、理解しにくいとか覚えにくい。章とか見出しは、そのためにある。つまり、仕様書もテスト項目も、章立てなどを明確にしておけばいい。そうすれば、どこに書いてありそうか判断できるし、書いてなければ追記する必要がある。(特にテスト項目で重要なのは、非機能要件に対するテスト項目が書かれているか。)


その次は、如何に迅速に読むかだ。迅速に拘るのは、ドキュメント更新が少なくないから。それはシステムであれば、ユーザからの要望追加とか変更も関係する。ユーザからのそれらがないとしても、内部的な細部仕様は結構変わる。ユーザには余り関係しない、サービス向けの仕様とか、いわゆる非機能要件部分の変更もその類。

なので設計系もそうだが、テスト系もテスト仕様書は誰かが、しかも迅速に読むことが必要である。ちなみに如何に迅速にと言っても、最初は整合性が欠如してる部分が多いので、どうしても時間はかかる、それは仕方ない。ただ、中盤~終盤になれば、差分や仕様記載/テストでのポイントに注力して、時間を短くする必要がある。

そのための具体的な方法は、やはりそれぞれの文書作成のインフラとかツールにも若干関係する。ただ注意は、そのツールの方が重要じゃなくて、それを達成すべきとの意識の方だ。(私の場合、文書とかテスト項目のエクセル記述は大嫌いである。100ページの仕様とか1万件クラスのテスト項目を、一挙に読む場合を想定してもらえればすぐに分かると思う。スクロール一つとかを想定してもらえれば幸い。)

まだ細部では伝わりが悪いところがあるかもしれないけど、それはまたの機会かな。


#補足:念のためだが、各ブロック等の文書が重要で、全体文書がさほどでもないケースはある。”摺り合わせ”などの類。ただ、そのためには、各ブロックでの限界などが明確に規定されていたり、その厳密なチェックが行われるケースに限定される。

12月 2, 2009 ソフトウェア, プロジェクト管理 | | コメント (0) | トラックバック (0)

2009年11月13日 (金)

スパゲティスケジュール

とあるコミュニティの勉強会(合宿)スケジュール管理での、続編。

ガントチャート書いてて、途中まで、どうもスケジュールがすっきりしない。Googleドキュメントでの紹介の図と異なり、別のサマリータスクでのタスクに対して前後関係が発生したりしてた。一見して「変だな~」と思ったけど、最初理由が余り分かってなかった。

どうも各タスクでの先行タスクを考える際に、関連するタスクと、すぐに順序関係を設定しようとしていたみたい。そのため、前後関係の矢印が複雑に絡んでいた。”スパゲティプログラム”という非構造的なプログラムの呼称があるが、まさにそれ。

つまり、WBSの階層化を十分に考えてない。またWBSを階層化することで、一旦成果物を発生させ、その成果物を次の段のサマリータスクと関連づければいいのに、小さなタスク間で順序づけしようとしていた。


普段慣れたプロジェクトなら、WBSの構造化なども注意して実践するので、余り発生しない。しかし、今回のように不慣れなプロジェクトだと、ついつい忘れてしまっていたというわけだ。あるいは、WBSの構造化がちゃんと身についていなかったとも言える。

プログラマーが”スパゲティプログラム”を避ける(避けてきた)ように、PMOなどのスケジュール作成する人達もその構造化には意識が必要である。と、自分の反省も含めて記しておく。

11月 13, 2009 プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

Googleドキュメントでガントチャート

とあるコミュニティでの勉強会(合宿)のスケジュール管理を、Googleドキュメントでのガントチャートでやってみたので紹介。

普段は、MS-Projectでのファイルのやり取りだったり、GanttProjectファイルのやり取りだったりしている。今回は、そもそもプロジェクト管理(のガントチャート)に疎い人が多かったことと、中心となる人もGanttProject等のソフトをインストールしてないことなどから、他の方法を検討していた。

他の用途としてGoogleドキュメントは今回も利用したので、その延長でできないかと考えた。ガジェットとかありそうだったし、それっぽいファイルも見つかった。ただし、今ひとつ。

20091113gantt詳しく調べたら、Googleドキュメントのテンプレートにガントチャート用のテンプレートを発見。左での、一番上などであり、GoogleSpreadsで利用できる。さらっとしか読まなかったが、左での一番上のにした。(説明の図では分かりにくいが、後述するようにチャートを書ける。)

20091113gantt_dataテンプレートには、データ部分のシートと、グラフ部分のシートがあることになる。

順序関係は、データシートの先行タスク(WBS)を示すことで、終了-開始を図示化できる。また、WBS番号を少数以下を使って記述でき、少数以下がゼロの場合は、図形的にサマリータスクになる。

ただし、ちょっと不便なのは、終了-開始は図示できるが、期間の変更により次のタスクの開始日などが自動変化しない。自動で変化するようにするには、関数などを埋め込むことで可能ではある。またサマリータスクのサマリー期間も自動計算ではないので、そこも同様に関数などの埋め込みを行うと良いだろう。

20091113gantt_chartデータシートにデータを入れたり変更すると、ガントチャートシートに表示されたり、その表示が変化する。

そこそこ動くので、重宝しそう。少なくとも、今回の勉強会(合宿)のスケジュール管理は、これで行うつもりである。

11月 13, 2009 プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2009年10月 2日 (金)

こうも「PMBOK」 第4版日本語版の発売が遅れると、、、

PMBOK 第4版日本語版、 アマゾンは「発送予定日: 2009/10/31」に変わってた。ちょっとした自分の説明の関係で、「(PMI会員向けの)ネット版で作業するか~」と思うようになっている。今月先頭の発売なら、本の方で間に合いそうだったんだけど。

で、こうも延期が重なると、色々思っちゃう。というのも、”プロジェクトマネジメント”の知識体系の本と銘打ってるのとが対照的。色々言い分はあると思う。そもそも米国PMIがとか、権利関係でとか、いや~アマゾン側の問題とか、、、。(流石に詳しく知ってるわけじゃない。)

でも、日本人のプロジェクト完遂の感覚じゃ、余りに間に合わないとか、それなりの応答が無いのは少し理解に苦しむ。個人的には、2,3年とか数年前はそれなりに回っていたと思う。そこまで言うのは、言い過ぎかな~。

QC活動等、日本で咀嚼しながら実施していった例は多いし、その方がうまく行っているように思う。ついつい、そんなことまで考えちゃった。

10月 2, 2009 プロジェクトマネジメント, プロジェクト管理, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2009年10月 1日 (木)

お台場ガンダム グッドデザイン大賞jにノミネート

今日のニュースでグッドデザイン賞の発表聞いたけど、ちょっと嬉しかったのが、「お台場ガンダム」が大賞にノミネートされたこと。大賞の方の発表は、11月6日とのこと。ガンダムの大賞受賞に期待したいな。

なお、ついでにロボットネタ。神戸の長田地区では、「鉄人28号」の建設が行われており、つい先だって完成したそうだ。

神戸鉄人28号 トップページ
建設の様子のページ

お台場のガンダムも長田地区の鉄人28号も、偶然かもしれないけど18メートル。(もしかしたら建築関係の制限が絡むのかもしれない。)


ちなみに韓国では、111メートルのロボットを建造する計画があるそうだ。

http://news.livedoor.com/article/detail/4347464/

日本の某ロボットに似ているとか、ポスターに対比的なロボットがあって「あれは?」といった意見なども出てる(出ていた)。上のページにはポスターはないようだし、以前のURLにはなくなっててすぐに見つからないけど。


韓国のロボットランドという発想も、(技術屋とすると)ちょっと羨ましい気もする。ある意味、日本での刺激になるかも。大きさとか、駆動部分とか、、、。お台場のガンダムですら、少し首とかが動いただけでも歓声が上がった。先々だろうけど、多少動きを見てみたい。二足素行などは、誰もが期待していること。

#個人的には、ゴジラやウルトラマンもありかと、、、、。happy01

10月 1, 2009 テクノロジー, プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2009年9月19日 (土)

組込み業界 ISO取得の頃が良かったかな

一昨日のPM学会の懇親会とか、他のコミュの懇親会や飲み会などで会話しながら思ったこと、、、。

PM学会って、業種的にはIT系の発表がほとんど。自分がソフトウェア系統に、ついつい目が行くせいかもしれないが。モチベーションなど業界に関係しない話はあったけど、エンジ系の話はめっきり減ってしまった印象。

さらに言えば、組込み系は皆無。もちろん企業名からしたら組込みやってるところも少なくないけど、組込み自体がテーマにはなってない。結構違和感あり。というか、PM手法とかを取り入れないんだろうかとの疑問がわく。


ふと思うに、ISO9000の取得の頃は、結構ハード屋さんと品質系のメンバーでプロセス改善をやっていたように思う。ただし、プロセス改善と言うよりも、ドキュメント作成とか整理に追われ、それが反発になった。また、CMM・CMMIの方はソフト屋オンリー。そっちはそっちで、レベル2などの取得が精一杯で、レベル2に書いてない事項(特にレビュー)なんて無視。そもそも、プロセス改善っていう視点での活動でないから、取得後は元の木阿弥。(正確には、用語としては取得とかじゃないけどね。)

組込みのソフト屋って、プロジェクト遂行という視点では、制限だらけ。全体リーダーじゃないから、お金や人をコントロールできない。ましてや期限なんて、口すら挟めない。なので、問題の解決方法は非常に狭まる。商品化のためにプロセス改善という言葉は出るけど、改善という言葉だけで、お金と人をもらえなければ、商品化への問題対応はできない。

そもそも、マイコンチップが出た頃から、ハード屋さんは考えることを放棄しだした。機能がソフトで実現されるのに、ハード屋さんがその機能を説明したりドキュメント化することを避けてきた。そのくせに、機能要求の列挙というかオウム返しは得意。実現したい機能を、ハード回路で実現するための工数把握とか図面を書く事はない。そのくせ、リーダーは彼ら。スケジュールの遅延が、機能決定が曖昧だったという視点や反省にはならない。ソフト屋のせいにしてた方が、保身になるから。(そこまでは言いすぎのケースもあろうけど、、、。)


PM手法とかが結構浸透している今、組込み系も少し考え直した方が良い。要求分析までハード屋さんがやるべきとまでは言わないとしても、PM手法くらいは知識として備えて欲しい。そしてプロセス改善というか商品化上での改善に対して主体的に動くべきなんじゃないだろうか。また、組込みソフトの人たちも、もう少し全体最適の視点を養ったり交渉すべきだろう。

PM学会の後、ふとそんなこと思った。

9月 19, 2009 ソフトウェア, プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2009年8月28日 (金)

「プロジェクト計画書」と「プロジェクトマネジメント計画書」

「プロジェクト計画書」と「プロジェクトマネジメント計画書」は、違う。

時々「プロジェクト計画書」なるものを見て違和感あったけど、理由などが判明した。

「プロジェクト計画書」って自発的に命名した場合もあるだろうけど、PMBOKを見倣った場合もあろう。PMBOKの第1版(正確には1996年版)とかでは、「プロジェクト計画書」という名前。しかし最近のPMBOK第4版とかでは、「プロジェクトマネジメント計画書」で、「プロジェクト計画書」ではない。ただし、PMBOKでの2つの書の基本項目は変わっていない。


自分が違和感持ってるのは、「プロジェクト計画書」にプロジェクトの内容とか体制などにのみ言及して、マネジメントに関して触れてないドキュメント。ベースラインの設定や変更手続き、進捗管理などが書かれていない。

PMI日本支部の”PMBOKテンプレート集一覧”でも、「小規模(4)UserGuide」は「プロジェクト計画書」という名前。多少マネジメント関係に触れてはいるが、少ない気がする。ちなみに、一般規模(?)の方のテンプレートは「4331 プロジェクトマネジメント計画書」。なおこれらは、PMI日本支部会員のみがアクセス可能。


問題は、「プロジェクト計画書」に、プロジェクトの内容とか体制などにのみ記載してプロジェクト管理しようとしているケース。結局変更管理とかリスク対応が甘くなってしまう。しかも一般のプロジェクトでは外部に委託する部分が多いので、調達管理方法などは十分に記載すべきだし、品質基準などにも言及すべきである。

もし開発プロセスに「プロジェクト計画書」なるものが規定されているなら、本当にプロジェクトマネジメントとして必要な項目が列挙されているか確認した方が良いだろう。できれば「プロジェクトマネジメント計画書」と名前を変更した方が良いというのが、個人的な考えではある。

8月 28, 2009 プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2009年8月 6日 (木)

安土城の宮大工の映画「火天の城」

TVでちらっと予告を見た。来月12日から公開。棟梁(?)役は、西田敏行さん。

http://katen.jp/

織田信長の命により築城し、そして現存しない城。しかも、今回の映画では、その建築関連が主なテーマとのこと。プロジェクト管理の側面でも興味ある。多分、無理難題をふっかける施工主=織田信長とのやりとりなども出てくるんだろう。ちょっと楽しみな映画。

「劔岳 点の記」といい、プロジェクト管理で非常に参考になる日本映画が作られてるのは、嬉しいことだ。

8月 6, 2009 プロジェクトマネジメント, プロジェクト管理, 映画・テレビ | | コメント (0) | トラックバック (0)

2009年8月 2日 (日)

PMBOK 第4版 日本語版 さらに遅れて10月へ

Amazonから、またお知らせ。配送が遅れますとの知らせ。特にメールには日を書いてなかったので、Amazonページで確認。

http://www.amazon.co.jp/gp/product/1933890681/ref=ox_ya_oh_product

だと9月が発売日だけど、アカウントサービスでは”発送予定日: 2009/10/1”。本を待ちながらも、受講資料などから、サブノートの類を4版に向けて作業した方が良いのかも。

8月 2, 2009 プロジェクトマネジメント, プロジェクト管理, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2009年6月24日 (水)

やっとPMP合格

PMP(Project Management Professional)に、“やっと”合格。

PMPというか、そもそもその教科書(PMBOK)には、以前から興味あった。PMBOKそのものも結構わかりやすく進化してるのも気に入っているし、そもそも知識エリアとかプロセスという考えがすっきりしてると感じてた。また、エンジ系の人と話すのが、個人的には楽しみだし。^.^; (正確には、PMBOKは教科書というよりも知識体系だし、PMPの試験ではPMBOK以外からも出題される。)

7月から、PMBOKの第4版ベースに変わるというので、タイミング的には切り替わり直前。自分としては、第4版の方がさらにすっきりしたとは思っているものの、細部の暗記とかになると今から第4版を覚えるのも少し苦痛。その意味で、ぎりぎりセーフだった。

実は、一度不合格だったので、なおさら。あやふやな覚え方してた部分が駄目。立ち上げの所など。プロセス間の繋がりとかが口ですらすら言えなかったので、自分でも不安だった。断片的な知識詰め込みじゃ限界。そしたら、案の定。

細部の暗記系と概要系の両方の記憶や理解が必要だし、倫理面ってなかなか対策本でも勉強しにくいのが結構難点だった。特に後者は、PMIの考えるドライな部分が、(日本人的には)ピンと来ないところが無い訳じゃないし。ただし、プレゼントとか食事での線引きで、参考になるところが多かった。

あと、CBT(Computer Based Testing)なので、受験後すぐに結果が分かる。それは良いんだが、PCの前の4時間は、終盤は耐え難いくらい。特に老眼^.^;には辛い~。終わってから外に出たときは、目に違和感覚えたくらい。

これからは、個人的には、PMPの有効活用がカギ。また、他の資格もそうだけど、資格維持のための制度があるので、そちらもクリアしないと行けない。まっ、焦るほどでもないので、それらは追々と、、、。

6月 24, 2009 プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2009年5月27日 (水)

PMBOK 第4版日本語版 うーん色合いが、、、

PMBOK 第4版日本語版がアマゾンで予約可能になった。結構予約注文が入っているみたい。

やっと。それにしても、詳細説明部分の言語は英語になっているなど、アマゾンの方もバタバタしている感じ。


しかし、最初表紙の写真見て、「えっ~」。ちょっと、センスが足りないような。以下のような歴代smilePMBOKを並べると明確だと思う。

http://www.amazon.co.jp/exec/obidos/search-handle-url?_encoding=UTF8&search-type=ss&index=books-us&field-author=Project%20Management%20Institute

単に、見慣れてないせいかな~~。

また少し値段が上がっちゃった。ちなみに、今のところ、アマゾンでの日本語版のページ数記載は無い。

まっ、多分どのみち買うと思うけど、、、、。

5月 27, 2009 ソフトウェア, プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2009年5月17日 (日)

「天地人」 秀吉+三成 が一枚上手

NHKの大河ドラマ「天地人」見てるけど、今回の”秀吉の罠”は、なかなか良かった。

秀吉+三成 と 景勝+兼継 が、越後で会談。いやー感想としては、秀吉+三成 の勝ち。秀吉は景勝の部下の名前を覚えていて、越後に入って最初の時に彼らの名前や業績を述べる。握手も。また端的なのは、兼継は三成が命の恩人なのに、それを覚えていない。三成が助ける時に会っているし、”石田”とは名乗ったのに。兼継のある意味では、失態。

なお、景勝陣営は、接待で部下らの舞を披露する。


色々現代に通じるところがある。やっぱ人の顔や名前を覚えておくのは重要。私の場合、顔を覚えておけることは多いんだけど、名前が、、、。だから、兼継も「どこぞやで」と、会った最初で言えば/言えれば良かったんだよな~。

そして、”手作り”は貴重。景勝陣営が、もし芸能人(職業歌い手や舞踊家)を呼んでいたら、秀吉がまたなんか言ったかもしれない。また、リーダ(この場合、トップと言うべきか)と参謀の役割分担を、うまく回したのも秀吉側。


実は、当初「天地人」で笹野さんが秀吉役と判明して、「え~」と思った。上杉家との敵対ということで、佐野さんはイメージ的には(良い言葉が浮かばないけど)お笑い系なので、緊迫感出るかな~と。でも、逆に今回の回で、良いキャスティングと感心した。今回の秀吉は、馬鹿なこと言いながらも、人とのつきあいを大事にする。三成の方は、ちょっと冷淡な参謀。

しかも秀吉と三成が良いパートナー。パーフェクトに近い。なので、どちらかというとお笑い系の秀吉を演じられる方が良かったんだと思う。また、真面目なと言うか譲れないところは絶対譲らない、秀吉の怖い側面が引き立つ。

プロジェクトやチーム編成を考える際に、こんな大河ドラマも良いネタだと思う。

5月 17, 2009 プロジェクトマネジメント, プロジェクト管理, 映画・テレビ | | コメント (0) | トラックバック (0)

2009年5月14日 (木)

Day2プロジェクトでの「統合丸」旗

Day2プロジェクト(三菱東京UFJ銀行のシステム統合プロジェクト)遂行のやり方などの話が、ぽつりぽつりと出だした。ご存じのように、11万人月という超巨大規模のプロジェクト。

日経コンピュータでは、記事やセミナーも。なお、本セミナーを含め、今はどちらかというと銀行側の話が多いけど、しばらくするとソフトウェア開発側の話も出てくるだろう。

で、そのセミナーの紹介文を見て結構好感持ったのが、”統合丸”っていう旗。セミナーの案内での下の方。念のためだけど、この写真の旗は、大漁旗と言わないと思う。

こんな旗を作ると値段はいくらくらいか、ネットで調べた。思った以上に業者がヒットした。プリントするタイプから、染めるタイプまで。各自の価値観にもよるだろうけど、メンバーの一体感のためには、安く上がると言える。というか、そもそもこんな旗を作ろうとか、旗のデザインをメンバーでやる様なところは、プロジェクトはうまく行くと思う。

もちろん、”うまく行く”って、100%当初の期間通りとか予算から1円も外れないのを言うと定義すれば別だけど。そもそも、そんな定義はナンセンスとか、ある程度の許容範囲を持たすべき。また、本プロジェクトでは条件が絡んで引き出せないことも発生した。マスコミが書いたけど。欠陥が発生したら”うまく行かなかった”というのも、考え物。

プロジェクトのチーム形成の時に、”旗”作成も検討の一つとしたら良いと思った。

5月 14, 2009 ソフトウェア, プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2008年10月28日 (火)

本「定量的品質予測のススメ」

2週間ほど前に本屋で見かけて、その日は荷物が多かったので買うのを止めてたもの。会社の本屋に注文していて、今日入手。

ページ数が100ページ強と薄い。断片的には、知っている事が少なくない。また、日頃、○○をソフトウェア品質のメトリクスにしても良いかな~と考えているような事が詳細に記載されている部分もあった。レビューでの指摘件数などにページを割いてあり、結構小気味いい。そのため読みやすいし、実践する時には再度じっくり読めば良いと思える本。

個人的には、”尺度”に関して順序尺度などの説明があったりするので、メトリクスに関して基本的なことに理解度の確認にもなると考える。(てっ、ここのブログ読む人たちには、無用だろうけど。)

管理図での説明が多いのは、少し閉口。

逆に、プロジェクトマネジメントでの効率指数、SPI(スケジュール効率)とCPI(コスト効率)をX軸とY軸にして、時系列にプロットする図は、応用してみたい気がしている。株式などでの逆ウォッチ曲線みたいな感じ。ただし、当たり前だけど、逆ウォッチ曲線のような蛇行での判断では無く、どちらも1を下回ったら危険と判明するというもの。もちろん、実務的には1以下にするよりも、0.9以下とか0.75以下だと警告するような運用だろうけど。

サンプルデータも具体的で、実務とさほどかけ離れていない(と考える)ので、自組織での値との比較も面白いと思う。興味ある人はぜひ読んでみて。

10月 28, 2008 ソフトウェア, プロジェクトマネジメント, プロジェクト管理, 出荷判定, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2008年8月 3日 (日)

「トヨタ製品開発システム」

今日、やっと読み終わった。といっても、多少斜め読み。(買って、1年以上経過、、、。もう少し早く読んどけばよかった。)

トヨタの書き物というと、生産関係の本、プロジェクトの人間ドラマなど、、。この本は、設計系のお話。

大部屋チームとか、機能試作、A3レポート、そして常駐技術者のことなどが述べられている。時に興味深かったのは、「常駐技術者」の記述。部品メーカーから派遣された人を最大3年トヨタ社内に常駐させる。

価値の流れ図と呼ぶ、タイムチャート+問題指摘の写真なども掲載されている。

プロセス関係の人には、非常に参考になると思う。ソフトウェアでのリーン開発の書物よりも参考になるのかもしれない。あるいは一緒に読んだ方がいいと思った次第。

なお、原本は英語で、海外での話が主と思われる。その分、情報としてあけっぴろげだったり、逆に「日本でやっているのかな~」みたいなところもあるけど、、。

8月 3, 2008 テクノロジー, プロジェクトマネジメント, プロジェクト管理, 書籍・雑誌 | | コメント (0) | トラックバック (0)

プレキャスト工法 (がっちりマンデー!!)

今日のTBStv「がっちりマンデー!!」は、コンクリート業界。世界で(恐らく)一番硬いコンクリート「ダクタル」なども紹介された。

で、建築現場での「プレキャスト工法」が紹介された。

http://www.tbs.co.jp/gacchiri/oa20080803-mo3.html

現場で生コン注入するんじゃなくて、工場(別の所)で作ったものを現場に運ぶというもの。1フロア2週間かかっていたのが4日で済む。ここのブログ読んでる人は知ってると思うけど、建築での進捗管理として、コンクリートで厄介なのが「養生」。コンクリートが乾くまでは、どんなに頑張っても日数がかかってしまう。そこには、いくら人数かけても解決しない。この工法だと、それを視野に入れなくてもいいんだから、期間短縮になり、発想として自由度が広がる。

建築ではそうやって工法など工夫するのに、ソフトウェアはなかなか進展しない。(進展しているとは思えない、広まっているとは思えない。あるいは工法が大規模建築に適応できるのに対して、なかなか大規模ソフト開発での効率化の決め手が無い。) 逆に、3K,5K,最近は7Kとまで言われる業界になってしまった。 

あっ、蛇足かもしれないけど、個人的には「養生」のメリットはあると考えている。建築だと、一度見回りなどをして確認するのに当てられる。ソフトウェアだと、レビューなどでの後日気づきみたいな感じ。なので、「養生」という期間を全くなくすよりも、代わりの(短くていいから)バッファは設けていた方がいいと思う。

8月 3, 2008 ソフトウェア, テクノロジー, プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2008年7月29日 (火)

トヨタの生産試作の呼び方は、号試

ソフトウェア関係の人達と話題となるのが、開発プロセス。特に組込みだと、(大まかには)設計の試作の会議、生産の為の試作の会議、出荷判定というプロセスだろうけど、その事を理解できない人とか、理解しようとしない人がいる。

段階を踏む事を理解しようとしない。(もちろん、それに代わるようにプロセス案を議論してる訳じゃない。)

前読んだのは、自動車のホンダ系の本で、DR1、DR2との名称。その事を言っても駄目。で、今日は、じゃっということで、トヨタではどう言うんだろうと調べもの。そしたら、設計試作は設計試作だけど、生産試作は号試(ごうし。正確には号口試作(ごうぐちしさく)と呼ぶと判明。いやー、正式名称は呼びにくい。coldsweats01

ほんとは、設計試作も2段階みたいだけど、短縮化の改善などもあるので、ケースバイケースなのかもしれない。

トヨタの名前を出すと説得性があるようなので、段階を踏む事の説明で次回から多用しようかな、、、。

ちなみに、今日は別件の関係もあって、”ISO 16949”の本を購入。こちらも自動車関係。なぜか、今日は自動車業界のプロセス関係の勉強が少なくなかった。うーん、良いことなのか??? (本来、ソフトウェア開発プロセス自ら、こんなプロセスとか認証メカニズムを確立すべきじゃないのかな~)

7月 29, 2008 ソフトウェア, テクノロジー, プロジェクトマネジメント, プロジェクト管理, 出荷判定 | | コメント (0) | トラックバック (0)

2008年7月17日 (木)

「沢田マンション」

今日受け取った「アジャイルプロセス協議会」からの案内に、”沢田マンション”の文字。「沢田マンションにおけるアジャイル性をお話しいただきます」

よく知らなかったので、なんだろうと調査。

http://ja.wikipedia.org/wiki/%E6%B2%A2%E7%94%B0%E3%83%9E%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%B3

http://jp.youtube.com/watch?v=ZlvssY-H9Oo

なお、YouTubeの方は、花とかの映像が長くて、あまり参考にならない。

早い話、一人(奥さんとか子供も手伝ったようだけど)で、100人が住むような鉄筋のマンションを建てちゃったというもの。

実は結構、プロジェクト管理とか大きなソフトの話の時に「一人で犬小屋とかは作れるだろうけど、高層ビルはちゃんと計画したり土台をしっかりしとかなきゃあかんでしょう~」なんて話してる。

今回の沢田マンションは、その話と相反するので、ほんとは世の中にあっちゃいかん。coldsweats01 ただし、アジャイルプロセス協議会のメンバーが、講演を企画したのも分からなくはない。もちろんコツコツと何年もかかったマンション建築を、アジャイルとは言わんだろうとは言いたいけど。(あっ、もちろんアジャイルのいい所は認めますよ。個人的に嫌いなのは、エセアジャイラー。)


いろんな思考実験ができるという意味で、この「沢田マンション」は存続してほしいな~。お上も、あんまり固いこと言わずに。

7月 17, 2008 プロジェクトマネジメント, プロジェクト管理 | | コメント (1) | トラックバック (0)

2008年4月30日 (水)

ソフトウェア単価調査のために月刊「積算資料」

ついさっき、アマゾンに頼んでいた月刊「積算資料」が届いた。5月号。

ソフトウェア開発等の単価が出ているため。ちなみに、プロジェクトマネージャー、SE1、SE2、プログラマでは、東京のプロマネと札幌のプログラマの人件費とで倍くらいの差。ページ数は、人材派遣料金まで含めても10ページ程度。

なお、開発プロセスはSLPC-JCF98に副っている旨が書いてあるから、少し驚き。(まっ、次回には2007になっているんだろう。)

「積算資料」は、何かの折に書籍の方も購入した。建設・土木での見積もりの仕方が、参考になって面白い。建設機器のレンタル料なども書いてある。今回、おさらいもあって最新号を購入しようとした。いつか本屋に行った時にでもと思っていたけど、アマゾンにも置いてあったので注文した次第。他での人件費も含めて、ちょっと情報を整理してみようと思う。

4月 30, 2008 ソフトウェア, プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2008年4月29日 (火)

PBL(プロジェクト型学習)

メールやネット情報を整理していたら、”PBL(プロジェクト型学習)”という言葉が引っかかった。Project-based Learning。

グループでプロジェクト型の勉強を行うもの。以前からグループ学習とか呼ばれていたものに近いけど、皆で成果を出すのがミソ。もちろん、それ自体も結構前から行われてるので、教育のタイプとして新しいというわけじゃない。

ただ、言葉が確定すると普及するということはある。特に、グループ学習の実践が乏しい会社や大学などには課題となる可能性が高い。特に横文字信仰の組織体には丁度良いかな。

もう20年以上も前にプロジェクトの合間に教育担当して、グループでソフト開発をやってもらった。生産性が相当落ちる。仕様の皆での確認とか、ドキュメント化とか、、、。逆に協業するということは、そんな作業が発生することを学習してもらうのが目的。また、協業のために何が必要かを学習してもらう。


最近PBLで多いのは、文字通りプロジェクト管理。LEGOを使ったプロジェクト管理や、そしてソフトウェア開発のカリキュラムもある。

じゃ、例えばソフトウェアテスト(テスト項目作成、テスト実施)の協業とか、UML図作成の協業、要求仕様整理の協業などをちゃんとグループ学習で行っているところがあるか、、、。まだまだ、行っているところは少ないと思う。

4月 29, 2008 プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2008年4月26日 (土)

「ソフトウェアの規模決定,見積り,リスク管理」

少し酔っ払いながら、本屋(有隣堂)へ。今頃と思われるかもしれないけど、J-SOX法関連の本とか、知り合いの人が出版したそうなのでその本の確認とか、、、。他にも携帯電話に記憶させてた気になる本を調査。結局、気になってて見つけられなかった本が1冊。他は見つけられたり購入へ。

で、いろいろ回って目に付いたのが、「ソフトウェアの規模決定,見積り,リスク管理」。富野さんの監訳。酔ってたこともあって、「買ってないはずだよな~」と思いながらも自信なし。中身をパラパラ見て、買ってなさそうと思い購入へ。

アーンドバリューなどプロジェクト管理志向、リスク関係、オブジェクト指向に関するメトリクスなどが書かれていて、整理されていると感じた。(今までの富野さんの本と比べて、紙質が良くなったというかつるつる感が増えたように思う。あっ、そんなことはどうでもいいか。wink



なお、本屋をぶらぶらしてたら、Google Androidの(新しい?)本を発見。結構気にいった表紙。少し買おうか悩んだけど、数冊買い求めたこともあって今回は断念。次回にでもゆっくり見て、買おうか決めようと思う。

4月 26, 2008 ソフトウェア, プロジェクト管理, 品質 | | コメント (1) | トラックバック (0)

2008年3月19日 (水)

日本近代化プロジェクトの俯瞰

プロジェクトマネジメント関連。日本、特に明治維新での、プロジェクトを調べるのをポツリポツリとやってます。で、それらの時期的な列挙を、俯瞰してみようと作ってみました。NiftyでのTimeLineてのを利用。

一般の人は見れて、TimeLineユーザーの方は”できごと”の投稿やコメントが可能です。興味あれば、一緒にやりましょう。

現在は、まだ3つしか入力してません。少なすぎcoldsweats01ですが、順次追加します。(上は最新版取り込むので、後日は増えていることでしょう。)

3月 19, 2008 パソコン・インターネット, プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2008年2月29日 (金)

「【楽々デブドックを書こう!】開発☆ドキュン」の最終号は、テスト関連

毎週少し楽しみにしているのが、Think ITでのドキュメント作成のシリーズ「【楽々デブドックを書こう!】開発☆ドキュン」。

若い女性二人の、しかもイラストが多いやり取りなので、ちょっと楽しい。シリーズの名前からして、我々にはsign02coldsweats01なんだけど。 でもドキュメント作成の必要性がうたってあり、若い子には是非読んで欲しいと思うような内容。

今回がシリーズの最後で、「第5回:テスト関連も忘れちゃだめドキュ!」。”各フェーズでのドキュメントを作成する際に、同時にテスト用のドキュメントを作っておくと良いわよ”というセリフも。ある意味では、当たり前のことなんだけど、当たり前を実行しない連中が多いんだよな。(あっ、念のためだけど、テストドキュメント関連としてはTDDとかBDDの動きもあるので、より効率的な手法の議論も必要。)

(若い子向けの教育で)なんかの時に活用させてもらおうかなと思っている。

2月 29, 2008 ソフトウェア, プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2008年2月15日 (金)

PMBOK 4th Edition パブコメ受付中だとさ

タイトルのとおり。他の人のブログで知りました。3月22日まで公開。

http://www.pmi.org/Resources/Pages/Exposure-Drafts.aspx

第3版も、細部では理解してない所があるのに、、、。あっ、もちろん、核となる概念でも十分出来てない所もある。

上のページで変更点(分かりやすくした点)も記載されてる。分かりやすくなるのはいいけど、現実的な側面では勉強というか覚えきれないのがネック。ふー。


2月 15, 2008 プロジェクトマネジメント, プロジェクト管理, 技術 | | コメント (1) | トラックバック (0)

2008年2月11日 (月)

今日は建国記念日 トヨタカレンダーでは出勤日

今日は建国記念日で、一般的にはお休み。でも、「トヨタカレンダー」では、出勤日。

「トヨタカレンダー」って、トヨタの生産系のカレンダーの事で、原則週休2日で休みを設定するというもの。工場などのカレンダーなんだけど、結局関連企業や商店街もそれに倣うことになる。ちなみに、年末年始やゴールデンウィークで日本の休み分を調整。

なので、今日はトヨタの工場は出勤日。日本の祝日との差異の今年最初かなと思ったけど、1月に成人の日があった。

考えてみれば、週5日の繰り返しなので、部品や作業量の見積もりがしやすい。実際の作業での間違いも少ないだろう。ある意味、たいした発想。こんな”おれ流”を徹底させるとの考えも、高収益を生む源泉なのだろう。(海外も、本カレンダーが原則だと聞いた気がしたが、こちらは勘違いかもしれない。)

ちなみにウィキペディアでは、「トヨタカレンダー」は出典明記の依頼をしている状況。ネット上は色々書かれているし、トヨタの内部告発的な本では触れていたように思う。が、言われてみれば、どっかの本に書いてあるのか?? 気に留めておきたい。

2月 11, 2008 プロジェクトマネジメント, プロジェクト管理, 自動車 | | コメント (0) | トラックバック (0)

2008年2月 7日 (木)

BShi 「ドキュメント 火星への挑戦」

今日のBShitvは、「人類 火星に立つ」の第2話、「ドキュメント 火星への挑戦」。人類が火星に到達するまでの課題を紹介したり、映画のようにシュミレーションする映像も紹介された。後者では”ヒロミ”と呼ばれる日本人男性も登場していた。

アメリカ、ロシア、ヨーロッパの取り組みなどが紹介されていたし、今までの宇宙滞在に関する事故や問題なども浮き彫りにしていた。昔の映像なども使っているので、課題の重さを痛感した。特にロシアによる長期滞在や事故例の映像の多くは、個人的に新鮮だった。

そもそも、2年半とか3年の宇宙滞在や、最大23分間の通信遅延が大きな課題。

ちなみに番組の最初の頃には、フォンブラウン博士の映像も登場。彼の意見を基にした宇宙旅行の映画のシーンも出ていた。細かいけど、発射の頃の飛行士の手は”素手”coldsweats01

宇宙線対策に関しては、船外活動のためのロボットも紹介されていた。なお、知らなかったが、宇宙船が人間の思考にも影響するとか。サイクロトロンを利用した脳神経?との関連の実験も詳細されていた。そこまでしないと、地上では因果関係を調べられないという事か、、。

また水の問題。飛行士のセリフが面白かった。「結局妥協点は、自分の尿を分解したものなら飲むのは仕方ない。でもさすがに他人のは不可。」みたいな話。

食欲の問題も。これも飛行士のセリフだったかな。「冷えたマッシュポテト」をずっと食べ続けるわけには行かないよな。体力減衰も大きな課題。

番組の途中からは、長期滞在での健康とか心理的な課題を浮き彫りにしていた。そもそも、宇宙飛行士の選定のためには、3日間単純作業を続けさせるとか。それに耐えられるのは、その後の名声とかがあるからだろう。あるいは高給とか。思うに、プロジェクトでの人選などでも参考にしないと。人集めたり、誰かをリーダーにすればいいといった次元じゃ駄目。しかも、低い見返りでは。

火星への旅となると、地球自体が見えなくなる。その不安感は相当なもの。宇宙線でのストライキやセクハラといった実例も話題となった。自殺しそうになったり、殺人の一歩手前になった状況の話も。直近でのリサ・ノワクの誘拐事件とか、NASAでの心理テストにも触れていた。個人的には、どんな心理テストなのか突っ込んで欲しかったけど。

ロシアの元飛行士は、女性が一緒に作業する事で整理整頓される事などを言っていたが、ロシアの立場としては火星旅行には女性を含めるべきでないとの意見とか。

顔の表情でストレス度を測る技術の検討の様子も紹介された。また、人工的な話し相手の技術の紹介もあった。

シュミレーションでは、6名としていたが、メンバー組み合わせの検討も課題。番組では深く掘り下げていなかったがNASAの事、是非成果を発表して欲しいものだ。チームビルディングでの画期的な手法となるかもしれない。

事故への対応も自分達だけで解決しないといけない。アポロ13号の事故での対応の(懐かしい)実写も紹介されたが、火星旅行となると通信遅延がネック。自己解決が前提。

スリーマイルでの事故の反省として、自動運転に慣れてしまった事が事故への対応を遅らせた。そのための訓練が重要。また、旅行の最中での練習もすべきなんだろうけど、後者は突っ込んでたか?? 事故と同時に治療も重要。かと言って、お医者さんを搭乗させてもどれくらいの解決になるか、、。検査システムや医療システムをどれくらい乗せられるか。薬の量だって無制限には乗せられない。(MRI装置なんて夢だろう。)

事故としては、塵旋風(じんせんぷう)への取り組みを紹介していた。砂粒の問題よりも、電荷の問題の方が大きそう。

いや~、面白かった。

ちなみに、今度の土曜日(16日)に再放送される。

http://www3.nhk.or.jp/hensei/program/p/20080216/001/10-1300.html

2月 7, 2008 テクノロジー, プロジェクトマネジメント, プロジェクト管理, 技術, 映画・テレビ, 科学, 科学・技術, 科学技術 | | コメント (0) | トラックバック (0)

2008年2月 4日 (月)

海老名駅改修 一部供用開始

昨日が海老名駅改修の一部供用開始だったけど、今日はじめて利用した。

相鉄→小田急での乗り換えは、一旦広場の方へ降りてそこから階段。少し時間がかかるようになった。

中央通路と思っていたのは、JR相模線への連絡通路だった。

以前は何の表示なのか分からなかったのは、エスカレーターの表示だった。下向きとか、通行不可のマークが表示されていた。以前は壁越しでしか見えなかったので、エスカレーターとの関連がぴんとこなかった。

それにしても、小田急の新駅舎の階段は狭い。ホームの幅の問題もあるけど、どうにかならなかったのか?? ガラスを利用してるのも、かえって狭く感じるのかな。混んだ時に脇に寄ろうとしても、ガラスなので、大きな荷物とかあると抵抗ある。

先週末からすると、自動改札の個数が増えたり位置が少しずれていた。下がコンクリートだったけど、塗りなおした感じじゃなかった。移動を前提に配線用の隙間を作っていたのかもしれない。

2月 4, 2008 プロジェクトマネジメント, プロジェクト管理, 海老名駅改修 | | コメント (0) | トラックバック (0)

2008年1月29日 (火)

海老名駅改修 一部供用準備

小田急海老名駅の改修は、2月3日日曜日に新駅舎の一部供用が開始される。中央通路などが開通する。日曜日にしたのは、当初(早朝)の混乱が避けられるためだろう。また、日曜日で通行に慣れた人が月曜日に少しでもいれば、動きがスムーズになる。

P1290019P1290020

従来の通路が通行止めになるので、通行止めの掲示が行われている。左は、相鉄と小田急の連絡通路部分での掲示。

駅のホームでの掲示板でも通路変更の旨を表示してた。あのシステムは、電車運行のデータとか、事故とかでの遅延の対応ではおなじみ。今回のような臨時的なニュースの掲示も行えるんだ/行うんだと、妙に関心した。

P1290021P1290022

中央通路は結構壁が取り払われて来た。


週の初めからだけど、通勤時間帯に駅職員がお知らせのチラシを配っていた。チラシは、ポスターでの掲示をA4の裏表にしたもの。(置き場所への配置もやってた。)

1月 29, 2008 プロジェクトマネジメント, プロジェクト管理, 海老名駅改修, 電車 | | コメント (0) | トラックバック (0)

2008年1月25日 (金)

海老名駅改修 通路変更のポスター

P1250018先週くらいからだったか、掲示されているポスター。2月3日の日曜日に大きく通路が変わるため。

1月 25, 2008 プロジェクトマネジメント, プロジェクト管理, 海老名駅改修 | | コメント (0) | トラックバック (0)

2008年1月15日 (火)

海老名駅改修 売店とエスカレーター

海老名駅の改修。まだ工事中で通行自体はできないけど、(新駅舎での)中央通路での売店を見かけた。実際は、2,3日前にできてたと思う。

P1150002少し分かりにくいが、左の写真での少し右のSHOPという緑の看板の部分。

考えれば当たり前だけど、駅の改修といっても、売店の営業を止めるわけにも行かない。まっ、乗客にとっても困ってしまう。

駅の売店って系列会社の運営だろうけど、売店としたら看板とか色合いとか変えたい部分もあるだろう。ジュース類の販売のための冷蔵庫(冷却機)もある。自販機の設置も。それらも一挙に解決しないといけない。工事の視点だけじゃ駄目なんだな。


P1150003左は、駅ホームのエスカレーター。数日前から、こちらも見えるようになって来た。以前は壁(パネル)で見えなかった部分。


1月 15, 2008 プロジェクトマネジメント, プロジェクト管理, 技術, 海老名駅改修 | | コメント (0) | トラックバック (0)

2007年11月26日 (月)

相鉄 海老名駅 ホーム拡張

先週だったか、相鉄の海老名駅のホームが拡張されていたのに気がついた。

Pb260107_2その前の1週間ほどがお休みで、海老名駅を利用しなかった。そのためもあって、最初「あれっ、なんか変わったような」程度。気づくのに時間かかった。特にそれ以前に、工事みたいなアナウンスなかったと思う。もちろん運休のニュースもないはず。

となると、一晩で作業した事になる。200メートルくらい。写真中央の黒っぽい所が前のホームの端。それを左方向に拡張している。

もちろんレールも拡張、屋根や柱も付けて、、。古いレールを外して、ポイントも増設。さすがに、今までの柱はそのままだった。多少通行の時に邪魔になるので、いつが作業するんだろう。

たぶん新しいレールは、相当前に敷設してたかも知れない。当初は引込み線とか古い線くらいに思っていた。でも、不思議なもんで、ちゃんとした記憶がない。レールのみの工事との違いは、屋根とかの工事との兼ね合いがあるところ。レールの工事先にやって屋根とかの工事だろうけど、個人的にはどっかで作業を重ねたように思う。所謂ファストトラッキング。あるいは、ある範囲のレール作業をやって、その後屋根と別の範囲のレールをやる方法も考えられる。うーんどうやったのか、、。

それらの作業を一晩で。始発を遅らすわけには行かないので、作業は分刻み。イヤー、現場を実際に見てみたかった。そんなプロジェクト管理も、こなせないといけないんだろうな。

ということで、手元のプロジェクト管理ソフトをいじってみた。2003版。開始日はあるけど、開始時刻設定がない。がーん。おっととと。

時とか分刻みのプロジェクト管理。ちょっとツールも含めて勉強してみるつもり。

11月 26, 2007 プロジェクトマネジメント, プロジェクト管理, 技術, 海老名駅改修, 電車 | | コメント (0) | トラックバック (0)

2007年3月21日 (水)

「海を渡った新幹線~開業までの1000日を追う」

今朝何気なくTVを見ていたら、オレンジ色の新幹線が出てきた。いわゆる「ドクターイエロー」かなと思っていた。が、色が違うし、一部しかオレンジ色じゃなくて何か雰囲気違う。さらには、変電所からの電気が通じなくて走れないことになるとか聞いたら??? 「もしかしたら」と思ったら、案の定”台湾新幹線”。えっ~、と思ったらどうもドキュメンタリー番組みたい。あせって、録画をスタートした。

調べたら「海を渡った新幹線~開業までの1000日を追う」、製作:テレビ大阪、放送:テレビ東京、10時半からの約1時間番組。

日本人スタッフの何人かにスポットをあてたもの。実験走行の様子も結構細かくて、丁寧な作りと感じた。その走行の頃は、日本人の運転手。向こうでの食事の様子や、太い腕での運転の様子を見ながら、本プロジェクトの幅広い人材の必要性をひしひし感じた。

途中からフランスの運転手になる所や、本格開業に向けての紆余曲折にも触れていた。全部が日本製(システム)だったらとの思いもそれなりに伝わってきたが、やはり相手のあること。そう声高には言えない。(うーん、難しい、、。)

少しショックだったのが、アース線の盗難とその対策。最近の国内の事件を含めると、しばらく前には検討項目にすらならなかったような事を、今はプロジェクト完遂のためには考えないといけない。残念だけど。


車両メンテナンスが日本担当だと言うのが出て、なんか安堵した。これから、教育などを通じてレベルアップを図るんだろうけど、メンテナンスが海外だったら技術的な一般論としてもおかしく思う。なお、メンテナンスの教育で、「よっし」だと思うけど、日本語なのが少し嬉しかった。

先頭から見れなかったのが、非常に残念。テレ東さんが、BSも含めて、再放送検討してくれると良いんだけどな~。

3月 21, 2007 プロジェクト管理, 技術, 映画・テレビ, 科学, 科学・技術, 科学技術, 電車 | | コメント (0) | トラックバック (0)

2007年2月19日 (月)

「東京マラソン」プロジェクト

昨日は、雨だった事もあり時々「東京マラソン」の様子をTVで見た。一夜明けた今日は、ワイドショーでも舞台裏を放送していた。

当日のTV放送(フジテレビ)等での値を以下に記載してみる。聞き違いとかは、ごめんなさい。また、約とかは省略。車椅子と10Kmの部も開催されたけど、ここでは記載省略。

フルマラソン参加予定者数 25873人
最少年齢 18歳
最年長(男性) 85歳
最年長(女性) 79歳
平均完走予想タイム 4時間9分59秒
ボランティア人数 1万人
動員警察官 5000人
スポーツドリンク 22万8200杯
ミネラルウォーター 40万本
給食エリア 4ヶ所
バナナ 4万2000本
一口アンパン 1万2000個
人形焼き 6000個
梅干 8000個
チョコ 1万4000枚
レーズン 1000粒
完走女子への花束 6000本
トイレ スタート地点に500台
トイレ 1キロ毎に確保(コンビニ、仮設等)
医師 40人
看護師 66人
トレーナー 110人
ドクターランナー 100人(赤いバルーンつけて併走)
AEDバイク隊 10人(自転車)
ランナーの荷物搬送 40台(11トントラック)

AEDバイク隊は大学のボランティア。一時心配停止者が2名。(救急搬送は16人?)

制限時間は、7時間。完走率96.7%。

全員がランニング用ICチップを実装。今回は、ゼッケンナンバーで携帯等からラップタイムが判明するようにしていた。

wikipediaの「東京マラソン」は以下。

http://ja.wikipedia.org/wiki/%E6%9D%B1%E4%BA%AC%E3%83%9E%E3%83%A9%E3%82%BD%E3%83%B3

交通規制の準備も大変だったようだ。交通規制の関係で、陸の孤島化した箇所には、事前に消防車待機。当日予定されていた慶応大学の入試では、受験票に交通規制の旨を記載。

TV番組では、予算は15億円で、そのうちの1億円が都の財政からと言っていたと思う。

結構意外だったのは、小雨の中でゴールでのテープを持つ人が着物姿だった事。いきだな~。ただし、女性ランナーの有森さんの時は普通の姿の人だったので、ちょっと残念。深々と頭を下げた有森さんと一緒だといい絵になったんだが。

また、ちょっと良かったのは、スタートの時に東京メトロの透明の薄いポンチョ。(あの寒さと、荷物を預けた後からの時間の長さじゃ、気休めだろうけど。)

交通規制の様子や、仮設トイレの搬送の様子を以前見たけど、これだけの規模のプロジェクトをほぼ完璧に進める所が日本のプロジェクト管理のすごい所と感心した。所々に気配りもある。


ただしTVでも指摘されてたけど、課題はトイレと荷物。後者は、特にゴールした後での処理が良くなかったみたい。1時間も待たされたとか。

飲食物が少なかったのも今後の課題。特にバナナは当初37万本との案内で、後になって1桁間違いに気づき急遽(元の3万7000から)増やしたとのこと。

初の市民フルマラソン大会だからとの話しがあるかもしれないし、都市マラソンとしてのユニークさやランナー等からの好感もあるが、やはりトイレ等の件はプロジェクトとしてはちょっといただけない。人数多いのは当初から分かっていた事だし、制限時間7時間となるとやはりトイレや食べ物などは大きな課題。

数年前までは、東京シティマラソンとして市民マラソンを開催している。また、車椅子のレースも同時というのも一緒。そのレースでも、都庁から大井競馬場まで荷物をトラック輸送していた。(ただし、シティマラソではそれなりの制限があり、フルマラソンかハーフマラソンで○○時間以内の記録証の送付が義務付けられていた。)

その当時を知っている人がいたら、今回のフルマラソンでの荷物搬送も改善できたのかもしれない。

プロジェクト管理でも、先達の知恵の確保なり継続が重要という事を感じた一日だった。

2月 19, 2007 スポーツ, プロジェクトマネジメント, プロジェクト管理 | | コメント (2) | トラックバック (0)

2007年2月10日 (土)

半導体プロジェクトはなぜうまく行く?

プロジェクト管理で参考にしたいと思っているのに、「建築・土木などのエンジ系」、「半導体等のハードの設計・製造」、「日本の祭りや共同作業(ユイ)」がある。ついこの前エンジ系の話しは聞くチャンスがあった。今日は、たまたま、とある会合で半導体関連の人と話チャンスがあった。会合は技術関係でなく立ち話だったけど、相手はある研究所の所属、海外での発表の経験もあるので、さほど的外れじゃないと思う。ただし、チップの種類や企業・部門間で違うことはあるかもしれない。

会話の概要は以下。(ほろ酔いだったりしてるので、聞き違えていたら、ごめんなさい。)

私「ソフトウェアのプロジェクトと比べて、何で半導体の設計とか製造はうまく行ってるの?」
「設計とか製造で、それなりのマージンを持たせるから」

私「それでも、先覚的な場合、うまくマージンどおりになるとは限らないでしょう。」
「それは、他も同じ」 (他って、いわゆる研究系の物性特性とかのことだろう。)

私「半導体もブロック毎の設計になってるけど、設計者の言ったマージンどおりの設計にならないとかインタフェースミスは起きないの?」
「それは、他も同じ。でも、作る前にタイミングとかはシュミレーションで問題ははっきりする事が多い。」
「設計で守るべきルールが少なくない。パターンの線間距離とか、アースの引き回しとか。」  (企業の各社とか部門や部でそれぞれルールを持ってる感じ。)

私「でも先覚的な場合、そのルールを守れない事があるでしょう」
「そこは悩みどころ。ただし、(先覚的とは限らないが)安易に守らない設計の場合に、後で問題発生する事が少なくない。まっ、人による事が少なくない」  (←「守れない」と「守らない」は、全然違うんだろう。)

私「設計と製造はどう切り分けてるの」
「設計の基本は、Cみたいなので書くとこまで」 (←Verilogなどの件と思う。)
「その言語で設計上の間違いをチェックする」
「基本的に言語上でのチェックがOKなら、その後は製造系の作業」


話しはVerilogなど一般的な情報だけど、キーポイントが分かってよかった気がする。(逆に、一般情報だったのでここで掲載。)

今回身に沁みたのは、ソフトウェアでの設計と製造の未分化やルール厳守が徹底してない点。ただし、分化してVモデルで猪突猛進で実践しようとするのは大きな問題。またルールの厳守で、一つ覚えのように静的解析ツールの結果での軽微な間違いまでも対応させる態度も大きな問題だ。


2月 10, 2007 ソフトウェア, テクノロジー, プロジェクトマネジメント, プロジェクト管理, 技術, 科学・技術, 科学技術 | | コメント (0) | トラックバック (0)

2007年2月 3日 (土)

多摩川 羽村取水場や八高線事故

今日は、多摩川をサイクリング。羽村取水場まで行く。

昨日、プロジェクトマネジメントの話を聞いたこともあって、玉川上水の工事を推進した玉川兄弟の銅像をいわばお参り。


P2030016P2030020羽村取水場の玉川上水寄りでは「牛枠」を展示していた。昔の治水のための設備。多摩川では、羽村取水場の少し上流に実物がいくつか設置している。前も目にしたが、今回結構数が増えたと思う。去年(?)の倍? ちなみに酒匂川では、他の治水設備の展示もあり興味深かったことがあった。

帰り道でちょっと疲れて休憩しようかと悩んでいる時に、サイクリングロード脇の「八高線事故」の展示を目にした。休憩をかねて写真を撮る。

P2030027P2030028終戦直後での、正面衝突の事故。いわば失敗事例の展示。身近な所に、こんな展示があるのはいいことと思う。なお今回細かく見たが、結構腐食(さび)が進んでいた。


玉川兄弟銅像をお参りしたので、プロジェクトがうまく行くようになればいいが、(自分以外の)課題が少なくないな~。昔、”後は神頼みのみ”みたいなプロジェクト体験は少なくなかったけど、今は少し違う気がする。

2月 3, 2007 テクノロジー, プロジェクトマネジメント, プロジェクト管理, 技術, 科学・技術, 科学技術 | | コメント (0) | トラックバック (0)

2007年2月 2日 (金)

エンジのプロジェクトマネジメント

今日は、技術士会の会合で、建設・土木でのプロジェクトマネジメントの話を聞く。

IT分野でのプロジェクトマネジメントは非常に立ち遅れているので、以前から、エンジ部門の人たちから話を聞きたいと思っていた。会合が決まって、ぜひ参加したいと思った。プロマネでのフォーラムとか学会で話しを聞くケースはあるけど、技法的話が多いので勘所を聞きたかった。

都合で途中からしか聞けなかったが、懇親会では席が隣になり講演者と結構ざっくばらんにお話できた。

懇親会会場へ向かう途中で「荒くれ男たちのコントロール方法は?」と聞いたら、ちょっと怒られてしまった。思うほど作業者は無法者でない。自分自身も分かっていて、その背景などを会話を通じて聞いていった。最近IT従事者には、セキュリティとか納期とかでコンプライアンスをまったく理解してない人の事件が少なくない。

やはり、業界の教育なり根本的なことの徹底が違うのだろう。具体的には、納期に対する考え。講演では、工事の際の警備や誘導の人たちの挙動で、成功するプロジェクトか分かるとの話しがあった。そうだと思う。

また、プロジェクト管理での技法などにも話が及んだ。講演者は、技法よりも、根本的なこと=危機への対応力とか解決しようとする意識の問題を言ってらした。

2月 2, 2007 テクノロジー, プロジェクト管理, 技術, 技術士, 科学技術 | | コメント (0) | トラックバック (0)

2007年1月29日 (月)

「ヨードン」さんのサインをもらう

今日は、ある会合で”デスマーチ”で有名なヨードンさんの話を聞く機会があった。詳細は言えないが、日本wikiの件数をも把握していて、やはりすごい人と思った。

で、表題のように、サインをもらった。デスマーチの1版の方を持っていたのでサインしてもらった。実は、昨日その本を読み直したが、今でも示唆に富む内容が多かった。逆にヨードンさんばかりでなくソフトウェア工学の人が大抵しゃべるけど、20年とか30年してもソフトウェア工学の利用がなかなか進んでない。ほんと、考えないといけない。

なお、懇親会の会場で、急に話せといわれた。デマルコさん論文集の訳本(共訳)をやった関係。まっ、ヨードンさん自身がデマルコさんと仲良しだと、講演で何回かしゃべった事も関係したのかも知れない。

共訳の本は以下。

ほんと、いいチャンスに恵まれたといってもいい一日だった。

1月 29, 2007 ソフトウェア, テクノロジー, プロジェクト管理, 品質, 技術, 科学技術 | | コメント (0) | トラックバック (0)

2007年1月18日 (木)

マイリストの「ソフトウェアテストにおける直交表やAll-pair法の利用」を更新

マイリストの、「ソフトウェアテストにおける直交表やAll-pair法の利用」を更新しました。

大きな変更は以下です。
・自明と書いた部分を補足
・図でHAYST法をタグチメソッドからの派生としていたが、実験計画法からの派生へ
・L18の水準組み合わせを訂正
・直交表の例でのLauncharを紙サイズへ。またその表での間違いを訂正。
・その他。誤字脱字も。

コメントやトラックバック大歓迎です。承認制ですが、勧誘の類でなければ反映します。また、普段のハンドルネーム外を含む匿名でも構いません(気にしません)。

1月 18, 2007 ソフトウェア, プロジェクトマネジメント, プロジェクト管理, 品質, 技術, 直交表, 科学, 科学・技術, 科学技術 | | コメント (0) | トラックバック (0)

2007年1月17日 (水)

リビルド・プロジェクト管理は大変かも

ここ2,3ヶ月、通勤途上で気になっているのは、小田急海老名駅の改修。通路も駅のホームも作り直すようだ。

駅のホームに補強用の大きな柱を作るために、ホームが普段よりも狭くなっている。早朝(6時くらい)でも警備会社の人が新宿寄りに廻るように言っているし、ホームにも結構な数の警備会社の人がいる。駅員もドアへの誘導を行なうし、ラッシュとかだと警備会社の人が駅員のサポートを行なう場面も。意外と言うと変だが、警備会社の人も利用ありがとうございますのような事も口にする。

で、今日は小雨。ぱらぱらと音がするので見てみたら、大きなシートでの雨音。柱の設置のために開けた空間での降雨を防ぐもの。

少し考えたら当たり前だけど、これを手順設計出来るかと考えたら、非常に不安になった。つまり、ついつい新築での手順を考えてしまう。また上での警備会社の人の手配とか、そのコスト、さらには(駅業務に近い部分などの)教育などまですぐに考えが及ぶだろうか?

用語として、「リビルド」がいいか解らないけど、改修とか整備とかリエンジニアリングには、それなりのプロジェクト管理手法が必要かもしれない。でも、あまり聞いた事が無い。

しかも、大学教育などで改修とかを教えるんだろうか? あるいは、そもそも学問として体系だっていないかもしれない。失敗学のように、「リビルド学」が成立すると良いかもしれない。ロボコンも、事前に作られたものをチューニングしたり、変更して競争させてみると面白いかもと、ふと思った。

そして、ついつい自動車とか事務機などと、電機などとの対比を考えてしまった。整備とかメンテナンスが自動車業界では発達している。電機でのそれらよりも市場と見てもはるかに巨大だ。自動車整備の資格は有益だから、勉強する人も少なくない。

ビルメンテナンスなどは、市場としても大きくなってきたように思うし、土地や建物の再利用はこれからどんどん進むだろう。再開発も少なくない。それに応じた、学術的なバックグラウンドの確立やプロジェクト管理でのノウハウが必要だ。

1月 17, 2007 プロジェクトマネジメント, プロジェクト管理, 技術, 科学, 科学・技術, 科学技術 | | コメント (0) | トラックバック (0)

2007年1月 7日 (日)

割増賃金は人月ベース算出の亡霊?

今日の日経新聞の1面が、結構面白かった。(13版)

トップ記事は、厚生労働省の残業代の割増率引き上げ案。日本版ホワイトカラー・エグゼンプションと対をなすものと言っていいだろう。

で、面白かったのは、すぐ隣に三井化学の社会的責任を人事評価対象に加えるというもの。(さらに左紙面は「ニッポンの家計 イエコノミー」の連載で、家計における地域や会社との関わりあいの変化を指摘している。)

残業代の割増率引き上げ自体は、労働者の健康等のためには必要。それは認めるとして、社会的責任との対比などで、ついついソフトウェア開発における”人月”との関連を考えてしまった。もう何年も前に指摘されていること。

ソフトウェア工学とかプロジェクト管理関係者の飲み会で、会社や部署での”人月”の呪縛が話題となる。コストプラスインセンティブフィー契約のメリットを知っていながら、実践が少ない(幅広く実践されていない)。ずっと昔、豊臣秀吉が一夜城の構築で、実証したのに、、、。(笑)

ソフトウェア作成のメトリックスに残業時間がメインという所も。というか、それしか尺度無い所も。バグの修正で残業が多いのと、ちゃんと動いて残業少ない人とどちらを評価すべきか歴然としているんだが。ちゃんと動かして残業少ない人も、長い期間残業で多量プログラム作成するとガタがくる。

割増率引き上げで社内規定を見直す企業が多いと思われるが、社会貢献とかインセンティブフィーまで視野に入れる所が多くなればいいんだがどうなるだろうか。。。


1月 7, 2007 ソフトウェア, ニュース, プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2007年1月 5日 (金)

トヨタの引越し

CS放送TBS”ニュースバード”でのトヨタの引越しの様子を、録画再生して見た。もしかしたら、昨日から放送したいたかもしれないが、早朝の出社前にチラッと見かけ、リピート放送を予約録画していたもの。

正月休みを利用しての、名古屋駅前”ミッドランドスクエア”への3000人の引越し作業の様子。”ミッドランドスクエア”は地上47階、そのうちの17階~40階がトヨタ。東京の海外営業も移動するとの事。

トヨタ流の引越しの様子が、所々紹介されていた。いわばトヨタ生産方式を引越しに適用した様子。マニュアルが整備され、社員や運送業者にまで行き届く。無駄を省くために、引越し前の廃棄で4割削減したとのこと。トラックでの積み下ろしを10分以内と目標設定。

ダンボール4万個、トラックはのべ800台。結局予備日の1日を残した状態で、6日で完了したとの事。積荷の時間ロスを1分とすると、800分=13時間→1日。そのため積み下ろし時間を重要視。

規模がでかいので、業者も多分複数。画面に出たのは、日通と西濃。運送業者が複数になるという事は、やはりマニュアルが必要という事か。(マニュアル化があまり好きじゃない私としては、再考しないといけないのかなと反省。)

壁に貼られたスケジュール表へ完了の旨の記載が映ったが、予定と訂正の欄があった。タスク(アクティビティ)の関連を示す矢印等や、訂正のスケジュール自体は記載されてなかった。そこへマジックで完了の旨をマーキングしていた。

タスク(アクティビティ)の関連性は、検討する時には便利だけど、皆が見て実行する時には不要なのかなとふと思った瞬間。来週実験してみるけど、MS Project→エクセルのツール使うのがいいような気がしてきた。あるいは、皆が見るスケジュールはカレンダー表示形式がいいのかもしれない。(ちょっと後者は、自分の場合アクティビティが多いので、芳しくなさそう。)

また、皆が見て実行する時の状況記載は、システムとかを絡めて考えた方が良さそう。少なくともその度にPCに向かってスケジュールソフトで更新するのは、効率悪い。かといって、巨大システム構築では期間やお金がかかるし、、、。

それにしても、引越しにまでトヨタ流を持ち込むのがすごい。うがった見方をすると、OB等のカンバンなどトヨタ流のコンサルが幅広くなる。OBも含めて、本報道はハッピーになるのかもしれない。

1月 5, 2007 ニュース, プロジェクトマネジメント, プロジェクト管理, 技術, 科学・技術, 自動車 | | コメント (0) | トラックバック (0)