EBt リリース反省会

遅れに遅れております

うん、EBt のリリースが遅れに遅れております。理由はいくつかある。で、それらについて個別に書いても仕方が無いので書かない。
そうじゃ無くって、もっと大きな枠で書きたい。これが今回のテーマ。

トラブルが起きるところ

結局は、トラブルって先送りにしたところとか、これぐらいでいいよね？って妥協したところで起きる。そんな印象がある。
今回のリリースが遅れまくった原因のトラブルは根っこはここに行き着くのですよ。

サーバーに同時に接続する EBt なんかそんなに多くないはずだから大丈夫。
同じリクエストが何回かとんでも時間経過で何とかなるはずだから大丈夫。
多少時間がかかるかもしれないが、そんなに遅くはならないはずだから大丈夫。

いや、全部大丈夫じゃなかったよね。で、全部直したよね。だからリリースも遅れたよね。

なんで大丈夫って判断なんかしたのか？

多分、時間が無い。あと、本筋とはちょっと外れている（＝その時には動けば良いと思っている）ってのもある。
つまり、判断したときの課題の優先度と、トラブルが起きたときの課題脳油尖度が全く違うわけです。
背景が異なるので、当然優先度の考え方が変わる。結果、訳のわからない判断を元に動いた結果の割を食う。

自業自得なので、余計に辛いのですよ。

でも、それだけじゃない。

人間の判断って、結構曖昧。状況に合わせて臨機応変に判断していると言えば聞こえは良いが、臨機応変ということは軸が定まっていないということ。
判断の軸を定めないと、その軸のブレが思わぬところで影響を与えてしまう。そういうことなのです。
でも、軸を定めることは難しい。そのためのツールはいくつもあるし、それにしたがってやれば良いと言われるのは重々承知している。

でもね。

それに従っていると、いつまでたってもプロダクトは完成しないのですよ。

100%を求めてはいけない

根っこはこれ。軸を定めてそれに従って判断する＝その軸を100%満たすような判断をするということになりがちです。
もちろん、重要度をスコアリングしてどこからやろうか？ってことはアジャイルでもやられている。アジャイルは、そもそも早くだすことを目指しているから良い。
この時の軸は？って考えると悩むけど、アジャイルの軸は「まず動くものを短期間でリリースする」ですよね。だから、別に問題ないんです。

そして、先頭に戻る。私の判断も実は同じなんですよ。機能に優先度をつけて対応しているだけ。そして、優先度が低かったものが問題を起こしただけ。
別に、アジャイルでやっているときにも同じ問題は当然起こりうるし起こる。

でも、アジャイルでこれは特に問題として出てこないのに私は問題として考えている。そこに大きな違いがあるわけです。

問題は人数?

そう、人数なんですよ。私は一人で開発をしている。だから、後回しにした機能を作ってくれる別の人なんか当然いない。
チームだったら問題なく解決できることであっても、一人で開発していると解決はいきなり困難になる。
結局、一人で開発しちゃいかんのか？と言う気分になる。

別に一人でも良いとは思う

これは、一人で開発しちゃダメという結論に繋げたくなると思うけどお、そういうことではない。
別に一人で開発しても良い。問題は、一人の時は安全係数をチームの時に比べてかなり高く設定しないといけないということだ。
そして、一人だと、ついつい「大きな修正を忌避する」ような判断をしてしまう。これが非常に良くない。
今回の問題は軸が定まっていないという問題もあるけど、更に掘っていくと「一人だからできるだけ短い時間で解決したい」といいう良くない思考が見え隠れしているのですよ。

だからこそ

一人で開発するのは辛いのです。安全係数を大きくするのは勇気が必要です。一人で開発するという決断だって結構勇気が要るのに、更に勇気を積み上げないといけないのです。もう、しんどいよね。
でも、たとえそうだとしても、一人で開発するという判断をしたのであれば、受け入れないといけません。

というわけで

EBt の開発は本気で一人でやっているし、なんだったら他のツール開発と並行しているから開発スピード的にはかなりの限界があります。
私の月あたりの開発ステップ数は多分1万超えているんですけど（計算するのが面倒くさいからやっていない）、そんなもの何の足しにもならない。
せっかくだから、EBt のコード量を Visual Studio で調べたら10万行あったよね。実行可能コードの量は2.8万弱だったけど。毎日開発しているわけでもないからなぁ。10ヶ月=200日で考えると、10万行/200日 = 500行/1日。コメントとか外すと、もっと少なく140行/1日。あれ、こんなに少ないのか。なんか悲しくなってきた。もっと書いているつもりだったのに。
※まぁ、1ヶ月20日も開発できてないけど。

にしても、このリアルな数字を見ると、1000行ぐらい書かないといけない修正をやろうと思うとそれだけで丸々二日潰れるってことになる。そりゃ、二の足踏むよね…一人だから短縮なんて出来ないし。

時間の余裕が必要

というわけで、判断を鈍らせる原因はどうにも短縮できない時間です。どの開発でも一緒ですね。
時間の余裕があれば良いシステムが作れるのに。

ただ、時間の余裕があるとサボる人たちがいるので、世の中ままなりませんね…

あぁ、時間が欲しい。今日の結論はここ。