たまに「人と余り関わらずに済む仕事の一覧」などにプログラマが含まれているのを見かけることがあります。もしかするとその部分に魅力を感じてプログラマを志望する人もいるかもしれないので、そんな方向けに実際はそうでもないという話をSIerの末端に５年ほど身を置いた人間として実体験を語らせてください。
「プログラマ」の業務内容
まず前提として、プログラマという肩書きの下に行う業務は場所によってかなりバラつきがあります。最も分かりやすい部分だと
- 詳細設計は自分でするのかどうか
- テストは自分でするのかどうか
などですね。ただ、今回は話を分かりやすくするために狭い意味でのプログラマ、つまり「コードを書くことが仕事」の場合について考えてみたいと思います。実際、業界の外の人だとプログラマに対するイメージはこんな感じじゃないでしょうか？
プログラマが人と関わる必要性
では、ここから本題で「コードを書くのが仕事なのになぜ人と関わる場面が出てくるのか？」という部分を見ていきたいと思います。
詳細設計→コーディング
理由の１つはプログラマの業務が設計書をもとにプログラム製作を行うという性質を持つことにポイントがあります。見ただけで完璧に設計者の意図を組んだプログラムが完成するような設計書であれば特に問題はないですが、実際はそのようなことは稀です。事前に対面での説明があっても、コーディングに着手して初めて気付く疑問点もあるものですし、その場で全ての疑問点を解決することは難しいです。
したがって、設計書を見ても分からない部分は設計者に問い合わせる必要性が出てきます。内部のメンバーだけで解決できればまだ簡単ですが、時には部署を跨いでのコミュニケーションも必要になるでしょう。連絡系統が整備されていなかったりすると、全く面識のない人たちの間を色々とたらい回しにされることも。
「人と関わりたくないからプログラマになりたかったのに！」という人にとってはこういうやり取りは結構ストレスになるのではないでしょうか。
コーディング→テスト
続いて、完成したプログラムの動作確認（テスト）を別の担当に依頼する場合です。テストの手順書やテストケースなどを作成して担当者に依頼する形式がオーソドックスですが、これも詳細設計→コーディングの流れと同じでテスト担当者からなんらかの質問が返ってくるケースが多いです。
特にテスト専門で行っている人の中にはプログラミングの知識がない人もいたりするので、場合によっては同じレベル感での説明ができずに意図を伝えるのに苦労することも。これもまた相手の立場に立ったコミュニケーションが求められるという意味で「自分はプログラミングだけをしていたい」という人にとっては苦手とする部分かもしれません。
レビュー
上記のコーディング→テストと順番が前後しますが、自分が製作したプログラムがなんの審査もなく次の工程へ進むことは通常あり得ません。有識者によるレビューが行われるのが一般的です。
- （他にも色々な書き方があるのに）なぜこの実装にしたのか？
- コーディング規約は順守しているか？
- 条件は網羅されているか？
など、レビューで見られるポイントは多岐に渡りますが、「これでリリースしても問題ないですよ！」ということを論理的に説明しなければなりません。ここでもまたコミュニケーションが求められるわけです。
バグ対応
最後にもう１つ。テスト工程、あるいは悪ければさらに後の工程で自分の製作したプログラムにバグが見つかることも往々にしてあります。その場合も自分のもとに「〇〇の条件で××という操作をしたらバグが発生します。原因を調査してください」と言った具合で依頼が来るので、原因を特定→プログラムを修正→テスト再実施→再発防止策の検討といった工程を踏まなければなりません。
特に再発防止策、つまり「なぜこのようなバグを作り込んでしまったのか？どうしたら今後同じミスを防げるか？」という点は厳しく追及される傾向にあるので、これまた相手を納得させるためのコミュニケーションを取る必要があります。
多職種との比較
と言うわけで、ざっとここまでの話だけでもプログラマが意外と人と関わる必要があるということがお分かりいただけると思います。
ただ、僕は以前営業の仕事をしていたこともあるのですが、さすがに営業に比べると人と関わる機会は少なくて済みます。ここまで色々書きましたけど、「一日中パソコンに向かってコーディングしていて誰とも話さなかった」なんて日もあったりしますしね。
その他の人と関わる量を左右するポイント
他に人と関わる量を左右するポイントとして開発するシステムの規模があります。例えば規模の小さいシステムを何度も開発していくような業務形式だった場合、必然的に上記の「設計→コーディング→レビュー→テスト」の流れを回す回数が増えるので人との関わりも多くなります。一方、大規模なシステム開発だと数か月単位で工数がとられたりして、その間ひたすらコーディングを続けるということもあったりします。もちろん、それはそれで経過報告などで人と関わる機会は発生してきますけどね。
他には人と関わる範囲にも段階があります。「人と関わりたくないけど、身近な人間とだけならまあいいかな」なんて考えもあるかと思いますが、プログラマもチーム内だけの関係で完結する場合もあれば、内部の人間だけど普段全く面識のないお偉いさんと関わらなければならない場合もありますし、もっと言えばユーザーさんと直接やり取りするケースだってありえます。人と関わりたくないという思いが強い場合はこの「人と関わる範囲」によってもかなりストレスの度合いが変わってくるので気にしておくといいかもしれません（なかなか自分でコントロールできる部分ではないですが）
さいごに
以上、「プログラマが人と関わらなくて済む仕事ならなってみたい」という人向けにプログラマの人との関わり方について語らせていただきました。「多職種と比べて特別人と関わる機会が多いわけではないが、それなりに機会はある」というのが個人的な認識です。
もちろん、これがプログラマの全てではありません。あくまで末端SIerとして働いている僕の一体験談として捉えてください。何か１つでも参考になるポイントがあれば幸いです。
