どこに時間をかけるか

最近、ソフトウェアの機能追加をしていて
追加する際の構造をどのようにするかで悩みました。

他の事をしながらではありますが、1週間くらい考えていたでしょうか。

既存のイベント変換機能を利用したいのですが、
現状のイベント変換機能は、
使う人が決まっているので、その人専用に作られています。

イベント返還の内容は全く同じなのですが、
変換後の処理が異なります。

偶然にも処理は変換と変換後の2つに分かれてはいたのですが、
変換後のデータを取得する手段がありません。
変換後の処理に変換後のデータを渡す手段が無いのです。

そんな事は想定外の事なので、
もちろん既存の構造が悪いわけではありません。

だからこそ、悩みます。考えます。

変換後のデータを取得するインターフェースを追加するか
現状の処理に条件分岐を追加して、変更してしまうか。
はたまた、まったく別の方法を考えるか。
などなど。

改めて、ソフトウェアの追加、変更は難しいと感じた次第です。

しかし、この時間がとても大事だと思っています。
考えて、考えて、考えうる手段を全てを比較して決断する。

この繰り返しが大事なのだと。

ここに時間をかける事が
結果的に全体最適になるのだと。
つまり、不具合対応なども含めた開発期間が短縮される。

しかし、この時間による効果の測定はとても困難なのですよね…

LAMDAの活躍

Lean,TOCの活用を進めてきた中で、
開発現場では、LAMDAの活用が馴染みやすいようです。

LAMDAとは、Leanで活用する学習サイクルのツールです。

L：Look（いまどうなっているか）
A：Ask（分からない事は何か）
M：Model（解決案）
D：Discuss（解決案を議論する）
A：Action（議論した結果、実施するアクション）

LAMDAが知らなくても、
質問に答えれば記載出来るように
各チーム毎に質問を工夫した形でフォーマットを作成して活用しています。

その中で、2つばかりの例を、
久しぶりにSlideShareに公開しました。

調査業務や試作段階、など
不確定要素が多い状況やフェーズでの適用や
育成での活用が適しているようです。

テスト熱中症

限られた環境でフィードバックを得る事が難しい為、
今年からABテストを試行しています。

なかなかハマります。

ハマるのは、結果が分かり易いので
際限が無いというか、テストしたい事が積み重なっていく感じです。

ABテストで分かった事を活かす事よりも
次にテストしたい事に思考が奪われてしまいます。

私だけでしょうか…

これは、Unit Testのテスト熱中症と同じですよね。
こんな事になるとは全く想像していませんでした。

ただ、ABテストとしてはユーザー母数がある程度は必要なようですので、
このあたりを注意して結果を捉える必要はありますね。

このまま熱中して研究モードとならないように
ABテストについてももっと勉強しつつ
視野を広くして、成果に繋げなくては！

単純なものはハマり易いって事でしょうかね…

思込み設計からセットベース設計へ

最近、デザインパターンの議論がありました。

Aさんは、△というケースでは、Zパターンの設計が良い
Bさんは、△というケースでは、Zではなく、Yのような設計にすべき
といった議論でした。

こういった議論はとても大事ですね。

重要なのは、「Xというケースでは、Zパターンの設計」
の根拠かと。

設計はそのときの環境や状況にも左右されるので、
何を優先すべきかはケースバイケースとなります。

実現する機能面だけを見て、これがベスト！
というのも、もちろん大事ですが、
これは、ある意味で諸刃の剣となります。

それがいつ、いかなる時でも必ず良い！
と思い込んでしまう可能性も高い為です。
TOCでいうアサンプションですね。

私は思い込みが激しいという事もありますが、
自ら幅を狭くする事になってしまうので、
可能な限り複数の回答を持つように心掛けています…
#実際に出来ているかは別ですが…

△というケースでは、
XかYかZパターンの設計が良いといった感じで、
2つ以上の選択肢をもつ事で
状況や環境に応じて選ぶ事が可能となり、幅広がります。

複数の解決案を持つ事、これはいわゆるセットベース開発ですね。
決めつけるのではなく、複数の解決案を比較する事で、ベストの解決策を決める

自身の幅を広げる意味でも、
セットベース開発（この場合はセットベース設計？）は効果的ですね。

セットベース設計で幅を広げましょう！！

抽象化をツリーで表現してセットベース開発へ！

SWEST20参加で大きな収穫の1つ

