2009年12月31日木曜日

NewKPTに関するご意見を頂きました。

友人より、「NewKPT」について、ご意見を頂きました。

■NewKTP

//////////////////////////////////////////////////
クッシーさんのNew KPTの記事についてです。
おもしろい視点だと思います、Whyを取り込むんですね。
当たり前だけど、気づきませんでした。

KPTってTOCの思考のプロセスと似ていると感じます。

思考のプロセスは、  「何を何にどのように変えるか?」

対応づけを以下のように考えています。
K or P・・・何を
T・・・何にかえるか
?・・・どのように

どのように(How)がないんですよね。
Tryなので、Howじゃないと思うかもしれませんが、
勉強会で皆さんのKPT見てると、実際は、「How」じゃない気がしました。

K or PとTを結ぶ導線がすぱっときれているような。
→T・・・にHowを書けばいいのかもしれませんが。

4マスに区切って、Howを入れるのもどうかなと思っています。







//////////////////////////////////////////////////



頂いたご意見の中で、一番興味深かったのは、この一文です。

「勉強会で皆さんのKPT見てると、実際は、「How」じゃない気がしました。 」


私は、「TはHowを書く」と考えていたのですが、この点がKPTを説明する上で欠けている視点なのだと感じました。

勉強会などでKPTを使ってふりかえりをする場合、時間が無いため「Tryには、明日から実行したい事を書いてください」と言いますが、本来の使用方法は「Pを挙げて、Pを改善するためにできることは何だろう?」という発想でTを考えます。思考の流れは次の通りです。
  1. 問題を挙げる
  2. 問題をPに書く
  3. 問題に対する具体的かつ有効な解決策を考える
  4. 思いついた解決策をTに書く
 上記思考プロセスの中で最も重要なのが「具体的かつ有効な解決策」の検討です。ここが一番難しく、時間がかかる所です。実際にKPTする際、私はTryを考えるため「なぜなぜ分析」による原因分析を行っています。下記に例を示します。

/////////////////////////////////////////////////////////////

  1.問題を挙げる
    ・障害が多発した

  2.問題をPに書く
    ・「障害が多発した」 をPに書く

  3.問題に対する具体的かつ有効な解決策を考える
    3-1.参加者全員で、「障害が多発」した原因を考える (Why)
      A) 特定パターンに関するテスト項目が不足していた
        なぜ1:テスト者が気付かなかった。
        なぜ2:テストパターンを知らなかった。
        なぜ3:テストパターンが暗黙知になっていた。

      B) 初期化していないポインタを使っていた
        なぜ1:変数の初期化の重要性を理解していなかった。
        なぜ2:言語の文法を理解できていなかった。

    3-2.挙がった原因に対し、解決策を考える (How)
      C) テストパターン一覧を作成し、全員で認識合わせする
      D) 変数の初期化をコーディングルールに追記し、全員で認識合わせする
      E) 不足していたテスト項目を増やして、明日から再テストする
      F) 静的解析ツールを導入し、自動チェックする

    3-3.実現性を判定し、即座に実行できる事を決め、Tに書く (Try)
      G) テストパターン一覧を作成し、全員で認識合わせする
      H) 変数の初期化をコーディングルールに追記し、全員で認識合わせする
      I) (進捗に影響させないため)毎日定時後一時間、不足していたテストを実行する
      J) 静的解析ツールの種類/機能/価格を調べる
/////////////////////////////////////////////////////////////


私のイメージでは、 3-1(Why) と 3-2(How) をKPTに書いていません。そもそもKPTに書くスペースがなかったので、不要だと考えていました。

私の場合、3-1(Why)を撲滅するために、暗黙知となっている事象を手順書やwikiなどに書き、失敗しない様対策を行うものだと考えていたのと、そもそもTryはKPT実施時に出席した者が理解できていれば十分であり、Tryを見れば会議の内容を思い出すことができたので、KPTの3項目で十分でした。


しかし、それではKPTがチームの暗黙知になってしまうため、他のチームへ水平展開することを考えると、やはり「Why」は必要だと考えています。

2009年12月28日月曜日

アジャイルを始まるヒトと始めないヒトの差

