脳の瞬発力

先日、ある音楽関係の打ち上げで、
リラックスした方がイイ音が出る。
固くなくて、自然な伸びのある音が出る。

リズムとしても、リラックスした方が
早いリズムに対応出来る。

スポーツも同じだよね。

という話で盛り上がりました。

それから数日後、これは脳も同じでは？！
と、ふと思ったのです。

リラックスしている時、
ボーっとしている時、
風呂入って「あ¨ぁ～」って声が出る時、
etc

ひらめく時がありますよね。

これって脳が自然体になってイイ音を出している時ですよね！？
つまり、脳が凝り固まらずに、柔軟にいろんな事を結びつけている時ですよね。

早いリズムに対応した時ですよね！？
つまり、瞬間的に、まったく異なる、遠くにあるAとBを結びつけた時ですよね。

改めて、リラックス！　大事ですね。
ぼぉ～っとする事！　大事ですね！！

これぞ、アナロジー　ですね！

分散オブジェクトと開発環境

今年もSWEST20  参加しました！

ROS2　は知りませんでしたが、とても興味深く
分散オブジェクトがキターって感じです。

約20年前にCOMで遊んでいた（開発に活用した）時に
CORBAやHORBを知り、感動し、この技術はスタンダードになる！
と思い込んで、DCOM（今はCOM＋？）などを活用しまくっていました。

当時は誰も同調してくれず、かなり孤立していましたが…

やっとキター！
って感じです。（まだまだかかる？）

しかし、過去、私が好きな技術はほとんどが日の目を見ていない…？！
いや、日の目を見るまで、かなりの時間がかかっているだけかも…

ROS2に話を戻して、
デバッグ環境がソースコードデバッグではなく、
データの可視化である事も、今後の可能性を感じた。
近い将来には、データの可視化が当たり前になっている気がします。
#私がそう感じるという事は、近い将来は20年後か？！

分散環境で、信頼出来るオブジェクトが増えれば、
組み合わせである程度動くようになるので、
データに注目が行くのは必然ですよね。

その上で、データを解析して、
どのようにフィルターを掛けるかなどを考えて動かしていく。
これからは、シミュレーションがますます重要になってきますね。

まずは単体テストから！

久しぶりに単体テストコードを書いてます。
既存のシステムの移植作業なのですが、
単体テストが無かったので作成しています。
ただ、解析するよりも単体テストを作成する方が理解も深まりますしね！

改めて、つくづくと、単体テストコードはソフト開発には欠かせないと感じます。

そう感じる事をつらつらと。

1)正しいコードに集中出来る
　環境(ハードやOS、etc）的な制約が無く、正しい論理を書く事に集中できる。
　もちろん、処理としては環境依存するものは存在しますが、
　これは設計でカバーすべき。
　結果的に、正しいコード（論理）を書く事に集中出来る。

2)不具合原因の特定が早い
　単体テストにパスしている論理を疑う必要がなくなるので、
　結果的に疑うべき範囲が狭くなり、原因の特定が早くなる。

3)再現可能
　単体テスト環境でほとんどの不具合が再現可能かと思っています。
　実機でしか起きない不具合は極々僅かかと。
　多少の制約や条件はあるにしても、
　すべて論理ですから、単体テストで再現可能になる筈

4)リファクタリングすべきところが分かる
　テストがし難いところは関係性が複雑だったり
　依存関係が強すぎる事が明確となります。
　つまり、それはリファクタリング対象となります。

5)動くドキュメント
　全体の概念図や構成図はドキュメント化が必要ですが、
　詳細な論理は細かなシーケンスを書くよりも
　単体テストを動くドキュメントとすれば十分かと。
　開発者にとっては十分過ぎるドキュメントかと思います。
　シーケンス図は設計作業としては必要かと思います。
　また、イメージとして記憶するのにも役に立ちます。
　ただ、あれもこれもメンテナンスするのは大変なので、
　単体テストだけをメンテナンスすれば良いと思うのです。

6)正しいコードに集中出来る（デバッグ時）
　今回、ある環境で動かすと発生する不具合を
　単体テストを活用して原因特定したのですが、
　関連した単体テストでパスしているテストがあるので、
　正しく動く条件は分かります。
　あとは、その条件をどのように壊すか、
　壊す組み合わせを考えれば良い事になります。
　それ以外は考える必要がなくなります。
　ハード的な要因を疑うよりも、論理に集中する事で、
　原因究明が早くなります。

と、長くなるので、このへんで。
やはり、単体テストが中心の開発が欠かせないですね！
それは、ずばりリボンモデルです！！　

