2008年12月 6日

横幹連合

横幹連合とは横断型基幹科学技術研究団体連合の略称で、国内の基幹技術研究の学会を会員とするメタな学会である。
地球環境問題などの対処に多くの相矛盾する課題の解決や、新たな価値創造の基盤を確立することが急務のものづくりなど、新たな価値創造の基盤を確立することが急務な日本の現状を背景としている。
これらの諸問題の解決には、横断的な視点に立った「知の統合」が不可欠だとの認識でスタートしたものだそうで、今回が2回目のシンポジュウムである。

茗荷谷にある筑波大の東京キャンパスで横幹連合総合シンポジウムがこの4日、5日と二日間に渡り開催された。

シンポジュウムの趣旨にも賛同するし、我々の仕事にもヒントがあると思い、初日の午後に参加してきた。
基調講演が東大の藤本隆宏教授であったので、これも楽しみのひとつであった。
講演の内容は例によって自動車産業を中心にものづくり概念と産業競争力のはなしであった。
藤本先生は想像していたより面白いキャラで、話もうまかった。
1Hrの講演に配られた資料は少なく見ても4〜5Hr分はあった。話はあっちこっち脱線するが話しなれているので、聴衆の気持ちを掴むのがうまいし、精力的に現場を回っていることが推測できる泥臭いネタばかりであった。

その後のパネルディスカッションも藤本先生の独壇場の感はあるが、得るものがあった。別途纏めてみたい。

ただ、出席者は大半がアカデミアの人たちで、居心地が良くなかったが、日頃無い良い刺激を受けた。

Posted by hirarin at 15:37 | コメント (0) | トラックバック

2008年7月 1日

PSP/TSP

JASPICのソフトウエアプロセス改善セミナに行って来た。

収穫はPSP/TSPの話かな。
日本ではまだそんなに馴染みが無いが、欧米ではかなり真面目に取り組んでいると言う。

組織の品質向上は構成する個々人の積み重ねにより決まる。
従って、まず、構成要素である個人のスキルをきちんと向上させることが肝要であり、PSPとはPersonal Software Processの略で、個人のスキルアップを目的としている。
このため個々の開発者のスキル、コミットメントそしてパーソナル・プロセスの規律を向上することが高品質の鍵となる。

TSPはTeamのSPの略である。
プロジェクト向きで、PSPを受講した人がチームを組むことが前提となっている。チームはメンバーが互いに協力しサポートし合うと最もよく機能する。また全員がよく定義されたプロセスを使うと高品質の製品を作ることが可能になるという考え方である。

カーネギー・メロン大学のワッツにより、開発されたmade in USA のメソッドであるが、日本人のマインドに近いものを感じる。
それもそのはずで、20年ほど前の日本のソフトウェア開発現場のベスト・プラクティスがべースになっており、欧米で盛んに取り込まれ、日本に逆輸入されている状況らしい。

USの大手企業(ボーイング、マイクロソフトなど)では取り組んだ成果がかなり明確に出ているという。

CMMと比較したPSP、TSPの位置づけは大雑把に言うと、

・CMM
 管理活動を行う上で「組織」として必要なroleとActivityについて
・TSP
 管理活動を行う上で「チーム」として必要なroleとActivityついて
・PSP
 管理活動を行う上で「個人」として必要なActivityについて

と言った感じかな。.

Posted by hirarin at 23:36 | コメント (0) | トラックバック

2007年4月10日

様式

新しい環境で新しく、直面することは多い。

一定の場所に、長くいると、それが常識と思われていることでも、違う場所、違うプロジェクト、違う価値観の人々、etcとの仕事で、それまで「常識」と思っていたことが見事に打ち壊される。

良く見るのは、工程や、テスト、検証などの考え方、名称、略号などである。

しかし、この地に来てみて、思い込んでいた常識も、もろくも崩れる。
えーっと、思うような事例も結構ある。
面白いといえば、面白い。新鮮といえば新鮮である。

この地で、長く磨かれた歴史が積み上げられているのだ。
secret に付き、紹介できないのが残念だが、磨き上げられた様式美を感じてしまう。

Posted by hirarin at 02:52 | コメント (0) | トラックバック

2006年9月19日

決定が遅れるプロジェクトでは

リーンソフトウェア開発に関する原則の一つに

不確定要素が多い場合,確実な情報を元に決定を下せるように、オプションを維持したままで前進することを許容しよう。このためには、システムに変更可能性を組み込んでおくことが戦略的に重要である。

とある。
これは,当たり前のことであるが、

「不確定要素が多いプロジェクト(仕様が緩い、利用者が多い、MMIで変更要求が多い、外乱要因が多い、トップダウンの変更が多いetc)では,この「オプション」を明確に示しながら(全員共有し)、従って、変更可能性を意識し(意識してもらい)進めることが肝要である。」

と言う事になる。開発メンバー内での共有は良いとしても、ステークホルダー全般に認識してもらう事が重要であるが、できてない。
オプションの提示、理解、共有。リスクの共有、協調推進にもなる。

Posted by hirarin at 23:03 | コメント (0) | トラックバック