抽象化を考えるツールとしてツリーを活用する！

フィーチャーモデルを活用したという事ですが、
形式に拘らず、単純にツリーで表現する事に意義がありそうです。

早速、社内でも演習を実施してみたところ、
ツリーとして出力する、見える化する事で、
考えがまとまっていく感じです。

という事で、
以下、ツリーで見える化（表現）する事の効果を5つほど紹介します。
（現時点で感じた事です）

1）自身の考え（抽象化）を整理する事に活用出来る
2）抽象化のポイントが分かり易い（クラス図より分かり易いかも？！）
3）考えをマネし易い
4) 横か縦かで決まる？
5）実装と概念の中間（ここがポイントかも？！）

5つを１つずつ説明します。

1）自身の考え（抽象化）を整理する事に活用出来る
　まずはツリーを書いてみる。
　そこから整理して、何度か書き直す事で
　視点を変えて見直す事で、気になる点、気にすべき点が見えてきます。
　ツリーという単純な図なので、
　どんなツールでも記載出来ますし、何度も書く気になります。
　考えを整理するのにお手軽なのに効果的です。

2）抽象化のポイントが分かり易い（クラス図より分かり易いかも？！）
　例えば2つの設計案をクラス図で作成した時に
　2つの違いを明確にするのって意外と難しい。
　ツリーだと誰にでも分かる。
　例えば、ツリーだとデザインパターンを知らない人にも
　抽象化のポイントが分かり易い。（と思う）
　そして、何より違いが分かり易い事は
　セットベース開発への可能性を感じました！
　セットベース開発にはツリーで設計案を比較すると効果的な気がします。
　（今後検証していきます！）

3）考えをマネし易い
　ツリーなので人のマネがし易い
　ベテランのツリーをマネて作成する事が出来る。
　自分で書く事で、考え方をマネする事にもなり、
　若手の育成にも効果がありそう
　クラス図をマネるのとは違う何かがある感じ。
　以降の5と関係するのかな？！

4) 横か縦かで決まる？
　大きくは、横に広がる形が抽象度が高くなる傾向かと
　下に深くなるのは抽象度が低くなる傾向かと。
　下に深くなる場合は、フローチャート思考というか、
　処理の順番を意識している事が多い気がします。

　ただし、単純に横に広げれば良いわけでは無いので、
　このあたりを整理出来ると、育成には効果を発揮しそうです。
　感覚的には、ただ横に広げている人とそうでない人は分かりますが、
　それを表現するのは難しい…（整理が必要なのです）
　
5）実装と概念の中間（ここがポイントかも？！）
　クラス図だと　 ”実装より”　か　”概念より”　かのどちらかになる気がしています。
　私自身は、これまで2つを必ず作成していましたが
　なかなか伝わらない事がほとんどでした。
　しかし、ツリーだと　”実装より”　にはなりません。
　”概念より”　になるかと思ったのですが、
　実際の機能名などをそのまま図に入れるので、
　概念とは違い、少し詳細化する感じです。
　なので、タイトル通り、実装と概念の中間な感じです。
　このあたりが抽象化を考えるポイントなのかもしれません。
　

素晴らしいQCストーリーとの出会い

先月、社内の技術発表会（改善含む）があり、
とても素晴らしいQCストーリー(A3)に出会いました。

何が素晴らしいかというと目標の決め方ですね！

1)目標設定の仕方が素晴らしい！
　分析内容はともかく、工数の多い作業を、ざっくり50％削減する
　という決め方がとても良いのです。
　と、いうのも、
　これまでのQCストーリー作成支援活動では、
　ざっくり決めるのは簡単なようで意外と難しいという印象だったので。
　決めるだけなので、簡単だと思うのですが
　支援活動の中では、ざっくり決めるてもらえないケースがほとんどでした。
　その前に数値化で前に進まないチームもかなりありましたが…

　ざっくり決めると、50％と大きく削減出来る事は何か？
　という視点で見るようになるので、
　このざっくり効果はとても大きいと思っています。
　
2)目標を更に細分化したのが素晴らしい！

　更に、作業を細分化し、どれかを50％削減する

