どこに時間をかけるか

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

他の事をしながらではありますが、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を結びつけた時ですよね。

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

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