アキゾラ

なんかふと思い立ったので、書いてみることにしました。

システム開発vsシステム保守。

それぞれ、どんなことをやってて、どんな問題が起こりやすいか、どんなスキルが必要でどんな人が向いているのか？この業界で15年目のアキゾラの経験から語ってみます。

なんか、やっぱり仕事の話ってたまに吐き出したくなるもんですわねぇ。

なお、ここでは、できるだけこの業界に入りたいと思っている人やこの業界のことを知らない人に向けた書き方をしたいと思いますので、この業界の人には回りくどく逆に分かりづらいところもあるかもしれませんが、あるあると思っていただける部分も多いかも。

システム開発とシステム保守とはそれぞれ何なのか

一口に「開発」「保守」といっても、正直携わるシステムやプロジェクトの性質により結構違うこともあると思います。

小さなプロジェクトだと、この二つが明確に分かれていないことも多々ある印象。

逆に大きなプロジェクトでは、しっかり分かれていることもあり、それぞれのメンバーがあんまり交わらないようなところもあると思います。

自分の実体験でしか語れないので、あくまでアキゾラが経験してきた中での話、ということを前置きとさせていただきます。

アキゾラ

まぁでも、大筋はそんなに外れることないんじゃないかな、しらんけど

システム開発ってどんなことするの？

システム開発は、文字通り、新しくシステム（アプリケーション）を一から作っていく作業です。

システム（アプリケーション）としましたが、そもそも、システム開発とアプリケーション開発って、厳密にいうとちょっと違うんですよね。（とアキゾラは思っています）

システムって、「こういうことがしたい」というものに合わせて作る、サービスとか仕組みの全体像的な感じだと思っています。

アキゾラ

自分でもわかる、すごい分かりづらい。

例えば、ECサイトのシステムとか、在庫管理システムとか、自社の会員システムとか、、そういう仕組みの全体像みたいなもの。

それに対してアプリケーション開発というと、もう少し小さな単位というか。

そのシステムの中で動く一つのアプリケーション、部品みたいなイメージでしょうか。

スマホのアプリとか、PCのソフト（画像処理ソフトとか音楽再生ソフトとか）、それ単体で動いてるものありますよね、そういうのもアプリケーション開発にあたると思います。

アプリケーション自体がシステムの一部のこともあるんですけど、そうじゃないものもありますね。

まぁそういった違いはあれど、「開発」という括りでいえば、まぁ大体同じようなことします。

アキゾラ

開発の仕方ってウォーターフォール開発、アジャイル開発などいろいろあって、それぞれ開発の流れが違うんですが、そこは今回置いておいて、できるだけ「作業」単位でお話しします。

アキゾラはどちらも経験がありますが、古い人間なのでウォーターフォール開発の方が多く、どっちかというとそっちに寄った話の流れになってるしまってると思いますが、ご了承を。

要件定義設計

開発は、まず要件定義します。

これは、これから作るシステム（アプリケーション）を「どういうシステム（アプリケーション）にするか」を決める作業です。

いわゆる、上流工程と言われる作業ですが、こういう考え方するのはウォーターフォール開発の時だけなのかな。

システム開発では、顧客（クライアント）からの要望、例えば「自社の製品を自サイトで新しくオンライン販売したい」とかがあって、それを吸い上げて要件定義するパターンが多いと思います。

アキゾラ

こっちのパターンはいわゆるみなさんがイメージするSEさんが活躍するイメージじゃないかなー。

それに対して、アプリケーション開発の場合は、「研究開発」といって決まった顧客がいるわけではなく、世の中の状況を見て、自分たち発信、例えば「今こんな画像処理ソフトがあったら売れるはずだ、フフフ」というところから新しいものを作ることもあります。（もちろん、「システム」自体をこういう風に作ることもあるんですが）

機能設計、詳細設計

そして、要件定義から、さらに細かい仕様に落とし込んでいきます。

一応、ここまでが上流工程と言われるんですかね、おそらく（適当ｗ）

一つのシステムの中には、Aという機能、Bという機能、Cという機能と、色々な機能に分けられるわけですが、この機能ごとそれを「具体的にどういう機能とするか」を決めて（機能設計）、それをさらにプログラミングに落とし込めるよう細かいことを決めていきます（詳細設計）。

機能設計は、プロジェクトによっては、基本設計というところもあると思います。そのほか、基本設計→機能設計→詳細設計と、3段階だったり、まぁ色々です。

なんであれ、大きな単位から、小さな単位へ落とし込んでいくんですね。

アキゾラ

アキゾラの経験では、基本設計→機能設計→詳細設計が多いですね。

ここでのアウトプットは「仕様書」です。言い方はプロジェクトによりますが、基本設計仕様書、機能設計仕様書、詳細設計仕様書みたいな感じ。

プログラミング、テスト

次に、仕様書をもとにプログラミングしていきます。

