思考の海(2/100)　～アプリ系SE 五年目の今～

▼メリット
「育てていけるアプリ」ってコンセプト良いかなと思ったんやけど、BtoBを根幹としている自分の会社では少しズレた思考なのかもしれん。企業側のメリットがないもんな。手間なく、短期間かつローコストで効果を出すのが企業の情シスの役割であって、育てていくなんてちまちましたことをやっていく理由がないもんね。

▼リスク
そう考えると、育てるというのじゃなくて機能をカチカチと組み合わせられたら、余計な機能と費用がなくスッキリと出来るんじゃない？...あれ？そうするとこっち側のリスクが増えるかな？組み合わせるということはそれだけ部品をたくさん分割する前提の設計をするわけで。さらに、その接続時のテストも必要で、あらゆるエラーの可能性が新たに出てくる訳やし。保守や機能拡張の際も最初の設計段階であらゆる考慮がされてないと修正箇所がとんでもなく多くなりすぎて、担保出来んかも。

▼開発指向
今の会社に入って最初の研修で勉強をしたのはJavaを使ったオブジェクト指向のWebアプリケーションなんやけど、現場に配属になってからはVisualStudioのWindowsフォームアプリで、プログラム内にずらっと機能を盛り込んでいくような仕組みになっていたから、もはやオブジェクト指向に切り替える方がリスクになってしまってるよな。
例えば、自分が休んだ時や部署移動になったときでも、他人がそのソースを見てスピーディーに修正することができるっていう点で今までのやり方に倣うことが重視されてる。やからこそ20年間現状維持のままだったところもあるんよね。逆に発展せずとも20年そのままで食べていける仕組みを構築した先人はスゴいね。

▼分類
話戻るけど、今の職場で「コンセプト」を定義して仕事するという経験は今までなかった。現場にあるのは、お客様の課題とそれをどれだけローリスクに解決できるか、簡単にいうとソリューションを考えて提供することのみ。コンセプトを考える必要がないくらい、横展開だけで解決してたってのもあるんかな。それか自分が全部を雑多に混ぜてて、きちんと分類してないのかもしれない。どうやって分類していけば良いんだろう。