2008-02-27

目標なんかについて思ったことのプチ話

雑感

ふと、自分の目標について考えてみた。すると、○○さん(ギョーカイ内の著名人なんかを想像してください)と対等に話ができるようになること、なんてことが浮かんだ。

ふむ、それはそれでよいことだし、実際そうなりたいと思っていることは事実。でも、よく考えると、これって本当の目標じゃない気がする。なんか別の(ちゃんとした)目標があって、それを達成した結果としてそうなっている、というものではないかと思うんだ。そもそも、○○さんが「○○さんと対等に話をする」ことを目標にしている人と、対等に話をするだろうか。

というわけで、目標について考えるときには、それが本当に目標たりうるのか、目標を達成した結果としてそうなっているものと混同していないか、考えて意識するようにしよう、なんてことを出勤途中で考えたのでした。

2008-02-25

自分をよく見せようという意識が強いらしい

雑感

そんな腐ったプライド、捨ててしまえばいいのにね。

2008-02-18

まずはトライだ、チャレンジだ

雑感

最初に抱いていた期待は、見事に打ち砕かれた。これでは、これまでと何ら変わらないではないか。

出てくる話がすべて、強烈な違和感を持って僕に襲ってくる。どのような価値を生み出すのかわからないままで、どこかわからない現場に連れて行かれ、そこのやり方でやるのがいいとでもいうのか。いや、そうではないはずだ。おそらく、どんなところでも改善の余地はいくらでもある。少なくとも、すべての関係者と力を合わせ、ともに価値を生み出せないような状況はお断りだ。そのためには、そこに影響を与えることができる必要があるんだ。

遠からず、何らかの判断が必要になるだろう。だが、まだそのときは来ていない。僕はまだ、何の価値も生み出していない。僕は、価値を生み出すためにここにいる。ここで価値が生み出せるのか、それをハッキリさせなければならない。

2008-02-15

デブサミ2008感想：1日目

仕事

2/13〜14とデブサミ2008へ行ってきました。というわけで、簡単に感想。

全体的な感想
- 2日間、全セッションを受けてみましたが、やるもんじゃない^^;。休憩時間があまりないので(移動に時間とられるし)、非常に疲れます。スタンプラリーとかもする暇がない。
- 完全に自社製品売りたいがためのセミナーには興ざめ。講演タイトルだけ見て選んだ自分も悪いけど、次回の教訓にしよう。

- (エンタープライズな？)ビジネス的にも、今後のキーワードは「マッシュアップ」っぽい。システム自体は低予算・短納期で、既存のシステムをマッシュアップすることでそれを実現する方向に行きそう。小さなシステムを組み合わせて大きなシステムを作る。つまり、システムを組み合わせるスキルが重要になる。
- それに伴い、あるプラットホーム上で動作する小さなシステムを作ることで、小さな会社が生きていく。なんとなく、昔のAppleのOpenDoc構想を思い出してしまった。

あと、印象に残った講演についての簡単なまとめ。まとめ切れてない部分もありますが、ご容赦くださいm(_ _)m

13-A-1：平鍋さんの「海外におけるアジャイルの現在」
- まずアピールは、「リーン開発の本質」を買ってくれ^^;
- いいものを作るには、よい技術とよいプロセスがあればよいと思っていた。でも、それだけではだめだと気づいた。いいものを作るには、そこにいる人が、お客様にいいものを作りたい！と思う気持ちが重要。
- Agile2007について。
  - 非常に規模が大きいイベント。丸一週間(5日間)、平行して14のセッションが行われる。
  - 人間系の話が充実している。コミュニケーション、信頼構築、教育など
  - アジャイルは、実はアメリカでもメインストリームではない(20〜30%程度)。
  - それでも、日本よりはずっと多い。それ故に、事例なども豊富にある。
  - これは、(日本的な言い方をすれば)ユーザー企業が、自社内にIT部隊を持っていて、システムを内製している。ここで、アジャイルな開発が行われている。
  - 日本のIT(SI)業界のエコシステムは、「ユーザー企業→SIer→ソフトハウス(→二次請け…)」のような形態になっている。これでは、もっとも重要な「価値の共有」がしにくい。これが、アジャイルが広がらない要因になっているのでは。
  - キーワードはエンタープライズ。エンタープライズな開発でアジャイルに取り組むこと。
- TPSの価値観と原則で、アジャイルは進んでいる。ソフトウェア業界では、TPSに影響されたものが「リーン開発」のような形で日本に輸入(逆輸入)されている。TPSの生誕の地である日本からこういう例が現れないのが残念。もっと海外へ発信していかなければ。
- Agile/Leanとは、
  - 「投資効果のある」：ビジネス価値
  - 「ちゃんと動くソフトウェアを」：テストで駆動
  - 「期待される期間内に」：タイムボックス
  - 「ムダなくつくり」：価値(MMF:Minimum Marketable Future)を流す
  - 「維持・変更し続ける」：繰り返し開発
- ソフトウェアは、人が人のために作っている。機械に任せられることが機械に任せるが、プロセスを改善していくのは「人」。
- 価値(＝顧客にとってうれしいもの)を定義したら、「流れ(フロー)」を作ってそこに在庫を持たせないことが重要。
- リーダーシップは、「ボトムアップ/トップダウン」「高い管理能力/その分野の深い知識」の組み合わせで4つに分類される。
  - ボトムアップ/高い管理能力は「グループファシリテータ」。権限委譲型で、「メンバーのみなさんが決めるのです！」
  - ボトムアップ/その分野の深い知識は「学習する組織のリーダー」。「これが私たちの目的です。いっしょに行きましょう！」
  - トップダウン/高い管理能力は「官僚的管理者」。「ルールに従え！」
  - トップダウン/その分野の深い知識は「作業管理者」。「これがやるべきことです。この手順に従ってやりなさい！」
