概要
去年の12月にオミカレに入社し、そろそろ1年経ちます。社員が400人近くいる中規模会社から社員10人〜20人規模のベンチャーに転職し、試行錯誤やってきました。
- フルリニューアルの振り返り
- 日常的な仕事のやり方に対する振り返り
- 自分のキャリアマップの振り返り
そういうわけで、この辺をテーマに振り返りをつらつらと書いていきたいと思います。
フルリニューアルの振り返り
中規模、小規模プロジェクトは色々やってきましたが、一番大きかったタスクは春から夏にかけてやっていたサイトリニューアルのプロジェクトでした。
同僚の@ikkitangも振り返りブログで触れていますが、デザインを変えるだけでなく、バックエンドも刷新する完全なリニューアルでした。
当時、古くからあるMySQLをPostgreSQLに移行するための取り組みが裏で進む中、僕ともう1人のフロントエンドエンジニアの@maeponは表側の画面をゼロから設計して作りあげていました。おっさんピンクと揶揄されていたピンクベースの画面配色、Bootstrapと混ざりあったカオスなCSS、scriptタグの中に書き捨てられているJavaScriptからの脱却を目的とした戦いです。
- CSSフレームワークは使わない。
- FLOCSSをベースとしたCSSの設計を組む。
- jQueryや、jQueryに依存したライブラリは使わない。
- 素のJavaScriptではなく、TypeScriptを使っていく。
この辺りを基本方針としつつ進めていきました。
上手くいったこと
1つ目はCSSについて。
大規模なCSS設計をするのは人生で初めてだったので不安要素が大きかったのですが、当時設計したCSS設計は数ヶ月経った今も大きな問題はなく運用できています。プロジェクトに合わせたちょっとした拡張はしつつも、FLOCSSの基本思想はそのまま活かしたのが良かったのかもしれません。また、当時は雰囲気で使っていたBEMに対する理解が深まるという副次的な効果もありました。
2つ目はTypeScriptについて。
「jQueryも使わず、いきなりTypeScript運用出来るのかな？」
サイトリニューアルの計画を練っている当初はこういう懸念も上がっていました。
Java畑で育った僕は型付きプログラミングに対する抵抗は無かったですが、PHPやPythonをメインにしている層からするとそうではなかったのかもしれません。そういう背景もあったので、出だしの頃は意識的に周りの手助けをするようにしていました。
更に、周りのメンバーの「とりあえずやってみる」チャレンジ精神が活きたこともあり、今では当たり前にTypeScriptを書く文化ができつつあります。将来的にReact + TypeScriptのような仕組みを入れることになったとしても、大きな足がかりにできそうな感覚があります。
上手くいかなかったこと
このサイトリニューアルは3月後半に始まり、6月末にリリースという流れで進めました。フルリニューアルを進めるにしてはなかなかの強行軍と言えるスケジュールで、その過程では色々なことがありました。
- 初めに作っていた画面のプロトタイプと、開発が進んでいく画面のズレ
- ページの洗い出し漏れによる仕様の膨らみ
- フロントエンド側のリソース逼迫
大なり小なり・・全部を挙げていったらキリがないですが、一部の例を挙げるとこんなところです。僕自身の立ち回りと進め方が上手くいってなかったと感じるところだけ触れていきます。
3月末頃、外部の協力会社さんに作って頂いたデザインを元に僕が画面の静的なプロトタイプを作りました。ページ全体のレイアウトの枠組み、ヘッダーやフッターといった多くの画面に共通して存在するパーツ、Button要素やテキストボックスといった汎用的な要素を順次作っていきました。このタイミングで作ったものを元に画面を量産していく想定でいました。
しかし、実際はそう上手く進まない場面が多かったです。開発が進む中で新たに必要になったパーツを都度作る必要があり、そこにそれなりの時間をかけました。同じようなパーツだけど微妙に見た目が違うパーツが量産されてしまい、後追いの調節や統一に時間をかけました。そうしている内にバックエンド側の開発が先行していき、フロントエンド側で止まってしまうタスクが増えていく結果になってしまった・・という次第です。
また、開発途中にブランドのテーマをどうするかで揺れていた時期があり、その前後の配色が入り混じった画面が出来上がってしまい、そこの調整がなかなかに大変だった記憶もあります。
精神的に追い詰められてしまい、「夏にリリースするのは無理なんじゃないか？」と発言するところまでいった時期もあった程です。 結果から言うと、6月末に無事にリリースは出来ましたが、6月はなかなかハードに働いていた気がします。完璧に仕上がらなかったところや、IE11でデザインが崩れている箇所はリリース後に急いで直したりしていました。
見積もりを甘く見積もりがちな僕の悪い癖が出た結果だなと、今でも強く思います。見積もりについての話は後でまた触れます。
日常的な仕事のやり方の振り返り
日常的な仕事を進める中で常に意識するようになったことを触れます。
コードレビューについて
前職にいる頃。特定の人にレビュー負荷が集中してしまうことが多かったこともあり、転職後はコードレビューのやり方を再考しました。コードレビューのやり方、レビューをする頻度など、色々と悩んだ気がします。
https://testing.googleblog.com/2019/11/code-health-respectful-reviews-useful.html 上の記事で言及されている方針や、以下のことを意識しながら日常的にPullRequestを眺めています。
- 語気の強い言葉は使わない。
- 相手の方針に異議を言う時は、きちんと根拠も言う。
- 相手の実装に対する代替案がある時は、簡潔なサンプルコードも載せる。
- 「動いてるから良いか」ではなく、設計方針やパフォーマンスも意識してコードリーディング
レビューをする頻度ですが、基本的に午前中に見ることが多いです。出社直後や、お昼ごはんに行く前に見ている感じです。 後は、自分のタスクが一段落した直後などの隙間時間に見るようにしています。
ですが、タスクが溢れていたり単純に疲れていたりするとレビューを雑に見がちなので、その場合はレビューをあえてせずに周りに任せてしまうこともあるのが課題ではありそうです。
スケジュールに対する意識
ここ最近、ようやく出来てきたことです。
僕の悪い癖が1つあり、完璧に作ることに固執して時間を使いすぎてしまってスケジュールを送らせてしまうことがありました。社内では「普通の船で十分のに豪華客船を作ろうとしがち」と表現されています。
いくら完璧に作っても、世の中に出さなければ意味がありません。しかも、後の続いているタスクのスケジュールにも影響が出てしまうので、このままでは良くありません。周りの助言を得つつ、以下のことを意識するようになりました。
- ザッカーバーグの「Done is better than perfect.」を意識する。
- タスクを日単位で考えず、週単位で捉える。
1つめについては僕が今更言及することでもないですね。僕の中の感覚では「70％くらいの段階で早く世の中に出して、後からのブラッシュアップで100％に近づけていく」という感じです。
2つめは一週間の仕事の進め方を週単位で考えるというものです。具体的に言うと、以下のようなことをやっています。
- 金曜日にその週で終わらなかったタスクがあれば。何故終わらなかったのかを振り返る。
- 終わっていないタスクがあれば、それらも考慮しつつ翌週のタスク予定を決める。
- 日曜の夜、もしくは月曜の朝に決めた予定を確認し、曜日ごとに工数の分量を見積もる。
このサイクルを回していき、自分の中で想定している工数と実際にかかった工数のズレを縮めていくのが狙いです。
自分のキャリアマップの振り返り
僕は32歳なので、今後のキャリアをどう積み重ねていくべきかを計画し、実行していかなければなりません。ということで、この数ヶ月は分野を越境していくことを意識していました。
近い領域への越境
僕はフロントエンド領域が好きですし、この領域を武器に戦っていくつもりでいます。しかし、自分もご多分に漏れず凡人の一人でしかなく、1つの分野に特化して戦っていくのは現実的ではないとも思っています。
そこで考えたのが、フロントエンドと近い領域にある分野への越境でした。ここで言う「近い領域」とはサーバーサイドとデザインの2つのことを指しています。このような方針を立てた理由は、t-wadaさんの資料で触れられている話を参考にした結果です。
https://speakerdeck.com/rtechkouhou/enziniatositekofalsexian-sheng-kifalsekorutameni
複数の柱を持つ、という話ですね。
サーバーサイドと向き合う
弊社はPHPとPythonでバックエンドを構築している会社で、簡単に言うと以下のような形になっています。
※APIがDjangoで分けられているのは、Webだけでなくスマートフォンアプリからも使えるようにするためです。
必要に迫られて書くようになったのもありますが、「フロントエンドだから見た目の調整に集中すればいいか」という姿勢は勿体無いという思いもあったので、今では積極的に書くようにしています。メンバーのコードレビューに積極的に首をつっこんでもいます。
とはいえ、CSSやJavaScriptとは気にすべき箇所が大きく違うこともあり、最初はまともなコードが書けているか大きな不安を感じてもいました。そこで僕が大事だと感じたのは設計力やアーキテクチャへの理解でした。これまで適当気味にやっていた領域を深堀りするため、色んな本を読んで実践してきたつもりです。
- 「PHPによるデザインパターン」
- CTOおすすめの本
- 「オブジェクト指向のこころ」
- 「リファクタリング 2nd Edition」
- ※僕が買って読んだ時期は原著のみでしたが、そろそろ日本語版が発売になるはず。
- 「A Philosophy of Software Design」
- EOF2019で知った本です。
- これは1/3しか読み終わってません・・。Kindleだと1,000円くらいで買えるのでおすすめです。
主にこの辺りの本を読みました。
本を読んだ内容と知人のエンジニアと話しあったり、弊社の技術顧問をやっていただいている@kawasimaに壁打ち相手になってもらったりしつつ、少しずつ知識を定着を図っています。
この1年はPHPをきちんとやるだけに留まりましたが、来年はDjangoにも手を広げていくつもりでいます。
デザインと向き合う
フロントエンド領域と一番近いようでいて、実は最も遠い領域な気もしています。しかし、良いUIを作るためにはデザインのことをきちんと理解しておく必要があると前々から感じてはいました。
そう感じ始めたのは、前職で同じチームで働いていたデザイナーさんがきっかけでした。当時の僕はデザインに対して「やっぱりセンスがないから無理だなー」くらいの気持ちでいました。しかし、そうではないことに気付かされたのです。
Webページを構成する要素は数多く存在します。要素同士の間隔、配色、タイポグラフィというように挙げたらキリがありません。それら一つ一つに対して、根拠となるロジックがあることをその人に教えてもらいました。全てがセンスで成り立っているわけではなかったのです。
僕がデザインのことを理解していこうと思い始めたのはそれからです。サーバーサイドの節と同様に、ここでも基本を固めるために色々な本を読みました。
- 「なるほどデザイン」
- http://naruhodo-design.com/
- 個人的にとても好きな本です。
- DesignShipで著者の方が登壇されていた時はびっくりして飛び上がりたいくらいの気持ちでした。
- 「けっきょく、よはく。 余白を活かしたデザインレイアウトの本」
- https://www.mdn.co.jp/di/newstopics/60010/
- 「marginやpaddingを調整してみたけど、なんかイマイチ」と感じるのはなぜなのかを知るために買いました。
- 【新版】UI GRAPHICS
- http://www.bnn.co.jp/books/9522/
- トレンドと歴史くらいは知っておいた方がいいか・・くらいの気持ちで買いました。
- iPhoneのデザインが辿ってきた軌跡を説明したコラムが良かったです。
- 「簡単だけど、すごく良くなる77のルール デザイン力の基本」
- https://www.njg.co.jp/5711bod/
- こちらの本も、DesignShipで著者の方が登壇されていましたね。
- 続・インタフェースデザインの心理学――ウェブやアプリに新たな視点をもたらす＋100の指針
- https://www.oreilly.co.jp/books/9784873117713/
- Webに限った話ではないですが、頭の引き出しに入れておくと役に立つことが多い本でした
他にも彩色手本の本を読んだりしたのですが、すぐに思い浮かんだのはこの辺りの本です。本を読んだくらいでデザインが出来るようになるとは勿論思っていませんが、「言語化出来ないけどダサい」みたいな状態を抜ける足がかりにはなっています。
まとめ
長くなりましたが、僕の振り返りはこんなところです。自分の専門領域の深堀りや越境は出来つつありますが、仕事の進め方は一層の改 善が必要になってくるなと感じました。とはいえ、何をやるべきかは見えているので、向こう半年は意味のある時間が過ごせるのではないかと思っています。
僕の方からは以上です。
