はじめに
この記事は、
- プログラミング歴： 入社時はゼロ
- 実装力：かなり微妙
- 設計の知識：当然ゼロ
という、 エンジニアレベルゼロ、むしろマイナス だった よわよわエンジニアこと私がデザインパターンに出会って勉強をしてちょっと成長して、「明日もエンジニアがんばろう」と思えるようになるまでの「ちょっとすごく頑張ってみた」記録です。
エンジニア歴半年、設計ができない
入社後、新人研修を終えてツール開発の業務に配属されて、半年近く経過した頃。
当時、プログラミング未経験の状態からC#・WPFを学習し、ようやく基礎的なコードの読み書きはできるようになってきた……という状態でした。
しかし、ツール開発業務でバリバリ開発を進めていくには、 実装力が依然不足していました。 コードの理解に時間がかかり、自力での実装もまだ難しいため、開発の主担当は持てませんでした。
また、 設計についてもまず経験がありませんでしたし、そもそも設計の知識もありません。 当然設計業務は担当できません。
もちろん設計の議論には到底ついていけず、議論中に発言することも難しい状態 でした。
「議論を聞いていても何もわからない、自分はここにいる意味がない」
と、非常に悔しい時期が続きました。
デザインパターンとの出会い
自分のチームには、設計も実装もバリバリできる先輩が何人もいました。
先輩方のように設計も実装もできるようになるためには、私はどうしたら良いんだろう。
そう思っていたところで、先輩方も学んできた設計の題材として薦められたのが GoFのデザインパターン でした。
先輩方は、GoFのデザインパターン23パターンをそれぞれ、以下の3ステップで学習していました。
①設計：題材とするパターンに沿った設計を考えてクラス図に起こす。
②実装：クラス図を元に、実際に動くプログラムを作成する。
③レビュー：作成したクラス図とプログラムを先輩にレビューしてもらう。
設計業務ができるようになるためには、そもそもオブジェクト指向設計の知識、技術を獲得することが必要ですし、デザインパターンを題材とすることで良い設計とされている設計パターンを23個も学ぶことができます。
全パターン実装しながら学習するので実装経験ももちろん積めます。
レビューを挟むことで間違った理解のまま完了してしまうこともありません。成果物を説明する経験も積めます。
「すごい先輩方と同じ勉強をしたら、私も先輩方みたいに設計実装できるようになれるかも！」
これはやるしかない、と当時の私は思って、デザインパターンの学習に取り掛かりました。
うまくいかない！
結果として、最初はうまくいきませんでした。
学習の進め方として、先輩の行っていた設計→実装→レビューの3ステップに加えて、以下のことを意識して取り組んでいました。
-
参考書籍のサンプルコードの変数名を変えただけの設計にせず、自分で何か「実際にありそうなシステム、アプリケーション」を題材にして設計を考える。
例えばInterpreterパターンなら、計算機を題材にして設計・実装を行うなど。 -
2日に1回のペースで、先輩の予定を確保してレビューをお願いする
ところが、自己学習だけではデザインパターンの理解ができず、設計以前の学習の段階でつまずいてしまいました 。
当然、自力での設計は難しく、また作った設計を実装することも難しく、学習に時間がかかり、設計に時間がかかり、その先の実装でも時間がかかり……ということが重なりました。
そうしているうちに、 2日に1回のレビュー実施も維持できなくなってしまいました。
設計・実装力の向上を目指して始めた活動 だったのに、設計・実装力がないために進められなくなっていたのです。
やり方変えてみた
そこで、学習を効率的に進めるために、チームの先輩にご協力を仰ぎ、進め方を少し変えることにしました。
①設計、実装についてチームの先輩にペアプロをお願いする
週に3回、学習しているパターンについて、わからない部分を教えていただいたり、設計・実装で詰まってしまった部分をペアプロで進めたりする時間を取っていただきました。
自力でできない設計・実装について、アドバイス・サポートをいただきながら進めることで学習効率をアップできました。
また、WPFで作る場合はMVVMで作るなど、業務側で活用できる内容も交えて学習したり、「WPFの依存関係プロパティを使ってみる」など、C#やWPFで書いたことのなかった技術要素を取り入れながら実装することで、設計の学習と同時に実装スキルの向上も図ることを目指しました。
これにより、自分ひとりで進めていたら獲得できなかった知識や実装スキルについても学ぶことができました。
ペアプロを含めた 総学習時間は166h、総実装行数は7052行 にのぼりました。
②レビューを設計完了時・実装完了時の2回実施する
今までは設計・実装が両方完了した段階でレビューする、という進め方をしていましたが、それを設計完了時・実装完了時の2回実施に変更していただきました。
設計(クラス図作成)完了時点で一度成果物や設計の理由を確認していただくことで、方向性の誤り・理解不足の検出や軌道修正を早い段階で行えるようになりました。
また、単純にレビューの回数が増えたことで、対策①のペアプロによる効率アップも含めて 2日に1回のレビュー頻度を維持できるようになりました。
レビューの回数は30回以上にのぼりました。
集大成としてのアウトプット
学んだことのさらなる定着のために、「社内・社外LT大会での発表」「技術記事の投稿」というアウトプット活動を行いました。
社内・社外での発表
学習した内容をもとに、社内・社外のLT大会で発表を行うことにしました。
StateパターンとStrategyパターンを間違って実装したという学習時のエピソードをもとに、学んだことを発表しようと考えました。
まあ、間違えたときのことはよく覚えてるし、間違えたからこそしっかり勉強したし、余裕で説明できるはず…………
できないんですよね。
いざ説明しようとすると言葉が出てこない。何が間違っていたんだっけ、そもそもStrategyパターンって何がメリットだっけ、Stateパターンってどういうパターンだっけ……？
確かに、166h使って7000行以上コードは書きました。レビューもいっぱいやってもらいました。
でも、よわよわエンジニアこと私の場合は、それだけでは足りなかった んです。
しかし、「発表します！」とLT大会に申し込んでしまった以上、「やっぱりできません！」とは言えません。
なので、勉強し直すことにしました。目標は、人にデザインパターンを説明できること。
理解が曖昧なところは書籍やwebで調べ直しました。
調べていくうちに勉強したことを思い出せたり、「最初に勉強してたときには腑に落ちてなかったな」というところがすとんと理解できたりしました。
発表ですから、スライドも必要です。
クラス図を改めて書き直したり、伝わりやすそうな例を考えて図示したり……と、自分の理解をもとに、「いかにして分かってもらいやすいスライドを作るか」を考えました。
その過程で、うまく説明できないことがあれば再び調べて理解し直す、ということもしばしばありました。
↓以下が実際に発表のために作成したスライドです。
デザインパターン学習で得た知見
本番は、「自分の技術力ごときで人前で話をしてもよいのか……」とはじめは怖かったのですが、一生懸命勉強し直したり資料を作ったりしたことで、ちゃんと自信を持って話せたように思います。
また、温かい雰囲気で発表を聞いていただけたため、安心したことも覚えています。
技術記事の投稿
デザインパターン学習で自分が間違えていた点、理解度に不安がある点、追加で学習した点などについてまとめ、社内で投稿することにしました。
StateとStrategyのことは忘れてたけど他にも勉強したことはあるし、それを記事にするだけだよね、できるはず…………
やっぱり、できないんですよね。
結局、社外発表のときと同様に、「人に説明できる」レベルを目指して勉強し直しました。
今度は、文章ひとつで自分の学びを伝えなければならないわけですから、発表とはまた違う難しさがありました。
そして、「悪戦苦闘！デザインパターン」と題した5本の技術記事として、社内に投稿しました。
↓Qiitaにも改めて投稿しました！ 勉強中に執筆した記事なので、つたないですが。
【デザインパターン】悪戦苦闘！デザインパターン ~State・Strategy編~
【デザインパターン】悪戦苦闘！デザインパターン ~Proxy・Flyweight編~
【デザインパターン】悪戦苦闘！デザインパターン ~Mediator・Observer編~
【デザインパターン】悪戦苦闘！デザインパターン ~Visitorとダブルディスパッチ編~
【デザインパターン】悪戦苦闘！デザインパターン ~SingletonとMonostate編~
記事を書いたことで、発表に持っていったパターン以外のパターンについても、
「やばい、全然わかってなかった！」「わすれてた！」
と、タイトル通り悪戦苦闘しつつ、学び直すことができました。
結論、アウトプット、超大事でした……
技術記事を書くことも、社外で発表をすることも、自分からはまだまだ遠い、すごいエンジニアがやること だと思っていました。
でも、逆でした。
私のようなよわよわエンジニアにこそ、発表や記事投稿などのアウトプットが必要 だったのだと思います。
アウトプットを行うためには、学んだ内容の理解を「人に説明できる」レベルまで引き上げなければなりません。
その過程で、学んだけど忘れてしまったことや、理解が足りていなかったことなどを学び直し、より理解を深められるのだと思います。
それに、デザインパターンを学習したことで、自信を持って話せる技術のネタができました。
アウトプットしてみたら褒めていただけたこともあります。
これらのことは、間違いなく エンジニアとして頑張っていくうえでの自信につながりました。
エンジニア歴9ヶ月、転機は訪れる
それは、デザインパターンの学習をあらかた終えた、エンジニア歴9ヶ月目のある日のことでした。
設計の会議に参加させていただいて、いつものように話を聞いていました。
その途中でふと、設計に気になる点を見つけました。
気になってしまったので、 質問しなきゃ、と思いました。
「的外れだったらどうしよう。変な質問をして、議論の邪魔をしてしまったらどうしよう」
という恐怖ももちろんありました。ですが、勇気を出して「気になったところがありまして……」と聞いてみました。
すると、
「確かに問題があるね」
という話になりました。
自分の指摘は、どうやら正しかったらしいのです。
さらにその後、チームメンバーの中で誰より早く設計の問題点を指摘したことも褒めていただけました。
今までの私であれば、設計の問題点になど気づけなかったと思います。
また、「どうせ自分は考えてもわからない、正しい指摘なんかできない」と思って、発言もできなかったと思います。
「議論を聞いていても何もわからない、自分はここにいる意味がない」 と凹んでいた私が、
エンジニアとしてはマイナス状態で、できることが全然なくて、自信も無くしっぱなしで、何なら心が折れかけていた私が、
「まだやれるかも。まだまだ頑張っていけるかも!!」
と思えた瞬間でした。
ちょっとすごく頑張ってみた結果
デザインパターンを学習し始めた頃の私は、
①設計の経験がない
②時間をかけても設計をコードに落とせない。説明もできない。
③ 設計の議論についていけない、発言もできない
という状態でした。
そこから23のデザインパターンをチームの先輩方に協力してもらいながら、166時間かけて7052行のコードを書き、さらに発表や記事投稿などのアウトプットをしました。
その結果、
①23パターン分の設計の経験を積んだ！
②自力で実装し、レビューで考えを説明できることが増えた！
③設計の議論中に設計の問題点に誰より早く気づいて発言できた！
という状態になりました。
学習始めたての頃と比べれば、学習を通して大きく成長できたと思います。
……それで、今は設計つよつよエンジニアになれたんですか？
なれてません。設計はそんなに甘くないです。
設計の会議に参加していても「やばい……何にもわからない……」と何の発言もできない日もあります。
わりと自信満々で持って行った設計が、設計の本筋とは関係のない基礎的なミスだらけだったこともあります。
ツール開発に関わるようになってもう一年半以上経ってるのに、日々経験は積ませてもらってるはずなのに、全然技術力伸びないなあ、エンジニア向いてないよなあ、と悩むときもあります。
でも、まだ折れていません。
なぜなら、166hかけて7000行コーディングして、デザインパターン23パターン勉強しきって、それでも足りなかったので発表と記事投稿のアウトプットも頑張ったら、ちゃんと成果が出たからです。
もちろん、成果としては 「ほんのちょっと」 で、大変小さなものです。それでも、
「この調子で頑張り続けられたら、もっともっと成果を出せるようになれるはず」
と思える、これからも頑張り続けるための 「(自分的には)すごい」原動力 になりました。
これからも 「ちょっとすごく」 勉強して、「ちょっとだけど(自分的には)すごい」 成果を出しつづけて、少しずつでも設計つよつよエンジニアを目指して成長していくために、
「明日もエンジニアがんばろう」
と折れずに頑張っていきたいです。
さいごに
この記事は、私と同じようによわよわエンジニアであることを嘆く誰かに、
「自分も、明日もエンジニアがんばろう」
と思ってもらえたらいいな、という気持ちで書きました。
ちょっとでも、この記事を読んだ誰かに勇気を与えられていたら幸いです。