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)

2014年7月13日 (日)

PMI日本フォーラム 2014

昨日と今日は、PMI日本フォーラムへ。2週間ほど前から台風の影響で荒れた天気になるかと思ったけど、台風一過で良い天気。何度かPMI日本フォーラムに出席してるけど、悪い天気の時と良い天気の時とが極端だと思う。

http://www.pmi-japanforum.org/pmij2/forum-2014/index.html

最初の日は、そんなに遅くなかったつもりだけど、大会場は人いっぱいで会議室の方に誘導された。なお冒頭の基調講演は、カーネギーメロン大学SEI所長の話だったけど、一般的なサイバー攻撃の話が主で、プロジェクトマネジメントの視点が希薄。その意味では会議室での視聴の方が正解だったかな。(逆に次の基調講演でのタレントマネジメント絡みは所々気になる箇所があったけど、聞き取れなかったりパワポが見えにくくて大会場の方が良かったように感じた。)

招待講演では、大阪駅前開発、気象衛星ひまわり、9.11に関連する放送、選挙ボランティアなどの話を聞いたが、IT以外の分野の話で、結構本質的に参考になることが少なくなかった。ついPM学会でのIT系の話にジャンプしてしまうのと対比的と感じた。個人的には日本フォーラムの方が、プロジェクトを議論するにはいいのかな~との印象が強まった。PMI日本フォーラムでの招待講演に該当するものがPM学会には少なくて各セッションでの講演になるからとの意見もあるだろうけど、PMI日本フォーラムでの各セッションの講演もIT一辺倒でない。

招待講演での大阪駅前開発は、JVなんだけど、官公庁との意見対立やその仲介役というかお膳立てによる根回しや各社役員クラスによる会議運営など、やはりそんな苦労があるんだ~と参考になった。各ビルは主体となる企業の担当にするけど、景観的な統一感は必要でそのための工夫の話などもあった。また、選挙ボランティアの話では、その前の映画作成にタッチした時(特に照明や美術といった専門家への対応)のことにも触れ、幅の広いプロジェクトメンバーの接し方などが参考になった。

各セッションで聞いたのは、PMBOK5版(特にキーワード”Change Management”)のこと、OPM(組織成熟度)、アジャイルなど。総じて以前よりは分かりやすい説明が多かったように思う。なお細部は省くけど、今年は自分の見聞きしたセッションでは、時間枠をぎりぎり講演に使って、Q&Aに割くケースはなかった。皆さん、質問したい人は休憩中などに個別に行っていた。PMIJの中に研究会がありその経由での発表が少なくないので、今回の方がいいのかもしれない。的確な質問の時もあるけど、変な質問で時間を取られるのも困りものだ。


充実した2日間だった。今後資料のダウンロードができるだろうから、ダウンロードして(聴けなかった講演を含めての)資料や自分の考えの整理にしばらくかかりそう。

7月 13, 2014 プロジェクトマネジメント | | コメント (0) | トラックバック (0)

2014年3月14日 (金)

PM学会 2014春季大会

昨日と今日(13・14日)は、プロジェクトマネジメント学会の2014年度春季研究発表大会へ。東洋大学。

ためになった講演やセッションも少なくなかったけど、全般的に以前よりさらにIT系セッションの割合が増えた感じがした。しかもIT系でのプロジェクト管理というよりも、ソフトウェア固有の問題と思えるようなことの、品質やプロセス改善の話が多いと思われた。また学生などの発表では、そんな研究してるんだ~と面白く聞けた半面、学内発表に近い気がしたというか考察も含めてもう少し練り上げや改良/改善が欲しいと感じた。

なお、印象的だったのは、”プログラム”に関するセッション。PM学会の案内等でプログラムの定義を募集してたりして、セッションに人は集まった感じ。でも、学会の定義募集への反応も希薄だったようだし、発表者と聴講してる人達とが上手く噛み合わない。自分もそうだけど、プログラムは多少は気になるけど、「プログラムをいかに上手く回すかは別の人達だろうに、、、」との思いがあるからかもしれない。事業部長とか経営層。プロジェクトは一生懸命やったけど、プログラム管理が良くなくて全体が上手く回ってない。そんな感覚の人/そんなことに遭遇した人が多いのかもしれない。プログラムに関して発表する人達の題材も、多少現実とかけ離れてるように感じているのかもしれない。(○○はプログラムだけど***はプロジェクトみたいな話もあったけど、そこから先のプログラム管理の問題や管理事項が急に抽象的に思える。)

なおその他のセッションでは、メンタルヘルスに関するセッションで具体的な取り組みなどを聞けたのは良かったと感じた。

全般的に、どうも春期大会は、自分には今ひとつの感じがしてきた。以前もそんな気分の年があったような気がする。次回の秋のプログラム発表の時には注意しておき、春期と秋期を比較してどちらに参加するかなども検討してみたい。


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

2013年8月23日 (金)

三人寄れば文殊の知恵が、、、、、まとまらない

ここ1,2週間、数人での作業が発生した。イメージ的には文章の手直しの作業で、時々意見の相違が発生した。「てにおは」の修正のような(ある意味)微々たる事項から、論理的な文になってないなど様々。ある意味そのための作業であり仕方ないし、話すことで妙案に進展したものもあったが、各自の考え方の相違で多少平行線のものがあった。似たような作業でのここ1年くらいでは、ヒートアップ度やその回数が一番大きかったかもしれない。

で、ふと思い出したのが、開発時の会議や設計ドキュメントのレビュー時の意見対立。直接レビュー会議のような場での意見提示でなくても、トラッキングシステム(大昔なら紙に記載してその紙を回覧しながらコメント記入)でも相反する意見が出ることがある。書いたのがAさんなら、修正案がBさんから出て、別修正案がCさんから出たり、元々のAさん記載が良いとの意見が出たりする。

ものの本ではレビューの必要性などが書かれているけど、レビューの必要性よりもどう収束させるかが悩ましい。その部分は、大昔から良い解法がないように思う。ある意味ではレビュー技法などが発展してないとも言えるし、レビューを実施している人達はレビューに関する記事や論文を余り当てにしてないのかもしれない。より正確な表現を使えば、レビューを実施している人達にとって参考となる記事や論文は少ないのかもしれない。

もちろん、論理的/合理的な説明で収束したり実験検証に委ねたりするケースもあって手法もあるが、リーダー格が「えいやっ」で判断せざる終えない局面もある。平行線になった場合、そのような判断を誰かがしていかないと、効率が悪くてしょうがない。

ここ1,2週間での作業で、意見の相違が多かったのにそれなりにまとまったのは、リーダー格を明示的に決めていたことだったろう。当然と言えば当然だけど、今回は皆さん意見がばらけるかもとの意識があったせいかと思う。

ちなみに、”インスペクション”手法での役割として”モデレーター”があるが、ここで言ってる意見集約での責任者という意味では、個人的にはちょっと違うと認識している。ファシリテーターに近いし兼ねることが出来るかもしれないが、合意形成を素早く行ったり判断が必要な点でも少し異なるように思える。なおここでのリーダー格がちょっと大変なのは、せっかく合意形成が出来たり自分が判断したのに、特に上司や他部門によりひっくり返される時があること。しかし、まっ、こればかりは仕方ないと割り切るしかない。


さて今回の作業などで、つい思い出したことがある。2つのプロジェクト。片方は開発ドキュメントもそうだが、特許明細とか営業やユーザ向けの文書チェック作業も発生。冒頭で書いたような「てにおは」の修正にも神経を使ったそうだ。(大変だったろうが、後述するプロジェクトよりは遙かに精度が高いことになる。)

もう一つは聞きづてのもので、納品物のドキュメントに対して「○○が書かれてないから記載して欲しい」とか誤字脱字の指摘を行った人の話。委託先から一言あってPLも誤字脱字“ばかり”指摘するのもと、修正に消極的。他の件もあって、システム化への意識のもなく横柄なPLとの印象もあって、結構プロジェクトそのものに幻滅したとのこと。本人は、不明な未記載ロジックの記載が主で、誤字脱字はついででの指摘のつもりだったのだが。

結局、納品物はそのままOK。検収とか支払いが絡むからだったのかもしれないが、何のための納品チェックなのか??? 修正などを見越してないやり方だったと言える。案外、請負や丸投げでの根本的な問題なのかもしれない。


つまりレビューをすることの必要性などが記事や論文で書かれているけど、それをそう反映するとか、契約と絡めて議論していかないと/組織体で解決策を持っていないとメリットが生まれない。逆にレビューをやっているところは、反映方法や契約と絡めた対処法をより向上させるべきだろう。

8月 23, 2013 ソフトウェア, プロジェクトマネジメント | | コメント (0) | トラックバック (0)

2013年6月13日 (木)

「あべのハルカス」 日本一高いビル

今日何気にテレビを見ていたら、「あべのハルカス」というビル名。なんでも日本一高いビルだとか。聞いたことが無くて、色々調べた。大阪のビルで、既にウィキペディアにも出ていて以下。

http://ja.wikipedia.org/wiki/%E3%81%82%E3%81%B9%E3%81%AE%E3%83%8F%E3%83%AB%E3%82%AB%E3%82%B9

今日のニュースは、そのビルのテナントである近鉄百貨店がオープンしたというもの。今回は一部開業で、ビル全体の竣工は来年2014年3月とのこと。

そもそも、建て替えで日本一高いビルというのが凄いし、しかも最初の計画から変更して日本一の高さにしようとしたそうだ。(東京スカイツリーの、世界一への変更を思い出させる。)

そして、一部を開業。営業設備の隣で工事がしているというわけだ。安全への配慮や騒音や工事車両の出入りなど、考慮すべき事項の難易度が1桁とか何桁も違うように思う。


建設分野って色んな課題をどんどんクリアしていて、技術開発も含めて、チェレンジャブルな業界に思える昨今である。

6月 13, 2013 ニュース, プロジェクトマネジメント, 技術 | | コメント (0) | トラックバック (0)