プログラミング以下がいわゆる下流工程です。

仕様書通りにプログラミングしますよ、プログラミングが終わったら、それが仕様書通りに動くかどうか、テストします。

テストは、仕様書通りに動くかを確認するものなので、仕様書に沿ってテスト項目を作成します。プログラムを見ながら作っちゃだめですｗ それだとバグが発見できない。

バグがあれば修正してまたテストします。この繰り返し。

テストにもいろいろ種類があって、機能仕様書レベルの確認、詳細仕様書レベルの確認みたいな、各仕様書ごとにテストのレベルがあります。

Aという機能の中の、一部分をしっかり確認し、Aという機能全体の確認をし、AとBとCと、それぞれの機能全体を合わせての確認、システム全体での確認・・。

ここでのアウトプットは「ソースコード（プログラム）」「テスト結果」です。

テストでバグが出なくなれば、出来上がり。

PMとかまとめの人になると、品質見解書とか書いたり、バグの分析したり、ペーパーワークも多くなりますがここでは端折ります。

そして、開発の手から離れ、たいてい品質保証部のようなところで品質の最終チェックが入るんですが、そこでNGがでると、またバグ対応、なんなら仕様書まで戻って作り直し、ということを繰り返し、だんだん納期ギリギリとなって炎上したりします。

アキゾラ

プログラムは仕様書をもとに作るので、仕様書がしっかりしていないと、死にます

ざっくりいうとこんな感じですね。

新規機能の追加なんかも、開発の作業

一から新しくシステムを作るだけじゃなくて、そのシステムにさらに新しい機能を追加したりするのも、開発の作業です。

この場合も、基本は前述の工程を踏んで作業をします。

システム保守ってどんなことするの？

では、システム保守は、何をするのか。

システム保守は、開発が作ったシステムが実際に世で使われだした後の、保守作業です。

これもプロジェクトによって結構やる範囲が違うかもしれないんですけど、大きくは以下。

お客様からの問い合わせ対応

「なんか、○○したらこんなメッセージ出たんですけど、なんで？」とか、「○○したいんだけど、いまのこの状態でやって平気ですか」とか、「急に動きが遅くなったんですけど」とか、「あんたんところのアプリ入れてるマシンの調子が悪いんですけど、アプリのせいじゃないのこれ？」とか、「アプリが起動しません」「至急、障害発生」とか、とにかくいろんな問い合わせが入ってきますので、それに答えます。

それ、マニュアル見てくれてます？っていうレベルから、いやそれうちに聞かれても・・マ○クロソフトに聞いて？、という謎質問、なんでこんな動きすんねん！！という嫌な予感のもの、「障害発生」・・・、と本当に様々です。

この辺は、そのシステムの保守契約の内容とも絡んできたりするんですけどね、細かいこと言うと。

お客様からの状況ヒアリング、システムのログファイル（動きを記録したもの）などを用いて、そのシステムで今何が起きているかというのを把握し、問題があればその原因を突き止めるのが主な作業。

ということは、お客様からの問い合わせがなければ、暇なんじゃね？という疑惑を持たれる方もいるかもしれません。

アキゾラ

あ、YESですね。

広く使われているシステムとか使われだしたばかりの新製品だと、とにかくひっきりなしに来ます。そんな暇ではない。でも波があるのも事実。

アキゾラ

問い合わせの多さは、そのシステムの品質の良しあし、ユーザビリティなどに左右されるところがあると思いますけどね。

逆に対して売れてないアプリだったり、使っているのがその特定のクライアントだけであり小さな規模のシステムなんかだと、暇かも・・・なんだけど、そういう場合はシステム保守とシステム開発が分かれていないこともありますね（開発が片手間で対応できちゃったりするんで）

なお、なんでこんな動きすんねん！系は嫌な汗が出るし、明確な障害発生はもうまじでやばいです。

不具合対応、改善対応

これは、問い合わせで発覚した不具合、いわゆるバグと認定したものを、直します。

基本的には、開発中に出た不具合は、開発で直してリリースまでもっていきますが、いったん外に出た後の不具合は、保守が対応します。

バグじゃなくても、もっとこうあるべきだよねっていうような改善にあたるようなものも、保守で対応することが多いと思います。

なお、いったん外に出た後の不具合は、お客様に迷惑をかけていることが多いため、結構大変なことになります。

システム開発とシステム保守でありがちな問題

どんなことをするのかをざっと説明したところで、ではシステム開発とシステム保守で、それぞれどんな問題が起きやすいか、ありがちな問題を挙げてみます。

システム開発でありがちな問題

開発途中で仕様が変わることがある

これは、特にウォーターフォール開発でダメージのでかい問題。

要件定義して、機能設計、詳細設計、プログラム作って今テスト中ですよ～順調ですってところで、仕様が変わるという大人の事情が発生したりします。

