単体テストと理想のサイクル

最近、社内で単体テストについて話題となり、
過去の資料をあさってみました。

eXtreme Programming の白本を読んでから
単体テストにハマり、取り組みはじめてから20年弱くらいでしょうか。
2002年の資料に久しぶりに再開し、少し感動してしまいました。

取組み始めた当初はテクニック的な内容が多いですが、
徐々に考え方的な内容が盛り込まれているようです。

そこで、いま資料を作成するなら、
何を伝える資料に仕立てるか？！

と考えてみました。

リボンモデルと同じで単体テストを中心としたサイクル
ですね。

単体テスト以外（結合テストなど)で検出された不具合、
及び危険性のある構造を発見した際に
それらの再発防止の為に、単体テストに引き上げる
単体テストに引き上げる為にリファクタリングする
というサイクルです。

リファクタリングは構造を良くしていく為、
良い構造を維持する為、という事は比較的言及されている気はしますが、
継続的に単体テストに引き上げる（より上流工程で検出可能にする）
事は、あまり言及されていない気がします。

良い構造にする為の1つの例でしか無いのですが、
常に単体テストで検出可能に出来るか？！
と問い続ける事は、とても重要なポイントだと思っています。

1ヶ月後どうなっていたいか？

TOCのFRT（未来構造ツリー）を書く事で、
状態を捉える訓練を実施しました。

「状態を捉える」とは、
行動（Action）した結果、どうなるか、どう良くなるか
という状態を定義する事です。

ソフトウェア開発技術者の傾向でしょうか？
身近な人の傾向でしょうか？
How思考が強い為でしょうか？

状態の表現が行動から離れていないというか、
行動と状態が分けられないというか...

2週間後の状態と
それを達成する為の行動を記載してもらうと、

レビューが完了した状態
など、プロセスが完了している状態
が記載されます。

完了した状態って具体的にどんな状態？
といったツッコミを入れると、成果物が完成している状態
となります。

ただ、これでも成果物の「完成」の基準が不明確ですし、
成果物の目的も曖昧なので、
まだ行動の表現からは離れていないと思うのです。
もちろん、成果物の基準や目的が具体的に定義されていれば何の問題もありません。

説明が長くなりましたが、という事で、

行動と状態を明確分ける。

状態を捉える為に、

1ヶ月のFRT（未来構造ツリー）をじっくり作成する訓練を実施しました。

まずは、

1ヶ月のなりたい姿、目指す状態を設定し、（これは少し抽象的でもOKとする）

そこに向かう為のスタートインジェクション（まず始めに行動する事）

を決めて、スタートインジェクションから
1ヶ月後に向けて、状態と行動の仮説を立てていきます。

これを1日じっくりやりました。

結果としては、状態の捉え方が、少し掴めるようです。
あと、2，3回やると習得してもらえそうです。
基本的には具体化だと思うのですが、なかなか難しいようです。

プロセス定義でも、同じ事する筈なんですけどね...

事実を分ける事に気づく

前回、A3作成に時間がかかっている事を紹介しました。
時間がかかっているのは事実を中心にまとめる事が出来ず
何度も修正する為なのですが、

指摘する前に、事実を中心にまとめる事が出来ない事、
これまで、いかに事実をもとに考える事をしていなかったか
という事に気づく人も出てきました。

こういう瞬間があると、活動を継続して良かったと思います。

そして、不思議な事に、こんな瞬間に閃きも生まれます。
事実を分ける事もせずに、ただただ、やった事を記載してしまうのは
まさしくプロセス思考の強さでは？！　との仮説がふっと湧き出てきました。

プロセスを実施していけば、成果となる。
という思い込みというか、習慣、慣習が、資料にも表れ、
とにかく、やった事を記載する。

やった事（行動、プロセス）は、結果、成果に必ずつながっている筈
というアサンプションだと思うのですが、
最近は、このアサンプションは癖の域となっていて、かなり根深い気がしてなりません。

繋がっている理由や根拠を明示していれば問題無いと思うのですが、
明示している事はとても少ない気がします。