- もっとも求められているリーダーシップは、「学習する組織のリーダー」ではないか。
- しかし、日本ではこのタイプのリーダーシップが生まれにくい。「契約」という形で、組織的に分断が起きてしまうから。
- エンジニアは、「大きな絵」に参加しなければならない。「大きな絵」は、システムが影響するすべての範囲。
  - エンジニアの意識にあるのは、開発の部分(受注〜納品まで)だけになりがち。でも、受注するまでのプロセスや、納品後の運用も含めたすべてがシステムであり、そこに参加しなければならない。
- 個人的には、(当たり前なんだけど)TOCとの共通点も強く感じた。「在庫」に関する認識とか、「なるおそ」とか、「顧客の価値」の位置づけとか。
- 最後のアピールは、やはり「リーン開発の本質」を買ってくれ^^;
  - まだ全部読んでないのでこれから読みすすめます^^。
  - 天野さんサインありがとうございましたm(_ _)m
  - 平鍋さんにはサインもらえませんでした。またの機会にいただければ…

13-A-5：関さんの「反復開発とテスト - 7年」
- 関さんのチームで行われている反復開発の、7年間の実績について。
- 「XPをやっているのではない。僕らは僕らのプロセスをやっている」というのが印象的。
- 予期できる変化は変化ではない。予期できない変化に耐える風土を作ることが重要。
- 工程はバージョン。
- プロセス自体、チーム自体も成果物。
- プロセスはV字モデルからWWWW字モデルへ。
- 変更に対する態度が変化していった。
  - 変更をなくせ→変更できるようにはどうすれば→変更はプログラマの燃料である
- 開発者はテストの支援を実感しているので、開発者はテスタになれる
- 繰り返し出力するから、プロセスも変化・安定する。
- 多くの問題を見つけるために、バグの滞在時間を短くする。
- とにかく、「やること」が重要。

13-A-7：「パネルディスカッション：TPSで進化するアジャイル開発」
- 平鍋さん、関さん、片山さん(元トヨタ、現日立製作所)のディスカッション。
- ソフトの人たちへのハードの人(片山さん)からの言葉が非常に印象的。とにかく「ムダをなくす」というマインドが根付いているという印象。
- ハードウェアは、企画→開発→販売とフェーズが進むが、
  - 企画フェーズでは納得がいくまで繰り返す。
  - 開発フェーズでは繰り返しはしない、というかできない。金型などの設備投資が必要なため、戻ることができない。これがハードウェア開発の特徴。
  - その分、企画フェーズでコンセプトが柔らかいうちに完璧にしておく必要がある。
- その点、ソフトウェアはギリギリでも戻ることができる。ソフトなら繰り返せる。
- 現地現物のマインドがない人はトヨタにもいる。そういった人が要職になった場合は、現地現物が徹底できない。そういう場合の扱いは、どんな人にもいい点はあるはずなので、それを生かせる立場にする。「人をムダにしない」。人はそれぞれ違うということを許容する組織になっている。
- 理想とするエンジニア像は、
  - 平鍋さん：「僕はこう思います」といえる志が大きい人、人の発想を受け入れることができる人、感謝を忘れない人
  - 片山さん：「情熱的で」「カリスマでないリーダーシップがあり」「Never Give Upのマインドを持っている」人
  - 関さん：今いっしょに仕事している人たち
- 常に前進し、やり遂げることが重要。いろいろな気づきから、自ら考えて、実践し、発信すること。
- 関さんは、「やりたいんですけどどうすればよいんでしょう」と聞かれるらしい。そのときは、こう答える。
  - 「こういうのがやりたい！と思ったら、やってしまえばいいんじゃない？」

PFPの懇親会に参加。実はああいうのは非常に苦手なのだけれども(内輪の人たちで盛り上がってて一見さんは入りづらそうな先入観あるし)、今回はがんばって参加。いろいろ有益な話も聞けたので満足(^^)。

本当はこの何倍も気づきがあったんですが、なかなかうまく表現できません。いろいろと精進せねば。

2008-02-12

お客様にとっての価値

仕事

見よう見まねで要件定義なぞをしている(まだ本格着手じゃないけど)のですが、どうもお客様の要望がよくわからない。直接請け負っているのではなく、上位に某SIerが入っていて、まだ顧客要望がちゃんと聞けてないってのも理由だと思うんだけど、このシステム、本当に開発する必要があるのかがいまいち不明。

現在Javaで稼働しているシステムをスクラップ＆ビルドでイチから再構築ってどういうことよ？COBOLとかのレガシーで稼働しているシステムを、将来的なメンテナンス面なんかを考慮してオープンシステムで再構築ってのならわかるんだけど。某SIerが、無理無理なプレゼンをしてとってきたんじゃないかと勘ぐってしまう。本当に、イチから作り直す必要があるのか、よくわからないんです。

しかも、肝心の現行システムの情報が、あまり入ってこないかもしれないという話。はて、何を見て再構築すればよいのか。所有権とかの絡みもありそうなんですが、現行システムの開発ベンダのイヤガラセ(?)で開示してもらえないとしたら、お客様にとっての価値ってなに？って話になるわけです。

システム開発ってのは、お客様の価値を最大化する仕事だと思っているんですが、某SIerの覇権競争に巻き込まれてお客様の価値を減らしてしまうことは避けたいのですよ。うーん。