仕様が変わると、場合によってはまた1から作り直しです。

でも、納期は変わらないことが多いです、そんなの、軽微な変更だと思ってますから、変更をかけてくる人は・・・。

そもそも、納期まで日程がない、思ったより作業に時間がかかり追いつめられる

まぁこれ、どこが悪いかっていうと、いろんな場合があると思うんですが・・。

○○なら、これくらいでできるでしょと勝手に上の方で決められていて、そんなわけないやんという、そもそも無理ゲーな場合もあれば、「こういうことをするなら、これくらいかかりますよ」と実際開発する側がきちんと見積もりをしたんだけど、問題ばっかりでて期日に間に合いそうにないことも。

作業量の見積もりは大事なんですが、開発経験が少ないとその見積もりが甘く、あとあと自分の首を絞めることになったりもします。

進捗の遅れが発生するのはテスト工程が多いかなーと思います。

いつまでも不具合がおさまらない、不具合が解決できない、こういう状況下で発生するAという不具合を直そうとするとBがうまく動かなくなるが、今の作りでは他にどうしたらいいのか・・（→仕様設計から作り直し）

その他、特定のテスト環境などの問題で、他の開発者と環境のシェアを行わないといけないこともあったりして、そのせいで当初の予定通り進まなかったり。

品質保証部のOKがもらえない

これは、問題っていうか普通のプロセスなんですけど、品質保証部のチェックで依然として不具合の指摘がおきていると、いつまでたってもOKになりません。

なんなら、この段階で発覚した不具合が、それ以前の開発側のテストでやればでるような問題であった場合など、そもそもちゃんとテストやってるの・・？（超疑惑の目）という話になって大幅な類似不具合の見直しなどを課されたりして、これが結構大変です。

その場合でも、当然そう簡単に納期は変わりませんよ。

でも、品質保証部は、世に出るそのシステムの品質を最終的に保証するわけですから、厳しいのは当たり前。ここが緩かったら品質保証自体が機能していないわけですね。

アキゾラ

だが現実問題として品質保証部とはあまり仲が良くないケースが多いと思うｗ

デグらして冷や汗

機能追加などは既存機能との関係も事前にしっかりと調べないと、デグレードといって以前は動作していたものが動かなくなるなどの問題も発生します。

デグレードの不具合は、新規の不具合よりも深刻度が高いです。

ありがちなことにあげるか迷いましたが、やっぱり、ありがちなんですよねぇ。

でも、リリース前に気が付けばいいんです。

まさか全くそこに影響すると思わなかった、みたいなものだと、それに関するテスト項目もそもそも作ってないし、品質保証部でのチェックもすり抜けてしまうことは考えられます。（これはとてもやばいです）

システム開発での問題は、納期に関するものが多い

システム開発での問題は、やはり多くは納期に関するものだと思います。

特にウォーターフォール開発では、上流工程で仕様をしっかりと決めないと、プログラムはグダグダになり、大幅な進捗遅延が発生します。

アキゾラは開発でそこまで死ぬほど苦労したことはないというか、あったかもしれないけどすぐ忘れちゃうｗ、でもリリース直前というのは2徹夜したりしたこともありました。

そう聞くと大変なように思うかもしれませんが、それでも、リリース前です、今ならまだ直せる、問題はまだあくまで社内で閉じている、ということで、精神的な緊張感は保守に比べると低かったと今になっては思います。今になっては。（あ、でも休職2回してますｗ）

システム保守でありがちな問題

よく知らん機能のことを調べようにも仕様書がない/古い

問い合わせ内容に回答するため、その機能の仕様、あるべき姿を調べたいんですが、そもそもどうあるべきなのかがよく分からない、という、改めて文章にするとなかなか残念な状況というのは割とあります。

仕様書探したけどないし、見つけたとしても書いてあることが今のプログラムといまいちあってない・・・これどっちが正しいの？とか。

自分が開発してきたわけじゃないものなんかは、特に何が正しいのか分からなかったりします。

有識者ももういないしさー。

ほんとにでっかいシステムで、しかもそのシステムに関してそもそも知識がないと、今問題になっている機能ってどのソースコードの話？と、仕様書も発見できないしよく分からないからとりあえずソースだけでもみたいのにそれすらもままならないという場合もまれに発生します。

初めて見た謎現象なのに、回答期限は本日中

突発的に目の前に振ってきた問題に、早急に対応しないといけません。調べても、そんな動きになるはずがないだろという謎の現象にぶち当たることも沢山あります。

泣けてきますが、泣いても期限は変わりません、お客様は困っています。このせいでお客様の業務が止まっているんです、早急に解決しないとまずいです。

そもそも何を見ればいいのか分からない、見ても分からない

こんな問題が起きてる、という問い合わせに対して、まず何を見ればいいのか分からない、見ても分からない、ということもあります。