2013年3月18日 (月)

WBC グリーライトのサインも一長一短

今日の昼。ふとTVの前を通ったら何人か見てて、なんだろうと思ったらWBC(ワールド・ベースボール・クラシック)の準決勝。日本対プエリトリコの試合で、8回裏の日本攻撃だった。1,2塁という場面で盗塁したんだけど、(2塁の選手はすぐに戻り)1塁からの選手がアウトになって、皆さんため息になってしまった。

その時にテレビの解説の人が、サインに関して「グリーンライト」がどうこうと言ってたので、さっき調査。テレビ解説者も少し述べてたけど、盗塁を選手の判断に任せるというものらしい。今回のWBCでの日本のチームは結構多用したようで、少し前の台湾戦でも用いて得点に駒を進めたようだ。

解説を聞いた時に、野球にもそんな指示の方法があるんだとか、自主性に任せるのは悪い事じゃないよな~とか考えた。ただし今回の状況は、1,2塁の出塁時。いくら自主性に任すと言っても、1,2塁の各選手の息が合わないとうまく行かない。なので本当にグリーンライトのサインだったか、個人的には疑問だ。

プロジェクトで、自主性に任せることは時々経験がある。なかなかプロジェクトマネジメントの教科書に出てくるテーマではないが、実践の際には留意している事項。ソフトウェアテストでは「殺虫剤のジレンマ」を回避する意図もあって、テストケースとして”***部分は担当者の考える値でテストすること”として、敢えて値や方法を記載しない事も行われる。

プロジェクトやソフトウェア開発でも、自主性に任せても良さそうな時と、それではまずい時があるので、使い分けが必要だ。今日のWBCのプレイを見て、ふとそう思った。

3月 18, 2013 スポーツ, ソフトウェア, プロジェクトマネジメント | | コメント (0) | トラックバック (0)

2013年3月10日 (日)

会計担当になって思うに

今日は、自分の属するふるさと会の会合。会合と言っても同郷の人達が集まっての飲食が主で、今日のこちらは会の運営サイドで、式では色んな裏方作業を担当した。

で、以前に会計報告を担当して欲しいと言われて「実際の会計担当でないのに、、、」と思いながら、渋々引き受けた。そしたら今日驚いたのは、来期の担当として”会計”と書かれていること。会合で会計報告をしゃべるのと、会計を担当とするのは大違い。自分は知識や性格で分野的に会計という柄じゃないし、他の人からも言われたけど「ほんださんは会計無理でしょうに、、」^.^;。 まっ、今までの担当の人とか新しい他の担当の人とかとも話して、(会計報告する程度の作業にさせてもらえそうだったので)結果的にはそっちも渋々引き受けてしまった。

会合での焼酎によるほろ酔い状態で帰宅し、ふとこんな団体での会計とプロジェクトマネジメントでのタスクとの関係が気になってきた。PMBOKのプロセス群と知識エリアの表を見ながら、思いをめぐらせた。

このような団体って、具体的には、町内会とか勉強会の団体なども似ている。設立されて、イベントの時など会費などの収入と設営や材料費を見ながら創意工夫。単位年度ごとにグループ内(外)に収支決算を述べる。団体の消滅はあやふやだけど、少し余ったら会運営メンバーの飲食に回して解散というケースが多そう。赤字での解散ケースでは、会長さんや会運営メンバーが身銭を拠出だろうか。

ただ、結構悩ましいのが、通帳の名義。最近は厳しくて、団体名で簡単に通帳を作成できない。かといって会計担当や会長の個人名義だと、担当などが変わった時に名義変更するなどの処理が必要になる。団体によっては、思い切って法人化するところもあるにはあるだろうけど。(個人的な実感としては、団体名通帳作成のための対応を行うところが少なくない。)

「”通帳作成”って、どこのプロセスかな~」と思ったけど、プロセス群と知識エリアの表に該当するのは無い。団体の設立プロジェクトの場合として表を眺めても無い。つまり、プロセス群と知識エリアの表って、組織体がある程度構築できてからの体系と考えるべきだ。ある意味当たり前で、今回認識を新たにした。

本ブログで他にも述べているけど、定常業務とプロジェクトマネジメントは、やり取りしながらの運営が必要だ。プロジェクトを、プロジェクト目線でばかり見ていては不十分と言っても良い。町内会だと、夏祭りを1プロジェクトとすると、それ以前に、会計担当やその資金プール、人的資源確保で言えば確実なメンバーと予備的なメンバーの想定や根回しなどがあるかと思う。 (プロジェクトマネジメントの技法的には、前提条件とかへの記載項目だろうけど、実際に夏祭りを運営する際には、それらの前提条件を実施しておく必要があるといったイメージだろうか。)


なんか渋々引き受けた会計担当だったけど、プロジェクトマネジメントの知識体系や定常業務との関係での気づきが出来たことは大きかった。


追記:今日金融機関に出向いた際に、ついでに団体での通帳のことを聞いてみた。4月に少し法律改正がありそうなことも含めて親切に教えてもらった。手間も少ないベストな方法は決まってないようだが、思うに、団体の申請も行って団体の印鑑も作成して使用するのが良さそう。担当や会長が替わっても対応しやすい。そうなると、組織体としてまず考えるべきは、規約、メンバーやシンボル(印鑑)ということかな。後者の括弧部分は日本の場合になるだろうけど。

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

2012年12月23日 (日)

定常業務とプロジェクト

ここ2年近く、プロジェクトマネジメントの講演や会合などで”プロジェクトの終結後、定常業務へ”との文言が気になってしまっている。定常業務へ移行するとか、定常業務メンバーに引き継ぐとかの表現がされる。

以下の図は、 http://www.pmdi.jp/article/14196510.html からのものだが、PMOを絡めたより詳細の図もあるようだ。(元々はどこでの図かと探したが、はっきりとは分からなかった。)

Photoプロジェクトと定常業務が対比的に書かれている。

ITの場合、設計開発が行われてカットオーバーされたら保守要員に引き継ぐ事が多くて、定常業務への引き継ぎとの表現には馴染みがあるのかも知れない。建設などでは、メンテナンス会社への移行のイメージだろうか。

ただ結構、サービスのために中盤や終盤からサービスメンバーの引き継ぎのためのプロジェクトや教育が始まることがある。逆に、製品開発で出荷後に開発者が更新プログラムをリリースすることなどが行われている。それらのために、「定常業務への引き継ぎ」に少し違和感を覚えてきた。

また、プロジェクトでも、会計や購買とか人事関係とかの部署の助けを借りることが少なくない。そのような部署のメンバーの活動はむしろ定常業務に近い。

建築現場を考えて見ると、作業自体はルーティンワークにも見える。研究、設計・開発も同様である。結局は、定常業務とプロジェクトとしての見方での区別や、定常業務とプロジェクトの作業割合による区別かも知れないと考えるようになった。よりプロジェクト的なのか、より定常業務的かの違い。(ちなみに、昔「タスクフォース」という言葉が使われた時には、普段の業務とは別作業を意味して、”タスクフォース専従”メンバーという言い方をしたりした。)

トヨタに主査(最近はチーフエンジニアと呼ばれるそうだ)という職種って、メンテナンスを含めて面倒を見るというかプロジェクトを統括する。日産やホンダといった企業も全く同様かは不明だが、似たような制度と思われる。以前このブログで「プリウスという夢」 というのを書いたが、ラインオフ時に既に次のプロジェクトに参画している開発関係者が少なくなかったことなども象徴的と言える。

そのようなことを考えると、各自の作業が、どのプロジェクトに属するかとか定常業務に属するかを経理的に把握することが重要と言える。そうしないと、特定プロジェクトが赤字なのか判別できない。

ちなみに、製造業では、製品の研究や開発、市場化で投入できる工数の番号(記号)を区別して、研究→市場化をトレースできるようにしているところがある(多い?)ようだ。したがって、運用的には、作業区別を行えるようにしてあるし、赤字プロジェクトかの判断も行っていることは想像に難くない。個別製品の場合などには、「製造指示番号」で区別・管理することもあるようだ。

会計ソフトでは、一般的な会計管理に加えて、プロジェクト管理会計の機能を備えていたりオプションで追加できるようにしてあるものがある。実際に利用してある企業も少なくないのだろう。

それらを考えると、示した図での定業業務/プロジェクトという二律背反で考えることが良くないと言える。あるいはモデル的にはそうでも、それらがミックスされた状況を考える必要があると言える。

なおプロジェクトの中盤では、むしろ大抵の場合は、各自の作業は定常的に行われるのに近い方が良いかと思える。ある程度、定時で作業が終了できるイメージだ。ソフトウェアの開発でも同様だ。プロジェクトの開始時や終盤ではそうも行かないだろうが、中盤で作業量が想定と大きく異なるのは避けるべきだろう。


プロジェクトをプロジェクト/定常業務、プロジェクトメンバー/定常業務メンバー、プロジェクト工数/定常業務工数などで考えたり、それらとプロジェクト工数やプロジェクト予算との関係や把握ができているかを考えてみるのは良いことであろう。


追記:プロジェクトと定常業務を全く対比的に考えたり、運用を定常業務への引き継ぎとの発想では、いわゆる”DevOps (a portmanteau of development and operations)”の課題をうまく対応できないと言える。ちなみにDevOpsは開発・運用の相互依存のことであり、アジャイル開発等では開発と運用を一体化した方が良いとの考えと言えるだろう。


追記:以下では、「定常業務にプロジェクトマネジメントを適用すると収益が下がる理由」を述べている。

http://pmstyle.jp/honpo/note/note167.htm

定常業務化した方が収益が上がる。逆説的には、プロジェクトは独自性を持つため、どうしても作業の継続的な効率化に結びつきにくい。本サイトにも書かれているように、”できるだけ多くのプロジェクトを定常業務として行うことが求められる”。

プロジェクトをマネジメントする際には、プロジェクトに関係する定常業務や定常業務化なども念頭に置くべきだ。

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

2012年11月28日 (水)

