プログラミング未経験のエンジニア女子が、アウトプット頑張ったら 設計わかるようになれちゃった話

プログラミング未経験の エンジニア女子が、 アウトプット頑張ったら 設計わかるようになれちゃった話

自己紹介 名前：加美川 真由子 (かみかわ まゆこ) 年齢：25歳(社会人3年目) 所属：株式会社デンソークリエイト 業務：ソフトウェア開発(C#) プログラミング未経験で入社。

エンジニア2年目、設計ができない ⚫ 大学時代は理系の学部にいたが、プログラミングはやってなかった。 ⚫ 「プログラミングでモノづくり、やってみたいなー」と、 プログラミングに興味をもったことから、現在の会社に就職。 ITの知識もないまま、プログラミングもまともに経験していないまま、 「やってみたい！」という気持ちだけでエンジニアの世界に飛び込んだ。 当然、新人研修についていけず、落ちこぼれる。 プログラミングのできる同期にみんな教えてもらわないと研修の課題が進められず、 「もしかして自分、このままだとヤバいかも？」と気づいた。

エンジニア2年目、設計ができない ⚫ 新人研修をかろうじて乗り越え、デスクトップアプリを開発するチームに入った。 ⚫ ありがたくも、勉強時間をしっかり割かせてくれて、質問もしやすいチーム。 ⚫ プロダクトで使うプログラミング言語の学習を、時間をかけながらも進め、 簡単なコードならどうにか読み書きできるようになってきた。 ⚫ しかし一つ上の先輩と比較すると、学習に使った時間はなんと2倍。 たくさん時間をかけたぶん、しっかり学習できたのでは？ たくさん時間をかけたが、ぜんぜん成果がでなかった。 プロダクトのコードは理解に時間がかかった。説明をもらってもわからない、書けない。 そんな状態なので、設計なんてもってのほか。 設計の打ち合わせに出席しても、質問すらできなかった。

できないままではいられない、いたくない できるようになりたいこと ⚫ プログラミングスキルを上げて活躍できるようになりたい！ ⚫ 設計も経験して、できるようになりたい！ ⚫ 設計の打ち合わせで発言できるようになりたい！ そこで…… 「GoFのデザインパターン23パターンについて、 クラス図とコードを作成して学習し、オブジェクト指向設計を わかる・できるようになる！」

デザインパターンとの出会い ◆なぜ、デザインパターンなのか？ • 自分のチームには設計もプログラミングもできるすごい先輩が何人もいる。 • 中には、自分と同じようにプログラミング未経験でエンジニアになったのに、 設計・プログラミングをバリバリできるようになった先輩もいる。 私も、先輩方のように設計やプログラミングができるようになりたい！ だけど、先輩たちはいったいどうやって、 設計力・プログラミングスキルを鍛えたんだろう……？ そう思っていた時に、デザインパターンと出会うこととなった。

デザインパターンとの出会い チームの先輩にデザインパターンの学習をすすめられた。 しかし、ただ勉強するだけではないらしい。 • 学習は、アウトプットを伴った方がクオリティも効率も上がる。 • 設計・プログラミングのアウトプットは、「設計書を書く」・「ソースコードを書く」・ 「書いた成果を説明する」こと。 • 23個のデザインパターンについて上の3つのアウトプットを行うことで、効率よく 設計・プログラミングのスキルをメキメキと伸ばすことができる！ その先輩の 小島優介 さんが Developers Summit 2020 KANSAI で ベストスピーカー賞1位になったセッションで発表された学習方法。 そして、チームのデキる先輩たちがやっていたという実績もある方法。 自分もやったら同じように設計分かるようになるかも！と思って取り組むことにした。

GoFのデザインパターンとは ◆そもそもデザインパターンとは？ ソフトウェア設計において、過去のすごいエンジニアたちが生み出した、 「設計でよく起きる問題」に対するノウハウをパターン化し、名前をつけたもの。 デザインパターンを学ぶことで、経験の浅いエンジニアでもよい設計を知り、 活用することができる。 ◆GoFのデザインパターン GoF(ギャング・オブ・フォー)と呼ばれる4人の技術者が 『オブジェクト指向における再利用のためのデザインパターン』で発表した 23のデザインパターンを指す。

デザインパターン勉強してみた チームの先輩方は、次のようなサイクルでデザインパターンを学習していた。 ⚫ 1つのパターンについて、設計とプログラミング、レビューを行う。 ⚫ このサイクルを、全23パターン分繰り返す。 題材とするパターンに 沿った設計を考えて クラス図に起こす。 設計 クラス図をもとに、 実際に動くプログラム を作る。 プログラ ミング 作ったクラス図と プログラムを先輩に レビューしてもらう。 レビュー 実績もある方法。同じように勉強すれば、きっと大丈夫なはず！

デザインパターン勉強してみた まずは先輩と同じように23パターン、勉強してみた。 ←実際に作成した Interpreterパターンの クラス図と、実際に プログラミングしたアプリケーション ■学習時のルール ① 設計のネタは、学習対象のデザインパターンを使えそうで、 かつ「実際にありそうなシステム、アプリケーション」を自分で考える。 ② チームの先輩の予定を確保したうえで、23パターン分のレビューを各2回、 2日に1回のペースでお願いする。

後は勉強するだけ、めでたしめでたし……と思いきや 最初はまったくうまくいかなかった。 その理由は……デザインパターンがわからないことだった。 GoFのデザインパターンについて全く何も知らない状態だったので、 設計を始める前にまず「デザインパターンの理解」をしなければならなかった。 しかし、基礎知識すら足りない私では、どれだけ調べてもデザインパターンが 全然わからなかった。 理解できないので、先に進めない！ 学習 設計 プログラ ミング レビュー

設計も、プログラミングも、うまくいかない 時間をかけて勉強したり、先輩に質問したりして、やっとこさ学習は終わり。 ……しかし、その後の設計、プログラミングもうまくいかなかった。 ① 設計したことが全然ないので、設計を考えるのに時間がかかった。 ② 設計が完成しても、プログラミングスキルが足りないので プログラミングにも時間がかかった。 ③ 設計・プログラミングが終わらず、レビューができなくなっていった。 学習 設計 プログラ ミング レビュー

手詰まり ■理想的な進め方 ① 設計のネタは、学習対象のデザインパターンを使えそうで、 かつ「実際にありそうなシステム、アプリケーション」を自分で考える。 ② チームの先輩の予定を確保したうえで、23パターン分のレビューを各2回、 2日に1回ペースでお願いする。 ■実際 ⚫ 自分で勉強するだけではデザインパターンがわからず、 自分で設計を考えることも、それをプログラムすることも難しい。 ⚫ 上記のことから、デザインパターンの学習・設計・プログラミングに それぞれ時間がかかるため、2日に1回レビューができない。 設計力・プログラミングスキルをつけたいのに、 設計力・プログラミングスキルがないせいで進まない

やり方変えてみた ■対策① 設計・プログラミングについて、チームの先輩にペアプロを お願いした。 ⚫ 自力でできない設計・プログラミングについて、先輩からアドバイス・サポートを いただきながら進めることで学習効率をアップ。 ⚫ UIのプログラミングは開発プロダクトで使う設計の考え方も交えて学習。 ⚫ C#の基本的な使い方を教えてもらいながらプログラミングすることで、 設計を学びつつプログラミングスキルも伸ばす。 ⚫ 先輩といっしょにコードを書くので、すごい先輩の技術を間近で学べる。 学習時間は1日1~2hのペースで合計166h、 プログラミングした行数は7052行になった

やり方変えてみた ■対策② レビューを設計後・プログラミング後の2回に分けて やってもらうように変えた。 クラス図が書き終わったときに一度見てもらうことで、分かっていないところを 教えてもらえたり、間違った理解のままプログラミングしてしまわないようになった。 単純にレビューの回数が増えたことで、対策①による効率アップの効果もあり、 2日に1回レビューをお願いできるようになった。 設計のレビュー結果を反映できる！ 設計 レビュー プログラ ミング 設計ミスでやり直しにならない！ レビュー

集大成としてのアウトプット ⚫ 学んだことをさらに定着させるために、 社内・社外のLT大会で発表してみることにした ⚫ StateパターンとStrategyパターンを間違ってプログラム書いちゃった！ という、学習時のエピソードをもとに学んだことを発表することにした。 ⚫ 間違えたときのことはよく覚えていたし、 間違えたからこそしっかり勉強したということで、 余裕で発表できると思っていた。 設計 レビュー プログラ ミング しかし…… レビュー アウト プット

学習しただけでは、足りない できなかった。 ⚫ まず資料が作れなかった。 StateパターンやStrategyパターンがどんなパターンだったかを、 学習から時間が経ったことで忘れてしまっていた。 ⚫ 学習したときに作ったプログラムやクラス図を見直したら何となく思い出せたが、 各パターンのメリットや目的が全然わかっていなくて、人に伝わるような 説明ができなかった。 ⚫ 確かに23パターンの学習はしたものの身についていない部分が多く、 「自分には、学習しただけでは足りない」ということがわかった。 「あんなに頑張ったのに、ちっとも身についてないじゃん！」 と、とてもショックを受けた。

学習しただけでは、足りない なので…… 「人にデザインパターンを説明できること」を目標に、 発表するデザインパターンについて勉強し直すことにした。 ⚫ 理解が曖昧なところは本やwebで調べ直した。 すると、前に勉強したパターンの目的やメリットを思い出せた。 ⚫ むしろ、最初に勉強していたときよりもスムーズに理解できた。 ⚫ 資料作りも、発表原稿作成も、自分の力でパターンを説明できるので、 サクサク進められるようになった。 ⚫ 勉強し直したことで、ちゃんと自信を持って発表もできた！ ということで、調子に乗って別のパターンについて、 技術記事投稿にチャレンジすることにした。

技術記事の投稿にもチャレンジしたが…… しかし、記事を書く手は止まってしまった。 「使い分けのわからなかったパターンを整理してみる」 「理解が難しかったVisitorパターンを自分で説明してみる」など、 自分が学習中に悩んだことをネタにしたが、 やっぱり「悩んだことは覚えていても、学んだことを忘れている」状態だった。 なので、発表のときと同様に、 「人にデザインパターンを説明できること」を目標に、 勉強し直して記事を5件書いた。 記事を書いたことで、ただ学習しただけでは身につかなかった知識を定着させ、 しっかり理解することができた。

結論 結論、アウトプット超大事でした…… 技術記事を書くことも、社外で発表をすることも、 自分からかけ離れたすごいエンジニアがやることだと思っていた。 しかし、そうではなかった。 私のように経験が浅く技術力も低いよわよわエンジニアにこそ、 発表や記事投稿などのアウトプットが必要だった。 私はきっと、アウトプットしなかったらデザインパターンを学習しただけで終わっていた。 そしてそのまま、せっかく得た設計・プログラミングの知識を忘れ去ってしまっていた。 そうしたら今頃、設計スキルの向上に大きな差が生まれていたはず。

ちなみに、発信、怖くないんですか？ もちろん、最初は怖かったです！！！！ 自分の発信したことなんて誰の役にも立たないかもしれない。 「こんな質の低い発信をするならエンジニアやめちまえ」って言われるかもしれない。 そう思っていましたが、これまで心無いコメントをもらったことはないです。 むしろ、自分では自信のないことでも、発信してみたら良いフィードバックを もらえたことの方が多かったです。 慣れていくうちにだんだん怖さは薄れていきました。 とはいえ、「勉強中のため、誤っている場合は教えていただけますと幸いです。」と 記事内に書いて、一応予防線は張っています……笑

勉強開始から180日、転機は訪れる 今までは… ・設計の打ち合わせに全くついていけず、質問もできなかった。 「聞いていても何もわからない、自分は打ち合わせに 参加している意味がない。」と、とても悔しい時期が続いた デザインパターン学習後のある日… ・ある日の議論中、設計に気になる点を見つけ、手を挙げた。 ・「的外れだったらどうしよう」と思いつつも発言してみたところ、 「確かに問題があるね」となり、自分の指摘が正しかったことがわかった。 チームメンバーの中で誰より早く指摘したことも褒められた！ 「まだまだ頑張っていけるかも!!」と思えた

最終成果 Before 課題 ちょっとすごく頑張ってみた結果 After ①設計の 経験を積む 設計の経験がない。 23パターン分の 設計の経験を積んだ！ ②プログラミング スキルを 向上する 時間をかけても設計を コードに落とせない。 説明もできない。 自力でコードを書き、 レビューで考えを 説明できた！ ③設計の 議論ができる ようになる 発言できない。 そもそも、議論に ついていけない。 設計の問題点に 誰より早く気づいて 発言できた！

そして一年後…… チームに後輩が入り、かつての自分と同じようにデザインパターンを学習することに。 →自分がついに後輩の設計・プログラムをレビューすることになった。 「指導する以上、間違ったことは絶対教えられない！ ……けど、Proxyパターンってどんなパターンだっけ！？」 人に指導することもアウトプット。 かつて記事投稿や発表でやったのと同じようにまた勉強することにした。 今度は教えるためなので、特に念入りにパターンを調べ直した。すぐに思い出せた。 その後レビューで後輩のクラス図とコードを確認して、デザインパターンに沿った、 正しい設計・プログラムになっていると判断できた。 教える側にまわることで、またひとつ成長できた。

結局、つよつよエンジニア女子になれたのか なれてないです。 ⚫ 設計の打ち合わせに参加していても、 「やばい……何にもわからない……」と思う日があったり…… ⚫ 自信満々で打ち合わせに持って行った設計に、 設計の本筋とは関係のない基礎的なミスがあったり…… 全然技術力伸びないなあ、エンジニア向いてないよなあ、 と悩むときも、もちろんある。

「ほんのちょっと」の、すごい原動力 それでも折れないのは、 166hかけて7000行コーディングして、 デザインパターン23パターン勉強しきって、 それでも足りなかったので発表と記事投稿のアウトプットも頑張ったら、 ちゃんと成果が出たから。 成果としては 「ほんのちょっと、当たり前」 でも、 「この調子で頑張り続けられたら、もっともっと成果を出せるようになれるはず」 と思える、これからもエンジニアとして頑張っていくための 「(自分的には)すごい」原動力 になった。

つよつよエンジニア女子を目指して できるようになったことは、 「エンジニアとして当たり前のこと」。 それでも、プログラミング未経験でエンジニアの世界に飛び込み、 スキルの無さに苦しみ続けた私にとっては、 「これで、明日もエンジニア頑張れる」と思えるようなこと。 これからも勉強して、アウトプットして、 「ちょっとだけど(自分的には)すごい」 と思える成果を出しつづけて、 いつか「つよつよエンジニア女子」と胸を張って名乗れるエンジニアに なれるように頑張っていきます！