サイバーエージェントが主催しているフロントエンドエンジニア向けのセミナー「Frontrend」は，毎回100名上の参加者がいるイベントです。2012年6月から不定期で開催されていましたが，2月21日に開催されたカンファレンス形式のFrontrend ConferenceをもってFrontrendの開催はひとまず終了することになりました。

本稿では，このFrontrend Conferenceで基調講演を行った斉藤祐也氏のセッションの模様をレポートします。

斉藤祐也氏「PRAGMATIC FRONTEND DEVELOPER」

今回の基調講演に登壇した斉藤祐也氏は，現在サイバーエージェントではなく，リッチメディアでUXエンジニアをしています。ただ，Frontrendをはじめたのが自分だということになっているため，担当することになったと話し始めました。

ちなみに斉藤氏はFrontrendのセミナー活動のほか，昨年，Frontrendの講演者らと共著で『フロントエンドエンジニア養成読本』を上梓しています。また，石本光司氏，谷拓樹氏とメールマガジンFrontend Weeklyを発行しています。

セッションタイトル「PRAGMATIC FRONTEND DEVELOPER」は，『⁠The Pragmatic Programmer』をオマージュしたものであるとし，今回はProgmatic＝実践主義をフロントエンド開発に当てはめて構成したそうです。「⁠今後のフロントエンドエンジニアがどのような成長戦略を描くべきか。次のレベルに向かうための道しるべになれば」と述べ，各論に入りました。

メンテナンス性を高めるためには，コラボレーションが重要

フロントエンド開発において欠かすことができないHTML，CSS，JavaScriptという言語は，基本的なことであれば専門的な知識がなくても書けてしまうというラーナビリティ（学習可能性）の高さを持っています。つまり，シンプルさと寛容さがこれらの言語の特徴です。

ただ，単に実用的に書けてしまう側面も持っています。また，仕様的にも変更が多く，決してメンテナンスしやすい言語ではありません。

そのため，メンテナンス性を高めるために，これまで様々な方法論やツールが生み出されてきました。メンテナンス性を高めるとはどういうことか。斉藤氏は，&yetのKarolina Szczur氏の記事から「メンテナンス性を高めるために，立ち向かわなければいけないチャレンジは技術的な問題ではなく，どのように効率的にコラボレーションを行うかということろにある」と引用し，メンテナンス性を高めるための問題は人と人の間に隠れているものだと指摘します。コラボレーションに焦点を当てることで，この問題を発見することに貢献し，イノベーティブなアイデアの発見にもつながることになると話しました。

そして，コラボレーションの効率を高めるための第一歩となる概念として，「⁠コードスタイルガイドライン」「⁠スタイルガイド」「⁠プロトタイプ」を挙げ，それぞれについて説明しました。

コードスタイルガイドライン

斉藤氏は，後述するIdiomatic Javascriptの作者Rick Waldron氏の「あるコードベース上のすべてのコードは，どれだけ多くの人が貢献したものだったとしても，一人の人間がタイプしたように見えるべきだ」という言葉を引用し，コードスタイルガイドラインとは，プロジェクトや会社組織でこのアドバイスに従うために作られるべきルールだと話します（会場の参加者のうち，コードスタイルガイドラインを持っている人は1割強程度だったようです⁠）⁠。

そして，「⁠コードスタイルガイドラインの存在自体は新しいものではない」と述べ，いくつか紹介しました。

JavaScirptのコードスタイルガイドラインとして，次のものを紹介しました。

• Idiomatic Javascript：JavaScriptの世界にコードスタイルガイドラインを持ち込んだものとのこと。
• jQueryチームのJavaScript Style Guide
• Airbnb JavaScript Style Guide

CSSのコードスタイルガイドラインとして，次のものを紹介しました。

• Idiomatic CSS：Twitterで働くNicolas Gallagher氏によるもの。
• CSS Guidelines：CSS Wizardryで知られているHarry Roberts氏によるもの。
• Sass Guidelines：Sassのエバンジェリスト的な立ち位置のHugo Giraudelによるもの（翻訳者を募集とのこと⁠）⁠。
• Code Guide by @mdo：Bootstrapを元々作っていたMark Otto氏によるもの。CSSに加えてHTMLのコードスタイルガイドラインも示している。

斉藤氏は，どのコードスタイルガイドラインが優れているかといことは問うべき質問ではないとし，「⁠まだチーム内で，または自分の中ででコードスタイルガイドラインがないのであれば，紹介したものを参考にして，自分のコードスタイルガイドラインを作っていくべきだ」と述べました。

コードスタイルガイドラインに則っているかを確認する

コードスタイルガイドラインは，継続して運用できなければあまり意味ありません。斉藤氏は，そのためにはツールの存在が欠かせないかないとし，コードスタイルガイドラインに則っているかを確認するのに便利なツールをいくつか紹介しました。

• EditorConfig：文字コードや改行コード，スペース，タブ幅などを異なるエディタの中で統一するためのツール。
• JSCS：コードスタイルガイドラインに特化したLintツール。jQueryのJavaScript Style Guideや，チームが使っているものをそのままガイドラインを元に確認できる。
• CSSLint：純粋なサポートスタイルチェッカーではないが，設定を調整すればある程度そのような目的でも使える。
• CSScomb：Lintというよりは整形ツールに近い。自分のチームにあった設定を簡単に選択でき，この設定を出力してくれる機能がある。

これらの確認で重要な点として，エディタ内で自動チェックが行われることを挙げました。また，Gitを使っていればpre-commit hookで，コミットする前にチェッカーを通して確認すること，通らなければコミットできなくすることも勧めました。

斉藤氏は，大事なことは自動化を目指すことだと言います。「⁠貴重なコーディングやコードレビューの時間を，コードスタイルを守るのに費やさない。どういうふうにコードを書くかではなくて，なぜこのコードを書いたのかの議論ができるようにすることがコードスタイルガイドラインの目標だ」と述べました。