Aという機能で問題が起きた、Aっていう機能はどのログファイルに情報残してる？情報がどこにもない。

ログファイルは見たが、なんかエラーっぽい文言出てるけど、このエラーは今の問題と関係しているのかしていないのか、、、。なんか判断つかないな～ここ突っ込んでると時間ロスかなぁーあーどうしよう。

正常時のログ状況を知らんのでよく分からんぜこれ。（ログ少なすぎだんまり系）

明確に○○というエラーが出ているんだけど、そこまでは分かるんだけど、結局なんでこのエラーが出るのか分からないｗ

あとは、ログファイルって延々と情報書き込んでいたら容量がどんどん増えてしまうので普通ラップアラウンドして上書きしていきます。なので、見たときにはもう情報残ってないｗｗというのも割とある。（どうでもいいログ出しすぎ系）

など。

お客様先で起きている現象が、こちらの環境では再現しない

何だか分からんものは、再現試験をして確認することがあります。

お客様からもらったログファイルだけでは何が起きているのわからない場合など、さらに詳細な情報が出るように修正を加えたシステムで、同じ操作を行ってその現象を再現させ、何が起きているのか調査します。

でも、うちでは再現しない・・・。できる限りの条件をそろえても、まー再現しない。環境依存あるある。

問題が再現できないというのは、結構致命的で、それを不具合と断定するのにとても時間を要しますし、お客様先の情報だけで不具合だと断定できても、それを修正してテストで確認するときに、「不具合が直った」と言い切れません。そもそもうちじゃ起きないから直ったという現象を確認できない。

お客様環境で実際にデバッグさせてもらえればいいんですが、それができることは少ないです。てかほぼないです、アキゾラの経験では。

あと、お客様先が海外、とかね。そう簡単にいかんですよ、はい。

不具合か、改善か、もめる

超内輪事情って感じですが、「何か不具合（バグ）っぽい微妙なもの」があった場合、やはり設計側（開発、保守を含めた作っている側の人間）としてはバグとは認めたくなく、直すなら改善扱いです、という心理が働きます・・・ｗ

アキゾラ

明らかなバグはバグですよ、そりゃ。でも、微妙なものってあるんです。例えば、仕様の不良（もともとそれで合意を取ってるのにそれじゃだめじゃんとなる）とか特定の環境下でしか起きない問題とか、そういうのになりがちです。

バグとか改善とかって、ポンポン勝手に直せるものじゃなくて、いろんなところと合意を取って直します。

バグか改善かって、結構違うんです、重みが。。プログラムに修正を入れるっていうところは一緒なんですけど。

作ってる側としては、いろんな事情がありそれはバグじゃないんですけどというものもあったりしますが、使う側としてはさくっとバグでしょ、となるわけで、社内でも役割として使う側に近いところにいる人は「バグ」、設計側は「改善」と主張が食い違います。

大抵は、バグに収まります。

システム保守の問題は、スキルと経験、そのシステムに関する知識に左右される

システム保守での問題は、スキルと経験、そのシステムに関する知識に大きく左右されます。

とにかく回答期限が短期間、明らかな障害であればASAPなので、悠長に仕様書調べて～とか、こんがらがったソースを机上トレース（処理を読み解きながらそのプログラムの動きを把握する）して～とかやってる暇なかったりするんです。

該当のことが書かれている仕様書を探り当てるのだけでも時間がかかります。

システムによりますが、仕様書って大なり小なり合わせて100以上は余裕であります。大規模システムだと数百ってレベルじゃないの？知らんけど。

おんなじ仕様書が何個もあったりしてリビジョンでも判断できないとか、どれが最新の仕様書なんだよという管理になっていることも、残念ながら多いんです。特にながーいこと続いている大規模システム。

しかも、探り当てても、知りたいことは書かれていないこともありますっていうか、大抵仕様書見ても得られるものはなかったりします。悲しいかな。

机上トレースはぱっとみて、ああこれ時間かかるやつだ。となると、心にドーンと重いものが押し寄せます。

アキゾラ

時間かけてる時間ないんだよー涙

でも、多分こうですとか、あいまいな回答はできません。推定要因として回答することは多々あるんですけどね・・。

こうですよ、と回答した内容が実は解析ミスってたりすると、やばいです。

例えば、以下のような流れで進みますね、うちの場合は。「運用保守」って一緒だったりすることもありますけど。

なので、「それを知っている人依存」になりがちなんです、保守作業はどうしても。

アキゾラ

「人依存」はよくないです。

これを解消するために、おそらくどこでもいろんなことをやってると思うんですけど、なかなか難しい。

また、そのシステムのプログラムだけを見ていて問題が解決することは少なく（そういう問題はそもそも開発段階でのテストで摘出され潰されている）、システムが動作するマシンの性能や他のアプリとの関係、メモリの使用状況などの環境問題が絡むことも多いです。

