作者別: kousuke

不安の中始まったフロントエンドの挑戦

今回のプロダクトで僕が任されたのは、フロントエンド周り全般。
特に、デザイン周りでは自分一人で結構な量の調査や選定、実践を行ないました。

• HTML/HTML5の調査
• CSS/CSS3の調査
• Sassの調査
• CSSデザイン/設計の参考書の選定
• 設計方針の選定
• 参考となる規約の選定
• プロトタイプの作成

などなど。

フロントエンドの調査に僕一人で突っ込まれて孤立しながら、右も左もわからぬまま「初心者」と「入門」を＆検索にググり続けました。。

※画像はイメージです。

CSS、HTMLの情報はネットに豊富にあるので、情報量については困りませんでした。
とにかく困ったのは、実際にCSSを書き始めた時。CSSにはたくさんのTipsがあります。その中でデザインに合うものを組み合わせてサイトを構築するのですが、当たり前ですが、TipsはTipsだけを説明しているものばかりです。

だから、

のような場合は、数あるCSSプロパティの中から原因を調査、発見して解決しなければならなかったのです。
Tipsだけでは対処できない部分ですし、原因の検索の仕方も難しいです。

対処法としては

• 地道に対象を探し、違う方法でのデザインを行なう
• 力技で無理やり対応する（位置を無理やり固定する。邪魔なモノは「display:none;」で消す。　などなど）

です。

綺麗なCSSが書ければ、もちろんよいのですが、まだフロントエンドのテクニカルレベルが低い僕には、スケジュール重視で無理やりなところも多々ありました。
あとになって、もっと正しい対応方法がわかることもありました、あまり立ち止まりすぎず、どんどんと前に進むことが重要だと実感もしました。

少しづつ見えてきたフロントエンドのカタチづくり

さて、悪戦苦闘しつつも進めていたフロントエンド挑戦ですが中でも特に印象的だったのが「CSSの役割分担」の設計の選定です。

いまはFLOCSSという設計思想を使用しています。ですが、立ち上げ当初はITCSSを使用しておりました。

フロントエンドの調査前に、チームメンバー全員で読んだのが『Web＋DB PRESS』という書籍のCSS記事でした。
記事には「ITCSS」について記述があり、ここで初めてCSSの設計という概念を知りました。

CSS設計調査ではその情報をもとに調査を行ないました。以下調査結果です。

これらは調査中に良く目にしたため、この中から選定しました。
（※今回はOOCSSやBEMは本線から外れるので割愛）

選定方法としては時間が限られていたため、設計方針を2つに絞り、実際にテストコードを書き、より良いものを選ぶことにしました。

採用
SMACSS　…　最もよく使われているという情報があった。
ITCSS　…　役割分担がわかりやすいと個人的に感じた。

落選
FLOCSS　…　BEM規約まで触れており、初心者にはボリュームが大きすぎると感じた。

以下は実際に作成したSMACSSとITCSSのサンプルコードです。

[SMACSS]

/**
 * SMACSS
 * https://app.codegrid.net/entry/smacss-1
 * http://qiita.com/matsui-a/items/9b9188904d160a3ec223
 * http://chroma.hatenablog.com/entry/2013/07/22/120818
 *
 * 「Scss」の設定ファイル
 * Settings...................プリプロセッサで利用するグローバル変数や全体の設定
 * Tools......................プリプロセッサで利用するmixinやfunctionなど
 *
 * 「SMACSS」の設定ファイル
 * ベースルール................normalize.css、reset
 * ベースルール................要素型セレクタ
 * レイアウトルール............ページのエリア分け
 * モジュールルール............再利用可能なパーツ
 *  →BEMを取り入れる場合はここ（http://chroma.hatenablog.com/entry/2013/12/15/165511）
 * 状態ルール..................特定の状態によってスタイルを上書き
 * テーマルール................テーマ管理用のCSS
 */
@charset "utf-8";

/* SCSS */
@import "settings";
@import "tools";

/* SMACSS */
// ベースルール
@import "normalize";
@import "base";

// レイアウトルール
@import "layout-1";

// モジュールルール
@import "module";

// 状態ルール
@import "state";

// テーマルール
@import "theme";

[ITCSS]

/**
 *  ITCSS
 * http://qiita.com/makotot/items/2c3e99f15dca2789d403
 *
 * Settings............プリプロセッサで利用するグローバル変数や全体の設定
 * Tools...............プリプロセッサで利用するmixinやfunctionなど
 * Generic.............normalize.css、reset
 * Base................要素型セレクタ
 * Objects.............装飾を持たないデザインパターン
 * Components..........コンポーネント
 *  BEMを入れるならここ
 * Trumps..............ヘルパー。!importantを利用していい
 */
@charset "utf-8";

// definitions
@import "settings";
@import "tools";
@import "generic";
@import "base";
@import "objects";
@import "components";
@import "trumps";

@import “settings”;　←これらが「レイヤー」と呼ばれ、各レイヤー毎に意味を持ちます。
@import “tools”;

importでレイヤーを呼び出しています。呼び出し順も重要で、CSSによる不具合を最小限にする仕組みのひとつです。
（詳細は各サイトでご確認ください）

結果としては、両者に大きな隔たりはなく、それよりも役割毎のレイヤー分割を行うことが重要だと感じました。
またSassの導入は決定しており「ITCSSのレイヤー設計の方がプロジェクトに合っている」と判断しました。

