エンジニアになったのはいいけれど、うまくいかないこと、分からないことだらけ。もしかして自分に向いてない……！？ バリバリ活躍する先輩や同期を横目に、ふとそんな不安がよぎることはないだろうか。

そんなふうに自分のスキルに自信を持てずにいる人に紹介したいのが、2022年11月2日に開催された『Women Developers Summit 2022』で発表を行った、デンソークリエイトのエンジニア加美川真由子さんの成長ストーリーだ。

株式会社デンソークリエイト 技術部
加美川 真由子さん

2020年に株式会社デンソークリエイトにプログラミング未経験で新卒入社。同年よりツール開発業務に従事し、設計・実装を行う

「新人研修中も、現場に配属されてからも、分からないことやできないことだらけ。実装だけじゃなく設計もできるようになりたいけれど、コードが理解できないから、質問すらできなくて……。以前は、よわよわ・崖っぷちエンジニアでした」

そう話す彼女だが、今では、現場の戦力となり、後輩の教育を任され設計についても説明できるようになった。一時は「エンジニアは向いていないかも」と悩んだ彼女が、実力と自信を付けることができたきっかけとは？

何もできない自分が悔しくて、帰宅後に涙…「絶対に、設計ができるようになりたい」

20年4月、私はデンソークリエイトにエンジニアとして新卒入社しました。一応、理系の学部出身なのですが、プログラミングは未経験。もともと興味はあったので、「取りあえずやってみよう」という精神でこの世界に飛び込みました。

ただ、新人研修からいきなりつまずいてしまったんです。プログラミングの基礎すらよく理解できず、見かねた同期にいつも助けてもらっていました。

そうこうして研修を乗り越えた後は、デスクトップアプリを開発するチームに配属されて……何とか周囲に追いつこうと必死に勉強しましたね。

でも、先輩の打ち合わせに同席していても、ほとんど内容が分からないんです（笑）。先輩たちは日本語を話しているのに、まるで全く知らない海外の言葉を延々と聞いているような気持ちでした。

そこでも何とか食らいつこうと頑張ってメモをとって帰宅後に見返すのですが、自分で書いたことの意味がさっぱり分からないんですよ。当時は、何もできない自分が悔しくて、家でひっそり泣いたこともありました。

でも、それと同時に「このままじゃ嫌だ。スキルを上げて設計ができるようになりたいし、打ち合わせで私も発言したい！」と思い、学習法を見直すことにしました。

「設計書を書く→ソースコードを書く→書いた成果を説明する」学びにアウトプットを足すと学習がより効果的に

チームの先輩にどんなふうに学習するといいか相談すると、「デザインパターンの学習がおすすめだよ」と教えてもらうことができました。

デザインパターンとは何かというと、設計をする上でよく起こる問題の解決策をパターン化したものです。いわば良い設計の見本といえますね。

その中で私が学習したGoFのデザインパターンについてご説明します。

これは「Gang of Four」の略で、著名な4人のエンジニアを指します。この4人がオブジェクト指向に役立てようと持ち寄ったのが23種類のデザインパターンです。

GoFのデザインパターンの学習とは、具体的に何をするのかというと、まず、一つ一つのパターンについて、設計を考えてクラス図を作ります。

次にクラス図をもとにコードを書き、プログラムを作成。最後にクラス図とプログラムを先輩にレビューしてもらいます。

この、「設計書を書く→ソースコードを書く→書いた成果を説明する」というサイクルを、23パターンすべて繰り返すのが先輩から教えてもらった学習法です。

この先輩は小島優介さんという方で、『Developers Summit 2020 KANSAI』でベストスピーカー賞をとった際にもこの学習法について解説していました。

小島さんいわく、勉強はアウトプットしながら取り組んだ方が効率的だそうです。

ただ、いい学習法を見つけてこれで全てがうまくいく、めでたしめでたし……とはなりませんでした。

私のような初心者エンジニアだと、クラス図を書く前のデザインパターン自体が理解できず……。学習サイクルに入る前からつまずいてしまいました。

デザインパターンの学習もしましたが、その次の設計やプログラミングでも時間がかかり、手詰まり状態になることも多かったのです。

学習のつまずき突破に役立った二つの対策

それでも成長をあきらめたくなかったので、二つの対策をとりました。

対策その一は、チームの先輩に設計・プログラミングのペアプロをお願いしたことです。週3回、一緒に設計とプログラミングの作業をしてもらうことにしました。

このおかげで、分からないことはその都度教えてもらいながらデザインパターンの学習をしつつ、先輩の考え方を学ぶこともできました。

対策その二は、レビューの回数を増やしたことです。

それまで設計・プログラミングの後にレビューをしてもらっていたのですが、設計後に1回、プログラミング後に1回と、分けてレビューしてもらうことにしました。

小まめに成果を見てもらうことで、間違えたまま先に進むことがなくなりました。

“よわよわエンジニア”こそ、アウトプットが「超大事」

さらに私は、学習の集大成としてアウトプットにも取り組むことにしました。具体的には社内外の発表会に登壇したり、技術記事を投稿したりすることです。

ただ、私はここでもつまずきを経験します。発表会の資料づくりや記事の執筆の段階で、デザインパターンのメリットや目的がスムーズに思い出せないのです。

人に説明するには自分が理解していないといけないことを思い知らされました。

理解があいまいなところは、Webサイトや本で学び直しました。そのおかげで作業をサクサク進められるようになり、自信をもって発表できるようになったと思います。

ここまで私の経験談をお話ししてきましたが、結論、「アウトプットをすることってとっても大事」と改めて強調しておきたいです。

私は社外への発表も記事の投稿も、誰もが認めるスキルをもついわば“つよつよエンジニア”がすることだと思っていました。

ですが、それは大きな間違いでした。むしろ私のように経験の浅い“よわよわエンジニア”こそ、知識を定着させるためにアウトプットするべきだったのです。

デザインパターンの学習とアウトプットに取り組み始めてから180日後、ある変化がおとずれます。

いつものように打ち合わせに参加したところ、設計に違和感を覚えるところがあって。「的はずれだったらどうしよう……」と思いながらも勇気を出して発言すると、「確かに、その問題があるね」と言ってもらえました。

自分が発言できるようになったことも、デザインパターンの学習とアウトプットを経て初めてチームに貢献できたことも実感できて、すごくうれしかったです。

それから1年後。チームに後輩が入り、デザインパターンの学習をすることになりました。そう、今度は自分が後輩にレビューする立場になったのです。

後輩指導もアウトプットの一環。後輩に説明することによって自分自身が勉強する機会にもなっているので、すごく貴重な経験をさせてもらっているなと感じます。

とはいえ、エンジニアとしてはまだまだです。打ち合わせの場で適切な答えがすぐ出てこないこともありますし、現場で設計を任されるようになったけれど基本的なミスを先輩から指摘されることもあります。

でも、私の心は折れません。それは今までにデザインパターンを23種類学習し切って、発表や記事投稿などのアウトプットを頑張った結果、確かな成長を実感できているからです。

分からないこと、できないことがあっても、着実に学習して努力することで、どうにかできるという成功体験を積むことができたからこそ、不安になりすぎることはなくなったんだと思います。

この調子で頑張り続ければ、私はきっと、エンジニアとしてもっと成長できる。そう信じています。

文/まゆ