社外の勉強会やセミナーに行くと,自発的にアジャイル開発を始めた方が簡単に見つかる。

逆に,それ以外で「アジャイルやってるんです」という方にはほとんどあった事がない。

これは,アジャイルが日本の開発現場に浸透していない証拠だと思う。

自社でアジャイルを始めたいと思っても,仲間が居ない→社外の勉強会やセミナーに参加→興味があるのでコミュニティに参加→セミナーの常連になる→試しにスタッフになる→次回,講演者に・・・

こうして,社外コミュニティが構築されていく。


問題は,「社外で学んだ事を自社にフィードバックするかどうか」である。


要するに,アジャイル実践者は会社で受け入れられない自分の知識をコミュニティで展開し,アジャイル非実践者は勉強しても社内に展開しない。


一番アジャイルを必要としている現場と,知識を持っている社外コミュニティとの"橋渡し"が上手く機能していないと感じる。

2009年12月27日日曜日

アジャイルが企業に嫌われる理由

昨今,製品開発には「測定可能な品質特性」が求められるのが常識である。


例えば食品を考えると,生産地や農薬の有無など消費者が気になる項目が記載されている。


一方,ソフトウェアには消費者が期待する特性が買って使うまで分からない。


例えば処理速度や使い勝手,不具合の少なさ等々。


アジャイル開発手法にも同じ事が言える。


ペアプロにおける企業のコストメリットは幾らなのか?


TDDの導入による障害削減率は何パーセントなのか?


これらの数値を提示しないまま「アジャイルは良いですよ」と言っても,まず間違なくない誰も信じてはくれない。


もう一つの問題は,「ヒトという数値化が困難な要素を含んだプロセス」という事。


アジャイルは,ヒトとヒトとのコミュニケーションを重要視する。つまり,ヒトに依存するプロセスであると解釈できる。

当然企業はそんな数値化困難なプロセスを受け入れてはくれない。


この問題が,マネージャー層に受け入れられない大きな要因だとおもう。


アジャイル開発プロセス導入による具体的かつ数値的なメリットが,導入を阻む壁を破る鍵となることは間違いない。

2009年12月25日金曜日

アジャイルの誤解

日本に「アジャイル」が紹介された直後,失敗事例が多数報告されたと聞く。良く聞く話が「ドキュメントを書かなくても良いと聞いて,本当に書かなかった」と言う話。


ドキュメントが必要か不要か,現場の担当者なら判断できたのではないだろうか。それに対し,どこかからか圧力がかかり,「ドキュメントを書くな」という指示がくだったのではないかと想像している。


新たに使おうとするモノ・コト・概念は,間違っている可能性を秘めているのだから,リスク管理が必要だが,それが不十分だったのではないだろうか。または,「これぞ銀の弾丸」だと考え,書かれている内容を理解せずに導入してしまったのではないだろうか。


先日呑み会で友人から「完全なアジャイルではありませんが,ウォーターフォールとXPを組み合わせたやり方で開発しています」と言われた。


僕は「完全なXP」という言葉に違和感がある。チームが最大限の力を発揮する手法が「XP」であり,XPのプラクティスを全て実践することがXPの目的ではないはずである。


先のチームは,自分達にとって最適なモノはなにか考え,そして「ウォーターフォール+XP」という結論を導き出したに違いない。


単に聞きかじったコト・モノ・概念を信じだけでなく,自分達が必要かどうか判断することが大切である。

2009年12月18日金曜日

【勉強会】「第6回日本Androidの会関西支部勉強会」に参加しました。

12/17に「第6回日本Androidの会関西支部勉強会」に参加しました。


個人的にアンドロイドがどんなものなのか興味があり,参加する事にしました。


内容は,開発環境の構築,個人でハードウェアを買ってきて組み上げた事例紹介,現場の方の経験談の紹介といったものでした。


どの発表も新鮮で,アンドロイドの事がなんとなく分かった気分になりました。個人でボードを買ってきていじれるのは凄い事だと思いました。


参加者が80名居たのですが,僕と同じように興味本位で参加された方,「アンドロイド」というキーワードで参加された方も多かったのではないかと思いました。


