池澤（入社4年目）

小野（入社3年目）

＜池澤さん回答内容＞

学生時代に遡っての経験という部分では、文系だからこそのハンデがあると感じます。例えば情報系などの学科にいた人との会話の中で、私自身は経験のない言語や開発環境について、彼は「学生時代に触ったことがある」と話していました。そういった意味でスタートラインのハンデはあります。ですが、仕事で扱う（開発する）業務システムとなると勝手が違うこともありますので、未経験の言語や開発環境についても実際の開発に携わってみると「自分でも案外できるじゃん！」となるのが「あるある」ですね。

言語や環境について感じたハンデ

— 経験のない言語や開発環境の話は具体的にどんな内容の話だったんですか？

＜池澤＞ 私が直接的に開発に関わったわけではないんですけど、今度スマホのアプリ（androidアプリ）を作るといった話題になりまして、その時に「開発環境がどう」とか「どういう言語を使ってどう」と話していたんですね。で、私自身はその部分に経験がなかったのに対して、理系出身の方は学生時代に経験があると言っていたので、やはりそういう部分ではどうしても差が出ちゃうなぁ…というのを感じました。

— なるほど。その話をしていたのは社内の方ではなくてプロジェクト先の方ですか？

＜池澤＞ プロジェクト先の方です。ちなみにその経験を持っていた方は少し年下の方でしたし、内心ちょっとだけ「マジか」って思いましたね。でも特に焦ったりとかはなかったです。

というのも私はもう4年目なのですが、有難いことに色んなプロジェクトに行かせていただいていて、その度に新しい言語や新しい環境に数多く触れてきているので、それがまた変わったところでおそらく対処できるだろうと思っていますし、業務系システムへの知見もあるから十分にカバーできるだろうと。だから、経験のない言語や環境のことを聞いてもそこまで危機感は覚えないです。

— 経験と自信を持っていらっしゃるのは素晴らしいですね！ちなみに、仕事で扱う業務システムとなると勝手が違うこともある〜とおっしゃっていますが、例えばどんなふうに勝手が違うんですか？

＜池澤＞ そうですね。読みやすいソースコードを書いたりするのはもちろんなのですが、自分で作って自分で使うだけではなく、チームで使って他の方に見てもらったりするものなので、誰が見ても読みやすいように作ることが重要です。

そうしたところは色んなシステムを触ってきていた経験が活きると思うので、「仕事でやる」となると学生時代にその言語や環境に経験があるということよりも、結果的にこの部分の方が大事かなって。

それにプログラミング言語ってなんだかんだ共通しているところが多いんですよね。基本的な考え方は一緒なので経験のない言語や環境については場数さえ踏めばなんとかなりますし、習熟の時間さえいただければ「できるじゃん」ってなりますね。

— 自分でもできるじゃんっていうのは、無意識にその対象に対してハードルを上げちゃっていたり、固定観念を持ってビビっていたりするけど、実際にやってみるとできちゃうあるあるってことですね？

＜池澤＞ そうですね。やったことないことって最初だけちょっとビビりますけど、やれば意外となんとかなるかなぁ。

— 「うんうん」って頷いていますけど小野さんも同じですか？

＜小野＞（笑）そうですね。完全にあるあるです。

じゃあ今度は、池澤さんと小野さんお二人にご回答いただきます。

＜池澤さん回答内容＞

私は学生時代に全くプログラミングに触れていなかったので、始めの研修から非常に苦労しました。会社支給の参考書を読んでも書いてあることが全く分からなかったので、当時の研修担当の先輩に基礎の基礎から相当教えていただきました。

＜小野さん回答内容＞

数学が苦手で理系には進みませんでした。特に物理は毎回赤点でした。社内の資格支援制度にある「基本情報技術者」の資格学習ではアルゴリズム分野の配点比率が高く、ロジカルシンキングが試される場面の多さにとても苦労しました。（ロジカルな思考が苦手なので。）

— 2人ともなかなか渋い回答（笑）じゃあ小野さんから。小野さんは数学が苦手で理系には進みませんでしたと。物理は毎回赤点でしたって言われると、文系の未経験にとっては勇気が持てるところかなとも思っちゃいました。ちなみに数学も物理も苦手な小野さんがプログラミングを学ぶということは、当時の小野さんにとって不安じゃなかったですか？