システム開発とシステム保守、それぞれどんなスキルが必要？どんな人が向いてる？

なんか、マイナス面の強調ばかりしてしまいましたが、システム開発とシステム保守、それぞれどんなスキルが必要で、どんな人が向いているのか、アキゾラ目線で。

ここでは、あくまでそれぞれの対比での話で、一般的にSE/PGとして必要なスキル/技術力云々というところは少し割愛します。

システム開発に必要なスキル、向いている人

これは、うーんなんでしょうね。

クライアントの要求を正確に吸い上げ、それを要件定義落とし込むってところは、プログラミングなどの技術力云々よりも、コミュニケーション能力というか、人の話をきちんと理解する力、相手が何言ってるか分からないような場合は、それをかみ砕いて「こういうことですよね」とまとめる力が必要だと思います。

アキゾラ

ただ、実はアキゾラはどっちかというと研究開発系のものにしか携わったことがないので、これあんまりよく知らないんですねーｗ

あとは、ガッツがあれば・・・（まじかｗ）

この業界の経験の少ない人でも作業しながら技術力をつけて成長していけるのは、システム開発だと思います。

いわゆる技術力があるに越したことないんですけど、ない場合でもできる仕事があるのはシステム開発。

経験者でも新規参入で作業がしやすいのもシステム開発。

基本は、新しく機能を追加するわけなんで、そんなに既存のシステムについて熟知していなくても作業に入れます。

（もちろんデグレードの問題とかあるから、きちんと既存機能の動きも調べたりして作業することになるんですけどね）

そして、新たに作り出すわけなので、クリエイティブさがあり、そういうのが好きな人は向いてると思います。

こういうことを実現するためには、こういう設計、こういう処理をするとスマートだなぁとか、こっちのやり方の方が保守性が高いなとか、いろいろ経験するうちに自分のレベルも上がります。

作る製品や機能によってやることは違うので、そのたびに新しい発見、新しい経験ができるのも開発です。

アキゾラは、自分が開発に携わった製品が、多くの人に使われているというのは嬉しいし、誇りに思うところもあります。

また、会社の中で評価が高いというか注目されるのも、開発部隊でしょう。

システム保守に必要なスキル、向いている人

システム保守は、前提としてある程度のIT知識（何かに特化、というより全般的な知識）、そのシステムに関する深い理解が必要です。

時間をかければ分かる、では難しく、時間をかけられないのですぐに状況を理解し、考えられる要因にあたりをつけられないとキツイことが多いです。

問い合わせ内容は多岐にわたるため、まずこうする、みたいな決まった作業があるわけではありません。そのため、システム保守では例えば新人さんなどの仕事を振るっていうのも結構難しい。

アキゾラ

たいてい、新人さんに任せる仕事は余裕をもって説明をし、最悪何かあっても自分がリカバれる範囲で徐々にお任せしたりしていきますが、システム保守でそれをやるのは難しいですね。

その場その場でやることは違うんです。

まずはAをみて、結果が××だから今回は次にBを確認し、次にCを確認し、総合的に考えて●●である、と期限内に結論を出すことができないと仕事になりません。

ある程度の経験がないとつらいかもしれません。

先ほども少し触れましたが、ログとソースコード見るだけで問題が解決するような簡単なものは少ないです。

そのため、保守するシステムの規模や複雑さにもよりますが、基本的にはそのシステムのことを全く知らない新規で入った人がいきなり携わるようなものではない、とアキゾラは思っています。（でも現実はあるんですけどね、こういうこと。）

向いている人は、問題解決するのが好きな人、責任感のある人、かな？

開発に比べて、仕様書を書くとか、プログラミングをするというような作業は少ないです。（不具合対応/改善対応するので、やりますけどね）

圧倒的に「調査」が多い。

アキゾラはなんか問題があると、なぜか？を解明するまでのプロセスが楽しいというか判明できるとめちゃめちゃ嬉しいですｗ 謎解きみたいｗ

そして、自分の解析一つに重い責任が伴います（と思います）。言ってしまえば、それがそのまま会社、組織としての回答になります。自分が責任をもってこの問題を受け持って解決するのだ、という心意気、結構大事かもしれません。

しかし、保守は基本問題が起きたら動く部隊。何も起きなければお金がかかるだけの部隊ですｗ（これは言い過ぎか）

新しい仕事が立ち上がるところではありませんので、注目度は低く、評価も低めというか、評価しづらいんでしょうね。結局。華々しい成果を見せるってことが難しいですから。

また、保守は開発に比べたら人数が少ないんで、一人がいくつもの案件を抱えて優先順位を確認しながら作業することが多いです。

開発では、基本は一つの担当を自分で進めていくということが多いので、仕事の進め方も違うかなと思います。

アキゾラ

まぁ開発は、細かいこと言うと、上流工程にしか携わらない場合、下流工程しか携わらない場合、全部やる場合などでも結構違うんですけどね。

