IT企業に入って驚いたこと(その1)

はじめに

IT企業と聞くとどんなことをしているイメージですか？
WEBサイトを作ったり、アプリを作ったり、AIだったりいろいろあると思います。今回はそんなIT企業に技術職（いわゆるプログラマー）として就職した私が、「え？そうなの？」と驚いたことを書いてみます。

1.全然プログラミングしない

色んなイメージを持たれがちなIT企業ですが、そのどれもに共通しているのはプログラミングをしているということでは無いでしょうか？

システムにしても、アプリにしても、WEBサイトにしても、DX化やデータベース、クラウドの運用や組み込み、セキュリティ運用どれもプログラミングを用います。私はコーディングという表現の方がよく使うので、以降はプログラミングの中身をコード、プログラミングすることをコーディングということにします。

え？それでプログラミング(コーディング)しないってどう言うこと？って思いますよね。これって何も
「IT業界は既にAIがコーディングするから人が必要ない！」
とかそう言う理由じゃ無いんですよね。

この話をちゃんとしようとすると、システムやアプリなんかの製造ライフサイクルを説明しなければなりませんので、今回は割愛します。

ざっくり説明すると、実際にプログラミングをするのは開発工程の中だと割と後半で、それ以外の工程では実際のコードの何倍もの文章書いています。

会社のスタイルやプロジェクトにも寄りますが、ガリガリコーディングをしているのは平均して年間で2ヶ月ほどと言われているようです。

わろた

2.脳内デバッグがメイン

何を言っているのか分からないかもしれません。私も最初は冗談だと思いました。

プログラミング言語を少しでも触ったことがある人であれば、書いてみたものを実際に動かしてみて、エラーや不具合を確かめるデバッグ作業にも馴染みがあるかと思います。

それを「実行せずに人力でやろう」というのが脳内デバッグです。正気かな？

とんでもなく非効率で効果的に思えないこの脳内デバッグですが、ちゃんと合理的な理由があるんです。

主に関係するのは
１．契約的な問題
２．環境的な問題
の二点だと思います。

1.契約的な問題は文字通り契約上の都合です。実際の製造ライフサイクルでは、顧客から依頼されたものは実際にコーディングする前にすべての仕様や構造が決まっている必要がある場合が多いです。
「こんなものを作るから金額はこのくらい貰いますよ」
みたいなお話しを進めるためにも、実際に作り出してから「やっぱこういう機能も欲しい」のような仕様変更をさせないためにも、あらかじめ作るものが決まっていることは双方にとって重要なのです。

この「あらかじめ決めておく」が結構えぐいレベルで、決めた内容をまとめた文書を作成するのですが、それは「誰が見ても同じコードを書く」レベルで詳細に記述されることになっています。

その結果、書く内容を考えている時点ではパソコンにコードを書き起こすわけではないので、脳内デバッグ以外やりようがなくなってしまうのです。

2.環境的な問題は、普段パソコンでコーディングをして、実行しているというイメージがある人にとっては盲点かもしれません。ただ、考えてみればプログラミングを使う製品ってなにもパソコンだけではないんですよね。

何ならパソコンでも、内部の基盤などの部品やBIOSやOSの深いところなんかを作る際には
「実行して結果を画面に表示」
みたいなことは簡単にはできないこともあります。自動車や電化製品の組み込み系(ブレーキペダルを踏んだらブレーキを掛けるとか、電子レンジの扉を開けた加熱を止めるなどの制御をするようなもの)なんかだと、製品がまだ完成していない or していても実験設備を整えないと動作確認ができないなんてこともありえます。これも必然的に脳内デバッグが必須になるわけです。

まぁもっと言えば、これらの問題がなくともレビューという工程ではプロジェクトメンバー全員が脳内デバッグをして問題点を探るという儀式があるので、ほぼ全ての製品に対して脳内デバッグは必須と言っても差し支えないように思います。

さいごに

長くなったのでいったん区切りますが、書きたいことが山ほどあって、中にはプログラマーではない人にこそ知ってほしいこともチラホラあるのでなんとかまとめてみたいと思います。

ここまで読んでいただいてありがとうございます。お疲れさまでした。