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 プロジェクトマネジメントプロジェクト管理 | | コメント (0) | トラックバック (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ドキュメントでガントチャートを作成してみたけど、その方法よりも楽。
https://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)