プロジェクトマネジメント国際標準化フォーラム

今日は、情報処理推進機構(IPA)の「プロジェクトマネジメント国際標準化フォーラム2012」。プロジェクトに関する国際規格(ISO 21500)の成立に関するもの。

今までPM学会や研究会の雑談を含め、色々聞いていた。成立したISO 21500での基本的な事項には既に聞いたことが多かったが、細部や話題となった考えで今回成立してないことも少なくなかった。その意味で、フォーラム自体で策定に関する裏話(?)も聞けて為になった。ちなみに、規格書は日本語訳でも結構薄い。邦訳版で23100円。(会社なら即買いだろうけど、自分での個人購入となると微妙な金額かもしれない。)


ISO 21500は、PMBOKでの考えが色濃く反映されている。ただし、PMBOKでの「知識エリア」を「サブジェクトグループ」と言い換えて、数もサブジェクトグループは10個としている。「ステークホルダー」サブジェクトグループが追加された。全39プロセス。他にプロセスの番号付けなど、意識体系的な側面でも考え方で異なる項も多い。

PMBOKでの、ツールと技法は考えや用語として採用されていない。PM手法や契約種の呼称もなく、特に後者は、国際規格化で共通の認識が生まれると(今回のフォーラムでも冒頭で複数人が)言っていた気がするので、個人的には拍子抜け。Work packageが無いのには、個人的には疑問に感じた。

今までの会合などで、BS6079(イギリスの標準)の関連だったと思うが「overarching」という考えが何度か出てきた。プロジェクトをより広範囲に捉えようとする考えと受け取った。ISO化の際に、それを盛り込む動きと言われていたが、今回は見送られたようだ。なお、”実行”としてexecuteを避けてinplementにしたのは、executeを「(死刑等)執行」と意味するとして使用を避けたい国が多かったからとのこと。

組織や個人に対する認証に関する記載は無い。なお講演の演題やQ&Aで、認証への取り組みが動き的にはあるようだが、どうも断言はなかった。逆に講演ではISO 9000での弊害のことが暗に出て、認証を行うとしてもISO 9000のような仕組みとは違えるのかも知れない。

今回はPC236として規格化されたが、今後TC258として、プログラムやポートフォリオなどを議論していくらしい。


フォーラムとして、質問に1時間を当ててあったのは良かったと考える。普通なら講演者の説明とか補足で時間取るけど、今回はフルにQ&A。なお、どう適用したらいいかの質問出たけど、(よく話に出る)組織体でテーラリングとか工夫が必要、PMIの商標、著作権の関係でそのまま利用できないの事などが出た。後者は、回答としては分からなくはないし会合ではよく聞く話だったけど、会場ではもう少しアドバイス的な返事があっても良かったかなという気持ちが湧いた。

なお自分として、質問したかったけど、止めた質問は以下。ちなみに最初挙手が少なかったらと質問しようと思ってたら質問がいくつか出てきたためと、何かの会合とかで聞けばいいやくらいの気持ちだったため。

・説明での規格化のメリットとして用語が共有化できるとの事だったけど、今回契約関係の用語は範囲外である。TC268に引き継がれる?

・契約に多少関係するが、日本のITシステム開発で請負契約が多い点は稀有に映ると聞いている。TC236も含めると、日本での商習慣で気にしておくべき事はあるだろうか? あるいは、ISOでは各国の商習慣を包含する考えが多いのか少ないのか。


他でもそうであるケースが多いが、国際規格の類は、結局差し障りのないところに落ち着くように思えた。開発プロセスとかだと、どうしてもそうなるのだろう。ただし、途中経過を含めてウォッチしておくことは必要と感じた。