まとめ

システム開発vsシステム保守。それぞれの違いは？、でした。

一口にシステムに携わっている人と言っても、開発と保守では結構やることが違います。

アキゾラ的には、どっちも経験するといいと思います。たいていは開発に携わるほうが多いと思うんですが、保守もやってみると、そこで感じたことを開発に生かすことができます。

開発だけしていると、特に研究開発の場合ってお客さんが実際にどう使っているのかとか結構遠い話だったりするんですね。

声が聞こえてこないから。

でも保守はお客さんの声がそのまま聞こえてきます。あーこういう風に使われているんだなぁとか、え、こんな使われ方想定してないｗｗとか、なんか色々新鮮だったりします。

まず開発で経験をつみ、保守を経験し、それからまた開発で活躍！こういうのが結構いいキャリアなんじゃないかなと思ったりするアキゾラです。

なお、以下のような記事書いたことがあるんですが、こちらもどうぞ。

【プログラマ】女性はプログラミングが苦手？男女問わず向いていない人の特徴とは？

仕事中、甘栗の間食が止まらなくなっているアキゾラです。食べ物でもなんでも、一度ハマりだすとしばらくアホみたいにそればっかりになる人、はい私です。今日は女性のプログラマって少ないよねっていうところから、女性はプログラミングが苦手、と言われる所...

akizorainvestment.com

2020.09.20

ではでは！

さて本日はちょっと思考を変えて、仕事について。

アキゾラは自己紹介でも少し触れていますが、プログラマとして働いています。

自己紹介

はじめまして。アキゾラと申します。平凡なIT系のサラリーマンです。一応、女であることを表明するためサラリーウーマンと言ったりしています。このブログでは、主にようやく自分の人生について（主にお金面）真剣に向き合いだしたアキゾラの資産形成の日々...

akizorainvestment.com

2021.09.06

女性のプログラマってどう？とか、プログラマの特徴だったりあるあるだったりを完全なるアキゾラの独断と偏見で語ってみたいと思います。

プログラマに興味がある方もない方も、同業者の方も、ちょっと読んでってくださいｗ

プログラマについて。システムエンジニア(SE)と何が違う？

まずは、そもそもプログラマって何？から。

なんか初めて会う人に自己紹介するときに、プログラマって言っても通じない気がして、ついシステムエンジニアですって言ってしまうことがあります。

この二つの定義は非常に曖昧ですが、大きく分けると、システムエンジニアはお客様先でシステムの提案とかしたり、全体像の設計をまとめたりするような人ってイメージを持っていただいて問題ないと思います。

プログラマは、プログラミングをします。 システムエンジニアが持ってきた「こんなのが欲しい」というシステムを、実際に作る人です。

ただ、この境は非常に曖昧で、システムエンジニアでも小さなプロジェクトになればバリバリとプログラムを書いているような人もいるでしょうし、プログラマだって言っても、上流設計から関わっている人もいます。

この業界にいると、割と「私はプログラマです、SEじゃないです。」という意識は強いんですが、外から見ると結構あいまいじゃんじゃないかなーというのが、アキゾラの思うイメージですｗ

アキゾラの仕事歴

さて、プログラマなアキゾラですが、転職歴なしの、この道一本ですｗ

セキュリティ関係のソフトウェアや、プリンタ関連のソフトウェアの開発を経て 、現在はストレージ関係をやってます。

ストレージって、ざっくり言ったら、記憶装置ですね。HDDとかさ。

「こういうもの作りたい」という要件をもとに、細かい仕様を決めていって、それをプログラミングして作り上げていきます。テストを行い、問題がないか確かめます。

開発、といったらやってることはこんな感じ。めっちゃざっくりですが。

ただ、アキゾラは現在保守作業の方を主に行っています。こちらは、すでに世に出た製品に対する問い合わせ、問題などがあった時に何が起きているのかを解析して問題を解決します。

簡単に言うと、こんなことを毎日やってます。

ちなみに、使えるプログラミング言語は、C、C++、Javaです。まぁ使えるというレベルでは、Delphi（比較的レア言語ですｗ）、Pythonあたり。

そして好きな言語はズバリC言語です！（泥臭いｗ この感覚が分かる方は同業者さんですね）

なぜプログラマになったか？

ちょっとなんでプログラマになったのか、も書いてみます。

アキゾラは商学部卒で、情報系の勉強とは一切無縁でした。

就活も、商学部らしく？主に金融系の会社を受けてました。

とある地銀の総合職で内定をいただきましたが、どうも銀行員として働いていく自分を考えたとき、一抹の不安があったんです。

ただ、その一抹の不安は漠然としたもので、単純に「社会人」として働く自分に対しての不安なのか、「銀行員」に対しての不安なのか、イマイチはっきりせず内定貰ってもちょっと悶々としていました。