しかし、それがA3を作成する事で気づく人もいる
この事実は勇気となり、モチベーションとなりますね。

恐らく、A3だけで気づいたのではなく、
それまでの布石があっての気づきかと思います。

このような人を増やす為に、もらった勇気を力にして
地道な布石活動を継続しつつ、
気づける仕掛けをもっともっと考えていく必要がありそうです。

コーディングの価値

突然ですが、コーディングという行為に価値はあるのでしょうか？！

当然、コーディングしないと動くものは出来ないのですが、
コードを書くだけでは動きません。

コードを書いた後にコンパイルなど、もろもろ環境を整えて、
やっとこ動くものになります。

しかもその動きは、単に動くものではなく、
動作する事で顧客に価値を与えるものである必要があります。


このように考えると
コーディングという行為はとても曖昧な行為ですよね。

コードを書いただけでは動作しないので
何も価値が無いとも言えます。
ですが、コードを書かないと動くものは完成しません。

価値あるものにするには動作させる必要があります。
動作しなければコーディングした時間も無駄ですし、
ゴミを創り出しただけになります。

価値あるものにするには、ゴミの生成を防ぐ必要があります。
つまり、必ず動くコードを書く必要があります。

ですが、これはちょっと難しいので、
ゴミをいかに少なくするか
という事になるかと思います。

その為の有効な手段の1つがテストファーストかと思います。
テストファーストは品質向上の1つの手段として捉えられていると思いますが、
それ以上の効果があります。

テストを先に作成して、確実に動作するコードを書く。
テストがあれば、それさえOKになれば良いのでゴミとなる確立はかなり少なくなりますし、
テストがOKとなれば、その時点で価値に繋がるものが創造された事になります。

で、思うのですが、
これってコーディングなのでしょうか？
コードは書いているかもしれませんが、やっている事は単体テストですよね？！

実はリボンモデルにはコーディングという工程はありません。
上記の通り、コーディングではなく単体テストだと思うからです。

コーディングという曖昧な行為ではなく、
確実に価値創造に繋がる単体テストとリファクタリングを繰り返す
これがリボンモデルの核となります。

価値創造に向けて無駄を無くす為、
動かないコード、無駄なコード、ゴミ生成を避ける為、
コーディングという工程を考え直したらリボンになりました。

やっぱりセットベースアプローチ！

改めて、複数案から絞り込む事はとても効果的であると感じます。
何が効果的かというと、以下の4点かと思います。

1)自身の考えを整理出来る
2)多角的に客観視出来る
3)セルフレビューとなる
4)後から見直す場合に理解が早い

案を検討する上で、
メリット、デメリットを明確していくのですが、
意外とやっかいなのが、デメリットを考える事です。

すんなり出てくる事もあるのですが、なかなか手強いです。

メリットを返せばデメリットとなる筈！
などと思ってはいますが、
そもそもが、解決策の1つとして考えているので、
ある意味「良い案」だとも思っているところがあるのだと思います。

なので、ちょくちょく固まります....

しかし、固まるので考える必要が出てきます。
これが重要かと思っています。
この時間は無駄ではなく、これこそ必要な時間だと思うのです。

だとすると、単純に複数案をプロセスとして定着させれば
考える時間が必然的に生まれる可能性もありますね。

ものすごく簡単そうですよね。
しかし、現実はなかなか広まらないし、定着しそうでしていないって感じです。

ですが、今は本質思考道場効果で定着する事を期待しています。
さて、どうなるでしょうか？！

プロセス or ケースバイケース ？

やっとこ「リーン製品開発方式」を読み始めました。

まだ1/4程度でしょうか。
しかしながら、冒頭から衝撃的な事が次々と....

そのうちの1番は、もう少し整理してからじゃないと....
という感じなので、

2番目くらいから。

「最も注意深く詳細まで定められた開発プロセスを持つ会社が
　なぜ一番大きな問題を抱えてしまうか。
　その理由の1つは、
　文書化されたプロセスは開発者に非効率な手法を使う事を強いるためだ。」

文書化されたプロセスは非効率

と、言い切っています。

すごいですね！

