コードを書かないという決断

でも、果たしてここでコードを書くことが本当に正解なんでしょうか？
たしかに正解かもしれないです。
ただそれでも正解なのかどうかを検証するステップは確実に必要です。

上記のエクセル作業を簡単にするという話で、よくよく話を聞いてみると「その3万行のエクセルはマーケティング部門が独自に管理しているもので営業部門で使ってるKintoneにだいたい同じ情報が入ってるからそれを見ればOKだった」とか、その作業不要だよねってケースは本当によくあります。

ソフトウェアエンジニアである前に我々はビジネスマンであり、会社に所属しているのであれば利益をどう出すかということにコミットするべきです。
多少論理は飛躍しますが、要するに無駄な作業は日々徹底的に排除すべきです。

話は変わりますが、会社という組織において最もコストを占めるのはほとんど場合は人件費です。
そして人件費の中でソフトウェアエンジニアというのは平均的に最も人件費がかかる職種です。
そんなソフトウェアエンジニアは、多くの場合自社プロダクトとか最も会社の主力となる製品に力を注ぐべきで、普段の瑣末な作業に時間を割くのは賢明ではないでしょう。

上記の3万行エクセル問題に話を戻すと、もしこれをソフトウェアエンジニアが解決するにしてもそのソリューションはなるべく軽いものであるべきです。
社内のお困りごと解決のために作ったツールなんて1年もすればだいたい使われなくなっていたり要求が変わっているのでメンテが超大変か不要になるかの2択です。
そういったことを考えると最初から自前でAWSでECSを作る必要なんてなくて、Power AutomateとかGASとかでパパッと作れるならそれで良いのです。

なんならKintoneとかZapierみたいなSaaSでも良いです。
ノーコードツールというのは営業とかビジネスサイドだけでなくエンジニアも幸せにします。

今回話した3万行エクセル問題にぶつかったとき、そこで真っ先のプロダクトを作り始めず「なぜこれを作る必要があるのか」を検証できるエンジニアこそシニアエンジニアたり得るのではないかなと考えています。

僕はK Squadという技術顧問を主要事業とした企業をやっていてアドバイザーとかPMみたいな動き方をすることが多く、その結果「本当にそれやる必要あるの？」と問わなければいけない場面というのに多く遭遇します。

問題解決こそエンジニアの仕事ではありますが、その問題解決にとれるアプローチをプログラミングを含めてなるべくたくさん持っておき、そのアプローチにエゴを排して優先順序をつけず一つ一つ平等に検討していく、これこそ優秀な人材と言えるでしょう。

急いでプログラミングしない、これはとても大切なことです。

以下、お知らせです。

今後はK Squadの普段の活動の中で得た知見をどんどん発信していこうということでウェビナーをどんどん実施していきます。

第一弾は3月6日(水)の12:00-13:00です。

是非とも気軽にご相談ください。