んー本当にこれでいいのかなー？と、もう一度自分は何をしたいのか考えてみたときに、ふと思い出したものがありました。

若き大学生のアキゾラが非常に感動しあり得ないほど涙した、とあるflash。（時代ｗｗｗ）

flash知ってますかね？ｗ

知っている人は知っている、2ちゃんねるの閉鎖騒動のflashです。

今はyoutubeにフルHD画質で上がってましたので、ちょっと貼っときますねｗ

いやひっさびさに見たけど、やっぱ感動する。←

ちなみにこの真偽は色々あるようなんですが、、そこは問題じゃないんです。はい。

当時まだ2ちゃんねるやってるって、結構オタクっていうかなんていうか、、表舞台では声高に言えない雰囲気がありました。（今もあまり変わらないかｗ？）

これを見て、プログラマってかっこいいなーというところから、何も知らない状態で、その道に進みました。

はい、本当にこの動画が、私の人生を決めたきっかけですｗ

プログラマという仕事について

一応、ざっくり特徴というか、働いていて感じることを。

・いい意味でも悪い意味でも男女平等

技術職ということで、仕事内容に男女差はありません。

これは、お給料面も同じ。うちの会社では、ランクによる等級で決まりますが、ランクが同じであればみんな同じです。

しかし、長時間労働、徹夜などが発生することもあり、女性でも同じ。

・比較的自由

お客様先にでていくシステムエンジニアに比べると、プログラマは社内でプログラミングをしていることが主な仕事なので、服装だったり髪型だったりが結構自由な方だと思います。（会社によるところはありますけどね。）

といっても、女性でとびぬけてええ？！と目立つ人は見たことないんですけど、男性の方だと、すごい長髪の人がいたり、髪の色も緑とかの人がいたりすることも。

アキゾラは普通のカジュアルで普通に出勤します。スウェットパーカみたいのも普通に着てます。プログラマに限らず、営業職とかじゃなければ女性はそこまで厳しくないことの方が多いでしょうかね？

・常に技術の勉強が必要

技術というのは常に新しくなっていきます。自発的に勉強（という大げさなものでもないんですけど）していかないと、使い物にならなくなります。

新しいことを学ぶ姿勢、というんですかね。逆に言うと、そういう新しいことを好きで探求していける人じゃないと、辛いかもしれないですね。いわゆる、勉強勉強！という意識ではないと思います。

周りは男性ばかり、がデフォルト

ちょっと生態的なところに入っていきましょうｗ

プログラマの男女比ですが、やはり男性ばかりです。これは間違いありません。

いくつかプロジェクト変わって携わっていますが、どこいっても女性はほとんどいません。

同じプロジェクトに1人、2人いればいい方ですね。

そのため、お昼休みは女子みんなで集まってランチ♪みたいなことは経験できません。

男性陣に交じって「唐揚げカレーのすごい店いくぞぉ！」みたいのに参加することはあり得ます。

また、この男女差から、トイレは常に空いてます。一方、男性陣はトイレが慢性的に空いてなく、空いてる個室探して屋内ツアー状態。

そして、女子トイレで井戸端会議？に花が咲く、みたいなこともありません。

たまに話している方はいるんです。でもそれは、総務だったりの管理部門の女子の方々。知らない人たちですｗ

うっすら、自分とは違う人たち、の意識があります。

あと、まぁやっぱり、おしゃれ最先端！みたいな感じの人は少な目かな・・？たまに身なりめっちゃきれいに整えてて、THE 女性！みたいな見習いたい方がいますが、たいていWeb系の、画面作ったりしている側の方です。そして、ああ、やっぱりね、みたいに思いますｗ

アキゾラのようないわゆるプログラマｗ側では、あまりこういう人もみかけないですね。サンプルが少ないので、もちろんいらっしゃるところにはいらっしゃるんだとは思いますがｗ

で、男性ばかりだからどうなの？というところですけど、アキゾラは楽でいいです。

中学高校と女子高上がりなので、女子でいることの楽しさはよく知っていますが、怖さも知っていますｗ

仕事する上では、今の環境の方が楽だなというのが、アキゾラの思いですｗ

まぁ会社員です、という

これね、最初にもちょっと言ってますけどｗ

プログラマの人は、仕事何しているの？と聞かれると、なんて答えたらいいのか分からなくなり、言えて「システムエンジニアです。」とか、もう大抵は「まぁ会社員です」とか言います。

でもなんかもやもやしています。OLですっていうのも、違う気がして、もやもやしています。

パソコンに詳しい人、とか、IT系っぽいことの何でも屋、のレッテルを張られる

これはもうあるあるNo.1ですね。

プログラマとかシステムエンジニアというと、この業界ではない方には、十中八九パソコンに詳しい人、と自動的に脳内変換されます。

「パソコンが動かなくなった」「インターネットにつながらない」このあたりは、友達からヘルプデスクのように聞かれます。

