どこに時間をかけるか

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

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

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

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

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

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

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

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

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

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

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

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

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

クラウドは強力だ！

最近、

TOCのクラウドの作成体験をしてもらう活動を始めました。
しかも30分くらいで。

これが想像以上に好評です。

時間が無さすぎる！
じっくり考えらない！
という反感も覚悟していたのですが、
これまで体験した全員が楽しかった！
という反応でした。

ソフトウェア開発を生業としている人は、
想像以上に考えるのが好き？！
現状の開発現場で考える時間が無さすぎるから、
その反響！？

などと妄想しています。

体験の冒頭は、いちおうTOCとクラウドの説明をざっとします。
（ジョナを持っている訳ではありませんが...）

クラウドの説明を何度もしていると、
クラウドの凄さ、強力さをひしひしと感じます。
実際に使う時より、説明する時の方が強く感じる気がします。

ただの5つの箱ですが、この1つ1つはとても強力です。
全体最適に向かう、第一歩であり、
シンプルに本質を捉える、とても強力な図ですね。
改めて、もっと活用していこうと思う、今日この頃です。