職業ITエンジニアの在り方 Jan 2022

職業ITエンジニアの在り方 Jan 2022

エンジニアリング(特にプログラミング)に対する意見は人それぞれで異なると思います．この記事ではITエンジニアとしてどうあるべきか，現時点の私の考えをまとめています．

ITエンジニアという職業

ITエンジニアという職業はプログラミングができれば誰でもなれるかというと，そうではありません．どの職業にも適正というものがあるでしょう．私はエンジニアという職業はクリエイター職だと考えています．歴史を紐解けば昔はコンピュータというものは個人で買えるほど安くなく，設置するための場所を取り，プログラムを実行するにはコードを実行するための順番待ちが発生するような代物でした．当然専門職ではありますが，クリエイター職という印象はなかったのではないかと思います．ところが現代ではその当時の性能を遥かに凌駕するコンピュータが1万円^[1]もしません．コンピュータは個人で店頭に行けば手に入る代物であり，プログラミングが教育の必修科目になるようにプログラミングという行為は特別なものではなくなりました．誰でもできるものになったのです．しかし，紙とペンを渡せば誰でも絵描きになれるのでしょうか?紙とペンがあれば誰でも絵を描くことができます．しかし，それを職業にしている人は少ないでしょう．今やコンピュータがあれば誰でもプログラミングはできます．

アマチュアとプロの境界

誰でもプログラムを書くことができる時代において，アマチュアとプロの境界は「保守・運用」を行うかどうかにあります．業務のプログラムというのは一度作れば良いというものではなく，継続して改修を加える必要が生じます．個人的にプログラムを書く場合，一度きりしか実行しない，もしくは一度作ってしまえばほとんど変更を加える必要がないものがほとんどではないでしょうか?しかし業務となれば話は別です．「保守・運用」のことを全く考慮せずに作られたプログラムを「保守・運用」することになった悲劇や，「保守・運用」を全く考慮しない人が入ってきた結果生じた悲劇というのは業界にいる人は一度でも聞いたことがあるのではないでしょうか?プロとしてプログラムを書くのであれば常に「保守・運用」について考えるべきです．そしてそのための試行錯誤を惜しむべきではありません．なぜならエンジニアとはクリエイターであり，自身の作品(システム)に対して責任を持つべきだからです．それが辛いのであれば，職業エンジニアになるのは向いていないかもしれません．

コードの品質

品質の良いコードとは「保守・運用」のしやすいコードです．「保守・運用」しやすいコードとは何か?を学びたいのであれば，「クリーンアーキテクチャ」「ドメイン駆動設計」「テスト駆動設計」について学ぶべきです．プログラムにおける設計の正しさというのはその時々で異なります．ITエンジニアとしてその時々でどれが正しい選択となり得るか判断できるだけの知識を身につけるべきです．そして当然知っているだけでは仕事はできません．実際に実践してみるべきです．業務時間内に実践する余裕がないのであれば，業務時間外でも実践するべきです．これは業務時間外に業務をやれと言っているのではありません．何度も言いますが，エンジニアはクリエイター職です．ピアニストが休日にピアノを弾いていようと絵描きが休日に絵を描いていようと当然と思う人が大半ではないでしょうか?エンジニアも反復練習を繰り返し知識・技術を身につけるべきです．特に「テストコードと実際のコードを同時進行で書く」ということは慣れておくべきです．これは品質に直結します．もし書いているコードが完成しないとテストが書けないのであればそれは設計が間違っています．プログラムは機能毎，文脈毎に分割されているべきであり，それぞれにテストコードが書かれているべきです．テストコードは単にその機能が正しいことを保証するだけにとどまりません．テストはプログラムが完成していなくても実行できるのです．つまり最後まで作りきっていなくともテストすることができます．これは「最後まで作ってから動きませんでした」といった事態を回避するのに非常に有効です．エンジニアは常にテストコードを書くべきです．

何を設計するべきか

エンジニアはプログラムを書く前に何を設計するべきでしょうか?私は「インターフェース」を設計すべきと考えています．インターフェースとは，物事の境界です．画面はエンドユーザにとってのインターフェースになりますし，REST APIはエンジニアにとってのインターフェースとなります．実装に入る前段階でどういったプログラムを書くべきかまでを設計することは時間の無駄でしかありません．そこを設計(デザイン)するのは実装を担当するエンジニアの責務です．故にエンジニアは設計思想について知っているべきであり，それを実現するための技術を身につけているべきです．そのための自己研鑽を怠ってはなりません．

組織の在り方

コードの品質はエンジニア(実装者)が担保するべきです．もし「私の責務は素早く実装することであり，品質はQAチームが担保してくれる」と考えているのであればそれは間違っています．エンジニアは自分が書いたコードの品質を保証するべく努めるべきです．QAと開発の距離が大きくかけ離れている状態というのは不健全な状態でしょう．そして営業と開発の距離がかけ離れているのも問題があります．プロダクトマネージャーという言葉があるように，組織はプロダクトを中心に語ることができるべきであり，それぞれの職種がその職種の責務しか語らずプロダクトのあり方を考えない状況は不健全でしかありません．

現実と理想の乖離

理想を語られても現実はそうじゃないと思うでしょう．それはもっともな意見ですが，理想をまず知るべきです．そして現状を把握し，理想との乖離を埋める努力をするべきです．現状に満足して理想を目指さないのは不健全でしかありません．一度に理想に近づく必要はなく，組織や個人のできるペースで理想を目指しましょう．現状に対して文句を言うことは誰でも出来ます．文句をいうだけに留まるべきではないです．

脚注

1. ここでは Raspberry Pi を指しています．