11月 28, 2012 プロジェクトマネジメント | | コメント (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月23日 (金)

単体テスト/コンポーネントテスト、、、、、

ソフトウェアテストでのテストレベルの用語(の統一)は気になっている事項だ。ISTQB/JSTQBでは、コンポーネントテスト、統合テスト、システムテスト、システム統合テストなどがシラバスなどに記載されている。

ところが、自分の最近目にするソフトウェアテストに関する記事や論文では、単体テストや結合テストが増えてきた気がする。(開発系では、以前からほとんど単体テストや結合テスト。)

ソフトウェアのISO化などもあり、ちょっと気になって調べたり、確認してみた。まずソフトウェアテストのISO化に関しては、以下が公式的だし、まとまっていると思う。

ISO/IEC JTC 1/SC 7/WG 26の概要 http://www.itscj.ipsj.or.jp/tutorials/tu87.html

そこでの(2)に書かれている”テストレベルを特定しない”ことから、テストレベル自体の明示も行われないような気がしてきた。あるいは、他のISO程度しかレベル分けしないと思える。

そうなると、ソフトウェアの開発なりテストのプロセスは、ISO/IEC 12207 (JIS X 0160)を踏襲すると思われる。ISO/IEC 12207では、ソフトウェア詳細設計、ソフトウェア結合、システム結合、ソフトウェア適格性確認テスト、システム適格性確認テストという用語が明言されている。他に”コードの検証”という用語もある。ちなみに、”Integration”を”結合”と訳している旨が明記されている。

そうなると、テストレベルとしては、単体テスト、結合テストが、ますます定着するように思える。

ちなみに、Googleで”単体テスト”等での検索結果件数は以下。”ユニットテスト” が多いのは、xUnitの関連だろう。

 ・”ユニットテスト”     415000件
 ・”単体テスト”       323000件
 ・”コンポーネントテスト”  14800件

JIS X 0160の頃でも、ソフトウェア開発でのプロセス用語が各社各様で統一に役立つとの記述もあったが、結局そう統一されたわけでもない。また、規格では細部を決めたり例示することを避けている感がある。組織体では、効率や品質向上にためにプロセスを細分化した呼称を用いたりするが、ISOなどはそれをフォローしていない事になる。むしろISOやJISは、ソフトウェア開発/テストのキーの部分から、より広範囲を含めたライフサイクルやプロジェクトの規格化が進んでいる気がする。

組織体で細分化したプロセス呼称を用いる場合もあろうが、企業間での統一は考えにくいと割り切った方が良さそうだ。ただし逆に、他社との情報交換の際には、用語の確認をした方が無難だろう。


個人的には、JISの規格内で単体テスト、結合テストを用語として明示して欲しい気もする。(ただし、こちらが単に知らないだけかも。) また、自分としてはコンポーネントテスト/統合テストという言い方に少し慣れていたが、今後は単体テスト/結合テストを用いることが増えると思う。

3月 23, 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年11月 8日 (火)

初期「受け入れテスト」

少し前に、何度か偶然「コンポーネント指向開発」が話題となることがあり、”コンポーネントテスト”と”コンポーネントのテスト”が気になっていた。コンポーネントテストはユニットテストと呼ばれるもので、ソフトウェアモジュールを分離してテストするもの。後者は一般用語にはなっていないが、ここでのイメージは、開発の際の市販を含めた外部のモジュールをテストするものである。

で、ここでの”コンポーネントのテスト”って、一般的な用語では”受け入れテスト”に近い。開発の最初の頃に、テストフェーズでの終盤のテストと同じような事を実施することになる。反面”受け入れテスト”と多少異なるのは、利用する部分のテストでも十分であることや不具合発見が開発全体に影響することが多いことだろう。(開発の中間や終わりに、中心的なモジュールが利用できないと発覚したら、システム設計自体の見直しにもなりかねない。)

ただその観点で、「受け入れテスト」(ただしコンポーネントのテスト)のテスト技法とかの議論を、あまり見かけないように思えてきた。特にテスト効率などの議論。その辺りが気になった。

で、調べてみたら、JSTQB(ISTQB)のFLシラバスでは、2.2.4. 「受け入れテスト」でいくつかのテストを述べている。FL:Foundation Level AL:Advanced Level

・ユーザ受け入れテスト
・運用受け入れテスト
・契約、および規程による受け入れテスト
・アルファ、ベータ(あるいはフィールド)テスト

また、「市販ソフトウェアプロダクト(COTS)は、インストールや統合時点で受け入れテストを実施する。」、「コンポーネントのユーザピリティの受け入れテストは、コンポーネントテストで実施する。」との記載もある。なので、ここで書いた”コンポーネントのテスト”は、受け入れテストと呼んでも良さそうに思う。ただしJSTQB(ISTQB)では、”受け入れテスト”はテストレベルでの1つとしており、テストレベルはテストフェーズの意味でもあるので、用語の概念としてすっきりしない。

ちなみに、JSTQB(ISTQB)のALシラバスの方では、受け入れテスト自体の細部に関してはFLほどには言及していない。

用語をすっきりさせるには、組織体で○○コンポーネント受け入れテストとか○○モジュール受け入れテストと呼んだり、多少一般化するのなら”コンポーネント受け入れテスト”という用語などを使った方が良さそうに個人的には思えた。


なお、懇親会の類では、特に海外製のモジュールに重大バグがあったり窓口対応が悪かったりで、開発スケジュールに大きな影響が出たなどの話は少なくない。そして、同じ社内のモジュールとか装置開発の遅れ起因がある。割合的には後者は少ない気がするが、起きてシステムプロジェクト側が責任を負わされたり犠牲になることも。同じ社内なので、責任追及しにくかったり、元々駄目チームと分かってても利用しないと行けない事情があるのだろう。

ちなみにコンポーネント受け入れテストで話題になるのは、以下辺りが多い。

・テスト効率
・負荷テスト
・非機能要件
・外部を含めたバグ管理
・スタブ作成チーム、テスト作業チーム形成
・テスト環境保存 (自動化でスクリプトを作成したらその保存なども)

最近は外部機器でもネット接続可能なものが増えたり、市販コンポーネントでもサンプルプログラムが付いたものも少なくない。パソコンを利用して、それらの機器やコンポーネントをテストすることは増えている。さらには、GUIやネット系の自動テストツールや画面操作再生ツールなどを利用すると、結構効率良いテスト環境を構築できる。組込みソフトウェア産業実態調査報告書などで自作テストツールの割合が多いが、今後は市販ツールの利用が増えていくと思われる。

用語がすっきりするのは良いことだが、結局この類のテストの重要性を感じているところは以前も含めて実施しており、何らかの呼称を行っているだろう。また、テスト自動化の議論と多少似てて、実施しているところはさらなる効率化を目指していて、一般的な議論は進みにくいようにも思えてきた。


補足:通常の受け入れテストが発注者側が主体であるのに対して、ここでの”コンポーネントのテスト”や”コンポーネント受け入れテスト”は機器やシステムの開発側/受注者側が主体となる。発注者、開発者/受注者の各々の目線でテストのフェーズを考えることが多いので、それも少し違和感が発生するのかもしれない。開発者/受注者目線で考えるなら、テストのフェーズとしては受け入れテストという言葉よりも、出荷テストとかカットオーバーテストの方が良いように思える。

11月 8, 2011 ソフトウェア, ソフトウェアテスト, プロジェクトマネジメント | | コメント (1) | トラックバック (0)

2011年9月16日 (金)

プロジェクトマネジメント学会 2011年度秋季

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

http://www.spm.or.jp/wp/%E4%B8%80%E8%88%AC%E7%A4%BE%E5%9B%A3%E6%B3%95%E4%BA%BA-%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88%E5%AD%A6%E4%BC%9A-2011%E5%B9%B4/

上は、お知らせでのページだけど、大会パンフレットへのリンクなどがある。場所が産業技術大学院大学とのことで、行ったことが無かったのも動機。

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

・昨日は、昼食は見学を兼ねて学食でと思っていたら、学食は食事の提供無しと。昼の暑い中、駅近くのコンビニまで歩いた。学内にコンビニもなかったように思う。学食の食事の提供無しは、事前案内が欲しかった。

・初日の開会挨拶などを含めて、マイクの調子が今ひとつ。事前確認不十分だった? キーノートの最初の頃に復旧してほっとした。

・〔キーノート1〕の旭山動物園の前園長小菅氏の講演は、面白かった。チーム形成で参考になる部分が随所に。特に、来場者への説明を飼育係などで行う際の、苦手なメンバーへの対応。苦手のメンバー「人付き合いが苦手で、飼育係になったのに~」。 でも結局自発的に説明を行うようになった。

・〔パネルディスカッション〕はPM標準の国際対応など。パネリストの忌憚ない意見もあったが、発言の一部に垣間見られる程度で各パネリストの背景などが分かってないと理解しにくかったかも。また、パネリスト間の意見の相違があまり深掘りされず、オーソドックスな結論に導くのが早すぎた気もする。

・実習教室(昔のLL教室みたいな感じ)でのセッションもあり、席の前のディスプレイをOnにするとプレゼン内容が表示されるようになっていた。ただし、初日の最初の頃は、その説明がなかったような気がする。

・学会への参加が多いわけじゃないけど、理論的な話やプロジェクト完遂の話よりも、品質改善とか効率改善の話が多かった/増えたように感じた。プロジェクト完遂の場合でも、その過程での創意工夫の話が多かった気がする。QC活動の発表のようなイメージ。

・上記とも関係するが、その発表の際に発表者の会社のメンバーと思われる人が少なくなかった。社内発表に近いようなイメージも。

・ちなみに、日本IBMでは「ITLMC(IBM Technical Leadership Master Course)」の活動、富士通では「PM事例研修会」からの発表が少なくないように感じた。ITLMCは、〔2411〕で他のコミュニティ活動も含めて述べられている。〔2210〕が事例として、〔2408〕はITLMCメンバーの助言との発表があった。PM事例研修会の方は、〔2212〕で事例発表。ただし、どちらも他の発表も関連しているのかもしれない。

・今年気になった発表は、大学PBLでのユースケース作成での分析〔1205〕。ユースケース総数が要件定義時と下流修正工程時で相当違うグループがあったとのこと。そもそもユーザとの確認を行えばユースケース数レベルで大きく違うことがないはずなのにと思って後で訊いたら、ユーザとの確認を行わなかった(ユーザがユースケースを理解できなかった)と。なんかユースケース表現の根本を勘違いしてるように思ったんだけど、こちらがおかしい?

一昨年だったかも、ちょっと気になる発表があった。そちらは企業で実プロジェクトだったので、社内でのチェック機構なりアドバイスのようなメカニズムが必要なのかと感じた次第だ。

それにしてもIT系の発表は、プロジェクトマネジメントの世界なのかソフトウェア工学の世界なのか微妙に感じる時もある。逆に、情報理論めいた発表もあって、むしろ情報処理学会のような場が良いのかなと思うこともあった。まっ、これはしばらく続くんだろうなと思う。

・NTTデータは、CMMレベル5絡み〔2111〕やアジャイル〔1405〕関連の発表もあり、大きな組織(企業)での取り組みとして参考になった。

ちなみに、NTTデータって、いくつかの標準プロセスがある(と思っている)ので、それらとの関係も気になった。フォーラムとかで少し気にしておこうと思うし、情報交換会の類で聞けたら聞いてみようと思う。

・Q&Aで古参と思われる人からの質問があった。プロジェクトマネジメント関係では、なぜか時々遭遇する気がする。今回は、同じ人の質問を2,3度も目にした。なんかその人の質問は、ピント外れというか多少自分の昔のことの自慢話臭がチラホラ。しかも、時間が長い。

で、標準化や知識体系化に関連して、プロダクトラインという言葉がその人から出た。某社での製品化に携わっておりプロダクトラインの視点が必要と。日本の得意分野だとも。

ただ、ふと日本の得意分野として体系化するメリットがあるのかと思えた。各社が創意工夫していることで体系化しにくいということと、体系化することで模倣されるという危惧も。その意味では、日本はプロジェクト管理でも”摺り合わせ”で来ているのかもしれない。ふとそんなことを考えた。


両日とも帰り道は青物横丁へ徒歩で。30年近く前に降りたことがあるはずと少し散策したら、降りたのは品川寺へのためだったと判明した。寺内に少し見覚えがあり、当時のことなど少し時を感じた。

9月 16, 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年8月 1日 (月)

イテレーションとトヨタカレンダー

先だっての講習で、イテレーションを全世界共通にして、(各国間の相違を含め)祝日によるベロシティ差異を吸収するにはトヨタカレンダー(方式)が良いよな~と漠然と考えてた。

で、今朝、トヨタの採用情報を確認。

http://toyota-saiyo.com/tech/i_recruit/index.html

「完全週休2日制(土・日)、GW・夏期・年末年始休暇」の文字。つまり休みに祝日がない。

もちろん冒頭で年間休日数を書いてあるし、トヨタ/トヨタグループに就職しようとしたら、ある程度トヨタカレンダーを知ってて混乱は無いのだろう。

ちなみに、似たような会社がないのか「”完全週休2日制(土・日)” -祝日」で検索したけど、”祝祭日”とか”国民の休日”とかの表記もあって、自動的に見つけるのは困難。でも、エンジニアリング会社で採用している会社もあったりした。

また、日産は以下の表記。(祝日が休みというわけじゃないようで、変則的ということか。)

http://recruit.nissan-careers.com/info/index.html

「週休2日制(※当社カレンダーによる、月5~8日)年間121日」


これから、ちょっと気にしておくつもり。

8月 1, 2011 ソフトウェア, プロジェクトマネジメント, 自動車 | | コメント (0) | トラックバック (0)

2011年7月29日 (金)

プロダクトオーナー研修

昨日と今日は、認定スクラムプロダクトオーナー(CSPO)の研修。場所は秋葉原、講師はVernon Stinebaker氏など。ちなみに「プロダクトオーナー」は、ソフトウェア開発手法”スクラム”での役割の一つで、ソフトウェアプロダクトの総責任者。ユーザ要求の管理やビジネス視点での責任を担う。

研修内容細部についてはここでは余り触れないが、勉強になることが多かった。ある程度知っていることでも研修の実作業で気づきも発生したし、研修中のQ&Aや研修後の懇親会で深掘りできた。ちなみに、開催社による”プランニングポーカー”を入手。

4つほど、思いついたことを記載しておく。

・即席チームのファシリテーション

今回の研修では、スクラムを相当実践している人から、ほとんど知らない人まで知識レベルが様々。グループ間のレベル差をなくすために、各グループに色んなレベルの人が混在する編成となった。

講師の問いかけやグループ活動で、スクラムマスターの人達が他のメンバーの発言を促そうとの意図から、発言を控えることが時々あった/あるように感じた。初日の懇親会で少し話題にしたら、余り気にすることなく発言すべきとの意見が。

即席のチーム、しかもレベルの差が大きなチームのファシリテーションの難しさを痛感。あまり知らないメンバーからでも発言があれば、そこからアイデアなどが発展することも少なくないのだが、、、。もしくは、ある程度グループ間競争やその意識を、ゲームなどの格好で取り入れた方が良いのかも知れない。

・実務に近い演習

今回の演習(ゲーム)では、実際のソフトウェア開発を想定してのプロジェクト。タスクカード作成やスプリント見積りもりをチームで行った。タスクカードに対する考え方がメンバー間で大きく異なったのには、ちょっと驚いた。独り言のように、タスクカードに書く内容をつぶやきながら作業すれば、(即席チームのせいもあるけど)ブレは少なくなったかのかもとか考えさせられる点も。

また、見積りはプランニングポーカーで行ったが、時々見積りに大きなばらつきが。チーム内で大きくばらついた理由の多くは、実装方法に依存した。実装に関する基本的な事項を、チームで述べ合うのも悪くない(むしろ良いこと)と感じた。

いずれにしろ普段スクラムを実践している人にとっても、意外な考え方などに遭遇して、ためになったと思う。

・”スクラム”のプレゼン資料が7人制ラグビー

たいしたことでもないかも知れないけど、、、。一般的に、スクラムでのチームサイズは、7プラスマイナス2人程度が良いとされている。もちろんスクラム・オブ・スクラムにより、チームを階層的にしたりして大人数でのスクラムの実践もある。また逆に、3,4人での小さなスクラムチームでの事例の話も少なくない。

ただ7人という人数に拘れば、15人制ラグビーはスクラムだけでも8人であり、少し人数が多い。またスクラム(のみ)の写真では、チームとして得点を獲得するとのイメージとは少し離れてしまう。7人制ラグビーでのスクラムだと、人数少ないし、他のメンバーを含めた7人で得点を重ねるとのイメージが生まれやすい。

講習の際に、そんなこと思いながら、「7人制ラグビーですね」とか言おうか考えたけど、話題はどんどん先に進んでしまった。^.^; 意図しての写真だったか、Q&Aでも聞いても良かったけど、、、、。まっ、頭の隅に入れておき、講習スライドなどを目にすることあったら話題にするかも。 (ちなみに、個人的にはゲームとしての7人制ラグビーは面白味が今ひとつと思えてる。人数の件よりも、15人制と同じフィールドの大きさのためかな。なお、7人制ラグビーは、2016年のリオデジャネイロオリンピックの正式種目で、女子ラグビーはオリンピック初登場。)

・PDU付与

今回の研修は、PDU(Professional Development Unit)が付与されるとなってた。PDUは、プロジェクトマネジメント資格PMPの受験や資格維持のために、必要な単位が決まっている。申込みの際の案内でも判ったのかも知れないが、気がついたのは研修の前日。ある意味個人的にはラッキーだったし、PMIの本部がアジャイル関係資格へ動いていたり、そもそも以前からアジャイルへの取り組みが活発なためだろう。


2日間の研修中のQ&Aで、プロダクトオーナーがスプリントの最初でバックログをレディにする率なども話に出て、考えさせられた。(正確には、レディにしているスクラムチームの割合。) 他にタスクカードの粒度に関しても、工夫の事例の話も出て参考になった。有益な2日間だった。

7月 29, 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年6月21日 (火)

プロジェクト管理ソフト (Webサービス) Gantter

今日見つけたのが、プロジェクト管理のソフトというかWebサービス。無料。Gantter。

https://app.gantter.com/

先行タスクの指定とか達成率の入力などが可能。MS Project形式でのやりとりも可能。テスト的に作ってみたのが以下。

Gantterテストした限りでは、日本語もOK。

iPadでもそれっぽく動いたけど、実際の作成や閲覧は実用的では無さそう。なお、画像ファイルへのエキスポートは可能で、機能的には多少不満もあるがiPadで見ることも可能ではある。

自分の場合は、Googleアカウントを利用してプロジェクトのファイルの作成などを行った。ファイルの保存も(主として)Googleドキュメント経由とした。

以前ここのブログで、Googleドキュメントでガントチャートを作成してみたけど、その方法よりも楽。
http://blog-honda.cocolog-nifty.com/gijyutuya_nikki/2009/11/google-6169.html


複数PCでの簡単なスケジュールの作成や検討の作業で、しばらく使ってみるつもり。


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

2011年5月11日 (水)

成熟度と競争優位性

Maturity Model での「成熟」って何だろうって考えることがある。”成熟”という言葉そのものには成長のようなイメージがあって前向きだけど、”熟女”とか”熟年”とかなると、少し陰りのあるようなイメージも付きまとう。

個人的に、CMMが弊害が多い(多かった)との印象があるせいか、成熟度は高ければ高いほど良いというわけでもないだろうにと思えてしまう。ちなみに、CMMでの印象が良くないのは、レベル2認定のため”だけ”に構成管理などを一生懸命やる話を聞いたりしているためだ。レビューなどのレベル3などの話には目もくれない。相手先の条件などのための認定取得ではなく、自組織のプロセス改善のために改善。スタッフが盲目的に指導して、現場とかは混乱するケース。端的には、構成管理のツール(のみの)導入や厳格な運用をしようとして、現場はうんざりといった感じ。(しかも予算の関係もあるだろうけど、継続的な改善として次のレベルを目指すとかCMMI認定を意識することがないようだ。)


で、最近ちょっと目にしたのが、ジェイ・B・バーニーの「競争優位の構築と持続」。

持続的競争優位性として、”自社の持つ経営資源は真似されにくいかどうか?”を挙げている。

また、画家の猪熊弦一郎が、尊敬していた師匠アンリ・マティスから「お前の絵は。うますぎる。」と言われてから自分の作風を確立していった逸話も目にした

スポーツ選手やチームが、その特徴を「弱点であり強み」と表現することがあるように、自分やそのチーム自身の特徴が強みであると同時に弱点になることがある。ただし、弱点部分を急に直そうとすると、バランスが非常に悪くなってしまう事が多い。

ある程度の成熟度のために自組織の成熟度を上げることは大事であるが、成熟度向上だけに固守するのもおかしな話である。また、参考とするその指標自体も数年もすれば改訂される。むしろ組織体の目標を明確にすることや継続的な改善をどうするかを検討すべきと言える。(スポーツの世界では、記録やリーグ優勝などの方が目標であり、打率などを成熟度での指標の1つと考えれば分かりやすいだろうか。)。

なお、昨今は企業経営が多岐にわたり、しかもダイナミックになってきた。1つの製品のみを扱うケースは皆無で、複数の事業を抱え、多くのグループ会社をもつ企業が多い。しかも、100%子会社ばかりではなく、資本支配や提携といった形態も少なくない。M&Aをはじめとして、全くの他企業を傘下に収めることも良く行われている。オーナー企業の方が、革新的な商品やサービスを提供しているケースが少なくない。

それらを考えれば、親企業などの特定企業や特定部署の開発プロセスとか管理方法を100%真似るような目標を持たせること自体が、非現実的である。一般的に言われている成熟度での、統一的な把握や制御は、困難とさえ思える。


とある会合で、成熟と”成長”とは相反するのじゃないかとの意見が出て、「なるほど!」と思った。成長を意識しつつ、成熟度の視点と継続的改善の視点の、両方を持つべきだろう。

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

2011年5月 8日 (日)

ISO/IEC 6592 (JIS X 0126)も悪くないかも

ISO/IEC 6592(JIS X 0126)は、「応用システムの文書化要領」と題され、ITシステムでの文書のひな形と言える。実は最近目にして、「悪くないな~」との印象。

正確にはJISは2001年に改訂され、そちらが好印象。従来いくつかの文書で構成されているものを、1つの文書(ただしサブ文書より構成される)の表記に変えている。JISの改訂そのものはISOの改訂によるが、そもそも日本は従来のいくつかの文書での構成としたかったらしい。(JIS X 0126の”解説”に詳しい。)

個人的には、設計ドキュメントは少ない方がよいとか少なくすべきとの考えだし、全体把握の文書があるべきとの考えなので、今回の改訂版の方が馴染みやすい。逆に、規格改定などをウォッチしておけば、早めに気がついたのにと少し反省。(以前の版だと、文書種の列挙で閉口したのだと思う。)

1 システム要求
 11 問題の定義
 12 目的
 :
2 システム記述
 21 システムの識別
  211 システム名称

のように書かれている。人的資源や費用/項目、長所/弱点といった項目もある。

個人的には、この規格をもとに、組織体で必要とされる項目を追加したり、対象物によっては未記載にする(削除する項目)などを検討しても良いだろう。また、この規格を文書一覧と考えて各文書を用意するよりも、ここでの項目をなるべく1つの文書にする方が良いと考える。

組込みでもそうだが、1つの製品なりシステムの文書化は、章立てをどうするかとか記載分担をどうするかが悩みの種。組込みでは、特に新規開発とか新分野の開発の場合が顕著である。文書の数を多くして、極端にはエクセルでの断片的な仕様表だらけとか、(やれエクセルが好きとかTexが好きとかで)多くのフォーマットでの文書の乱立ということもあるようだ。文書が増えればメンテナンスが大変だし、そもそも協業での変更管理やCO/CIに関連する弊害も発生する。

まっ、一見をお勧め。

5月 8, 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年2月15日 (火)

「戦艦大和誕生」

プロジェクトマネジメントの勉強のつもりで、特に日本での歴史物を読むことがあるけど、これもそんな観点で読んだ本。ネットの情報で、戦艦大和は同じ設計図での別の戦艦に対して、半分の工数や工期で建造したとのことをひょんな事で目にしたためだ。

http://itpro.nikkeibp.co.jp/article/Watcher/20070817/279845/

元々戦艦”大和”には興味もあって、呉の大和ミュージアムなどにも行ったりした。一般の人、特にエンジニアだと、零戦と大和には大なり小なり興味があるのではないだろうか。ただし、零戦の方は設計技師堀越二郎の名前は有名で本もいくつか出ているが、大和の設計や製造となると一般的には広まっていないように思う。

(文庫)本2冊のちょっとしたボリュームということもあって、駆け足で読んだ格好になった。

著者は、元エンジニア。その視点での記述が多く、造船や溶接に関しては、詳しく書かれている部分が少なくない。他にもいくつかの著書があるようだ。

2冊それぞれに副題があり、上巻は”西島技術大佐の未公開記録”、下巻は”「生産大国日本」の源流”。実は、戦艦大和の建造までの話し自体は、下巻の1/5位まで。その後は、製造での中心人物である西島(技術大佐)が商船などの建造に関与するため、その話題が多くなる。駆け足読破だったこともあり、下巻のその後は、最初少し拍子抜けした。

しかし読み進めるうちに、西島のドラマが、現代での各自のプロジェクト経験とか企業内での複数プロジェクトと似ていたり参考になる部分が多いと感じてきた。その意味で、この本では戦艦大和の建造やその関連を通じて、多くのことを学べると言える。


なお、戦艦大和、およびその類型の建造に関しては、以下などが参考になると思われる。いわば”A-140”が、類型も含めた戦艦のコードネームで、派生的に4つ建造したことになる。戦艦大和は海軍での建造で、冒頭で対比的に述べられる武蔵は三菱長崎造船所による。また、空母に改装されたものもある。

http://military.sakura.ne.jp/navy/b_yamato.htm

またここでは西島の作業を建造との表現を用いるが、現代やソフトウェア設計だと、(詳細)設計~生産までを手がけたとのイメージが良いと思う。


そもそもこの本では、戦艦大和建造までに、西島などの失敗事例や試みなども書かれている。特に溶接技術に関してはページが割かれている。

戦艦大和建造の当初の予定は、以下だった。(上P350)

 昭和12年(1937年)11月4日 起工
 昭和15年(1940年)8月上旬 進水
 昭和17年(1942年)6月15日 引き渡し

しかし実際の引き渡しは、1941年12月16日。半年も”前倒し”される。むしろ、”前倒し”を達成したと表現すべきかもしれない。

海軍といえども、予算があるから切り詰めろの指示が来る。性能として頑丈にしろという点と、航海性能を上げろという相矛盾する要求が突きつけられる。頑丈にすれば重くなり、速力は落ちる。また要求事項に関しては、頑なに変更を拒む、、、、。

軍縮の関係で、戦艦建造のノウハウはほとんど無い状態。ドック(の拡張工事)や工具から検討が必要だった。囚人までをも利用したという。さらには機密性のために、全体や他ブロックが分かりにくい図面での作業。砲塔部分の図面では寸法すらなかったそうだ。(上P379) ちなみに、拡張して工事したドッグは、各側2メートルの余裕しかなかった。対応として、実寸大の木の模型を作ることで、内装等の確認や実組み立てを効率よく行ったとのこと。実寸大といっても、全長は250m超。 また、特許に関する意識の件も触れてあった。

そのようなことを考えると、現代でのプロジェクトマネージャーの抱える課題と似通っている。その意味で参考になるし、親しみすら沸いてくる。

なお、人数を増やせないことが工員数一定となり、管理しやすくなった側面もあったと。(上P417) この辺りも現代に通じる。つまり、人月などでの見積もりして進捗管理するが、土壇場ではそう人を急激には増やせない。あるいは、増やしたことでかえって弊害を引き起こす場合がある。

戦艦大和は46センチ砲が有名であるが、砲塔を進水後に搭載している。(上P351) 船体がドックの底についてしまう可能性があったためと書かれているが、半分ほど合点がいかなかった。ドックの工事状況や工事結果により砲塔搭載をリスケジュールしたのではないだろうか。進水後に砲塔搭載するためには、雨が入らないようにするとか周りの装備の作業が通常と大きく異なってしまう。それらを含めて手順を考え直したのだろう。なお、46センチ砲が目に触れること(46センチ砲を想像できること)を避けたのも理由だったのかもしれない。

鋲打ちに対する二重底検査の逸話も面白い。(上P422) 鋲打ちの検査を徹底的行って、その後の残作業を減らしたというもの。 ソフトウェアでのテストファーストなどにも相通じる。

第二次世界大戦の状況により、計画に対して前倒しとなる。引き渡しを、2ヶ月半繰り上げて3月末とすることになる。(下P82)  実際最終的には、さらに前倒しになるが、この辺りも現代と似ている。そもそも完成予定を変更することは良くある。機能追加で実質延びることもあるだろう。まっ、古今東西似たようなものとの認識と、段階的詳細化やそれに伴う予測精度向上は念頭に置いておくべきだろう。

戦艦武蔵との工数などの対比は、下P94辺りに詳しい。武蔵の建造の見積金額にもそれが現れ、(いわば発注側としての)西島と、三菱との関係がギクシャクしたらしい。 ただふと思うに、当初から戦艦大和建造に三菱メンバーを参画させたり、製造に関するノウハウ等の伝授も行ったら違っただろうにとも思った。個人的には、派生機種開発とかサービス移行などとも相通じそうに感じたが、どうだろう。


戦艦大和の進水式の後、1940年10月、西島は艦政本部に転任する。そこでは、(勘違いかもしれないが)ざっくばらんに言って民間向けの商船の建造にタッチする。本来(元々は)逓信省の役目を引き継ぐ格好。ただし逓信省側からすると、ぶんどられた格好。軍事物資の運搬能力アップが急務だったためだ。(本では、海軍 vs. 逓信省のわだかまりにも触れている。)

第二次世界大戦では、アメリカの攻撃で一般船の沈没などがあったが、当時はそれがアメリカにとって有効に働いた。逆に日本は武士道のような意固地さで、商船攻撃に踏み出せず。また、そもそも商船の生産能力に大きな隔たりがあった。(商船攻撃の逸話が下P319にある。)

その生産能力向上に、西島は駆り出されることになる。工場の建設や生産方式の改良、車のエンジンの利用、X線を利用した検査など、、、、、。ただ、歴史を知っている我々の視点では、回天などの特攻兵器、そして原爆の話題にまで及ぶにつれ、もの悲しさも感じてしまう。

そんな中で、個人的に気に入った逸話(下P285)を紹介しておく。西島が民間の浦賀船渠(うらがせんきょ)へ増産依頼をし、その際に浦賀側として問答したのは狩野忠男。勉強会などを通じて知っており、会議の際に西島の同級生を含めた他の重役連中を差し置いての問答を行った。そして、材料を西島が確保し、工場の開設にこぎつける。工場の船の建造では、大津高等女学校から100名ほどが来て、うち20名ほどが狩野のもとで現場作業を行った。他の所では事務作業をさせたので、(監督官から)文句が来た。移動させようとしたら、彼女らの方が泣きながら反対したため現場に戻ることになった。そして、終戦後42年ぶりに狩野と再会。


当初”戦艦大和プロジェクト”を知ってみようみたいな観点だったけど、派生開発とかプログラム管理そして人員確保なども含めて現代に通じることが多くて、非常に参考になった。”西島亮二”とか”西島カーブ”とかで検索すれば、トヨタ生産方式との関連や対比などに言及しているページもある。個人的には、リーン開発の観点で、西島生産方式について眺めてみるのも悪くないと思った。

2月 15, 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月24日 (月)

紅白歌合戦プロジェクトの振り返り

昨年暮れのNHK「紅白歌合戦」関連で、個人的に面白かったのが、Twitterでのつぶやき。アカウントは、 nhk_kouhaku 。以下で、少し過去のも読める。当日の様子もそうだったけど、プロジェクト進行の様子を知る上でも参考になった。

http://twilog.org/nhk_kouhaku

今日24日のつぶやきは、ディレクターさんたちでの反省会。プロジェクト終了後、1月後の”振り返り”というわけだ。

で、ウィキペディアにも2010年の紅白歌合戦の項目があって、以下。

http://ja.wikipedia.org/wiki/%E7%AC%AC61%E5%9B%9ENHK%E7%B4%85%E7%99%BD%E6%AD%8C%E5%90%88%E6%88%A6

歌手・グループは紅白22組ずつの計44組。225分番組。10月14日 に放送日時とテーマを発表して、本放送は12月31日。個人的に、仮想プロジェクトと考えて、どんなスケジュールでどんなタスクがありそうかを考えてみるのは良い思考実験になるかな~と思えた。

ウィキペディアでの項目にも色んな事があるし、Twitterでのつぶやきでは他の番組での取り上げとか、データ放送やワンセグのことも時々書かれていた。紅白歌合戦プロジェクトマネジメントなり、紅白歌合戦プログラムマネジメントを意識してしまった。しかもふと思うに、管理的な側面よりも、色んなサブプロジェクトとの協調といったイメージの方が良さそう。(本件は、結構身近なプロジェクトでもそうなんだけど、その辺りはいつか、、、。)


ちなみに、つぶやきで面白く感じたのが以下。 (もうTwilogそのものには無い。)

12月10日のつぶやき:紅白の新人スタッフによるリレー連載「はじめての紅白」がブログでスタート。

12月27日のつぶやき:紅白の台本が印刷所からあがってきました。全449ページ! 厚さおよそ2.5cm


10日の方は、新人スタッフの立場では、ちょっと想定外の作業だったかと思う。身近なプロジェクトとかなら、不平にも結びつきそうとか、新人スタッフさんも大変だな~と感じた。逆に、乗り気な人もいたかもしれない。

27日の件は、29日からリハーサルだったので、28日の1日でスタッフで読み合わせとかやったんだと思う。大なり小なり間違いも見つかるだろうから、その修正とかその情報徹底も必要だったろう。 (ちなみに、225分/449ページなので、一般的なドラマそして歌番組などよりも、結構濃厚な台本なのではないだろうか。専門じゃないけど。)

ボリューム的にはちょっとした製品の仕様書程度にも思えるので、(精度とかも関連するだろうけど)1日とかでレビューする世界も、少し頭の隅に入れてても良いかと思った次第だ。超俊敏。いずれにしろ、良い思考実験になった。

1月 24, 2011 プロジェクトマネジメント | | コメント (0) | トラックバック (0)

2011年1月20日 (木)

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

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

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

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

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


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

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

2011年1月14日 (金)

NHKアニメ「もしドラ」 3月放送

NHKで「もしドラ」(「もし高校野球の女子マネージャーがドラッカーの『マネジメント』を読んだら」)のアニメ版を放送するというのは知ってたけど、声優さんのスペシャルトークがYouTubeにアップされてた。

また、既にサイトもあって、以下。

http://www9.nhk.or.jp/anime/moshidora/

放送は、3/14~25日の、月~金。ホワイトデーの日からということ。NHK総合(NHK G)、時間は22:55から。

この歳になってアニメ注視ということもないだろうけど、そうは言っても多分少なくとも録画設定は行うだろうと思う。

1月 14, 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年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年10月12日 (火)

フロー、フローチャートに、start/endを

フローを元に、やり取りしていたら、どうも勘違いが判明。こちらは、状態としてAもしくはBと思ってたら、相手は状態無し(Null状態)もあるし、AかつBもあると。勘違いの発生は、早い話、フローにちゃんとend(終了)が書かれてなかったから。条件分岐の後が、終了なのかはっきりしていなかった次第。

考えたら、フローチャートで、start(開始)/end(終了)を書いてないケースが少なくない。プログラミングじゃないとのことで、業務フローとして表記ルールが曖昧なケースが横行すらしている。ちなみに、業務フローにもいくつか表記例があり、以下のNOMA方式だと、▽が終了。

http://www.internalcontrol-navi.com/impruve/flow_chart/mark.html

これが、業務プロセス開発なら、大問題。AもしくはBと、AかつBがあるのは、GUIから内部のデータ構造からが大きく違う。フローやフローチャートに、end(終了)とかがあるかをチェックするだけでもメリットが大きいかなと思った次第。

開発時は、さすがにチェックするとは思うけど、、、。また、昨今はフローやフローチャートは流行らないかもしれない。しかし、それと同等のロジック面を確認する図示種などは明確にすべきだろう。

10月 12, 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月31日 (木)

2009年雑記

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

・「システムLSI設計のためのリユース・メソドロジ・マニュアル」

半導体に関しては直接関係しないけど、基本的に知っておくべき事もあって、ぽつりぽつり本とかを読んでる。(頭に入り込んでないけど。)

この本は、システムLSIでの再利用に関するガイドラインの本。規格的なものでなくて、業界的にこの本をベースにしているところが多いらしくて読んだ。半導体での、IP(Intellectual Property)に関する本と考えて良いだろう。

ハードウェアよりも、半導体記述ソフトウェアの再利用に関する記載がほとんど。テスト/テストベンチとかプロジェクト管理にも言及してる。

純粋なソフトウェア再利用の本もあるけど、この本の方が全般的に書かれていると感じてしまうし、タイミングのような微妙な部分は”組込みソフトウェア”の再利用検討でも参考になるような気がしている。


・「UMLは手段」

新書版。

とかく設計などのプロジェクトで、手段を目的にはき違えているケースを散見する。設計向けやプロジェクト管理のツールを導入することが目的になってて、製品化などに(極端には)無頓着。

この本は、そんな勘違いを指摘している。またUMLそのものに関してもポイントを押さえて書いてあるので、UMLの全体的な把握のためにも有用と考える。


・「日本絶賛語録」

来日外国人の日本に関する記載を集めたもの。111個。本のタイトルが示すように、日本を絶賛したもの。時代的には、江戸~明治。

懐かしさを覚える事項もあるけど、同じ日本人のことなのにむずむずするくらい気恥ずかしい事項もある。

勤勉さとか高い教育水準。当時に戻ろうとは言わないけど、グローバル化という言葉と一緒に日本の強みを忘れてしまうのもおかしな事。この本読むと、「日本の強みって○○かな~」と思い起こせるだろう。

なお、今まで余り感じなかったけど、この本に記載されている人で、幕末での”攘夷”のもとに殺害された人もいる。逆に下関砲撃などを主張した人も。 幕末と来日外国人を考える意味でも、参考になるかもしれない。


・「劔岳 点の記」(Blu-ray) 

今月発売だったけど、宿題とかのために購入を延ばしていたもの。宿題も一段落したし冬休みになったので、購入。

あらすじは、明治時代の日本での測量で残っていた剣岳へ登頂するというもの。陸軍と山岳会が先を争ったり、案内人(ガイド)探しやその案内人との駆け引きがあって面白い。そして、剣岳そのものの風景が素晴らしい。(ただ個人的には、冬以外の春とか夏などの風景も、もう少しあったら良かったのにとは思ったけど。)

今回はBlu-rayの方を購入したけど、メイキング映像とか映画外の剣岳の風景があって、感激した。木村監督の、撮影じゃなくて修行に行ったという表現もうなずける。

ちなみに、この映画でガイドの宇治長次郎を演じたのが、香川照之さん。TVの「坂の上の雲」や大河ドラマ「龍馬伝」予告を通じて、TV画面上で何度も見ることになってる。しかも、それぞれの演技がうまい。この映画では、最初の方での”歩き方”が妙に気にいった。腰の下の方に手を添えて、すっすっと歩く。 ちなみに調べたら、宇治長次郎は登山道の「長次郎谷」として名を残してる。

プロジェクト管理の視点での映画としては、「八甲田山」と同じように参考になるように思う。明治39年秋に命令が下り、1年くらいで達成。遂行のために、経験者(学識者)に聞いたり協力者の手当てに奔走する。また悲しいかな(あるいは現代でも少なくない?)、命令する方は地図のためじゃなくてメンツに拘る。


・お台場 ガンダム

今年印象的だったのは、お台場の等身大のガンダム。実際に見に行ったのは、2回。

また、CS放送での「立ち上がれ!ガンダム」って、結構面白かった。

プロジェクトマネジメントと考えると、内部では色んなトラブルなり、衝突なども起きていたとのこと。衝突と言うほどでもないだろうが、当初のコンセプト上の皆さんの意見対立とか、ある程度固まってからの富野総監督からの要望(というか仕様変更)に対する折衝とかは生々しかった。個人的には、実物よりも、そのCS放送番組の方がプロジェクトマネジメントの良い教材になると感じたほど。

また、建築物なので、建築許可の申請とか掲示なども行ってる。当然だけど、倒れないような設計とか計算、そしてコンクリートでの強固な土台。等身大ガンダムの肩の所などには、風力計とか避雷針。

さらに言えば、多分コストの関係だろうけど、海外(タイだったはず)でのパーツ製造とかを行ってるシーンが出た。その際のペンキの色の管理や、輸送などでのひずみの件も面白かった。特に後者は、最終的な製造現場で削ったりするシーンもあって驚くと共に、身近で見聞きするプロジェクトと大同小異で親しみを覚えた位。 また、タイで漫画ガンダムそのものを知ってる人が少なくなかったのもちょっと印象的。 (タイでのシーンでは、短い間だったけど、1,2人のぼかしの人がいて、妙に気になった。)

実は、CS番組を見て、自分なりにプロジェクトでのチャートを書いてみようかと思った。しかし断念。CS番組からスポット的は話は理解できたけど、各分野を時系列的に記載するのって実質無理。他の題材を探してみるつもり。ただし見つけるのにちょっと時間はかかりそうだし、皆が知ってるかとか情報が多い方が良いので、頭の隅に入れておく程度になりそう。


来年もいい年でありますように、、、、、。

12月 31, 2009 ソフトウェア, プロジェクトマネジメント, 日記・コラム・つぶやき, 映画・テレビ, 書籍・雑誌 | | コメント (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年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月26日 (土)

ほんまかいな。「工事進行基準”廃止”の波紋」

もうすぐ次号が出る日なんだけど、日経コンピュータの9月16日号での記載。

表紙の大きな表題が”マニフェスト”だったので余り読んでなくて、今日ぱらぱらと。そしたら表紙の右上の方にタイトルでの文字列。ニュースの欄。ちなみに、ニュースの欄での見出しは「工事進行基準、廃止の可能性」

IFRS(国際会計基準)の策定の過程で、厳密な運用が良いので見直すべきとの意見があったというもの。

日本でのIT系での工事進行基準は今年4月からの運用が開始したばかりだし、移行しつつあるところも多いと思う。本や講演なども多い。

それがひっくり返るとしたら、大変。というか、工事進行基準自体が良くないという話になるのが、理解に苦しむ。大幅が良いか分からないけど、少し厳密な運用に移行すれば良いだけと思うんだけど。プロジェクトの成功と失敗の確率を考えると、工事進行基準にしていた方が早期に発見できたり会計ベースの手当ができるはず。

あて推量だけど、なんか日本が一生懸命やってるのを見て、はしごを外してみたくなったのか??? また個人的には、ITシステムの構築を一挙に行うよりも、部分部分の完成で進める方がお互いメリット大だし、昨今の開発手法とも合致するはず。また、「じゃ、建築や土木でも工事進行基準を無しにするのか?」と考えてしまう。 

おいらがどっか勘違いしてる?

9月 26, 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月16日 (日)

「火天の城」ネタ インターンの人の”お茶サーバー”のブログ

映画「火天の城」は、こっちで紹介したけど、そちらのブログにちょっと面白いネタが書いてあった。

http://katen.blog.eonet.jp/making/2009/08/9-d2bf.html

映画の制作部の人が、”お茶サーバー”のお茶が無くなっていることに気がつく。そこから、熱中症とか、雑務だろうけど仕事の重要性を感じるというもの。

それだけなら、ここで紹介するような話題でもないけど、最後に「インターンの私の」とある。ある意味学生の頃にOJT、しかも貴重なエッセンスでのOJTを受けたことになる。

最近ちょっと思うのは、PBL(プロジェクト型学習) とかを含めてプロジェクト管理なりプロジェクト遂行の教育やるけど、身についてない人も少なくない。若い子が応用が効かないというのはよく言われるけど、そればかりじゃ無さそう。知識は脳に入るんだけど、筋肉とか血になってないというか、、、、。学習結果の○×テストには躍起になりそこそこの点数を取る(取ろうとする)けど、基本を理解したかは疑問。

やっぱ、実体験する学習の方が良いのかな~。プロジェクト管理やソフトだと、LEGOとかロボット共同作成の類。教育カリキュラムだと、そのための時間確保がネックなのがつらい。ただし、(一部だろうけど)そもそも教育部署に丸投げする感覚が問題だと思うけど。

8月 16, 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年7月 2日 (木)

PMBOK 第4版 日本語版 出荷予定遅れ

Amazonに予約していたら、出荷遅れそうとのこと。1月くらい。

実は、来週と再来週に講師役の作業が。その際に、第4版を示せればラッキーと思っていた。1996版と一緒に提示するつもりだった。その意味で、ちょっと残念。

(急いで第4版そのものを入手したいわけじゃないので、本を待つつもり。)

7月 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月26日 (火)

チーフエンジニア トヨタもだけどホンダにも?

今日、ネットマガジン経由でさらっと読んだのは、毎日jpの”トヨタ:新型プリウス 「HVのトヨタ」盤石に--大塚明彦チーフエンジニア”。今も「チーフエンジニア」と呼ぶんだと、ふと思った。

というのも、昨年から今年にかけて読んだ本で、結構参考になったのが、「マルチプロジェクト戦略」。細部は、また後日ブログに書くけど、マルチプロジェクト=プログラム管理に書いて述べたもの。自動車メーカーのトヨタの組織変遷についても、詳しく述べている。

今回、少し読み直したけど、同じ自動車のホンダにも「チーフエンジニア」の肩書きがあった。終わりの方のインタビューワー一覧。

調べたら、ホームページで「自動車工場の概要(開発主査(チーフエンジニア))」というページも見つかった。結構、詳しく述べている。しかも相当ドライな切り口。

トヨタのチーフエンジニアは、技術系の部長経験者から選ばれるとか、直属の部下を5、6人しか持たないとかも。その辺りになると、多少真偽も気になってくる。ただし、責任の重さは確かだろうし、実際に心労で犠牲になった人のこともニュースにはなった。

なお、「自動車工場の概要(開発主査(チーフエンジニア))」のページでは、ホンダでのリーダーをLPL(リーダー・オブ・プロジェクトリーダー)と呼んでいるとの記述。「マルチプロジェクト戦略」でのチーフエンジニアとのインタビューは1992年、1994年とのことなので、本の方が新しいと思われる。あるいは、LPLとかは研究所での呼び名なのかもしれない。


自動車業界でのマルチプロジェクトも、人事権までは無いと書かれている。でも、人を集めることは、できるような書き方だ。また、細部になると、会社毎を含めて結構違うようだ。

少し先になるけど、マルチプロジェクトについてまとめる時に、少し突っ込んで調べてみるつもり。

5月 26, 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)

2009年2月24日 (火)

TVドラマ「黒部の太陽」

何気なくTV番組のガイド誌見ていたら、「黒部の太陽」の文字。この前、とあるコミュニティで”プロマネバトル”に参加しました。その中で、エンジ系のパネラーが黒四ダムに触れてました。「黒部の太陽」って、その黒四ダムを扱った小説、そして映画、何度かTVドラマにもなってます。

今回見たのは、フジテレビのTVドラマで、映画の方じゃありません。(映画は、石原裕次郎の意見とやらで、今となっては一般公開の可能性はほとんどなし。)

3月21日と22日の、21時4分から。 主演が香取信吾で、個人的には、今ひとつかな~との感想。(若い世代向け? やはり、こっちが年取ったんだな~。)

ちなみに、フジテレビでの制作発表のページはあり。

2月 24, 2009 プロジェクトマネジメント, 映画・テレビ, 科学技術 | | コメント (0) | トラックバック (0)

2009年2月20日 (金)

半導体から学べなかったのか、日本の「電機」

実は結構以前からソフトウェア品質の向上のために、半導体のアプローチが参考になるかと思い、少し勉強している。(細部は後日。) また、明日、とあるコミュニティで「組込みソフトウェア開発プロジェクト」に言及することになり、組込み業界を再俯瞰している。

こちらは、今週月曜日に発売となった週刊ダイヤモンド。タイトルが、すごい。”「電機」全滅!”。すごいと言うよりも、実感がストレートに表現されていると言った方が適切か。

電機業界の損益とか人員整理に言及したもの。

組込みソフトウェアで括るけど、電機業界のそれと、自動車や機械のそれとは、アプローチが違うと考えた方が良さそうに思えてならなくなった。アプローチと言うよりも体質的な事なのかも。


また、週刊ダイヤモンドの表紙にもある、”半導体”の文字が気になっていた。半導体も、昨今はCでの記述など高速にソフトウェア的な面が出てきた。一般論としての、組込みやIT業界のソフトウェアの品質と、半導体のそれとは比較にならない。ソフトウェア開発の立場では、高品質半導体ソフトが非常に参考になると思いながら、何かが頭に引っかかっていた。それが何か、、、、。結局、収益なんだと、今週気がついた次第。

そこで、なんで日本の半導体の収益が悪化したのか、わかりやすい資料を探してた。今のところ一番わかりやすかったのが以下。

「技術力から見た日本半導体産業の国際競争力の研究」

要は、過剰技術、過剰品質で、利益確保するチャンスを失ってしまったというもの。サムソンなどの製品化のための流れなど、非常に参考になった。携帯の”ガラパゴス化”とも通じる面があるだろう。そう考えると、過剰技術、過剰品質は、電機に共通な”性格”なんだろうと思えてきている。

ちなみに似たような内容で、同名レポートがある。ただし、個人的にわかりやすかったのは上。また、本レポート作成の(元エンジニアの)同志社大学 湯之上 隆氏の記事が、ネットにはいくつか転がっている。

QCDというのは容易いけど、C(コスト→利益)の事も考えないと、ソフト”全滅”になっちゃう。今年とかは、その辺りを意識しないと大変なことになるということ。

2月 20, 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年3月19日 (水)

日本近代化プロジェクトの俯瞰

プロジェクトマネジメント関連。日本、特に明治維新での、プロジェクトを調べるのをポツリポツリとやってます。で、それらの時期的な列挙を、俯瞰してみようと作ってみました。NiftyでのTimeLineてのを利用。

一般の人は見れて、TimeLineユーザーの方は”できごと”の投稿やコメントが可能です。興味あれば、一緒にやりましょう。

現在は、まだ3つしか入力してません。少なすぎcoldsweats01ですが、順次追加します。(上は最新版取り込むので、後日は増えていることでしょう。)

3月 19, 2008 パソコン・インターネット, プロジェクトマネジメント, プロジェクト管理 | | コメント (0) | トラックバック (0)

2008年3月17日 (月)

工事進行基準がらみ? 日経コンピュータ「納得できるITコスト」

届いたのは一昨日とかそれ以前だったけど、ついさっき日経コンピュータ3/15号を読んだ。

特集は「納得できるITコスト」。来年4月以降適用される、会計基準の工事進行基準をも意識したもの。冒頭でもその旨が記載されている。

面白かったのが、リクルートのベンダーの生産性のランク分け。ファンクションポイント(FP)ベース。SSランクという44FP~/人月から、Cランク~6FP/人月。ランク分けは、スキルとかで色々やってる所が多いし、FPでやりそうなのはわかるけど、具体的な数値まで見たのははじめてのような気がする。

もう一つは、ローソンでの案件の評価制度。案件の企画段階で、撤退の判断基準と撤退方法を記載するように決めている事。

実は、後者は先週の某損害賠償のニュースの絡みもあって、撤退方法を収束させるにはどう考えればいいかを思考しつつあったので参考になった。あっ、検討は出荷判定のコミュニティがらみ。

3月 17, 2008 ソフトウェア, プロジェクトマネジメント | | コメント (0) | トラックバック (0)

2008年3月16日 (日)

Googleの社内ツール

「POLAR BEAR BLOG」に、Googleの社内ツールが載っていた。元ネタ(英語)のリンクも記載されている。

http://akihitok.typepad.jp/blog/2008/03/google-4b0f.html

プロジェクトのダッシュボードなども。社内リソース検索エンジン(エンタープライズサーチ)や Google Calendarは、一般公開されているのと少し違うようだ。専門家の検索システムもある。(なお、専門家検索は、マイクロソフトのシステムでの構築例を見た気がする。マイクロソフトのデモだったか、そもそもマイクロソフトの社内ツール説明の時だったか??)

こういうのを見ると、Googleって社内ツールの外販化と言えなくもないと思えてきた。コミュニティでのツール類で、結構Googleは利用している。DocsとかBlogger、グループ、そしてYoutubeのグループも。もちろん、結構不満な部分もあるけど、協業するには非常に便利。(プロジェクト管理ツールが欲しい。Calendar形態ではなくて、アクティビティ間の関係を記述できるツール。)

なお、個人的に以下もお勧め。

http://itpro.nikkeibp.co.jp/article/Watcher/20061223/257663/
IT Proでのシリーズ。多分全部読むには登録が必要。

http://jp.youtube.com/watch?v=pc-IQkVmOdI
Google Developer Day TokyoでのGoogle社員の鵜飼文敏さんの講演。トイレでのバグ(?)の掲示の話が出たはず。

http://japan.cnet.com/blog/umeda/2003/05/12/entry_google_1/
記載が2003年で、今となっては変わっている部分も少なくないだろうけど、基本的な考えを知るにはいいかと思う。(採用のための時間とかは良く知られている? 採用問い合わせ先を、クイズ(数式の解)にしたのもgoogleだったはず。)

3月 16, 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年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年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)

