どこに時間をかけるか

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

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

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

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

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

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

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

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

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

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

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

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

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

LAMDAの活躍

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

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

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

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

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

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