ファーストインプレッションが覆された時、何をするかで能力の高さが決まる | 熱脳しゃちょのブログ

熱脳しゃちょのブログ

おせっかい焼SE兼プログラマ兼……の辛い日々と、思う事なぞ

なぜ「ウォーターフォールからアジャイルに」と言われるか理解しないで「うちはアジャイルでやってます(ドヤ」ってるところが多いような気がする(まぁ、炎上現場スキーなので、偏ってるかもしれん w)。

アジャイルでやってるのに、当初設計のまま突き進み、詰んだタスクの消化しか考えてなくて、どんどん追い詰められてるプロジェクトが多い。

自分の経験だけじゃなく、現場で出会ったエンジニアの過去の話聞いても、なのだが。


昔に比べて、時代の進み方も激しいし、利用者の幅も広いし、システム自体が巨大になった。

コードベースという意味もあるが、関係する端末数の多さという点でも、巨大になっている。

当初見込みで全てを正しく見通せる人間は、もう存在しないんじゃないかな?

当初想定された利用者像と、実際の利用者は別物なので、ちょっと使ってみたら「ああ、違うな」と感じることは、多い。

内部構造だって、「これなら結局こうすればいいんじゃないか?」となることは多い。

というか、それがないプロダクトは、よほどクローズドなものでない限り、ないと思う。

そんなことないというプロダクトがあるとしたら、現実把握能力とか感性とか知力とかが決定的に欠如しているだけです、と断言していいのではないだろうか?

 

当初予定のままスプリントをこなすっていうのは、単にウォーターフォールを細切れにしているに過ぎない。

細切れにすれば進行度の測定がより正確になるのではないか? と思ったら大間違い。

まず、トヨタがカンバンを導入するきっかけになった、各工程のマージンが、より大きな影響を与えるようになり、進行が遅れます。

また、細切れにしてDoneになった項目に再度手を入れることが困難になり、取り返しのつかないレベルまでプロジェクトが進んでから、仕切り直すかどうかの鬱陶しくて長い会議を開く羽目になります。

仕切り直せば締切と予算の問題が、仕切り直さなければ品質と利用者の満足度の問題がのしかかってきます。

ダメなものは仕切り直すしかないのに、そのままGOして利用者の不満を高め、離脱を加速させ、結局マネタイズ失敗、追加出資のためにできもしない機能をぶち上げて、うんこプロダクトのうんこ化を加速させ、さらに利用者の離脱を招いて金銭的苦境に陥る、と(心当たりある人、おおかろ? w)。

 

このファーストインプレッションが覆された時、間髪入れず見直すということができるかできないかというのは、そのプロダクトの今後を決定的に左右する重要な要素の一つです。

そしてエンジニアは、コードを整形して整えることができる人より、それができる人の方が数段能力が高いのです。