実際どうなの？というところですが、別にパソコンに取り立てて詳しいわけではありませんｗ

それはこういうことが考えられそう、というような切り分けとか一般的な対処などは普通の人よりはできますが、基本的にはそのメーカーのマニュアル見てくれ、私も分からん。というところです。

パソコンに詳しいってのは、ハードウェア好きのPC自作とかしているような方々かと。

あと、Office製品（主にEXCEL）などにも、詳しいと思われています。

プログラマは別にEXCEL得意じゃないですよ。

アキゾラはデータをまとめて解析することなんかもあるのでまぁ使うんですが、EXCELで関数全然使えない人とかもザラにいます。なんでこれ自力で計算して直接入力してんのよｗみたいなの普通にあります。EXCELでマクロとか組むこともほぼないので、大して分かりません。

このあたりは事務の方なんかの方が詳しかったりするんじゃないでしょうか？

ホームページを作りたいから教えてほしい、というのも、たまに発生するワードです。（最近は減った）

Web系ならまだしも、HTMLとか、別に全く詳しくありませんｗ

昔知人から、ホームページをどうしても作ってほしい自分は全く分からないので、という話があり、今ホームページなんかHTML自分で打って作る人いない、そういうの簡単に作れるサービスがいくらでもある、と話をしたんですが、分からない、やってほしいってことで、ちょっと受注したことがあります。

全然分からない人には、簡単になったとはいえハードル高いんでしょうね。

派生形として、「自分もちょっとプログラム勉強しているよ、HTMLとか。」という話もたまに聞きますが、なんていうか、うん。相手によっては反応が難しいｗ

椅子3つでちゃんと寝れる

最近はあんまりないんですけどね。働き方改革なども手伝って、徹夜などはここ数年経験していません。

しかし、徹夜になることもあります。

プロジェクトが思うように進行していなかったり、問題が発生していたりして徹夜で対応を迫られることもあります。

女子でも全く関係ありません。

徹夜で仮眠をとるときなどは、基本的に椅子を3つつなげてその上で寝ます。

机に突っ伏して寝るより、体にいい。

アキゾラは最高で2徹したことがあります。男性だと、人相が変わっている人が出現します。

MacじゃなくてWindows、iPhoneじゃなくてAndroid

最初に言っておきますが、これはなかなか大きな偏見ですｗ

プログラマな人は、Apple製品？しゃれっ気づいてんな。と思っています。

MacではなくWindowsが基本です。スマホはiPhoneじゃなくてAndroidです。

iPhone使う人は、システムエンジニアだと思っています。

200より256がすっきりする

プログラムの世界では、16進数が使われます。

そのため、直感的になんか切りのいい数値、というと、例えば200（10進数の1～200）より、256（=16進数の0x00～0xFFの256個）になります。

独り言は気にならない

プログラマって独り言する人が多い気がします。

アキゾラも普通に独り言いいながら仕事していますｗ（ええ？なんで？とか、あ、そっか！とか、（・・・これやべぇ・・）、とかｗ）

隣の席の人も結構心の声が通常ボリュームで漏れていることが多いため、それが普通でスルーしていたら話しかけられてた、ということもｗ

大規模通信障害など、世間を騒がせる障害が起きると胸がザワザワする

アキゾラは保守業務を行っているため、問題が発生しなければ平和なんですが、ひとたび問題が発生すると、モノによっては至急の対応を迫られます。

生活していると、携帯の通信障害が起きた、とか、大多数が使用してるシステムでのシステム障害、なんかが速報で入ったりすることがありますよね。

スマホ使えなくなったら、ちょっとーなんなのー早く復旧してよー！と思うと思うんですが、こういう問題が起きると、それに携わっているエンジニアたちが、復旧できるまで作業に当たります。

こういうことが起きると、作業している人たちを思い、自分も他人事じゃないところがあるわけで、なんかザワザワするのですｗ

まとめ

こんなところですかね。

あんまり、女性ならではっていうのはなかったですねｗ

ぶっちゃけ、プログラマな女性はー、といえるほど、多くの女性を見てきていないことに気づきました！ｗ 人数がいないんです本当にｗ

なので、アキゾラの生態のようなところになってしまいましたｗ

プログラマの仕事は結構好きです。

物づくり(プログラミング)とか、問題解決のための調査とか、楽しいんです。

よく、キャリアパスとして、プログラマ→システムエンジニア、ということが言われたりしますが、アキゾラはプログラマでいたいと思っています。

モノを自分の手で作っていたいんですねｗ

それが世間で動いていると、嬉しいです。

そういうのが好きな人は、プログラマお勧めです（誰向けのポストか分からなくなったｗ）

文系出身、未経験でプログラマになったアキゾラの話は、こちらでつづっています。同じような境遇になる人、これからが不安な人の参考になれば嬉しいです。