といったブレークダウンしたのも、とても良いポイントだと思っています。
　全体の50％に拘るのでは無く、
　細部化した作業を50％でもOKとして
　改善を進めていたようで、これも、かなりのGoodポイントだと思います。
　
　細分化した作業が全て50％になれば、必然的に全体も50％になる筈ですからね。
　つまり、小さな成果を出しながら、大きな目標に向かう
　という進め方になっていますので、悪いわけがないですよね。
　アジャイル的でもあるし、
　小さな成功の積み重ねはチームのモチベーション向上には欠かせません。

これも意外と難しい。
　ついつい大きな目標達成についてのチャチャが入ったりするので…

3)対策もすぐに出来る事から実施したのが素晴らしい！
　すぐに出来る事といっても、
　数値で示せる効果がある事も当然条件に入っています。
　効果が高そうで、すぐに出来る事。
　この案を出すのが難しいところではありますが、
　これは、目標を50％と、ざっくりした数値にした結果、
　全員の視点がそこに向かったのでは無いか。
　もしくは、意思統一がし易くなったのでは無いか
　と思っています。
　余計な対策案が出ずに、全員が50％削減に向かった結果、
　このような対策案が出たのではないかと思います。　
　
なので、目標で全てが決まった！
と思う次第です。

脳の瞬発力

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

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

スポーツも同じだよね。

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

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

リラックスしている時、
ボーっとしている時、
風呂入って「あ¨ぁ～」って声が出る時、
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を作成する事が目的化していて、
チームにとっての価値を意識出来ていなかったですね。
今後はチームにとっての価値を強く意識していこうと思います。

開発で最も注力すべき事とは？

最近、TOC(Theory of Constraints)のフォーカスについて考えています。

TOCのフォーカス同様に
アジャイルでも「やらない事を決める」事が重要となります。

更には、そんな中で、設計はコンセプトが重要！
といった議論をする機会が偶然にも重なったりしました。

そんな事をもやもやと考えていると
「開発でフォーカスすべき事は何か？」
「ソフトウェア開発でもっとも集中すべき事は何か？」

が、気になり、考えています。

状況などにより変わる気もしますが、
共通な事がある気もします。

VUCAと言われる昨今、複雑で不確実な中で、
共通的な事など無い気もします。

しかし、実はとてもシンプルな気もしています。

などと、モヤモヤしていると、突然

「運転で大切なのは，
　車を正しい方向に進めることじゃないのよ．
　大切 なのは，常に注意を払って細かく左右に方向修正していくことなの．」

を思い出しました。
eXtreme Programmingの有名なメタファーですね。
集中すべき事は、このような事なのかもしれません。

その次に、
リーン製品開発方式の著者、アレンウォードさんの言葉も思い浮かびました。
「より良いやり方を永久に学び続けることにある」

3ヶ月後の状態を決める

A3(QCストーリー)を作成するのに、
3ヶ月で区切るのがいい
と紹介しました。

3ヶ月で区切る為には、3ヶ月後の目標を設定する必要があります。
その為、まず最初に実施する事が、
「3ヶ月後の目指す状態を決める」となります。

決める上でのポイントを３つ紹介します。

1)明らかなギャップを作る
　今は確実に無い状態、明らかに今より良い状態
　を設定します。
　今と変わらない状態を設定しても意味が無いので、
　明らかに今とは違う状態で、かつ、良い状態を設定します。

　しかも3ヶ月後です。

　この3ヶ月後が夢物語とならないリミッターとなります。
　3ヶ月後の状態となると、かなり現実的になります。

　目指したい事（希望）はあるが、現実的にどこを目指すか
　とか、
　変えたい事はあるけど、現実的にどこを目指すか
　といった現実的な悩みとなります。

2)曖昧でも状態でなくても決定とする
　最初からバチっと決まらないので、
　少し曖昧な設定で終わらせます。

　曖昧どころか状態ではなく手段が設定される事もありますが、
　最初から具体的な状態には出来ないです。
　また、具体的にすると時間もかかるので、
　曖昧でも何でも、なんとなくチームでの意識統一が出来たら終わらせます。
　そして、その後、「ふりかえり」ながら具体化します。

　いちおう、最後には「達成条件は？」と質問して、
　悩み出すので、少し悩んでもらって、
　「今後2週間毎にふりかえりながら、決めていきましょう！」
　という事で、その場はチェックアウトです。

　まれに、目指すものが無い（現状で良い状態である）
　という事もありますが、
　その場合は上位方針を持ち出すなどして設定してもらいました。　