この勉強会をきっかけに,アンドロイドにハマって行く方も多いのではないかと思いました。

【勉強会】「Silverlightを囲む会in大阪#6」に参加

12月16日に「Silverlightを囲む会in大阪#6」に参加してきました。


ブレンダーというGUIツールの紹介と,追加された新機能の紹介が主な内容でした。


確かに便利にはなっている感触はあるのですが,自動生成されたコードが動かなかったり,インストールや他アプリとの連携に専門知識が必要であったりと,初心者には敷居が高い印象を受けました。


Silverlightの対抗製品としてアドビのAIRがありますが,そちらもどうなっているか気になりました。機会があれば触ってみたいと思います。


最後にマイクロソフトの開発者の方から,とても興味深いお話しを伺うことができ,大変参考になりました。


ブレンダーを使われる方で勉強されたい方には,とても有意義な勉強会だと感じました。

5つの価値その5「尊重」

最後に紹介する「尊重」。

実は、XPの聖書「XP eXtreamProgramming入門」初版では、「尊重」が無く、「4つの価値」が紹介されていた。その後出版された第2版で、「尊重」という価値が1つ追加された。

これは、重要な事である。
XPを始めとする、アジャイルソフトウェア開発手法は、「ヒトの関連」を重要視している。そのため、XPでも「コミュニケーション」という価値が存在するが、恐らくそれだけでは足りなかったのではないかと想像している。

しかし、コミュニケーションには「情報・伝達」という意味はあるが、相手を思いやる人間性が薄いのではないかと考えている。一方、「尊重」(=respect)は、他人に対して敬意を払うという意味の言葉で、我々日本人が古くから重要視してきた概念である。


ただ単に情報を伝えるだけでは、有効なコミュニケーションは構築できないどころか、ミスコミュニケーションによるロスが発生する危険性がある。

情報を発信する際、相手を思いやり、「どうすれば正しく伝わるか」または、「どう伝えれば分かってもらえるか」そこまで考えて情報の伝達方法を考える必要がある。

上司は部下を思いやり、部下は上司を思いやることで、お互いに信頼関係が生まれ、良質なコミュニケーションを図ることができ、仕事をスムースに進めることができる。

ソフトウェア開発において、お客様、上司、部下、その他ステークスホルダー全員に対し「尊重」の気持ちを持つことが大切である。そうすることで、お客様が真に望むシステムを構築することができ、顧客満足度を向上させ、エンジニアの「お客様の役に立つシステムを作りたい」という欲求を満たすことが可能になる。

ここでやっかいなのが、「お客様」である。
「私達は、お金を払っているんだから、言う通りにシステムを作ってあたりまえですよね?」
というスタンスに立たれると、開発者はモチベーションを下げることとなり、結局お客様も欲しいシステムが手に入らない結果となってしまう。

お客様と開発者を上手に橋渡しするマネージャーの役割が重要になってくる。

2009年12月16日水曜日

5つの価値その4「勇気」

「勇気」。

通常、「勇気」という言葉を聞くと、「死をも省みず挑戦する!」という印象を持つのではないだろうか。

ここで語られる「勇気」とは、メリット/デメリットを比較し、失敗した時のリスクを押さえた上で実行する事を意味する。単に蛮勇を奮って危険な場所へ飛び込むことではない。

しかし、メリット/デメリット/リスクを真剣に考え出すと、「勇気」を使うかどうか判断するのに時間がかかってしまう。仕事を行う上で、即座に決断を迫られる状況が多々ある。

そんな時のために、「勇気」を使うかどうか判断する一つの行動指針がある。それが、「シンプル」「フィードバック」「コミュニケーション」の3つの価値である。

チームメンバーが暗礁に乗り上げ、開発が進まなくなり、あなたは次の解決策を思いついたとする。

1.メンバー全員を入れ替え、ハイスキルメンバーで対応する
2.メンバーにご馳走して、やる気を回復してもらう
3.メンバーに、「出来るまで会社に泊り込んでもらう」と告げ、その通り実行する

これ以外にも、良い方法があるかもしれない。

