もともとSIerに8年いたのだが、長女が産まれたタイミングで退職した。これが、2016年の12月末。それから気づけば4年弱が経過した。
最初は無謀にも退職即フリーランスだったのだが、半年後ぐらいに、貯金がやべえw ってんで急いで札幌の小さなWeb系企業に滑り込んだ。そこからなんやかんやあって今は札幌の中規模ベンチャー（？）でフロントエンドをやっている。
その間に次女も産まれ家も買い、35年ローンも組んでしまい、まあ大変！ これからはローンに追われ会社に縛られ馬車馬のように働くしかないのね！ まだ住宅ローンで消耗してるの？ とかインフルエンサーに煽られそうな状況である。
が、全然幸せである。なぜかと言うと、他者に貢献していると言う実感があるからだ。
会社に限ったことではない。世界は広く、僕の腕を必要としてくれる人は世の中にたくさんいる。
また、万が一無職になろうとすぐに死ぬわけではないと言う確信もある。その気になればスキルの使い方次第でどうやっても生きられる。そうした自信がついた。
そう言う風に思えるマインドセットの所以は何かと問われると、そう言うキャリアを築いてきたからだと思う。
まだまだスキル的には上には上がいるし、コミュ障で居心地の悪い思いをすることは多々あるが、それでも自分は開発者としては無価値ではない。
人と比べることに意味はないが、僕よりできないで価値を生み出している人はごまんといるし、僕よりできるが価値を生み出していない人もまたごまんといる。
と言うより、誰それよりできるとかできないとか、そこに意味は何もない。ただ、何か開発を頼まれた時に、「僕が関わったとて最高なものができるとは限らないが、まあちょっとは役に立つことがあるだろう」と言う自信がある。俺がいればプロジェクトは安泰だ！ とかそう言うのは恐れ多くて言えない。
しかしこれだけは言える。SIer時代にイキり系うっとおしい社員だった頃よりは遥かに自信がある。そして給与もあの頃よりは高くなった。ここが大重要である。なんと大企業で無くとも、給与は十分に高くなるのである。(ここで大企業信仰の教育ママ、口角に泡を吹きながら怒り狂い、ぶっ倒れる。くたばれ)
と言うことで、4年間でやってきたこと/勉強方法などをまとめる。これをトレースしたとてWeb系の仕事を十分にこなせるようになる確証はないが、少なくとも公民館のホームページを作って感謝されるレベルには確実になれる。誰かに感謝されるレベルになれれば、それでいいと思う。
では行く。
駆け出し期にやったこと
駆け出し期はとにかく挫折しないことが重要だった。そのため動画講座中心に受けて様子を掴み、いい感じであればお金を出して有料サービスを使う、と言うことの繰り返しだったように思う。
ドットインストールでWebサイト制作練習
一番最初はドットインストールから始まった。動画で学習できるプログラミング学習サイトだ。大体の講義は無料である。
↑に「ウェブサイトを作れるようになろう」と言うセクションがあるはずだ。これを動画の通りに真似してやると、1ヶ月ほどでそれっぽいホームページが作れるようになる。
多少わからなくてもガンガン進めると良い。はじめはコピペでも全然良い。意味がわかってなくても良い。作れるんだと言うことが分かれば良い。
このレベルは今からしたら駆け出しも駆け出しである。
でも、このレベルであっても世の中の役に立てるから驚きだ。
現に僕はドットインストールをやっている途中、floatで要素を横並びにするのが怪しい段階でLP制作を受注してお金をもらっている。
当時のクライアント曰く、画像だけ用意するから、なんでもいいから早くやってくれとのことだった。なので、tableレイアウトで2カラムっぽいやつを作って納品した。もはやHTML4時代のテキストサイトのレベルである。
tableレイアウトでやったせいかカラム間の幅がまちまちになったが全然大丈夫だった。marginが云々などのディテールよりはLPが存在することが重要だった。そう言う案件だった。ビジネスとは時にそう言うものだ。tableレイアウトでLP作るのはバカと楽天市場ぐらいなもんだろう。
しかし。この作業。正味2時間ぐらいの作業だったのだけれど、なんと5000円ももらえたのである。このレベルで時給2,500円である。使っている技術の巧拙とお金とは多くの場合で関係がないのである。要は顧客が求める価値さえ提供できれば良い。新鮮な体験であった。
TechAcademyでWebデザイン+WordPressセットを受講
ドットインストールでHTMLとCSSはできるようになった。ついでにPHPやWordPressの講座もあったので受けておいた。おかげでなんとなくホームページは作れるようになったのだが、所詮は趣味レベルであった。実務で使うにはもう少し体系的に学べた方が良いと思った。
なので、2017年元旦からTechAcademyを受講した。当時は2ヶ月で13万ぐらいだったから破格だった。この辺の寄稿記事でまとめているが、まあまあ良い。
もともとWebデザイナー志望だったので、Photoshopだとかの使い方を学べたのはかなり良かった。あと、Webサイト作るぞってなった時に、実際どうやって作るのかみたいな仕事のフローを知れたのがでかい。
WordPressも基本構成を知れたので良かった。便利なプラグインとか定番の構成とかをテンプレートで作れたのはかなりよかった。この講座を受講したことで、変なことをやらなければWebサイト作りは簡単かもしれないな、と思った。
ノンデザイナーズデザインブック+Udemyのデザイン講座
Webデザインの基本は学んだが、なんとなく自分のデザインがダサかったため書籍でも勉強した。
ノンデザイナーズ・デザインブック ［第4版］
デザインの基礎はぶっちゃけこれだけである。素人ではないが、限りなく素人に近い。
さらにUdemyで下記の講座も受けた
サンペー先生の『なぞって学ぶプロのデザイン講座 簡単！10分で美しいバナーを作ろう！』 | Udemy
Photoshop 中級者、上級者がプロになるために最後に学ぶ「超絶技巧」テクニック
あたりのUdemy講座も受けた。どちらもPhotoshopのテクい技術を使って、いかにもなレタッチをする手法を学べる。あるあるなデザインの引き出しにもなった。ものの切り抜きやら、質感の向上やら、バナー制作などに使えそうな技術を習得できた。
その後、僕にWebサイト制作を頼んでくる奇特な人があまりいなかったため、ぶっちゃけデザインのスキルはあまり使っていない。
が、例えばデザイナーさんがアイコンを用意してくれずにバックれた時とか、偉い人に何か説明する時にいい感じの資料を作るとか、回ってきたHTMLが明らかにデザイン的に狂ってる時とかにこっそり直したりする時に役に立った。現職の面接時に職務経歴書を独自デザインで作れたのもデザインの基礎を学んでいたからだ。
また、ありがちなのが、プログラミングばっかりやってると、いざ画面を作ろうとした時にクソダサデザインしかできなくて野暮ったくなると言うシーン。例えば業務用のWebアプリの管理画面は、デザインが終わってる時が多々ある。そう言う時に物怖じせずにいい感じに直せるのはかなりストレスが減って良い。
さらにさらに。この先自分のプロダクトを作ろうとした場合、自分がデザインの基礎を知っていれば、非常に作りやすくなる。自分で作っても良いし、自分がざっと作ったものを元にガチデザイナーに委託してブラッシュアップしてもらっても良い。いずれにせよ、多少の教養があることで、開発の自由度が格段に上がる。
今はゴリゴリのプログラマーとしての仕事が多いが、デザインをやっていたおかげで役に立つことも多い。皆もやった方が良い。
1年目 ~ 3年目あたりにやったこと
副業でもいくつか受託開発を行い、本業でもいくつかプロジェクトをこなすうちに、ある程度独力でやりきる力がついていた。プログラミングの勉強についてはドットインストールを継続してやっていた。新しい言語やフレームワークが必要になるたびに、ドットインストールをまずやる、と言う形式でキャッチアップしていった。
言語やフレームワークはやれば大体理解できる。
問題は設計だった。
好き勝手プログラミングして半年ぐらいした頃に気づく。
「なんか最近、どっか直すとすぐに違うところがバグったりしねーか？」
と。
テスト駆動開発(TDD)を始める
僕の書くプログラムと言うのは、同じロジックのコピペ記述が多いものだから一つの何かを直すとあらゆるところを直す羽目になる。ケースAのテストをしたら、同じロジックがコピペで書かれているケースBもテストしなければならない。
そんな塩梅だから、プロジェクトが大きくなればなるほど、開発スピードが落ちていく。じゃあ直せばいいのでは？ と思うだろうが、直そうにも影響範囲が大きすぎて容易に手が出せないのだ。しかも手でテストするから効率が悪いことこの上ない。
そこで出会ったのがテスト駆動開発(TDD)だった。
テスト駆動開発
プロダクトコードを先に書いてテストを書くと言う従来のやり方ではなく、
- 仕様からテストコードを書き
- そのテストをエラーにし
- エラーを直すようにプロダクトコードを書く
- 動くものを維持しながらリファクタする
- これを繰り返す
と言うやり方である。
これが実に有用で、まともなテストが書けるコードは疎結合になりやすい。一つ一つのメソッドを明確な目的を持って書くので、妙なロジックのメソッドを書くことが減り、プログラムの拡張性、可読性が格段に良くなった。また、TDDのサイクルのうちでコピペプログラムはギャンギャンに共通メソッド化する羽目になるので、ロジックがあちこちに点在すると言うことも少なくなった。共通メソッドの処理を変えた時は、その共通メソッドの単体テストさえすれば良いのである。最高に簡単だ。
さらにさらに。何かを修正した時に全テストを自動で流して、結果がオールグリーンであれば。少なくとも仕様をぶち壊していないことが分かる。リファクタリングの手間が格段に少なくなり、心理的にも余裕ができた。自動テストを流している最中の気分も最高である。
その後順調にTDDにどハマりし、日本のテスト駆動開発の先駆者@t_wadaさんのハンズオンに参加したりした。TDDの具体例についてはいずれ紹介できればと思う。皆、テストが書きたくて仕方なくなるはずである。
3年目 ~ 4年目あたりにやったこと
インフラ周りの勉強を始めた AWSクラウドプラクティショナー
色々なプロジェクトを渡り歩いてきたところ、サイトが遅いとか、DBがスケールしない、と言う話を耳にすることが多くなった。また、デプロイフローが整っていなかったり、何か起きた時のリカバリー的なものをきちんと準備しなければならない、と言うシーンが多くなってきた。インフラにも手を出す必要が出てきたのだ。
そこでAWSでも勉強してみるかと思って勉強してみた。勉強内容は下記。
単にAWSに詳しくなってもしょうがないので、インフラ構成のベストプラクティスは何かを意識しながら勉強した。
結論としてはインフラの知識は最高に役に立った。Web系でやれることが格段に広がった。
例えばサイトの画像が重いとなれば、CDNを使って高速化してみたり、負荷分散を試みたり。なんか良くわからないが用語だけ聞いたことがある的なことが自分の手でできるようになった。
これは副業にも大いに役立ち、インフラのあらゆることを自動化したりテンプレート化したりすることもできるようになり、やれるビジネスの範囲が広がった。
例えばレンタルサーバーみたいな事業もやろうと思えば1人でやれる。顧客が管理画面からクリックしたら僕のWordPressテンプレートを使ったサイトが秒で出来上がる、的なこともできる。何に使うか、可能性は無限大である。インフラは学んでおいて本当に損はない。
ドメイン駆動開発(DDD)を始める
以前テスト駆動開発で格段に僕のコードは良くなったと書いた。が、まだイマイチだった。ちゃんとしたアーキテクチャに乗っ取って開発していない感があったのだ。無手勝流に処理を書いているものだから、どこで何をやっているかが分かりづらく、バグの温床にもなっていた。
例えばユーザーの登録処理を作ろうと思った時。どう言うことを考えるだろうか。
MVCで言えばModelに処理内容を書くのがいいんだよね？
で、Controllerにビジネスロジックは書いちゃいけないと。
するとControllerはModelのメソッドを使ってViewを作ることに注力すればいいのかな？
そしてViewにもロジックを持ち込んじゃいけないと。
で、書いてみたところModelがギャンギャンに肥大するし、結局読みにくいことこの上なくて、どゆことだ！？！？
て言うか主戦場のWordPressだとModelとかないけど！？！？ LaravelとかのServiceProviderとかもないから依存性注入できなくない！？そもそも依存性注入って何！？
ModelがDBに繋がってるから、テストやったらデータ変わっちゃったよ！？ とか。
みんなどうやってんの？？？？？
Twitterを見渡せばみんなカッコ良く、「ビジネスロジックはここに書くべきではない」とか「ドメインのロジックがControllerに染み出してますねえ」とか、メガネくいくいさせながら言ってるけど、どうしてそう思ったの！？ てか、どこでそれを学んでるの！？ と。ビジネスビジネス言ってるけど、結局どこに何を書けばお前らの言うベストプラクティスになるのさ！？！？ って。
つーことで、下記を読んだ。
ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本
まだ1回しか読んでいないので、血肉になったとは言い難いが、言ってることは分かった。なんちゃらサービスとかなんちゃらアプリケーションサービスとかコードに書かれてたのはこう言うことかい！？ って。
まだ実務や副業に応用できていないが、何をどこに書けばクリーンなアーキテクチャになるのか。その正解は分かった気がする。前は「アーキテクチャ的に微妙」と言う判断自体ができなく、経験と感覚でこれはクソアーキテクチャになりそうだ、と考えていた。しかし、今。明確な指針が定まったことで格段にやりやすくなった。
開発に慣れてきて、失敗して、クソコードをある程度量産したタイミングで、これを読むことをお勧めする。きっと自分のコードをリファクタしたくなるはずだ。
その他メンタル面でやったこと
開発を前線でやりまくっていると、時折悲しい目にあうことがある。
例えば一度決めた仕様をちゃぶ台返しされた挙句、スケジュールは変わらないとか。
例えばプルリクレビューでコテンパンにやられたとか。
例えば「そんなもん知らねーよてめーも分かってただろ？」みたいな今更なことをクライアント様に言われるとか。
例えばバグじゃないものをバグと言われるとか。
例えばリーダーが、
PMが、
〇〇さんが、
etc…ect…とかそう言うの。
一つわかったことがある。こう言うのにイチイチ腹を立てていてはメンタルがもたない。
特に開発の何たるかが少しだけ分かってきた2年目3年目あたり。他者に攻撃的になったり自分の正当性をことさらに主張するようになる人がいる。僕もそのタチであった。
他者批判をすることでいかにも仕事ができる、本質が分かってる風に自己を錯覚するが、その実ただの厄介者である。あと、自分自身も意外にキツイ。
人生は短く、他者にかかずらっている暇はない。そう言う考え方の基礎として役に立った書籍がいくつかある。
嫌われる勇気
下記で紹介したが、Audibleで買って耳で聴いた。
アドラー心理学を解説した本である。
嫌われる勇気は、そのタイトルから「嫌われてもいいから自分の好き勝手に生きようぜーーーヒャッハーーーー！」な本かと誤解されるが、大いなる誤解だ。
曰く、「全ての悩みは人間関係にある」。
曰く、「トラウマは存在しない」。
今まで自分が抱いていた常識とはかけ離れたことが書かれていた。が、読んだ後は確実に生きるのが楽になった。
特に「他者の課題を分離する」と言う考え方が好きだ。
例えば〇〇さんのやり方がイマイチで気に入らないとか、そう言う場面は開発の現場にいたら山のように発生する。
一旦気に入らないと思うと、〇〇さんの一挙一投足が気になってどんどんどんどん気分を害していく。
時には〇〇さんにキツイ指摘をするも、一向に改善しない。こういう場面って何もITじゃなくても家庭ですら起きる問題である。
こういう時に、「これは〇〇さんの課題だ」と割り切ることができるか。「〇〇さんが助けを求めてきたらいつでも助けるぞ！」という態度を見せることができるか、が幸せの分水嶺になる。
他者の課題を他者の課題と認識して応援する姿勢でいられるか。難しいが、ただイライラしているよりはずっと前を向いていて、幸せである。
また作中で、人間は「他者への貢献感を感じることにおいてのみ、幸せを感じる」とされている。
コミュニティ(会社、友人関係、家族関係、日本国などなど)に属し、そのコミュニティにコミットすることで「自分はここにいても良いのだ」と言う満足感を得るのだと。
自分の中の「貢献感」。これを意識して生きていくと、より他者に貢献する意義が深まり、人生が生きやすくなる。自分を受け入れられるようになる。
人を動かす
小規模なチームでリーダーをやるようなことも増えてくる。そうした場合、必然誰かに何かをやってもらう、と言う場面に遭遇する。そうした時に役立ったのが、カーネギーの「人を動かす」だった。
人を動かす 文庫版
例えば誰かが間違ったことをしようとした場合、その間違いを厳しく正してチームを動かすアプローチはどうだろう。あるいは間違いを犯した人、サボりぐせが酷くてどうにも使いづらい人を、めちゃくちゃにゲキ詰して動かそうとするのは正しいだろうか。
僕はゲキ詰するのも厳しくするのも効果はないと思っている。
本の中で、トラックのセールスをやっている方の話がある。実在の人だ。
その方は、客が他のメーカーのトラックを褒めようものなら、恐ろしくいきり立って議論をふっかけていた。最終的に自分のメーカのトラックの方が優れていると言う結論で落ち着くのだが、その代わり、全く車は売れないのである。
彼はその悪癖をやめ、客が他のメーカーの良い点を言ったら「全くもってその通り！ 〇〇社のトラックは良いですからね！」と完全に受け入れるようになった。議論したり、反論すると相手は余計に持論に凝り固まる。結果モノが売れないのである。こう言う態度に変えることで、「ところであんたの会社のトラックはどうなのさ」と会話を自然に持っていき、長所について自然に説明することができるようになった。しかも、相手は反感ではなく、少しだけ自社製品に興味を持っているのだ。
こう言うのはトラックのセールスだけに止まらない。議論をしたり、相手に反駁したりするのはだいたいにおいて意味がないのである。
なので、基本的に僕は何か人が間違ったことをやっても、叱ったり、咎めたりしない。その行為の中でも良いところを認め、良かったところを指摘する。
その後、してほしいこと、もうちょっとこうした方がいいんだけどな、と言う点があれば、「XXは最高でしたが、〇〇についてはどう思いますか？」とやる
基本的に同僚は優秀な方ばかりなので、イマイチなところがあれば自分で気づいている。そこを少し指摘するぐらいしか、僕にできることはないなと。
これは経験則だが、めちゃくちゃに指摘をすると、人は自発的に動けなくなる。手取り足取り指示して良いのは、タスク習熟度の低いうち(新人や中途で入った最初の数ヶ月)だけだ。これについてはHIGH OUTPUT MANAGEMENTあたりでも解説があるので、いつか記事にしたい。
あと、これはむしろ嫌われる勇気の話になるが、人を自分の思い通りにコントロールするなんてのはそもそもできない。チーム開発で誰かに何かをやってもらおうと考えた時。自分にやれることは、「その人を勇気付ける」ぐらいしかできないのだと。たとえまずい結果になったとしても、それはその人の課題であり、その人が向き合わなければならない。結果、会社として致命的にマズければ僕かその人が降ろされるだけだ。そこに思い悩む必要は、あんまりないなと。(そして思い悩んだって結果は変わらない)
まとめ
こうして振り返ってみると、駆け出し期ほどコーディングやらPhotoshopやら、実際に手を動かして何かをすると言うことをやりまくった気がする。このアプローチは成功だと思う。わからんくてもとにかく手を動かさないと何も見えないので。
設計や、アプリ以外の部分(インフラ)は最近身につけたスキルだ。これもそもそも手を動かした経験がないと、重要さに行き着けない。特に設計。設計が全然できてない！ って言うけど、設計の仕方なんてそもそも習ってないっすからね。この段階で気づけて良かった。
そして、ある程度独力でできるようになったところで、一番大切なのはコミュニケーション力やメンタル面であると感じた。嫌われる勇気や人を動かす等を読んだが、本当にこれは良かった。結局メンタルやられたり、自分の人生が落ち込んだら意味がないからだ。僕は2015年あたりにメンタルをやって1年近くまともに仕事ができなかった。その1年で僕が人に与えられた価値が丸々無くなったのだ。これは大いなる損失だと思う。
と言うことで雑ではあるが、これが4年でやったことの概要である。これを全部やった、みたいな人がいれば、少なくとも札幌に家を買うことぐらいはできるようになると思う。