＜小野＞ もちろん不安でした。周りの友人たちもみんな文系。大学の授業でプログラムが入ってくるとなった時に「え、どうしよう、どうしよう…」って。みんなも同じように不安に感じていましたね。完全に文系あるあるです。

— じゃあ続いて。アルゴリズムは苦手ですか？

＜小野＞ 苦手です。ほんとに（笑）

基本情報技術者のアルゴリズムでは、本当に問題を解いていくしかなくて…。でもプログラムに活きるアルゴリズムというと数学とはあまり直結はしてなくて、プログラムをやるためのアルゴリズムみたいなイメージですかね？

— プログラムをやるためのアルゴリズム？

＜小野＞ なんて言うんですかね。数学で学んでいた分野とプログラムで必要になる知識や経験は少し違っていて、数学ができない私でもプログラムをいっぱい書いてみたり人のコードを真似してみたりと、とにかく自身で手を動かして書きまくることが大事ですね。回数をこなしていくなかで自然とできるようになっていく部分だと思っています。まぁ相変わらず苦手なことには変わりはないですけど（念押し）

＜池澤＞ うんうん。あれ難しいもんね。基本情報技術者はマジで苦労したよね（共感）

— わかりました。ありがとうございます。じゃあ続いて池澤さん。学生時代にプログラミングに全く触れていなかったので、初めの研修から非常に苦労しましたと。苦労した箇所は部分的に？それとも全体的に？

＜池澤＞ 当社は入社前研修もあってそこでの課題はこなせていたんですが、入社後研修でjavaの資格を取得するというのがあったんですね。資格試験に合格するためには体系的に勉強をしていく必要があって「ここのコレがわかる」ではなくて、「全体的にわかっている」のような状況にならないといけないんですけど、それがびっくりするほどできなくって…。結果ボコボコに落ちましたね。

— では全体的に苦労したと言っても過言ではないってことですか？

＜池澤＞ はい。最初が一番苦労しましたね。だからボコボコに落ちてからは逆に焦ってすごく頑張りました。

— 会社支給の参考書を読んでも書いてあることが全くわからなかったので、当時の研修担当の先輩に基礎の基礎から相当教えていただきましたとありますが、結果的に先輩に聞きまくっても分からず仕舞いなところはどうしましたか？

＜池澤＞ そうですね。やはり感覚として掴むっていうのはすごい難しくって。参考書を読んでいるだとぜんぜん掴めないですよね。プログラムの動きが「こういう時にこうなる」って自分で体感して理解するためにはとにかく書いて動かしてみる。そこに尽きますね。

— でも課題などを定義せずにひたすらやってるだけではだめですよね？

＜池澤＞ ですね。ベースに課題があって「これ、どうやるんだろう」って調べながらやる際に、ちょっと立ち止まって「もうちょっとこうしたらこんなことになるんじゃないかな？」といった好奇心を巡らせたり、そこに時間を使って考えたりしてみると深い仕様に気づけるとか。

もちろん参考書に載っていることはその通りに書けばそう動くんですが、「そうじゃない書き方をした時にどうなるのか」ということを考えることも大事。ちょっと改造するために書き換えたものが間違っていたら当然動かないですし、逆に本質を理解して改造していればちゃんと動かすことができて目的の結果が得られるので、そういうのがちょっとずつ増えていくと「こんなこともできるのかぁ！！」と楽しくなります。

ではこのお題は小野さんにご回答いただきます。

＜小野さん回答内容＞

まず、カラー印刷を行なったことです。何かとペーパーレスが騒がれるこのご時世ですが、IT業界では紙を使用する際は白黒印刷がマストです。ところがそんなルールを確認せずにカラーで資料印刷をしてしまい、しっかり叱られました。

また、私がクライアント機能の設計からチームに参画した際、「これじゃ使いにくいなぁ」と思ったボタンについて、より良いと考えた仕様に改変して設計書に落とし込みました。しかしそれはNG行為であり、設計前の企画・要件定義段階では、何人ものメンバーが検討を重ねて決めた仕様だという理解が不足していました。当然、設計をやり直しました。

— なかなかな内容ですね（笑）ちなみに誰に何を見せるための資料印刷だったんですか？

＜小野＞ これは自分のためにです。別の資料を参照しながら作りたいなって時に「印刷していいよ」と言われたので「よし！」と思って印刷をしたんですけど…