ここでは、あなたは1分以内に回答を出さなければならないとする。上の3つ (または、あなたが独自に考えた方法) どれを選ぶかはお任せするが、どの方法が最適か1分間真剣に考えて頂きたい。

そして、選んだ判断基準が何であったか、考えて欲しい。どの方法を選択するにしても、「勇気」が必要だったのではないだろうか。そして、選択した基準の中に、下記の価値を見出したのではないだろうか。

---------------------------------------------
「シンプル」
複雑なものよりシンプルな方が簡単に問題を解決できる

「フィードバック」
実際に試した結果、良いものは再利用/悪いものは改善

「コミュニケーション」
ソフト開発は生物である「人間」が行う

---------------------------------------------


例えば、「開発が進まないなら効率を上げるため、専門家を導入する」といった解決策を決定した思考プロセスを考えてみると、下記のような判断があったのではないだろうか。

・過去に専門家を導入して成功した経験がある → フィードバック
・専門家1人を導入するだけなので、費用が屋安いし簡単 → シンプル
・ツールやパソコンなどではなく、専門家という人を雇うので安心 → コミュニケーション

「勇気」という価値は、「シンプル」「フィードバック」「コミュニケーション」の4つ価値を判断基準とすることで、強力な価値を手にすることができる。

2009年12月15日火曜日

5つの価値その3「コミュニケーション」

複数のメンバーでソフトを開発した経験がある方は「コミュニケーションが大切」である事を,経験としてご存じだと思う。

しかし,コミュニケーションは目で見ることができず,定量的な測定が困難である。
強引に定量化した例を挙げると,

・メールの発信件数
・ミーティングの回数/時間

などがあるが,果たして効果があるかどうか疑問が残る。

メールの場合,メールに重要な事が書かれていなくても件数が足りていればOKになるし,ミーティングの場合,誰もなにも発言しなくても規定時間/規定回数消化すればOKになる。

「ソフトウェア開発は伝言ゲーム」だと言われるが,この様に測定困難なコミュニケーションを上手に使いこなす必要がある。

解決策の一つは「複数の伝達方法を使う」事。
口頭やメールだけに頼らず,絵や図を書く事である。

もう一つは「情報を正確に受信できたか確認する」事。
情報受信者が自分の理解した内容を情報発信者に確認する事で,誤解や抜け・漏れが減る。

最後に「アウトプットを確認する」事。
どんなにコミュニケーションを取れたとしても,勘違いや間違いを犯す可能性がある。アウトプットを確認する事で結果が分かる。

そしてコミュニケーションで一番大切なのは,「良質な人間関係の構築」である。
悪い報告や重要な報告を受け取るためには,発言しやすい場作りが最も重要である。
コミュニケーションを改善するためには,場作りを考えるべきである。

2009年12月14日月曜日

5つの価値その2「フィードバック」

ソフトウェア開発にける「フィードバック」の類似後と言えば「PDCA」サイクルが一番有名である。


  •  P:Plan (計画)
  •  D:Do (実行)
  •  C:Check (評価)
  •  A:Acton (改善)


計画して実行した結果を評価し、問題点を改善し、次回のプロジェクトにフィードバックする。
ここで「フィードバック」という言葉が出てくる。

しかし、ソフトウェア開発において、「フィードバック」はどの程度実施されているのか疑問である。

「フィードバック」を明確に説明し、なおかつ意味のある「フィードバック」を実践できている人がどの程度居ているのだろうか。

少し話が逸れてしまった。XPの話に戻そう。

XPで言う「フィードバック」とは、「PDCA」という言葉すら意識しない、本当に身近な所からフィードバックを得ることが重要であると説いている。


  1. 実際に動作するプログラムから、フィードバックを得る
  2. 顧客から直接フィードバックを得る
  3. テストでフィードバックを得る


例えば、[1.]の場合、机上で実現方法を悩むより、実際に動作する動作するプログラムを作り、問題点を早期に抽出する。その結果、悩む時間を削減することが可能となる。

[2.]の場合、顧客に動作するプログラムを見せて、仕様を決めてもらう。顧客の悩みを取り除くと同時に、顧客と開発者双方が合意した仕様を早期にFIXすることが可能となる。