3)フューチャーマッピングを利用する
　とはいえ、なかなか決められないチームが多いです。
　その為、最初は、ほぼ全チームでフューチャーマッピングを利用しました。
　
　3ヶ月後までの曲線に、架空の物語を作成します。
　線と物語により、時間の流れが意識出来るようになり、
　大よその状態を決める事が可能となります。
　
　フューチャーマッピングは、1時間くらいで作成出来ますので、
　1時間で大よその状態を決める事が可能となります。
　1時間楽しんで決まるので好評でした。
　1時間ただただ悩んで決まらない事を考えると、特に最初は効果的です。

A3の後半5項目

リーンの影響から
ソフトウェア開発でのA3（QCストーリー）を推進してきましたが、
作成するコツが少しだけ見えてきました。

前回は、前半4項目でしたが、今回は後半の5項目についてです。

5)分析
　1回目は必ずTOCのクラウドでアサンプションまで書き入れる事で
　分析としました。
　2回目以降は、データなどが蓄積されてデータ分析可能であれば
　グラフなどを活用した分析としました。
　データが無い場合は引き続きクラウドとしました。
　クラウドとする事で、問題意識が合い易くなった気がします。

6)対策案
　最初の3つのポイントの通り「やった事を記載します」ので
　ここには実際にやった事を記載します。
　実施していく中で、案として上がったけものは
　実際にやっていなくても全て記載します。
　
7)選択案と実施計画
　実際に実施した案と実際に実施した時期を計画として記載します。
　計画の粒度としては、1ヶ月単位から1週間くらいの大きな単位です。

8)結果
　目標に対する結果を記載します。
　ここのフォーマットがとても重要となります。

　目標に対する結果を記載するように工夫しないと
　ここにやった事を記載するチームがほとんどでした。
　対策案以外でやった事を記載していました。
　How思考の典型パターンとでも言えるでしょうか。
　改めて、How思考の強さを認識しました。

　目標が曖昧な場合は、結果は「判定不能」として、
　その他の成果として、今までと変わった事を中心に記載してもらいました。
　何かが変わっている筈なので、3ヶ月間で今までと何が変わったのかを質問して
　それを記載してもらいました。

9)フォローアップ
　新たな課題や次の注力点を記載します。
　3ヶ月が終了した時点で、次のA3のインプットとして考えている事を
　明記してもらいました。
　多くは、最初の3ヶ月では、目標を明確化（数値化）できず、
　判定不能となりますので、
　ここには、目標の明確化が記載される事が多くなります。

　しかし、それがA3化する事で、きちんと「ふりかえる」事が可能となり、
　次のA3で目標の明確化（数値化）をするチームが多くなります。
　この効果はとても大きいです。

全体的に、
状態としてとらえる事は必要と分かっていても難しい。
数値化については、そもそも不可能。
というアサンプションが多い印象です。
それを一緒に考えて完成させていく事になります。

必要以上に時間をかけても無駄なので、
お互いに納得出来ない場合は、指摘事項や考察事項を記入してFIXとしました。

A3の前半4項目

リーンの影響から
ソフトウェア開発でA3（QCストーリー）を推進してきましたが、
作成させるコツが少しだけ見えてきました。
前回の続きとなる9項目の記載内容についてです。

今回は前半の４つを紹介します。（後半の５つは次回で紹介します）
前半の４つがとても重要です。
主観や対策案の裏返しのような内容が入らないように
箱を埋めるようなフォーマットにしました。
　
しかしながら、それだけでうまくいく！なんてことはありません。
主観や対策案のような内容が入ることもありますが、
少なくともエビデンスが無い事を認識して、考えて記載しているようでしたので、
FIXした時には、エビデンスが必要な理由や効果を
改めて納得した人が多かったように感じています。　


1)表紙（テーマ）
　「内容や熱い思いがイメージできるように」
 　とにかく思いを書いてもらうようにしました。

2)背景
 　以下の３つの箱を埋めます。
 　A)プロジェクトや課題、問題の背景
 　B)自分達の思い、顧客の思い
 　C)テーマ選定の決め手

　ここにもエビデンスが必要なケースもありますが、
　ここは各自のレベルに応じて指摘し、
　エビデンスよりも思いを分かり易くする事に注力しました。

