プログラマはプログラミングをしていないという現実 ＠ A-Listers
書いてあることが当てはまりすぎて笑ってしまった。
SIerからソフトウェアベンダ、企業内の社内情報システム部門まで多くのプログラマには上記に書かれていることが当てはまる人は多いかと思います。
個人的には、本当にプログラミング（または特定の技術分野としてのエンジニア）だけをしたいのであれば、ラボや研究機関といったところに入らないと無理なんじゃないかと思ったりします。
プログラマの仕事の現実
プログラマがプログラミング以外の仕事をしなければならないのは、入り組んだ技術の話はプログラマでしかわからないことが多いからです。
営業やプロマネは顧客との要件を決められても、内部仕様についてはプログラマやアーキテクトにお任せということになりますし、顧客との話のネタになるのはその内部仕様に言及することが多くあったりします。
技術営業という肩書きでエンジニアが営業に同行して顧客企業まで足を運び説明や質問に回答するということはよくありますし、ユーザーからの問い合わせもヘルプデスクやサービスデスクにそのソリューションがあればそこで返答できるものも多いでしょうが、数多く寄せられる問い合わせの中ではそのストックしたソリューションから解決できないものも多々出てきて、プログラマなど実際にそれを構築して仕様を熟知するメンバーエスカレーションされることになります。
特にシステムトラブルともなると、その原因の追究やログの捜査やトラブル報告書の作成に多くの時間をとられたりします。
まぁ、これはプログラマ自身が出したバグということなので身から出た錆ともいえるでしょうが、運用上のトラブルということになると、その操作方法や機能の不備ということも指摘されたりして、それを回避・解決するための案を出すことにもなったりします。
そして、その機能を改善することへの既存のシステムへの影響調査や工数の算出などプログラミングとはかけ離れたしごとをする羽目になったりもします。
まぁ、この辺はシステムのライフサイクルと共存するエンジニアの仕事のあり方による影響が多いのかもしれません。
要は本来プログラミングをするというのは開発フェーズでの話ですけど、システムを構築していくには設計やテストといった工程もあり、全体を見渡せば開発フェーズに割く時間というのはそれほど多くありません。
そして、なによりも開発期間よりも保守・運用のフェーズに当たる期間の方がはるかに長くなるわけです。
システムを無事にリリースして、次のプロジェクトへ移行したとしても前のプロジェクトの保守の中で出てきた課題や問い合わせへの対応というのは多く発生し、プログラマの本来の仕事の妨げともなっています。
ただ、プログラマという仕事がプログラミングだけしているというのは、結構昔のイメージで今はシステムの形態とともにその仕事の範囲や役割というものも拡大してきているのだと思ったりもします。
その他のプログラマのお仕事
先のサイトで書いてある16の項目以外に、個人的にプログラマの仕事してあるのは下記のようなものがあったりします。
- バグ再現のための試行
ユーザーからの問い合わせは、何もすぐに判断できるようなものばかりではありません。
そのようなものはテスト段階で数多く潰せるので、むしろリリース後に問い合わせがあるのはユーザー環境によるものだったり、特定の入力条件や操作条件に合致した場合など、レアケースのものの方が多かったりします。
それらについて、わかりやすい表現で問い合わせされることもまた稀で、数少ない情報からそのバグが再現しないかと試行錯誤したりします。
多くは開発・テスト環境というものが存在するでしょうが、そこに実際に入力したデータを投入してみたり、本番環境から移行してみたりと、その準備のためにも多くの時間がとられたりもします。
まぁ、どうしてもわからない場合は、「システムの調子が悪かったので、もう一度やり直してもらえますか」とか、お茶を濁して逃げることもあったりしますがね・・・。
- 開発メンバーへの教育やレビュー
これはエンジニアに限った話ではないでしょうけど、他のメンバーへの教育にも多くの時間を取られます。
チームをリードする立場だったり、アーキテクトの役割を担った場合は、使用するフレームワークや開発環境、コード標準の書き方などの開発規則を周知・教育するのにも時間をとられるでしょう。
それらを確認するためにコードレビューをすることも多くなりますし、開発ライブラリの利用方法を書くにするためにサンプルのソースコードを読んだりすることにも時間がかかります。
ひどい場合はソースを書く時間よりソースを読む時間の方が長いということもあるかもしれません。
- システムへの影響調査
先にも書きましたがシステムへ改修を加える場合は、まず現在運用しているシステムへの影響調査というものをさせられることが多かったりします。
それによりどれくらいの工数で改修が行えるかや、改修を加えることでどういったシステム上の影響や運用の変更が必要かということを洗い出したりするわけです。
さっさとソースを変えてしまいたいという衝動を抑えながら、頭の中で改修後のイメージや画面がどう変わるかのイメージを練っていったりします。
この時点はやるかやらないかというのがはっきりしない場合が多かったりしますので、下手に手を出すこともできませんし、顧客側もそれによってどういう悪影響があるかなんてわからずに言ったりしていますので、その辺を分析して実施可否の判断材料を洗い出す作業に追われたりします。
で、それなりの時間をかけて報告した結果、「そんな面倒なことになるならやめましょう」とか一言告げられて完了したりすることもしばしばあるわけですね・・・。