Written by Toshiki

忍者CODEさんのコーディング案件に挑戦してみた

Life Work

こんにちは、トシキです。
今回は初めてTwitter経由でいただいたコーディング案件の感想、反省点についてまとめます。

本記事の内容

案件を獲得した経緯

案件を獲得した経緯

案件探しに動きだそうとしていたところ、Twitterでフォローしている忍者CODEさんから「HTMLコーダー募集」のツイートが流れてきました。

あまりにもナイスタイミングだったので、「これは応募するしかない!」と思い即DM。
他の理由としては、

  • クラウドソーシングの応募と違い、既に相手のことを知っていたので安心感があった(更に言うとサービスを利用したことがある)
  • 学習教材でお世話になったので、お礼も兼ねてコーディングでお手伝いできればと思った
  • 自分のコーディング技術が通用するか試したかった
  • 他のコーダーさんとも協力して制作する機会が欲しかった

などがありました。
提案内容はシンプルに、

  • 自分は何者で現在何しているか
  • 学習でお世話になったことへのお礼と、応募に至った経緯
  • ポートフォリオのリンク

の3つの内容を記載。
あまりかしこまった感じの文章にはせず、素直に感じていたことを言葉にしました。
それと文章は長文にすると書く方も読む方も疲れますし、相手は恐らく沢山の応募者のDMに目を通さないといけないだろうなと思ったのでシンプルを意識。

ポートフォリオに関してはサイトのキャプチャ+そのサイトリンクを載せている一覧Salon.io)と、コーダー募集でしたので一応GitHubのリンクも添付しました。
GitHubのリンクは制作途中のポートフォリオでしたが、最新のコードを反映させていたのでワンチャン見てもらった際、「どんなコーディングをする人なのか」の判断基準にしてもらえれば良いなと思いました。

案件スタート

案件スタート

案件のやり取りはSlackを使い、初回の打ち合わせはZoomで行いました。

打ち合わせ

打ち合わせではFigmaのデザインカンプを共有しながら、概要と誰がどのページを担当するか、金額や納期などの説明を受けました。
作業範囲はWordPress前の静的コーディングの部分。
私の場合は、返信を頂いた時点で既にトップページを担当することが決まっていたので、他の方の担当箇所が割り振られるのを聞いていました。
当時の心境としては、Webサイトの顔にあたる部分の担当になったことの嬉しさ反面、プレッシャーを感じていました(笑)

作業開始

コーディングルールについては特に指定はなかったので普段どおりに作業。
私の開発環境は最近導入したGulpを使いPugとSCSSでコーディング。
そこからコンパイルされたファイルを共有していました。
Gulpの導入はハードルが高く私は過去に2回断念しましたが、のせっちさんのnoteのおかげで導入することができたので、絶賛苦戦中の方にはオススメです!

CSSはPRECSS手法でスタイリング。
「BEMやFLOCSSじゃないの?」って思われたかもしれませんが、CSS設計に関する書籍を探していた時に偶然発見したのが、「CSS設計完全ガイド ~詳細解説+実践的モジュール集」でしたのでそこから使い始めて今に至ります。
もしあの時違う書籍を手に取っていたら、確実に別の手法になっていたと思います。
jQueryを使った部分は「動くWebデザイン アイディア帳」を参考にさせていただきました。
これら2冊は下記の記事で紹介しています↓

スタイリングはピクセルパーフェクトに近づけたかったので、Chrome拡張機能のPerfectPixelで整えていきました。

進捗報告は1〜2日毎にSlackで報告。
私はヘッダー、フッターのような共通パーツも担当していたので早く進めることを意識しました。
今回GitHubは使わなかったので、ファイルはギガファイル便で共有して変更箇所はSlackに記載していました。

反省点

反省点

やってて「失敗したな…」って思ったところ。

  • とにかく時間がかかった
  • 画像かCSSか問題
  • デザイン見落とし
  • タブレットサイズ時のスタイリング
  • 修正作業

とにかく時間が掛かった

時間を計りながら進めていましたが、初校までの作業時間がおよそ27時間
その後の修正作業には15時間
初回の打ち合わせとSlackメッセージの思考時間も含んでいるとはいえ、かなりかかってしまいました(汗)
マークアップよりも主にスタイリングやJSの実装に時間が取られた感じです。(20時間もあれば終わると思ってたけど甘かった)
後述する4点も時間ロスの原因ですが、これはまだまだ経験不足なんだと痛感。

画像かCSSか問題

CSSで表現できそうなアイコンは、極力画像を使わないで容量を軽くするようにしています。
ボタンやリンク横のアローアイコンは、擬似要素のbefore、afterで棒を1本ずつ作成してrotateで傾ける実装方法をとっていましたが、場所によっては再現が難しく結局画像で実装し直す手間が発生してしまいました。
ホバーやクリックでアローが回転するアニメーションは困難を極めたので、前もって動きを確認した上で擬似要素にする or 擬似要素に画像を設定するか決めるのがいいと思いました。
ちなみに回転じゃなく、ただ横にスライドするだけでしたら擬似要素で問題ありません。
書いてて気付きましたが、よくよく考えたらafterにborderで実装すればよかったのでは説…。

画像かCSSか問題

デザイン見落とし

ヘッダーとフッターは全ページ共通と伺っていましたが、初校提出後にヘッダーのデザイン違いが下層ページにあることが判明。
打ち合わせの時にデザインカンプ全体を見渡したつもりでいましたが、本当にただ見渡したつもりになっていました(汗)
これからは説明を聞いた上で、本当に見落としが無いか自分の目でもしっかり確認します。

タブレットサイズ時のスタイリング

制作会社に勤めていた頃は、LIGさんで紹介されているViewport Extraを使ってPCレイアウトをタブレット時にも適用させるルールだったので、暫くタブレットサイズを考慮したスタイリングはしていませんでした。

「PCのスタイリング終わったー!」ってなった後に、「そういえばタブレットサイズどうなってるかな?」と検証したら見事に崩れてました(泣)
そこから固定値を%やvwに修正するのに時間ロス。
pxをvwに変換する方法は、はにわまんさんの記事を参考にしました。

修正作業

修正作業に関しては、各自作成したファイルを統合修正する作業(これは仕方ない)に加えて、ドロワーの挙動の修正が大きかったです。
iPhoneの実機確認でドロワーボタンの反応が悪く原因をググっていたら、position:fixed;の中にposition:fixed;を入れると不具合が起きるらしい記事を発見。

入れ子にならないようにスタイリングし直すも改善されず、6時間溶かしたところでギブアップしてSlackにヘルプを要請。
JSファイル内のjQueryの記述場所が悪かったのが原因でした…。
エラーの原因は意識していない部分にあったりするので、該当箇所に関連する記述は一見問題無さそうに見えても念の為触ってみるのが大事ですね。

終わりに

終わりに

今回は諸々反省点が見つかり、途中思ったように進まず大変でしたがとても良い経験になりました。
コーディングの機会をくださった忍者CODEさん。
それと一緒に参加されたコーダーの、
あさひさん
はまたろうさん
リュージさん
お三方にも感謝です!
ありがとうございました!

»追記
今回コーディングしたリペアサイトのライブコーディング動画が公開されましたので共有します↓

人気記事忍者CODEさんのコーディング案件に挑戦してみた

人気記事WordPressのトップにHTMLページを表示させる方法