2006年12月 3日 (日)

マイリストに「ソフトウェアテストにおける直交表やAll-pair法の利用」をアップ

やっと、「ソフトウェアテストにおける直交表やAll-pair法の利用」について、まとめることが出来たので、マイリストにアップしました。

何年か前からタグチメソッドのソフトウェアへの応用への感心が無くはなかったので、まとめてみました。ソフトウェアにおける直交表の利用での問題点を書くとともに、提言も書いてみました。

問題点の記述では、直交表に携わっている人達(色んな会合で私がお世話になっている人達を含みます)には、ちょっと挑発的な記載もあるかもしれません。これから、ソフトウェアテストが良い方向になればとの思いからですので、了解ください。

なお、ソフトウェアテストの専門家と言うほどでもないので勘違い等があるかもしれません。

意見や指摘等は、トラックバックなりコメントでください。許可制にしているので、反映までにちょっと時間かかるかもしれませんが、反論とかでも掲示する予定です。(さすがに、勧誘目的のトラックバック等は勘弁してくださいネ。)

順次コメント追記したり、マイリストのドキュメントそのものを更新して対応して行きます。(でも他にいろいろ宿題があるので、どれくらい対応できるか多少不安ですが。)

よろしくお願いします。

12月 3, 2006 ソフトウェア, プロジェクトマネジメント, 品質, 技術, 直交表, 科学技術 | | コメント (2) | トラックバック (1)