この一連の流れをリーダーに報告し、採用の許可を頂き、そして本格的なデザイン作成に入りました。

チームリーダーのフロントエンド参入により崩れ去った足場と気づいた未熟さ

設計方針がITCSSに決まり、少しづつ画面もできてきました。

画面自体はお見せできませんが
・全体レイアウト
・ヘッダ
・サイドバー
・メインコンテンツ
とTOP画面だけでいうと6,7割くらいです。

いままで外注したデザインのCSS/HTMLの拡張はありましたが、ゼロからのコーディングは初めてで骨が折れました。
ですが、少しづつデザインが完成されていくのはやりがいがあり、また成果が目に見えて楽しかったです。

「よし、もう少しでTOP画面は終わりそうだぞ！」と思っていたある日。いよいよリーダーがデザイン作業に参入しました。

リーダーはすぐに独自に調査とテストコーディングに着手しました。
「少し調べてみたいから、そのままTOP画面は作成を続けて」ということで僕はTOP画面作成を続けました。
やがて他メンバーも参入し、みんな独自にCSSのテストコーディングをしました。

ちなみに、この時点では以下を提出していました。

• ITCSS
• シングルクラス
• BEM
• 外部の使いやすそうな規約

しかし、やがてリーダーの調査が終わると「FLOCSSの導入をしよう」という話しが持ち上がりました。

理由としては以下です。

1. 「FLOCSSは　OOCSS, SMACSS, BEM, SuitCSS, MCSSなどの考え方を取り入れたもの。CSS設計のいいとこ取りをしたいときは、FLOCSSをベースにすると良い」という情報がある。
2. ITCSSの日本語ソースが少ない、世の中の流行りとネットの情報量は重要である。
3. 全体の方針が固まっていない、共通部品がないのに、各々がなんとなく作業に着手してしまったので、既にカオスになりつつある。
   なので、FLOCSSの導入、ガイドライン策定、共通部品・画面の雛形（サンプル）を先に定めてレビューしてから、全員で開発に入りたい。

聞いた時の正直な感情としてはスーパーサイヤ人になるのではないか、と感じるくらいに怒りと悲しみの狭間にいました。
「え、ちょいまって、OKしましたやん」とか
「全体の方針は決めましたやん、、だからITCSSでがんばってたんやん」とか
「TOP着手って僕だけやん、結局一人で全改修かい」とかとか

ただリーダーの

「みんなほぼ初心者なので、実際にやってみないと良し悪しがわからないし。で、実際にやってみた結果、方向性や改善点が見えてきたので、軌道修正と規約策定に入るところだね。」の言葉で、「いままでやってきた結果として、次の段階に進めたんだ」と言われた気がして救われました。

冷静に考えると

• 日本語の文献が豊富。
• BEMの考えを取り入れているので使いやすい。

というのは大きな利点です。

想定通り、改修作業はひとりで行なうことになり、精神的に辛いところでしたが、FLOCSSとITCSSは基本的な構造は似ているので、改修作業は案外簡単に完了しました。

また、リーダーの規約を決める力はすごく高く、それまでは方向性だけが決定しているのみで曖昧だった規約が次々に明文化されました。

チームにおいて「これを規約とします」を明らかにすると、メンバーも安心してコーディングができることも勉強になりました。

今回の挑戦を経て得たもの

以下が今回の失敗です。

• 選定基準として「情報量」や「世の中の流れ」を考慮しなかった。
• TOP画面のような大きい画面から作ってしまった。
• 規約の明文化をしていなかった。

以下、反省と学んだことです。

＞選定基準として「情報量」や「世の中の流れ」を考慮しなかった。
選定基準は多岐に渡るため、これを考慮すればいいというわけではない。
リーダーを満足させられなかったことが問題で、他の設計手法と比べてより良く、より合っていると言えるだけの材料が必要。
選定時のインプット量をもっとを増やす。

＞TOP画面のような大きいものから作ってしまった。
まず試作に時間がかかる。それだけで悪といっても過言ではない。
モーダルのような小さな雛形があれば話しにも説得力が増し、改修時に手戻りも少ない。
小さく始めることを心掛ける。

＞規約の明文化をしていなかった。
「これがうちのチーム規約だ。」という明確な形まで落とし込むと、メンバーは安心してコーディングができる。
規約の選定時にはここまでを行なうこと。

以上です。

リーダーからの一言コメント

チームリーダーの尾形です。

CSSのコーディングを行なう上で一番重要となるのは、やはり「規約」です。
規約を定めずにチームメンバーが好き勝手にコーディングを行なったらどのような結果になるか。。想像に難くないですね。

CSSの設計方法（方法論）は数ありますが、サイトやチームの特性を考慮したうえで、それに適した方法論を採用することが重要です。
ひとりだけでコーディングするのであれば、正直どの方法論でも大きな問題はないと思います。
今回の開発では、わかりやすさ、チームでの開発のしやすさ、再利用性や拡張性の高さが、規約策定においての重要なポイントとなりました。

まとめと予告

今回僕の失敗談をお話させて頂きました。
あまりフロントエンドの失敗談ではない気がしますが、これから選定やプレゼンを行なう方の参考になれれば幸いです。
最後まで読んでいただきありがとうございました。