＜池澤＞ 鮮やかに印刷しちゃった？（笑）

＜小野＞ はい、鮮やかに（笑）

— で、叱られたと。ちなみに叱られた理由というのは、コスト面において？他にも何かありますか？

＜小野＞ 主にはコストですが、印刷についてはセキュリティにも厳しい風潮なので、実は印刷すること自体にあんまり良くないイメージがありまして。パソコンの持ち出しはかなり厳しく禁止されているんですが、印刷しちゃうとそれが持ち出せる可能性もあって。とはいえ資料の持ち出し自体もかなり厳しくなっているので、できれば印刷は避けてパソコンで見てもらいたいというところに繋がっています。

— わかりました。ありがとうございます。続いて、勝手にボタンの仕様を改変したということですが、やってしまったこととしていつ発覚したんですか？

＜小野＞ これは仕上がった設計書を確認してもらう時に。「あれ？なんかおかしいぞ」って先輩に言われまして。私は（こっちの方が使いやすいし…）と思って書いていたので勝手に変えたことがまずいことだとその時に知って（あ、やばい…）と。

— でも改変をした当初はそれがNG行為だということを知らずに、より良いものを作りたいからっていう気持ちが先行してその行動を取ったということですよね？それが結果として御法度だったと？

＜小野＞ はい。完全に御法度でした。

— じゃあお二人に聞きます。例えば今回の話のように「使いにくいだろうな」と感じたり、「この部分は歯痒いな」って思った時はどうするんですか？

＜池澤＞ うーん。基本的には最終的に使う人たちに決めていただきます。私たちは作る人間であって使う人間ではないので、どうしても観点がずれてしまいます。それに、お金を支払っていただくのはユーザーの方なので、私たちが決める分野ではないですからね。なので案は出しますが最終的に「どうしますか？」と確認します。その上で、この案に対してはこのくらいコストがかかりますとか、このくらいの時間がかかりますとか、そういうところで最終的にお客様に決めていただくことがほとんどかなと思います。

＜小野＞ そうですね。

— ありがとうございます。ちなみに設計をやり直したというのは、元の状態に戻したということ？

＜小野＞ はい、そうです。他の先輩がお客様からの要望を受けてきて、私がそれを設計書におこすといった段階だったので。

— では既にお客様側が「こういう風にしてくれ」と要望していたものを勝手に変えてしまったっていう？

＜小野＞ ですね（苦笑）

ではこのお題は池澤さんと小野さんにご回答いただきます。

＜池澤さん回答内容＞

初めはプログラミングの経験も少ないので、いい意味で「プライドがない」というのが文系出身だからこその強みではないでしょうか。下手な先入観もないので「できない」と決めつけずにまずはやってみる。そうしたチャレンジを続けていけば、やがては経験も理系の方を超えることができると思っています！

＜小野さん回答内容＞

経営的な目線は鋭いと思っています！私は経営学部出身ですが、単に経営分野だけではなくマーケティング、ICT、企画、会計、ものづくりなど、企業経営に関して広く学んできました。IT企業とはいえイチ企業として、社会に役立つシステムを開発・運用しながら利益を追求しています。現在の私はチームメンバーとしてシステム開発に携わっていますが、ただ開発するだけではなく、「どんなことが会社の利益に繋がっているか」ということを頭に置きながら働いていますし、今後チームをまとめるリーダーやPMになったときには、学生時代に学んだ知識が大いに活かせるのだと思っています。

— じゃあ池澤さんから。「やがては経験も理系の方を超えることができる」と。これは池澤さんがいろんなプロジェクトに携わって場数をこなしているからこその発言ですか？自信の部分っていうか。

＜池澤＞ 言ってしまうと、多少は（笑）

＜小野＞ さすが！

— それはこれまでも食わず嫌いせずに対応範囲を広げてきたからこそ言えると？

＜池澤＞ そうですね。とりあえずやってみないと何も始まらない。だからやる！で、気づいたら勝手にそうなっていました。

— 勝手にそうなったか（笑）

＜池澤＞ 私は後からプロジェクトに参画していくことも多いので、これやってほしいと言われたことから行なっていくのですが、やっていくなかでだんだんと全体がわかってきて「これってどうなってるんですか？」とか「ここ、もっとこうなるんじゃないですか？」といった感じで、いろんなこと話したりしていくうちに様々な問題に触れていくことになるので、そのシステムのプログラムにも詳しくなっていきますし、それ以外にも「このプロジェクトがどういう風に動いてるのか」などにも目が向けられるようになってきたので、総合的な経験として食わず嫌いせずにやっていくことが「結果として強く育つ」というか。