3)現状
　以下の３つの箱を埋めます。
　目指す姿に対する、LAMDAのLookとAskを記載するイメージです。
 　A)現在の状態（エビデンスを記載)
 　B)目指す状態
 　C)AとBのギャップに対するASK（分からない事など）

　「現状を事実と思いを分けて記載」と注意書きを入れましたが、
 　予想どおり、Aにはエビデンスが入りません。
 　そのため、チームやグループ外の人でも認識出来る事、認識している事
 　はエビデンスとして記載OKとしました。

4)目標
　以下の２つの箱を埋めます。
　A)長期的な目指す姿、上位方針
　B)大まかな指標値、方向性、目指す姿との関連

　Aは特に問題無いのですが、
　Bの指標値は、具体的にアドバイスしていく必要があります。
　最初は、いくつか提案して選んでもらうくらいが良いかもしれません。

　
残り5項目は次回紹介します

3ヶ月で区切る

リーンの影響から
ソフトウェア開発でA3（QCストーリー）を推進して3年が経ちました。

1年目は大惨敗でしたが、
ようやく作成させるコツが少しだけ見えてきました。

まずは、大きなポイントを3つほど紹介します。
ポイントは以下の3つです。

・3ヶ月で区切る

・パワポ9枚

・やった事を記載する

A3の記載内容についても、それぞれコツはありますが、

とっかかりとして、大きなポイントはこの3つかと思います。

記載内容のコツについては、次回以降で紹介します。

1)3ヶ月で区切る
　どんなに大きなテーマであっても必ず3ヶ月という期間で区切ります。

　A3を作成する単位はあくまで3ヶ月。これが最大のコツです。

大きなテーマを継続的に実施するのではなく、
　小さなテーマに分割して、3ヶ月毎単位で継続して実施していく感じです。　

　ソフトウェア開発だからなのか、受託だからなのか、原因はさておき、
　制御不可能な状況が変わってしまう事が多いので、
　3ヶ月くらいで区切るのが丁度良いです。

　3ヶ月単位で成果をまとめて「ふりかえる」のがポイントです。

　やった事ではなく、3ヶ月後の成果（状態）を「ふりかえる」のです。

2)パワポ9枚

　以下のタイトルでパワーポイント9スライドのひな形を作成します。

　ひな形を埋める形にします。

　プリンタの設定でA3に9枚印刷すると丁度良いです。

　１．表紙（テーマ）

　２．背景

　３．現状

　４．目標

　５．分析

　６．対策案

　７．選択案と実施計画

　８．結果

　９．フォローアップ

　分析でグラフなどがあるとスライドが1枚に収まらない場合もありますが、

　必要な事だけが簡潔にまとまっていればOKとしています。

3)やった事を記載する

　特に、最初の1回目は3ヶ月後に、3ヶ月間を「ふりかえる」かたちです。

　3ヶ月間の活動をまとめる感じでA3を作成します。

　3ヶ月前の事は比較的覚えているので思い出すのも楽です。

　3ヶ月間の成果をちょこちょこ残しておくのがポイントでもあるのですが、

　なにか残っていれば、それをキカッケに思い出す事が出来ます。

　そして、1回目でしっかりA3を作成するのがポイントです。

　ここでしっかりA3を作成すると、次の3ヶ月のA3作成は断然早くなります。

　そして、フォローアップの内容が次のA3へのインプットとなるので、

　これを繰り返していく事で、活動を実施しながらA3作成へと移行していきます。

という感じです。

次回は、記載内容について紹介します。

時間軸に並べる

How思考からの脱却の為に
ソフトウェア開発での状態定義を推進してきましたが、
どうしても状態ではなく手段となります。

手段の最後に「状態」を付けるだけ...

手段が既に頭にあるので、そこからなかなか離れないのでしょうね。

いろいろと模索していますが、
なかなか改善されません...

そんな中で、ちょっとだけ光が差した感触がありました。

時間軸に並べてみる
と、気づきを得るかもしれません。

時間軸で並べると、やった事より
起きた事を中心に組み立てて話をする傾向にあるようです。
ちょっとした実験の結果からの感触で、確証はありませんが...

もしかすると、行動も１つの事ではなく、複数の行動を時間軸で並べると
気づきが得られるかも？

模索は続きます。

自分の事は見えていない...

必要条件から因果関係への変換が難しい！

最近、ずっぽりとTOC漬けです。

先日、3つのクラウド（ジレンマ）からコアクラウドを作成し、
そこから、更に中核問題行動を導き出す！　筈でしたが、

