原因結果グラフの結果ノードに何をおくか

TEFのメーリングリストで、原因結果グラフのことがあり、自分なりに色々と考えてみました。

私の考えとしては、結果ノードは、要求の価値（ソフトウェアの目的）が高いものをおくことがいいのではないかと思います。

テストを実施するソフトウェアにおいて、この価値を結果ノードにすれば、要求を満たすテストことができるのではないかと思います。
又、その部分の実装が肝になってくるので、ソースコードの行数も比例して大きくなってくるのでバグが発生する率も高いのではないかと思います。（実装の仕方によってはそうならない場合もあるかも）

このことを頭においておけば、無駄なテストやソフトウェアが構築されることは少なくなってくるのではないかと思います。

勉強会が開催されるのはいいな？地理的な条件などがあり参加できないのは残念。

いつ実装しているか？

最近、会議などがあり、席に座っていることが少ないので、周りからいつ開発しているのかと言われます。
決して残業時間が5時間、6時間行っているわけではありません。

答えは、席にいるときに、短時間でかなり集中して開発を行っています。

そのほかにも、技術検証や調査をしているときに、ある程度まで実装しています。

一般的にはどうかわかりませんが、技術検証や調査をしているときにもソースコードをたたいていると思います。
そこである程度、実装しておくことで、その後の設計・実装に入ったときもスムーズに作業が進みます。
例えば、この場合には仕様的に不整合が起きるやバグが発生するなどです。

製品開発とは常に定義・実装・テストの繰り返しであると考えます。
ウォータフェールモデルのように全てを決めてから次の工程に移るような手戻りが発生したときのリスクが大きくなるようなことは無駄であると思います。

基本的には小さな単位で、定義・実装・テストを繰り返しているので、手戻りも少なく、無駄のない効率的な開発ができるからそういわれるのだと思います。

遺伝子は受け継がれているのか？

今日、来月旅行に行くために、旅行会社で待っているときに、少し時間があったので、子供と2人で、近くの消防署に消防車を見に行ってきました。

消防署に行くと、当たり前ですが、はしご車・ポンプ車などがあり、子供がいつも絵本で見ている車がありました。

子供はいつも見ているものが近くにあるので、はしゃいでいました。
私も小さい頃に、父親が消防車に乗っている姿をみて、あこがれていました。

遺伝子が受け継がれているのか、親子揃って小さい頃に消防車が好きなのかと思いました。

そういえば、就職活動をしているときに、サンデーで「め組の大吾」がはやっていていて、一時期は消防士になろうとしたこともありました。

常に次の塁を狙う走塁による効果

常に次の塁を狙うことは重要であることは昔から言われております。
なぜ、このようなことが重要であるかというと、常に次の塁を狙うことを意識するだけ、相手チームに対してプレッシャーをかけることができます。

そうすることで、相手がミスをする確率が高くなること・得点を奪いにいくぞというプレッシャーが相手にかかります。
得点を奪いにいくぞというのは、必ずしも得点を奪いに行くのではなく、意識させることで、色々な攻撃ができるようになるから、相手は今度はどのようなことをしてくるのかまったく読めなくなります。

一昔前に、浜松商業が強かった時代は、この戦法で、甲子園まで進みました。
最近のプロ野球を見ていると、どうしても大味な感じがしてしまいます。
WBCのイチロー選手のように常に次の塁を狙うということも必要である。

意識していなかっただけかも

今まで、あまり意識してこなかったことですが、プログラミングをしているときには常にモデルファーストで作成していることに最近気がつきました。

例えば、Windowsアプリを作成する際に、画面構成を決めてから、主目的を達成するためのモデルを作成します。
XPで言うところのモデルファーストです。そこから単体テストを実施して作成を進めて、最後には画面と結合する部分を作成していきます。
正確に言うと、テストコードを記述してから、実際のコードは作成していきますが。

なぜ、モデルから作成するのかと考えてみたところやはりMVCモデルで言われているように、Viewの部分は変化しやすいから、本能的に後から作成したほうがいいだろうと感じ取っているかだと思います。

まあ大体、Windowsアプリを作成する場合に、単体テストにおいてModelとControllerの部分は細かくテストをしますが、Viewはそれらに比べるとパワー配分が低いことが往々にしてあるので、細かな問題がちらほらと見つかったりします。

デバッグ能力の重要性

自分が想定していない挙動をした場合に、デバッグをします。
あるメソッドのところで仮に問題があったとします。

デバッグの手順は、基本的には以下の通りであると思います。
1.パラメータの値が期待通りの値か
2.パラメータが正しいのならどこの箇所で問題になっているか？
3.影響範囲を見極めて正しく修正を行う。
4.回帰テストを実施する。

