TAKAが試したこと考えたこと

先週「ゲンセキ」という番組で気になっている。 オリエンタルラジオ（東京吉本） ネタそのものと勢いがよい。でもその2つがアンバランスな気がしています。そのあたりのバランスが取れたらきっとブレイクすると思う。 M-12004上位だから青田買いじゃないかも(^^; トップリード（太田プロ） 洗練されていないアンジャッシュという感じ。スマートな感じはないけど爆発力がある感じ。面白い。 今日のエンタの神様でてきてきなったコント。 ビーム（ホリプロ） 今日のネタは面白かった。落ちはパワー不足だった気がしたがネタの一つ一つが面白かった。

[続きを読む →]

効果を出すために必要な、大事なポイントがあると（私は）思う。 それを考えることなくして（考えると時間がかかるから）、時間が大事だから 考えない。（と私には思える）ことをいう人がいます。 時間が大事なのはわかりますが、効果がなくてもいいのだろうか。 効果がないとは思っていないのかもしれませんが・・・ でも課題に対して、対処慮法的な施策が根本的療法の施策があることもあると私は思います。 試行錯誤＆フィードバックループがいいのでしょうが、フィードバックに遅れがあるものに対してどう対応するのかが課題な気がしています。 もう少し考えてみたいと思う。

[続きを読む →]

テストのカバレッジは計測すべきと思っています。 開発者で プロジェクトで 計測して、単体テスト（ホワイトボックス）の実施度合いを把握しましょう。 できればカバレッジは高くした方がよく、経験的には80～90％にしておくのが良いと思います。工数の割合で高くできない場合があります。ToBe的には100%（実施できないものは目視をする）がいいのですが、どうしてもコストと時間がかかってしまうのでバランスすると80～90％かと。でもプロジェクトの特性（リスクあるいはプロファイル）によって変わるかもしれません。 何ができていなくて、そこにはどのようなリスクがあるのかそれを判断して進めていくのがいいのかなと思っています。 カバレッジを高くする結合テストは非常にコストがかかります。（あるいは献身的なサービス残業） もし品質を高く、リリース後の欠陥を押さえてコストを安くしたいなら単体テストを実施すべきです。少なくともブラックボックステストレベルでパス網羅をしておきましょう。

[続きを読む →]

単体テストが話題になっているようですね。 私も似たような経験があります。 （脚色しています） 単体テストをおこなう見積で実装・単体テストに関する内容をつめていた時のこと。 「単体テストは、夜間で自動実行することも考慮して、JUnitでテストコードを作ってください。」 「それでは作業が増えるので工数が増えますが・・・」 「はい？　スタブやドライバを作るのだから同じじゃないでしょうか」 「単体テストは画面から値を入力して動くかどうか確認しています」 といったやり取りがありました。 モンキーテストというテストのやり方があるので、テストではないとはいいませんがブラックボックステストにもやらず、仕様書の通りか検証もしていません。 仕様書があいまいで、テストケースがひとつしかできないようなものであればやもをえないのかもしれませんが、検証をしないで納品するという行為はいかがなものでしょう。 欠陥が発生した際に、発見する工程が遅れるほどコストがかかります。依頼した方も私たちもlose-loseの関係になっている気がします。 短期的な利益は長期的な利益をも凌駕するのでしょうか。未来のことはわからないからなのでしょうか。 対立構造ができたときに納得ができるまで話をすることが大事だと個人的には思っています。「共に語るに値せず」という場合もあるでしょうが・・・ きっと納得できる話をするためには情報が必要なのでしょう。

[続きを読む →]

通勤電車の中でいまさらですが 最強組織の法則―新時代のチームワークとは何か 作者: ピーター・M.センゲ, Peter M. Senge, 守部信之 出版社/メーカー: 徳間書店 発売日: 1995/06 メディア: 単行本 購入: 7人 クリック: 3回 Amazon.co.jpで詳細を見る を読んでいます。 メンタルモデルの重要性を理解して、思い込みの激しい人が 人の意見に納得しても次につながらない理由がわかりました。 でも、メンタルモデルを変えるための工夫はしようとは思うものの それを変えようとしない人には無駄な気がしています。 どういうアプローチがいいのでしょうか。

[続きを読む →]

いろいろさわって、周りの人にデモしていて気づいたのですが フレームワーク的にいろいろなものを持っているのが更にすごい。 WBS 議事録 ブランド形成プロセス マーケティング リスク管理 などがあり、テンプレートしてはできすぎの感があり 脱帽です。 またいろいろ書いてみます。

[続きを読む →]

中1日で到着。 遊びで使ってみた。なかなかイメージが膨らむ。面白いツールかも。 遊びで書いたのが右の図です。 明日の勉強会の資料も書いてみようと思う。 MindMap読書術をしてみてもいいかも。

[続きを読む →]

エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented Selection) 作者: マーチン・ファウラー, 長瀬嘉秀, 株式会社テクノロジックアート 出版社/メーカー: 翔泳社 発売日: 2005/04/21 メディア: 単行本 購入: 6人 クリック: 42回 Amazon.co.jpで詳細を見る 待ちくたびれましたがやっとでました。ゆるゆると読んでいこうと思います。

[続きを読む →]

忘れないうちにメモ 業務設計・RFP・要件定義の“天動説”―ユーザーの主体性発揮を! 作者: 木ノ下勝郎 出版社/メーカー: 同友館 発売日: 2005/04 メディア: 単行本 クリック: 3回 Amazon.co.jpで詳細を見る

[続きを読む →]

結構良くまとまっている 問題解決のための高速思考ツール 作者: デビッドストレイカー, David Straker, 富沢昇 出版社/メーカー: エスアイビーアクセス 発売日: 2005/02 メディア: 単行本 Amazon.co.jpで詳細を見る ポストアップ 交換整列 トップダウンツリー ボトムアップツリー 情報マップ アクションマップ といったツールを利用して問題解決をはかろうとする書籍。 Post-itを多用しているのが特徴ですが、特にPost-itでなくてもできそう。 問題の洗い出し、並べ替え（整理）をおこなっているということです。 議論するときにも利用できそう・・・ ネットワーク上のバーチャルでもできればいいのだが・・・ NOTA、WEMAを待つしかないのかな・・・

[続きを読む →]