こんにちは、もりぞうです。
本記事では、プログラマーの業務の一部「アプリケーション維持」に関して記載します。プログラマーが作ったプログラム（システム）は、作られた後、その後どうなるのか。システムを利用する側からは見えないプログラマーが日々奔走するその舞台裏をついてお伝えしようと思います。多少苦々しい様子をお伝えしますが、未経験でIT企業にプログラマーとして採用された方には参考になると思います。
ここではプログラムの維持についてお伝えします。”プログラムの維持” は 業界では”AP(アプリケーション)維持”と言われます。このAP維持が、プログラム（システム）が作られた後にプログラマーが担う業務ということになります。要するにオモリですね。
作られたプログラムはしっかりと計画されたテストの工程を経たのちに納品され稼働を迎えますが、テストで見つけられなかった「予期せぬ不具合」や「ユーザーからの変更要望」に随時応えていくことになります。プログラムを作ればそれでお終いというわけではないのです。
そしてそのプログラムを利用していた会社の業務の変化やプログラムの刷新により、「もうこのシステムいらね」という判断が下されると共に世の中から除却されていくというのがプログラム（システム）のライフサイクルとなります。
もちろん様々なプログラムで再利用可能なプログラムコードというのもあることが多いので本当にゴミ箱に投げ入れられると言う訳ではありません。今後も転用可能なプログラムコードは「共通部品」として後に再利用され後進のプログラマーの支えになっていくのです。
そう言う意味でこれからプログラマーとして活動される皆さんはそうした先人たちの遺産を引き継ぎ、更により良いプログラム開発を実現していくことが求められていているのです。是非IT業界の発展に貢献いただき便利な世の中を築いていって欲しいと思います。
続いてプログラムのライフサイクルにおけるプログラマーの役割・苦労についてです。
１番の苦労は先に述べた「予期せぬ不具合」への対処です。システム稼動後の不具合は原因を見つけるのが難しいです。「ある条件の下でしか発生しない」「そもそもサーバ、ミドルウェア、ネットワーク、セキュリティに不具合がある」あるいは「ユーザーの勘違いだった」とかそう言うパターンもあり再現させることができないと対処のしようもなく、最終的に調査凍結というケースも出てきます。
そしてその過程において何より辛いのがユーザーからのクレームを懇々と受け続けなければならない事です。（上司も盾となってくれますが、ほとんどの場合一緒に怒られる仲間という立ち位置に留まられることが多いです）ユーザーはそのシステムが正しく動いてくれないと業務が進まなくて家に帰れなくなるなんていうことを考えると当然なのですよね。必死の形相で迫って来られますからね。ユーザーからのプレッシャー、これが１番の耐え処であり苦労と言って過言ではないと思います。
あと補足ですがプログラムコードが書けなくて仕事が進まなくなったらどうしようなんて言う心配は余りしなくても良いと思います。分からなければ先輩に聞くなりググればなんでも答えが見つかるように今の時代なっていますからね。
そんな日々を送ると自ずと気づくことがあります。それは意外とプログラミングに割ける時間って短くって、プログラミングの環境を取り巻くサーバ、ミドルウェア、ネットワーク、セキュリティそれから打ち合わせなんかでの対人スキルといった知識と能力も合わせて身についてくる事です。
なので、あくまでプログラマーとして採用されたあなたであっても、自分の仕事の範囲外だからとサーバのことはサーバ担当に、ネットワークのことはネットワーク担当にという具合に担当者に任せきりにするのではなく、他分野にも積極的に興味を抱き自分事として自らアクションを起こしていくことがとても重要だと僕は思うのです。
冒頭に述べたように僕はプログラマーとしてキャリアをスタートしその延長でAP維持に従事してきましたが、その中でこれらを意識してきた結果、現在はサービスマネージャとしてのキャリアを歩めているでいるのだと感じています。
最後に、これはプログラマーに限らずではありますがITエンジニアとして役立つ考え方を少しご紹介して終わりにしたいと思います。
同じ意味を持つ言葉であっても、現場毎に意味が違っていたりするので注意しましょう。例えば ”テストの完了” という言葉一つでも現場Aでは「単体テストの完了（そのプログラムが単体できちんと動作するかのテスト）」を意味するのに対して、別の現場Bでは「結合テストの完了(単体テストを終えたプログラム同士がきちんと相互に働いて動作するかのテスト)」を意味されるケースがあったりします。
なので、特に別のプロジェクトに参画する際には、指示一つの単語一語一語をきちんと確認する癖をつけましょう。「●●はここでは何を意味しますか？」という感じにライトに聞くのがいいと思います。
何をいつまでに作り上げる必要があるのか、管理職でなくともしっかり意識しましょう。そしてできれば会社間での契約内容も上司に聞いてみることをお勧めします。会社間では発注元から発注先にRFP（Request For Proposal：提案の依頼書（やって欲しい事が記されている））が提示されています。これをみることができればやるべき事と責任範囲が明確に把握できるはずです。一度上司に聞いてみましょう。
先にも述べたとおり、この業界、分からないことが多分に発生します。そういう時はすぐにエスカレーション（上司に報告する事）しましょう。自力で解決しようとググるばかりでは信頼性の低い情報を摑まされるリスクもあるので注意が必要です。ググって得た情報を上司なりお客さんに言う場合は「一般サイトからの情報ではありますが」との前置きを必ずつけましょう。
こちらも前述の通りプログラムの仕様はお客さんや設計者の思いで容易に変更されます。本当に「アンタの都合なんて知りません」てな感じです。朝令暮改は日常茶飯事です。なので自衛策としそうなったとしてもメンテナンスしやすい可読性の高いプログラムを書く技術を身につけましょう。
そのためには書籍やスクールを活用するなど自己研鑽を継続的に行うことがプログラマーとして生き残るためには重要となります。
フリーランスエンジニアのための、案件紹介サイト「ギークスジョブ」
iStudyACADEMYのディープラーニング講座申し込みはこちら
アジアでユーザー数100万人超え！AIを活用したTOEIC学習アプリ【SANTA TOEIC】
ネットビジョンアカデミー（NVA）はインフラエンジニアの教育に全力投球
最後に最優先すべき事についてです。
それは「あなたの健康」です。頑張ることやそうせざるを得ない場面はこの先幾度も訪れますが、心身を壊してまで耐えるのはナンセンスだと僕は思います。本当に苦しくなった場合は「インフルエンザに罹患しました（どやっ！）」と一報を入れ1週間休むといった、非人間的な判断もありなのではと常々思っていて、この考えはそこまで外れたものではないと本気で思っているからです。
如何でしたでしょうか。本記事を通してプログラマーの業務の一部「アプリケーション維持」に関して少しでもご理解が深まって頂けていれば幸いです。ここまで読んでいただきありがとうございました。
もりぞう