JTBDのいろいろ活用法

先日、ある雑談から、
JTBD(Jobs to be done)の意外？
いや、むしろ当たり前と言って良いと思う活用法を知りました！

それは、自分達の直接の「顧客が解決したいJOBを知る」
と、当たり前というか、基本的なところです…

これって当たり前の事ですが、
なかなか意識されていない気がします。

こう考えると、身近で活用できるシーンが多くある気がします。

ちょっとした頼まれ事や、
クレーム対応などでも、JOBに着目する事で
無駄が無くなり、解決が早くなる気がします。

更には、
改善でも、そもそも我々が解決したいJOBは何か？
提案でも、どんなJOBが解決されるのか？

こちらも、JOBを定義する事で無駄が無くなる気がします。

TOCではUDEやDE、中間状態など、
状態を定義するのに苦労しますが、
解決したいJOBは、DEと同じですね。

JOBとして考える方が考え易い場合もありそうです。
また、ひとつ気づきを得ました！
雑談侮るなかれ！

数値と明確化

とある計画をしていて、改めて
明確化する上で数値は重要だと感じました。

目指す姿や中間状態、などを具体化する上で数値が無いと
どこまで行っても曖昧な部分が残ります。

ですが、
数値が入ると、現実的なアクションや
現実的なアクションを実施する上での不明点が明確になります。

当たり前の事なのですが、自分自身では気づき難い事なのだと
改めて認識しました。

数値化しないと、曖昧な事に気づけない。
自分では具体化、詳細化しているつもりなので、気づけない。
つまり、思い込みであり、アサンプションですね。

数値化したとたんに、今まで具体化していたのは何だったのだろう！
と思ってしまいました。（つまり、今までの検討が無駄だった！）

しかも、数値はある程度大きくする事が重要だとも感じました。

実現出来そうな数値よりも、大きめにする設定する事で、
見えていなかった部分が見えるようになります。
見ないようにしていた部分にまで、踏み込んでいく必要があるので、
より確実に目標値の達成に近づくと思います。

数値化する。大きめの数値を設定する。
この2点は、昨年から周囲に推奨していたやり方なのですが、
自分では気付き難い事なのだと、改めて認識しました。
さて、自分で気付く為に、どうしたら良いものか…

データ構造のリファクタリング

先日、移動中の車での話題です。

単体テストについて話をしていたところ、
いろいろと整理ができました。

単体テストとリファクタリングがセットなのは
だいぶ浸透している気がします。

構造を常に良くしていくには、
常にリファクタリングしていく感じがベストですね。

しかし、その際に、意外と忘れられているのが
データ構造のリファクタリング！

モジュールやクラスなどの構造は良くするのですが、
データ構造に手を付けないために、
構造がある時点から良くならないケースはありませんか？

もしくは、これ以上、良くならないな。
などと、思うときはデータ構造のリファクタリングをすると
更に良くなるケースがあります。

もちろん、
構造とデータを同時にリファクタリングしていくのがベストですが、
まず構造にのみ注力しがちな気がします。（私だけかな？！）

単体テストを容易にするためにも
処理をシンプルにする為にも
ジェネレータなどを作成して、抽象化したモデルから
必要な処理に必要なデータだけを取り込む工夫は不可欠ですね。

価値のあるA3

ゴールシステムコンサルティングさんの最新事例交換会に参加しました。
そこでディスカッションさせて頂き、ふと疑問に感じる事が...

昨年度は20チーム以上のA3(QCストーリー)をレビューしました。
しかし、今になって、
本当にチームの役に立ったA3はあったのかと疑問に感じています。

A3作成者には気づきはあったと思うのですが、
チームにとって価値があったのかを改めて考えています。

と、いうのも、
作成者のスキルに関係無く、完成したA3のレベルに関係なく、
A3は価値を生み出せると思い始めたのです。

そして、その価値は完成したA3ではなく、
A3を作成する為に考える時間、悩む時間にある。
まさしくA3プロセスにある。
と、改めて感じています。

作成者とはA3プロセスを実施していたと思っていますが、
それをチームにまで持ち込めているケースは少なかった気がしています。
チームに持ち込む事で、作成者の気づきも更に大きくなり、
チームとしての価値を生み出す可能性が高くなったのではないかと....
価値を生み出せれば、定着したのではないかと...

A3を作成する事が目的化していて、
チームにとっての価値を意識出来ていなかったですね。
今後はチームにとっての価値を強く意識していこうと思います。