プログラマで一番難しいことは設計だよね

Share on:

プログラマとして働き初めて 4 ヶ月がすぎました。
いろんな知識が付いてきて、これのやり方がわからない!ということはかなり少なくなってきたし、こんなことがやりたい!と言われた時にそもそもできるのかどうかということまで考えられるようになってきました。
 
しかし、何かが足りない
できる先輩プログラマと比べて何かが足りないのです。
コードレビューをしていても、こんなロジック思い浮かばないし。
と思うようなことがたくさんあるし、どうやったらこんなところまで
頭が回るのかと思うこともあります。
 
何が足りないのかというと、圧倒的に設計力だと思っています。
設計がしっかりしていれば、初心者でも簡単にこなすことができる仕事だと思っています。
3 ヶ月間はすでに課題になっていたものをただこなしていただけですが、4 ヶ月も経つと全ての課題が入社後の生み出されたものに置きかわります。
ということは課題設計の段階から考えていかなければならないということです。
 
これまで、課題を決めるときには技術的に可能かどうかという部分に焦点を絞ってきましたが、それだけでは足りず、他にも考えるべきことがたくさんあることに気がつきました。
まず 1 つ目に

簡単にできるかどうか

できるエンジニアができるのは、簡単なことしかやらないからです。
難しい課題を出されても、「これはこうした方が良いよ」とアドバイスを出しながら、自分の都合の良い方向に持っていきます。
これができれば、課題を出す側も納得できるし、開発するエンジニアも楽することができるという win-win な関係に持っていくことができます。
 

運用ができるかどうか

その課題が今後どのように修正されるかを予想し、その時に楽することができるように課題設定をします。
そうすることで、実装自体も楽になることが多いですし、後々の課題にも対応しやすくなります。
ただ機能ができれば良いということではありません。
 

自分にできるかどうか

google のアルゴリズムが欲しいと言われたら、どうしますか?
google がやっているのだから技術的には可能に決まっていますが、自分自身にできなければ OK を出すべきではありませんね。
これは極端な例でしたが、やはり難しくなりそうだなと思う課題はなるべくシンプルな設計にするよう心がけるべきです。
OK することでステップアップする方法もありますが、それは仕事ではなく、自分の勉強でやるべきだと思います。
 

まとめ

プログラマだからコードが書ければ良いというわけではありません。
自分が今どんなことができるかを把握し、それに沿った提案、受注をしないとお互いに苦しい思いをしてしまいます。
もちろん日頃から勉強をして、できる分野を増やすことは必要ですが、それでもできない部分が出てきた時にどのように対応するのかが重要です。
特に交渉相手がエンジニアではない場合は、技術的な面だけでなく、ビジネス面でも先を見据えた提案ができるのがベストです。
最近、次のステップアップをするためには何が足りないのかを整理したかったので今回まとめてみました。