５つの価値その４「勇気」

「勇気」。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

５つの価値その２「フィードバック」

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

• 　P：Plan　（計画）
• 　D：Do　（実行）
• 　C：Check　（評価）
• 　A：Acton　（改善）

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

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

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

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

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

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

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

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

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



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

５つの価値その１「シンプル」

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

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

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

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

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

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

XPで一番大切な事

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

XPとは？

eXtream Programmingの略。

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

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

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

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

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

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