ただ、必ずしも上記のように実施して修正ができるわけではありません。
例えば、初期化し忘れにより、まったく違った箇所でエラーになっていたり、浮動小数点の関係でエラーになったりして、中々根本原因を突き止めることができなかたっりします。

デバッグを繰り返していくと、経験値があがり、そんなに大規模でないソフトウェアの場合には、急遽配属になった際にもソースコードを見ながらある程度の構造や振る舞いを理解するのに、時間がかからなくなります。

新規のソフトウェアを作成する際にもこの経験は有効になるので、まずはこの技術をあがることが必要であると考えます。

お勧めの本

かなり昔に読んだ本で、お勧めの本は、「失敗の哲学」です。

この本とは別に「失敗学のすすめ」もあり、その本と同様の著者になります。

この本では、具体的な人物が登場して失敗事例からどのようなことを学んだかを紹介しています。

その中で、稲尾和久さんの話が印象に残っています。

稲尾さんは、肩の異変に気がついたのにもかかわらず、「油断」と「過信」から最悪のシーズンを迎えたときがあったそうです。

その失敗から、目の前で起きていることを冷静に受けてとめて分析するようになれたとありました。
私たちビジネスの世界でも問題は多数起こります。例えば、売り上げが好調だから、「油断」や「過信」といったものは、人間誰しもあります。しかし、ここで油断するのはなく、なぜ、売れているのか・売れていない地区にはどのような問題があるのかをしっかりと分析する必要があると思いました。

成功する人としない人の差は、なにかしらの予兆に気がつける人ではないかとこの本を読んでいて感じました。

そのほかにも信念を持って取り組み、必ず達成できる・成功させるといったことが必要ではないかとこの本を読んでいて感じました。

要求駆動テスト

テストを実施するうえでは、弱点分析しながら、実施することがテスト実施の効率化につながるというのはよく聞く話です。

確かにテストといった観点から考えれば、これは正しいことだと思います。
私としては、タスクフォース立ち上げからソフトウェアを市場へ投入するまでのスループットを考えたときには、要求の価値の高い順にテストをしていくことが必要であると考えます。

従来のようなウォーターフォールモデルで開発した場合には、テスト工程に入ったときに、実装時のテストが不十分で、バグが収束しなく、納期をオーバーしてしまうことがあります。アジャイルでも顧客への確認が遅れたりすることで、仕様変更が発生して、納期をオーバーしてしまうことがある。

これは、そもそもテスト実施の順番に問題であると考えます。

従来のウォーターフォールモデルの開発ではバグりそうな箇所や不吉な匂いがする箇所からテスト実施することは必要であると考えます。

今後は、要求の価値が高いものから順にテストを実施していくことが必要であると考えます。
一つの要求を一つのバージョンとしたときに、小さな単位でテストを実施していけば、バグが収束しないや、納期を越えるようなリスク発生の確率は減らせると考えます。
それも要求の価値が高い順にです。

このブログでも以前紹介したように、単体テストの後に、シナリオテストを実施すれば、顧客との認識のずれが減り、手戻りの無駄が減るので、それらを組み合わせることが必要であると思います。

勝手に用語を作成してみました。名づけて「要求駆動テスト」です。

脳トレでようやく20歳になった

今日、6日ぶりに脳トレをやってみたら、脳年齢が20歳になりました。
今までは、最高齢が24歳で、中々それよりも下の年齢になることができませんでした。

たまたま出題された問題によるところが大きいので、常にこの数値を出していないと正確には20歳になったとはいえませんが、最高齢に達したことは非常にうれしい。

常識力検定でも63になり、今日は頭がすっきりしていたので、この2つのソフトで最高の数値を出すことができました。

体力年齢は、ちなみに20歳を100としたときに104.5でした。

原因結果グラフの作成で気がついたこと

原因結果グラフを自分なりに作成していて気がついたことは、AND条件、OR条件に入ってくる線は、2本が最適であることがわかった。

Jasstで公開されている資料の遊園地の入場料のところを実際に行った。
無料のところに、3本以上線が接続されてしまうと、その後のデシジョンテーブルを作成するときに非常に作成が大変になってしまうことが実際にやってみてわかった。
3本以上になってしまう場合には、途中にAND条件、OR条件を付け加えたほうが、デシジョンテーブルを作成するときに、簡単だなと感じた。

実際に、作成してみてわかったことだが、確かに敷居が高いかもしれない。

グラフの作成にはあまり時間はかからなかったが、デシジョンテーブルの合成に時間がかかった。たぶん慣れていないので、時間がかかったのではないかと思う。

これから、色々な場面で試してみて慣れることが重要かなと思う。