[3.]の場合、TDD(テスト駆動型開発)でテストスィートで自動テスト環境を作って、新規にバグが組み込まれていないか確認する。開発後半で発生する障害を削減し、素早いリリースが達成可能となる。



以上の様に、様々な場面で意識的に「フィードバック」を得ることで、開発を加速することが可能となる。

2009年12月7日月曜日

5つの価値その1「シンプル」

物事はシンプルに考えた方が上手く行くものである。

ソフトウェアという複雑なモノの実現方法を考える時,様々な事象を考えなければならない。

複雑なモノを複雑なまま考えると,どうしても抜け/漏れが出てしまう。

そこで,機能分割を行い,関心事を小さく分けてしまう。これも1つの「シンプル」である。

更に,複雑な関数を複数に分割し,1つの関数の機能/ステップ数の減らす事も「シンプル」である。

この様に,無意識の内にシンプルの価値が活用されている事が分かる。この価値を意識して様々な場面で活用する事で,より大きな効果を得ることができる。

2009年12月3日木曜日

XPで一番大切な事

XPは,ソフトウェア開発手法の一つである。

そのため,「XPと言えばペアプロですよね?」とか「テストを先に作るヤツですよね」などといった意見が非常に多い。

XPに関する書籍を読むと分かるが,プラクティスより5つの価値がいかに重要か気付かされる。

下記に5つの価値を記す。

・シンプル
・コミュニケーション
・フィードバック
・勇気
・尊重

ソフトウェア開発において,この5つの価値を得るための手法が,XPの目指す所である。

2009年12月2日水曜日

XPを始めるために必要な事

新しい事を始めるためには「理由」が必要です。

新しい事を始める時,人は誰しも「変化に対する恐怖心」を抱きます。失敗した時のリスクが高い程,「変化に対する恐怖心」は強くなります。そのため,恐怖心に打ち勝つだけの強力な「理由」が必要となります。

僕がXPを導入した理由は,「生産性と品質向上」でした。従来のやり方に限界を覚え,別の手段を模索している時にXPに出会いました。

僕も「変化に対する恐怖心」があり,導入をためらっていました。しかし,下記の方法で導入を実現しました。

1.相談する
社内の人に相談して,リスク軽減策を検討しました。

2.ちょっとずつ実践する
いきなり全てを導入するのではなく,できる所から徐々に導入しました。

3.手順を文書化する
試してみて気付いた点を文書化し,チームで共有しました。これがルールブックになりました。

この3点を意識して実践した事で,導入時のインパクトを軽減することができました。

2009年12月1日火曜日

XPとは?

eXtream Programmingの略。

直訳すると「究極のプログラミング」となる。

この訳文を見ると,「この手法を使えば,究極なプログラミングが可能になるんだ!」と誤解されてる方が非常に多い。

XPの本質は,「チームが良いと思う事を最大限実行する」であり,書籍に記載されている事を鵜呑みにするのではなく,チーム自信で良い/悪いを判断する必要がある。

ペアプロやTDDなど有名なプラクティスも,チームにとって無益なのであれば,それらをやらない事が「eXtream」となる。

極論すると,チームにとってウォーターフォールが最良な開発手法であれば,それはXPであると言っても良いと考えている。

何が良くて何が悪いか,判断する事が大事である。

2009年11月29日日曜日

eXtreamProgramming

「XP」という言葉が日本にやって来てからもうすぐ10年になる。

eXtream Programmingは、1999年に米国で「eXtream Programming」が刊行され、急速に知られるようになった。

日本では、2000年に「eXtream Programming」の翻訳本「XP エクストリームプログラミング入門」が刊行され、広く知られるようになる。

私の記憶が正しければ、2001年頃に「アジャイル」と「スクラム」というキーワードを知り、なんとなく気にはなっていたが、それほど興味は無かった。

しかし、2003年頃、ソフトウェア開発手法の効率化を目指し、新たな手法を模索する中で、「アジャイル」に再開する。

私自身、2005年に「XP」を実践し、その素晴らしさを実感し、今に至っている。
この手法を、もっと普及したいという強い思いが今の自分を突き動かしている気がする。