« 2005年4月3日 - 2005年4月9日 | トップページ | 2005年4月17日 - 2005年4月23日 »

悪のプログラマ

個人情報保護が時事ネタらしいが、マスゴミからは微苦笑を誘われるのみ。ちゃんとした犯罪者ならその痕跡すら残さないから、誰も気付かないよという話。

昔のプログラマの犯罪についてはご存知のとおり、稚拙なものが多い。口座利子の銭厘毛を集約し、チリ積もプログラムを書いたプログラマ。電話回線をハックしてトーン「音」から暗証番号を盗聴したプログラマ。いずれにせよ、犯罪が実行される場とプログラマが論理的に近いため、当局は容易に容疑者を割り出すことができた(そのため、皆が知るところとなった)。つまり、「どこで犯罪が起きているか」と「それは誰が書いたのか」がコードにあるというわけ。

ところが、最近では「コード」の形で提供されない。提供主体との関係にもよるが、納品時点で既に動作する「部品」や「ライブラリ」、クラス「群」、パッケージ「一式」の形態をとる。発注先はもちろんチェックをするが、そのチェックは「プログラムが必要な機能を実装しているか」と「プログラムの品質が基準をクリアしているか」の2点に限定されている。「成果物」としてのコードは儀式の供物として渡される。

つまり、求められる動作をする限りブラックボックスでよしとする考え方。市役所の業務システムを丸ごと某国へ外注するのは、国産プログラマは高価だからという理屈。安価至上主義を標榜する輩は、バックドアを付けるかどうかはプログラマの良心に依存するという単純な現実すら想像できない。誓約書があるだと? それが「守られていないこと」を 管理者はどうやって証明するつもりなのか?

そして、上記の連中を喰いものにするためには、特別な訓練の必要はない。フツーのプログラマでもルールを守りさえすれば。

  動作するのは1回だけ(write once run anywhere, but ONCE)
  分散化
  時限式
  遠隔式
  動作後は自らを廃化

さらに、この簡単なルールをちゃんと守り、利益(?)をあげているプログラマはいる。自分とのつながりはパラメータをカスケード渡しにすることで痕跡を隠す。実行するインスタンスは自分が書いたものですらない。バックドアが開くのは一回だけ。「プロ」のプログラマならコードに「証拠」を残すような書き方はしない。自らの犯罪証明書にサインをするようなものだ。最も単純な隠し場所はログ出しorトランザクション発行、対象は決算・収支の基幹系…って誰でも思いつくね。念のために言うけれど、

や っ て は い け ま せ ん

では、どうすればよいのか。有効な対策は2つ。

対策1 XP

いわゆるペアプログラミング。ふたりはプログラ~っと、闇のプログラマはとっととおうちに帰りなさいってコト。ペアプロの「楽しさ」「創造性」「技相伝」が強調されているが、悪のプログラムを入れないためにも有効かと。ただし、ふたりとも悪のプログラマだとお手上げだが、そのときは対策2へ。

対策2 コード検閲

誰ですか机上デバッグという人は。バグ取りでなく、ひたすらコードを読む。「悪のプログラムを見つけるため」と宣伝して読む部隊を作るだけで、闇のプログラマにとっては脅威だろう。全部ではなく、たとえサンプリングだとしても、犯行の意思をくじくことはできる。ただし、会社ぐるみで悪のプログラマだとお手上げ

バレないから目立たない。だいたいマスゴミがはやし立てるプログラマの犯罪って稚拙だと思わないか? あれこれ頭をひねって(解決)策を練るのがプログラマの本懐なのに、まるでやっつけ仕事のような犯罪の報道を見るにつけ、「わたしならこうするのに」と感じるプログラマはたくさんいる。

そのうち、実行する人は痕すら残さない。

| | コメント (0) | トラックバック (0)

日立のPMO

前身は6年前のプロジェクトリスクマネジメントセンタ。火を噴いてから支援するやりかただと、カネもかかるし対処にも限界があるため、対症療法ではなく先手管理をねらいとした。当初の目標はプロジェクトの安定として「損益悪化プロジェクトの撲滅」を掲げ、リスク回避型の体制を採ったとのこと。

経営者としては、特定のプロジェクトの大成功よりも、全プロジェクトが失敗しないことの方が大切。90のプロジェクトが成功しても、残り10で利を全部食いつぶし、赤まで出すようなら意味が無い。だから石橋を叩くのは大切だし、どの石橋のどこを叩いておくのかを予め知っておくことはもっと大事。

現在のPMOは、以下の2組織で構成されている。

  1.プロジェクトマネジメント技術センタ
  2.業種別プロジェクトマネジメント部

技術センタではPMに関する組織の方針決定をはじめ、PM制度の確立やプロマネ育成、技術開発、アーカイブ、ナレッジの蓄積を行う。一方、業種別プロジェクトマネジメント部では実際のプロジェクトに密着して組織的な支援を行う。いずれも属人的なプロジェクトマネジメントから組織的にシステマティックに対応していくしくみをとり、プロマネを孤独な状態にさせないよう組織的な支援をすることを念頭においている

そう、PMは常に孤独。周囲といかに親密な関係を築こうともPMの悩みはPMだけにしまっておくもの(周りに相談するときには相手向けに「加工」されている)。腕っこきマネージャだといわゆる落下傘作戦で降りてくるから孤独感はひとしお。キャリアパスを用意するだけでなく、組織的なバックがついているということは心強いに違いない。

また、興味深いのはプロジェクトマネージャ制度にも独自色を打ち出し、

  1.ブロンズPM
  2.シルバーPM
  3.ゴールドPM
  4.プラチナPM

と段階的な認定資格を独自に設けている。Oracleのアレみたく面白い。同じPMでもやってきた経験や得意分野により、任せられるプロジェクトは限定されてくる。比較的小ぶりのプロジェクトをスプリントで数こなすマネージャと、巨大プロジェクトとがっぷり四つで操縦できるマネージャは、かなり違うはず。「○億円以上のプロジェクトはプラチナに限る」といった具合に人割りの目安にもなる。

また、PM制度は報酬にも連動している。プロジェクト終了時、プロジェクトの成果によってプロマネの評価が行われ、評価に応じボーナス時にインセンティブが支給される。どれぐらいの多寡かは気になるところだが「評価に応じ」ではなく「入札価格の○%」に応じだったなら目の色が変わってくるんじゃぁないかと。

PMOが最終的に目指しているのは「経営者に全体リソースを見極められるようにする」という。「現在のリソース全体」は勘定できるかもしれないが、その全ては何らかのプロジェクト・業務に投入されている。プロジェクトのエンドはまちまちだし、解放されるリソースも確定できない。そんな状況でも「できます」「できません」を根拠を持って入れるのは素晴らしい。

ネタ元:日立情報システム
http://www.hitachijoho.com/


| | コメント (0) | トラックバック (0)

« 2005年4月3日 - 2005年4月9日 | トップページ | 2005年4月17日 - 2005年4月23日 »