みなさんこんにちは。文系女子ＳＥのほりごたつ(@horigotatsuSE)です。
と悩んでいませんか？
私も入社３年目くらいまでは、失敗ばかりで悩んでばかりでした。
上記の通り、私は文系未経験から新卒でSEになりました。
そのため最初はプログラムも読めないし、ミスも多かったです。
「向いてない」と思うことも何度もありました。
そんな私が失敗や悩みを乗り越えて仕事を続けてきた方法をお伝えしていきますね。
SE向いてないと悩んだ実例
文系からＳＥになった方や
プログラミングの経験自体はあっても経験したものと全然違う言語を扱うことになった方など
いろいろな理由で今仕事で扱っているプログラムが全然読めなかったり、
何やってるか全然わからなかったりで悩むことがあると思います。
私もそうでした。
SE向いてないと悩んだ実例１．プログラムが読めない
入社して最初に配属された部署ではJavaを扱っていたのですが、
入社前研修や入社時教育で扱ってたのはC言語だし、
そもそもJavaの仕組み（オブジェクト指向）も全然理解できないしで
全然プログラムが理解できませんでした。
試しにプログラムを読んでみてもこんな感じ。
経験のある人も多いと信じたいですが。。
迷子だ。。
こんな調子で日々迷子になっていました。
周りの同期はプログラム内容のすり合わせも終えて修正に取り掛かっている中、
私だけいつまで経っても現状把握すらできないのは悔しくて悲しくて。。
向いてないのかもなぁと思ったりもしました。
SE向いてないと悩んだ実例２．プロジェクトの推進力がない
バックエンドの現場に異動して入社３年目を迎えたころ、
案件のあたま（要件定義から外部設計へ落とす）から終わり（納品）までを私主導でやることになりました。
私がはじめて主導でやった案件
・まるっとすべてが新設のシステム
・プログラムも３～４本新設
・規模としては1.6kstepくらい
今思えば新設とはいえそれほど難しいこともやらないので大したことはないのですが、
そのときは新設が初めてだったこともあり、スケジュール引くにも分からないことだらけでした。。
プログラムはどれくらいで書けるのかな。。
これはオンスケ？それとも。。
・・・
こんな感じで負のスパイラルでした。
どうやったらプロジェクトが進んでいくのかが全然わからず、
結構悶々と悩み続けました。
SE向いてないのかな？という悩みを解決した方法
さて、ここまで悩みをお伝えしてきました。
という方もいるでしょう。
安心してください。
私は上記の悩みをしっかり解決し、今では開発責任者を任されています。
どんな方法で解決したのか、お伝えしていきますね。
「プログラムが読めない」の乗り越え方：”プログラム”を読もうとしない
私が読めなかった原因はズバリ「そもそもの構成がわかってないのにプログラムからたどろうとしている」ことでした。
ある日、あまりにも迷子になるので「迷子になってしまって。。」
と恥ずかしい相談を先輩にしにいくと、逆に先輩からいくつか質問をされました。
聞かれた内容は以下の２点。
先輩から聞かれたこと
・そもそも全体として何やっているかはわかる？
・このプログラムはそのうちどのあたりかわかる？
これを聞かれて結構ハッとしました。
確かにプログラム自体を読もうとしても、
地図も見ずに町をウロウロしているようなもの。
そのあと先輩から大まかな構造を説明してもらと、
・画面から入力された値を取ってくる箇所
・データベース（Oracle）にアクセスして実際にデータを取得する箇所
・取得した内容を画面へと渡す箇所
の大きく３つに分かれていることがわかりました。
プログラム読むためにやったこと
・まずは今読んでいるプログラムがどこにあたるのかを整理
・別のプログラムに飛んでも、それがどこにあたるのかを整理
これを繰り返していくと、変数１つをとっても「ざっくり何が入ってきてるのか」
を把握することができるようになってきました。
それでもわからなければ、
と自分がここまで理解している内容＋聞きたいこと
の合わせ技で先輩に聞くようにしました。
この聞き方をすることで先輩もどこでつまづいてるのかわかりやすいので
いろいろと教えてもらえました。
「推進力がない」の乗り越え方：数字を自信にする
今思うと「概算」という考え方が全然身についてなかったのかな、と思います。
今の自分だったらどう動くのか振り返って考えてみると、
まず要件定義が出てきたところで上司に相談。
なぜなら上司はいろいろな案件を知っていて”概算”の感覚が鋭いからです。
ここが調査しなきゃいけないポイントですよね。
ざっくりこんなプログラムとこんなプログラムをつくる感じですよね。。？
こんな感じで徐々に細かい内容についてすり合わせるのがまず一歩。
そうするとたぶん
とか
とか言ってくれるはずで、それをもとにざっくりの設計方針を固めておくと
・調査にはどれくらい時間かかるのか
・設計書はどれくらいの量になるのか
・プログラム組む時間はどれくらいなのか
がざっくり見えてきます。
この「ざっくり」が結構重要で、細かくなくても「ざっくり」が見えると
それを根拠に時間やスケジュールなどさまざまなものが見積もれるようになります。
ポイント
「はじめてやることだから見積もれない」のは間違い
「はじめてやることだからこそ見積もる」ことが必要
過去の数字・先輩の経験測・自分の経験・・・etcを根拠にする！
はじめのうちから見積を精度上げてやるのは無理ですが、
過去の開発時の数字や先輩の経験による数字を引っ張りだせれば
それを根拠にざっくりは見積もることができるようになります。
もしそれが結果として実態とかけ離れていたとしても、
次の見積に生かしていければよいのです。
そのためにも、自分が見積もろうと思ったときの根拠となる数字
実態の数字、過去の開発時の数字をいろいろ集めておくことをオススメします。
まとめ：仕事に悩みはつきもの
どんな仕事だってそうですが、
悩みはつきものだしラクな仕事なんてないと思っています。
今回挙げた２つの例から、私は結構「細部まで細かく見ようとしがち」だったのかも、と思います。
私と似たようなことで悩んでいる人は、
まずはざっくりでいいから把握していく、
ということを意識してみてみると案外解決策につながるかもしれません。
次回は、私の実体験その２として、
私が失敗したこととそこから見える解決策をお伝えできればと思います。
仕事で悩んだらコチラの記事もオススメ！
仕事ができない人の特徴は考え方にあった！「入社１年目から差がついていた！頭がいい人の仕事は何が違うのか？（中尾ゆうすけ）」
失敗から学ぶために読むべき本！「ミスしても評価が高い人は何をしているのか？（飯野謙次）」
仕事を抱え込むタイプは読みたい本！「最速で１０倍の結果を出す他力思考（小林正弥）」
仕事がうまくいかない時に読みたい本「多分そいつ、今ごろパフェとか食ってるよ。（Ｊａｍ）」
ビジネスにおける重要な思考法が詰まった本！「Think Smart（ロルフ・ドベリー）」
SE(システムエンジニア)の失敗は許されない？現場SEの失敗談【文系女子ＳＥの実体験】
工数の見積もりこそ「ざっくり力」が重要？見積をこなすSEがコツを伝授
仕事がうまくいかないのは国語力のせい？！ビジネス国語の重要性
仕事がうまくいかないのは○○のせい？入社5年でサブリーダーになった女の仕事術