それに対して、トヨタでは、

「トヨタ標準プロセスを突き止めようと開発者に聞くと、

　毎回「ケースバイケースだ」との答え返ってきた。」

という事なのですが、

こちらも、「ケースバイケースだ」と言い切ってる事がすごいと思います。

前回の非マニュアルと同じく、要するに

受動的なプロセスではなく

主体的なカスタムプロセスが無駄を無くす。
（リーンでは無駄を無くす、非マニュアルでは感動を生むという感じでしょうか）

という事だと思うのですが、
説得力というか、力強さに圧倒されますね。

しかし、ケースバイケースで、どうやって品質を確保するのか
というツッコミがありそうですが、

それについては、

「トレードオフ曲線に埋め込まれた知識を用い

　知られている問題を設計から除外しながら

　更に問題が発生することを予想して新たな解析や試験を開発していた。」

という事で、
プロセスとは別に、
データに基づいて品質を確保する方法を確立している。

という事です。
すごいとしか言いようがないですね。


で、これをソフトウェア開発に適用出来るのか？！
という事ですが、

トレードオフ曲線はやりたいですが、
ソフト開発では難しい気がしています。

因果関係図くらいは作成出来るとは思いますが、
それと品質を結び付けられるか
という点では、これまた難しい気がしています。


とにかく、A3報告書で知識を蓄積してみる
などと考えましたが、
再利用されなければ無意味ですし、
これまでも文書で残したものが再利用された事など皆無な気がします。
なので、ただ蓄積してもダメな事は明白です。

そこで結びついたのが、
以前紹介した、複数案。
これを蓄積すれば再利用も可能では？
と考えています。

現状でも、デザインパターンは考え方として再利用出来ているので、
これをメリット、デメリット、適応性などと共に蓄積すると
再利用し易くなるのではないか！？

などと日々考えています。

非マニュアル化

先日、新聞で
フジオフードシステム社長　藤尾政弘さん
の記事を読みました。

そこには

「チェーン店を出すにはマニュアルは必要だけど

　マニュアルで感動は生まれない。

　お客さんに

　ゆっくり食べてね

　と話しかけられる距離感が大事。」

これ、ソフトウェア開発でのプロセスも同じかも！？

と思いながら読んでいました。

同じように開発プロセスも必要ではありますが、

そこからは感動は生まれないと思います。

昨今では、プロセスがある故に考えなくなっている

いわゆる思考停止状態でしょうか。
というような事を聞く機会が増えたように感じます。

必要なのは、顧客の要望に合わせて

基本（プロセス）を抑えつつどのように利用するか、

どのようにカスタマイズするか

という事が重要なのだと思います。

更に、記事には、こんな事も

「従業員がマニュアルでなく笑顔になるには

　日ごろのリーダーのコミュニケーションが大事です」

ソフトウェア開発でも同じかと思います。

笑顔だけでなく、モチベーション、ゆとり、などなど　

は日ごろのリーダーのコミュニケーション次第ですよね。

考える時間

昨今、ソフトウェア開発で、
考える時間を削減する傾向にある気がします。

複数案もそうですが、
多角的に考えて、メリット／デメリットを共有した上で
一気に作る

のが最も早く作れる気がしています。

これは、つまるところ、

セットベース開発にて
多角的に分析し、
ポイントベース開発で一気に作る

のが最も早く作れるのだと思うのです。
セット・ポイントベース開発についてはこちらも参照してみて下さい。
セット・ポイント開発のススメ

セットベースの段階で
個客と共にいろいろと考え、共有する事が
ポイントベースの速度が上がる最大の要因だと感じています。


昨今は、このセットベースの段階を省略、
もしくは、とても短い期間となり、
ポイントベース開発が出来る状況では無いのに
ポイントベース開発に入ってしまう事が多いのだと思います。


そんな状況なので、
プロセスとか、いろいろな事をリセットして、
「今、本当にすべき事は何か？！」
みたいな事を
議論というより、みんなで改めて考えてみよう！
という感じで社内ワークショップとして開催してみました。

その結果をざっくりまとめて公開しました。
考えよう！