— なるほど、食わず嫌いをせずにっていうのは重要なワードっぽいですね。同じ文系の後輩が「ちょっと困ってます。自信ないんですよね」って言っていたら何てアドバイスしますか？

＜池澤＞ とりあえずやってみて考えようと。「経験がない、できない」ことがあれば「できない」ということが分かっているので、やる前から自信ないって決めるのは早いよねって。やってみる、経験をするということが大切なんじゃないかな。

— 理系の方よりもおそらく苦労している箇所が多いから、その分わからない人に教えたり乗り越え方を伝えるのも得意だったりするのでは？

＜池澤＞ 得意かなあ？自信はないですけどね（笑）

理系の方って頭の回転がすごい早いなとは思うんですけど、文章としてアウトプットに出したりとか、それこそエンドユーザーさんってプログラムが分からない方だったりしますし、納品するお客様にしても言語的な仕様などは全然わからない方も多くいらっしゃるので、そういった方に噛み砕いて説明する時には文系の方が有利かも。

だって私も元々わからなかった側の人間なので。

— これはラストの裏質問。実際のところどうですか？釘を刺す意味でも厳しめの意見を教えてほしいですねえー。

＜池澤＞ きちんと覚悟が必要だということですね。それこそ先ほどの小野くんの失敗談にあるボタンの仕様の話にも出ていましたが、勝手に自分で決められない部分が多々ありますし、プログラミング以外の仕事もたくさんありますから夢に見てるような仕事ではないですよ。

— なるほど。少なからずギャップはあると？

＜池澤＞ はい。でも、それは実際どの仕事であっても同じじゃないですかね。

＜小野＞ ですね。文系でエンジニアを目指すとすればプログラミングの経験はほとんどないはずなので、そこだけは入社してからひたすら頑張らないといけないと思います。

＜池澤＞ どうしても最初のうちはプログラミングが主な仕事になってくるので、そこをいかに頑張って身に付けていけるかが鍵ですね。「絶対に挫折しないぞ！」っていう強い気持ちがないと研修途中からガクっと心が折れちゃいます。私たちも例外なくみんな折れていました（笑）

でも、逆に挫折しない気持ちと覚悟を持って臨めば問題ないって言っても過言ではありません。

＜小野＞ それに研修を明けて初めて参画するプロジェクト先でも、システムを作りだしたところでだいたい挫折するので（笑）

でも絶対に最初のうちに挫折した方がいいかな。

— 入社後研修で挫折して、さらにプロジェクト先でもまた挫折する？

＜池澤・小野＞ 挫折します！（断言）

＜小野＞ でも誰かしら社内の先輩が駆けつけるような体制が取れているので存分に挫折してもらって大丈夫。困ったところは先輩がいつでもカバーしますので。

＜池澤＞ 私はいつもここ（事務所）に逃げてきますよ（笑）

辛いことがあって誰かに話を聞いてほしいなって時は自社に帰ってきて先輩に話を聞いてもらいます。そこでちょっとスッキリしたりしますね。私としてはそういう下地があるということが大事なんじゃないかなと思います。

— あとは何か言っておきたいことはないですか？

＜小野＞ そういえば今日の話なんですが、終業してプロジェクト先を出てくる時に「このあと自社に戻ってインタビューがあるんですよ」って話をしたんですね。テーマが文系エンジニアの話なんですよって話していたら、理系の先輩から「え？小野君、文系だったの？」って。

— ほー、嬉しかった？

＜小野＞ （照）まぁ、嬉しかったですね。でもそのぐらい溶け込んじゃってるってことですね。文系でも。

＜池澤＞ 理系文系というのは実際の現場では意外と意識されていない感じだよね。

＜小野＞ はい。入社条件だと理系卒の人っていうのはよくあるんですけど、プロジェクト先ではそういったものは特に感じたことはないです。

— だから最終的には、文系ハンデっていう表現とはちょっと違うかなっていうことですよね。結局のところはご自身たちの…？

＜池澤・小野＞ はい！「どれだけ頑張るか！」ということですね。