みなさんこんにちは。文系女子SEのほりごたつ(@horigotatsuSE)です。
![他人アイコン](https://horigotatsu.tokyo/wp-content/themes/the-thor/img/dummy.gif)
![他人アイコン](https://horigotatsu.tokyo/wp-content/themes/the-thor/img/dummy.gif)
と不安になっていませんか?
![ほりごたつアイコン](https://horigotatsu.tokyo/wp-content/themes/the-thor/img/dummy.gif)
みなさんは文系SEと聞いて辛そうなイメージありますか?
少なくとも私はよく友人から「ツラそう」と言われます。
この記事の信頼性
私は文学部卒からSEになりました。メカも苦手、カタカナも嫌いです。
こう並べてみると私がいかにSEに不向きな状態かわかると思います。
ですが、今は文系や理系の壁はこえて仕事をできていると感じています。
今回は、そんな私が辛いと思ったポイントをつ2ほどお伝えしたいと思います。
文系SEが辛いポイント①何を考えるにも数字が必要
一口に文系といっても、経済学部の方とかは数字に強そうなイメージありますね。
一方私は文学部卒なのですが、
大学までの研究では「数字」がそこまで求められなかったんですよね。
でもエンジニアは
![他人アイコン](https://horigotatsu.tokyo/wp-content/themes/the-thor/img/dummy.gif)
と品質を維持するために数字。
![他人アイコン](https://horigotatsu.tokyo/wp-content/themes/the-thor/img/dummy.gif)
と見積に対しての売上を管理するために数字。
![他人アイコン](https://horigotatsu.tokyo/wp-content/themes/the-thor/img/dummy.gif)
想定処理件数100万件×ループ回数分が削減されて・・・・
とプログラムの処理性能を考慮するために数字。
![ほりごたつアイコン](https://horigotatsu.tokyo/wp-content/themes/the-thor/img/dummy.gif)
進捗なども、基本的には数字を根拠に報告するのが普通です。
品質や売り上げ、性能など
すべて数字が指標となって業務が動いていきます。
![ほりごたつアイコン](https://horigotatsu.tokyo/wp-content/themes/the-thor/img/dummy.gif)
今でも数字がすべてじゃないんじゃないの?
と思ってはいます。
進捗報告とかで
「数字を報告しろ」
という人がいるけど、個人的には数字よりも「概況」が知りたいかな🤔
☑️進捗はオンスケ?
☑️仕事量は多すぎない?
☑️仕事内容に不安はない?ここら辺がわかれば結構安心かな✨
量と不安具合はリスクヘッジのために聞いときたい😃数字はあくまでもその根拠✏️
— ほりごたつ@文系SE×ブログ (@horigotatsuSE) February 17, 2020
それでも「数字は根拠になる」とは思っています。
数字は根拠になる
数字が根拠になると思ったエピソードをお伝えしますね。
入社4年目。私はとある案件を担当しながら、品質に悩んでいました。
![ほりごたつアイコン](https://horigotatsu.tokyo/wp-content/themes/the-thor/img/dummy.gif)
あれ?いいことなんじゃないの?
と思われるかもしれませんが、
バグが出ないということは、質のいいテストができていないかもしれないということ。
特にその案件は新設のプログラムを1年目の子に書かせていたので
バグが出ないわけがないと不安になっていたんですね。
そんなとき、先輩がかけてくれた言葉が
![他人アイコン](https://horigotatsu.tokyo/wp-content/themes/the-thor/img/dummy.gif)
レビュー密度出してみたら?
テストの質が高くても、バグのないプログラムからバグは出ません。
テストだけでなく、レビューなどの指摘から品質を担保すれば?という考えですね。
![ほりごたつアイコン](https://horigotatsu.tokyo/wp-content/themes/the-thor/img/dummy.gif)
そう思った私は、レビュー密度を出してみることにしました。
レビュー密度は、書いたプログラムのステップ数とレビュー指摘の数で算出するものです。
さっそく算出してみると、
レビュー密度がかなり高めだったことが分かりました。
![ほりごたつアイコン](https://horigotatsu.tokyo/wp-content/themes/the-thor/img/dummy.gif)
ベテランのおじさんに1次レビューをお願いして私は2次レビューしよう
と2段階レビューを取り入れていたのですが、
それが数字に表れたんですね。
レビュー密度が高いことが分かると、少し安心できました。
そんな経験から、
![ほりごたつアイコン](https://horigotatsu.tokyo/wp-content/themes/the-thor/img/dummy.gif)
そう思えるようになりました。
数字は根拠になる。数字は自信につながる。
数字が本当にキライだと、もしかしたらSE業界は苦しいかもしれません。
でも単に慣れていないだけであれば、
自信につなげるためにも、なんでも数字化してみるといいのではと思います。
![ほりごたつアイコン](https://horigotatsu.tokyo/wp-content/themes/the-thor/img/dummy.gif)
数字に早く慣れたいなら、数字でアウトプットするクセをつけるのが有益です。
(私は自分の給与をExcelでまとめてます。)
▼アウトプット力を鍛えるならコチラの記事もオススメ!
アイデア力を鍛えるならこの本!「アウトプット大全(樺沢紫苑)」
文系SEが辛いポイント②入社後2年間のわからない時期
いちばん辛いのはなんといってもこれだと思います。
入社してしばらくは業務内容がちんぷんかんぷんの時期が続きました。
![ほりごたつアイコン](https://horigotatsu.tokyo/wp-content/themes/the-thor/img/dummy.gif)
この時期は本当に仕事が面白くないです。笑
主に何が理解できていなかったのかをお伝えしますね。
それは概念。
初心者の方は特に「概念」を理解することを意識するといいと思います。
というのも、私はここを理解するのに2年近くかかったから。
理解しなければいけない概念
①開発環境と本番環境
②開発環境内のデータベースやオンライン構成
③プログラムそもそもの仕掛け
この3点はいずれも、
「現場ごとに異なり、一般的な参考書にはない」という点で共通しています。
つまり
![ほりごたつアイコン](https://horigotatsu.tokyo/wp-content/themes/the-thor/img/dummy.gif)
ということ。
開発環境の理解
開発環境と本番環境というものが開発現場には存在します。
現在稼働中のシステムに機能を追加することも多々ありますが、
そういったときは「今現在実際に動いているプログラムを修正」するわけですよね。
動いているプログラムを直接修正したら簡単にバグりそうなのは想像すればわかると思います。
そのために必要なのが「開発環境」です。
開発環境・・・現在開発中のシステム
私はこれを理解できずに
準本番(もうすぐ本番に移行する)プログラムを上書きする
という大惨事を起こしたことがあります。
![ほりごたつアイコン](https://horigotatsu.tokyo/wp-content/themes/the-thor/img/dummy.gif)
とにかくこの「環境」という概念を理解しないまま進めると大変なことになりますし、
この概念がわかっていない状態の業務は結構辛いです。
私はこの状況をどう乗り越えたかというと
![ほりごたつアイコン](https://horigotatsu.tokyo/wp-content/themes/the-thor/img/dummy.gif)
先ほどの図を思い出してください。
このように、
本番がどうなってて、開発と何が違っていて、それぞれ何を参照しているのか。
このあたりを図に書き起こしてみます。
図にしてみると案外
![ほりごたつアイコン](https://horigotatsu.tokyo/wp-content/themes/the-thor/img/dummy.gif)
みたいな箇所がちらほら現れます。
それをきちんと質問しながら理解する。
そしてさらにイメージを固めていくのです。
プログラムの仕掛け
これも結構理解に時間がかかりましたね。。
私が初めて配属された部署ではJavaを扱っていたのですが、このJavaという言語は特に概念が難しいです。
先輩に質問してみても、概念が理解できている先輩からの抽象的な説明がさっぱり理解できませんでした。
この頃、私がやっていたことは以下の3つでした。
当時の勉強法
・Javaの本を買って読む
・eclipseというJavaの実行環境を自分のパソコンに入れて実際に動かす
・基本情報技術者試験というSEがよく受ける資格の過去問題にあるJavaの問題を解く
中学高校時代の勉強と同じで
「読む→手を動かす(演習)→試す」の流れはそこそこ定着するんじゃないか?
と思っていたんですね。
正直あまり理解は進みませんでした。
では結局、何をやって分かるようになってきたかというと、、
![ほりごたつアイコン](https://horigotatsu.tokyo/wp-content/themes/the-thor/img/dummy.gif)
実は家での勉強ではなく、業務内での確実な理解でした。(個人的な感覚ですが)
何度も何度もプログラムを行き来し、そして迷子になりました。
それでも少しだけ理解できたら「ここまでは読めた」と自分の理解を伝えたうえで先輩へ質問。
これが結構理解につながりました。
![ほりごたつアイコン](https://horigotatsu.tokyo/wp-content/themes/the-thor/img/dummy.gif)
Java以外でも、コンパイルやロードモジュールなど
プログラミングする上で必要な概念はいろいろあります。
それを目の前のプログラムを動かしてきちんと理解する。
これが結構大切ですね。
文系でもSEはできる!
今回は数字への慣れや概念理解に苦戦する話をしました。
が、逆に数字がニガテな理系や概念理解で躓く経験者もいることでしょう。
裏を返すと文系だから辛い、という内容はほぼなく、きちんと業務で出会うプログラムに一生懸命かじりついていくことで文系でもSEはこなせます。
これからSEを目指そうとしている文系のみなさん、
自分SE向いてないかもと悩む新人文系SEのみなさんは
ぜひ参考にしてもらえればと思います。
▼失敗ばかりだったり、仕事に悩んでいる人はコチラの記事がオススメ
失敗から学ぶために読むべき本!「ミスしても評価が高い人は何をしているのか?(飯野謙次)」
仕事ができない人の特徴は考え方にあった!「入社1年目から差がついていた!頭がいい人の仕事は何が違うのか?(中尾ゆうすけ)」
![ほりごたつアイコン](https://horigotatsu.tokyo/wp-content/themes/the-thor/img/dummy.gif)
SEの現場の様子を知りたいならコチラの記事もオススメ!
文学部卒はSE(システムエンジニア)に向かない?SEになって4年経って思うこと
SE(システムエンジニア)はきつい?就労時間とメンタルが比例しない話
SE(システムエンジニア)を辞めたい理由とは?SEの退職理由3選
リモートワークがIT企業なのに進まないワケ【SIer勤務の現役SE実体験】
文系のSE(システムエンジニア)が不利はウソ?現役文系SEが思う不利ではない理由
SE(システムエンジニア)の仕事内容は?文系女子SEがわかりやすく説明します
SE(システムエンジニア)に必要な能力とは!現役SEが仕事内容から解説!
SE(システムエンジニア)の仕事内容は?文系女子SEがわかりやすく説明します
文系はSE(システムエンジニア)の新人研修についていけない?研修に向けた心構え
入社前教育だけでOK?新卒SEに内定してる学生が入社前にすべきこと3選
思考力鍛えるならコチラの記事もオススメ!