2021/08/30 (最終更新日: 2023/12/03)

忍者CODEさんのコーディング案件に挑戦してみた

Life Work

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

本記事の内容

案件を獲得した経緯
案件スタート
反省点
終わりに

スポンサードサーチ

案件を獲得した経緯

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

毎年恒例の忍者CODE登竜門🥷
実案件の募集をさせて頂きます🔥

リペアを広めるサービスサイト
コーディングを担当して頂きます

募集人数は3名〜4名

【募集条件】
✔️実務経験を積みたい人
✔️HTML/CSS(SASS尚良)コーディング経験
✔️やる気のある方

やりたい方は奮ってDM下さい！

8/13　23:59締め切り pic.twitter.com/Z6ln7N4to1
— 忍者CODE⚔️プログラミング初心者が未経験からプロへ甲賀-KOGA/無料問題集の利用者3万人突破 (@ninjacodeee) August 12, 2021

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

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

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

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

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

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

案件スタート

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

打ち合わせ

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

作業開始

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

のせっちさん(@nosecchi01)のGulp導入noteがとてもわかりやすい！
Gulpの導入は過去に挫折してたので、今回は躓かずに最後まで進めて助かりました😊

ちなみにPugを触るのは初めてですが、この機会に慣れていこうと思います。
それと安いうちに購入できてよかったです✨#note https://t.co/Jxyd3ztHxz
— トシキ@Web制作(コーダー) (@tototo_jinguuji) July 21, 2021

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

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

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

スポンサードサーチ

反省点

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

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

とにかく時間が掛かった

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

画像かCSSか問題

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

デザイン見落とし

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

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

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

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

修正作業

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

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