一筋縄ではいかず、
かなりの回数、行ったり来たりを繰り返しています。

必要条件（コアクラウド）は完璧と思っていたのですが、
必要条件を因果関係にすると矛盾がある事に気づくのですから、
必要条件に矛盾があるという事になります。

つまり、必要条件は満たせていない...
自分の事は見えていないのだと痛感します。

一度矛盾が気になると、更なる深みに入ってしまう感じです。
見ようとしていないのか、決めつけているのか、
どうにもスッキリしない状態で、時間だけが過ぎていきます。
しかしながら、この考える時間がとても重要なのだと思います。

必要条件から因果関係にするだけで、矛盾が一目で分かる感覚は
ちょっとした不思議体験でした。
視点が変わるので、当たり前といえば当たり前ですが、
視点を変える難しさを感じずに簡単に出来る感じでしょうか。
想像以上の効果を体感出来ました。

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

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

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

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

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

と考えてみました。

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

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

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

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

曖昧な表現と事実とデバッグ

問題表現も改善成果の表現も事実を示す事が重要です。
ですが、なかなか事実が表現出来ません...

「多い」、「少ない」、「増える」、「減る」、「早く」、「遅い」
などは、当たり前ですが曖昧な表現ですね。

「多い」であれば、
具体的にどのくらい多いのかを明確に示す為に数値を入れる。
更に何に対して多いのかを明確にする。
こうする事で、誰もが同じ認識となる事実として表現される。

これも当たり前な事だとは思いますが、

意識しないと、問題提起や改善成果の表現は
ついつい曖昧な表現になってしまいます。

癖ですかね...

今は、2段階で変換しています。

まずは曖昧表現で見える化し、

自分で「具体的に！」とツッコミを入れて数値を入れる。

ソフトウェア開発（特に受託開発）では、

事実を意識する機会が少ないのが原因かと思っていたのですが、

考えてみると、デバッグ時は発生する環境や症状、その時の状態

など、事実を集めて原因を突き止めます。

つまり、事実を意識しています。

新人さんがベテランに「たまにエラーとなります」

などと報告すると、
「”たまに”ってどういう事？」
「エラーってどんなエラー？」
と突っ込まれる光景は良くありますよね。

まさに曖昧表現を無くすように指導していきます。

となると、ベテランは曖昧表現などしない筈！

ですが、問題表現となると別なようです。

私含めて、曖昧な表現だらけ....

なぜでしょうね？？？

なぜかは、分かりませんが、

癖では無く、出来る筈！　ですね。

繰り返しは簡単？

先日、FRT(未来構造ツリー）を作成していて、
繰り返す、継続する
といった事をFRTで、どのように表現するか？！

という議論になりました。

しかしながら、表現方法より、
本当に繰り返し？
本当に同じ事を継続するの？

繰り返しや継続で本当にDEが達成されるか
と、疑い始めました。

中間状態として明確に、ある指標や数値が確実に良くなる
繰り返し、継続であれば問題無いとも思うのですが、
ただ繰り返すだけで良くなる事って、あまり無い気もしています

繰り返す、継続する為の「何か」が常に必要な気がします。

実は、繰り返しているようで、繰り返していない。
継続しているようで、継続していない。
そんな事も多くありますよね。

FRTを見直す観点として、
徐々に、着実に良くなっていくツリーとなっている事
はポイントかもしれません。

ナラティブは未来を変える？

最近、ナラティブに関する記事や論文などを読んでみましたが、
未来に向かう感じがとてもしっくり来ています。

しかし、その一方で、ちょっと不思議な感じがします。

それは、ナラティブは過去を語るのですが、未来が変わる。

過去を語る事で、過去の出来事の意味づけが変わり、
意味づけが変わる事で、価値観が変わるので行動が変わり、未来が変わる。

とても納得するのですが、やっぱり不思議です。
過去を語るだけ！　なのに、未来が変わる！

という感じです。

語るだけ！ではなく、語る事による効果で未来が変わる
という事なのだと思うのですが、

その効果が分かり難く、見え難いものなので、
不思議感が払拭出来ない感じです。

どのように認識すると未来が変わるのか？！
どのように意味づけが変わると未来が変わるのか？！

実際にやってみないと分からない気がしますので、
試してみながら、平行して勉強していく必要がありそうです。