僕が好きなWebのデザイナー、デベロッパーの一人である、CSS Wizardlyこと、Harry Roberts氏がdotCSSというヨーロッパのカンファレンスで講演した内容について書きたいとおもいます。
#10CSS
彼は大手のメディア企業などのフロントエンドを経て、現在はコンサルタントとして活動しています。CSS Wizardlyと言ってしまってるくらいに、CSSやその周辺のことについてブログでアイデアや意見を述べていたり、またinuit.cssのようなフレームワークを公開しています。現在は、また新たにITCSSというプロジェクトを進めているようで、公開が楽しいです。
彼がカンファレンスで話す内容は、CSS Architecure関連の話も多いのですが、ワークフローなどについての講演することもあるようです。その中で、今回とりあげたいのは、CSSの具体的なテクニックやコードの解説ではなく、フロントエンド開発の教訓、原則をまとめた10CSSという話です。
以下、公開されているスライドを元に、その10の原則を紹介します。
Ten Principles for Effective Front-end Development
※講演の動画などをみながらではないので、素直にスライドに書いてあることから推測して解説します。彼の意図とあってるかわからないですが、僕はこう捉えた、って感じです。
01.The Simplest Option Is Usually the Best
オプション、機能がシンプルであれば、実装コストも抑えられるし、早い。また他の開発者がその実装、コードを理解するのも容易になるので、メンテナンスやデバッグも良いとなるし、また失敗したり、壊れたりするリスクも減る。
02.Reduce the Amount of Moving Parts
Moving Parts = 可動部分、と素直に受け取ったとしたら、次のようなことかな、と。デザイン上、アニメーションなども含めたダイナミックなUIであるとか、動くようなものがあれば、極力減らした方がいい。そのすべてに何かバグや失敗を招く可能性がある。それに関する機能、コードは減らすべき。
03.Understand the Business
コードそのものは重要ではなく、それによる最終成果物に意味がある。ビジネスとして、その仕事のコストや価値を理解することが大事。
04.Care Less, Care Appropriately
誰もあなたのコードのことを気にかけたりしないし、それに執着するべきじゃない。プロジェクト本来の目的を忘れず、関わる人達が求めていることとのバランスを取る必要がある。決して自己中心的にはならないようにする。
05.Pragmatism Trumps Perfection
明日完璧なものをつくるよりも、今日（完璧ではないが）十分なものをつくる方が良いこともある。ビジネスの価値ではかるようにする。
これはコードとして、実用なレベルになっていれば十分で、04のような開発者の美徳で完璧さを求めるべきではない、ってことかもしれないですね。
06. Think at Product Level
デザインをブラウザで再現する、ということだけがあなたの仕事ではない。狭い世界にこもらず、周り巻き込んでいこう。プロダクトにとって正しいことを実践しよう。
07. Do Not Design Systems around Edge-cases
数少ないケースに目を向けた設計をしない。まずは一般的なシナリオを想定して組み立てる。
08. Do Not Make Decisions Based on Anecdotal Evidence
どこかで聞いてきたエピソードや事例を元に判断すべきではない。ストーリーではなく、データを信用する。
09. Don't Build It until You've Been Asked for It
頼まれていないものを作ってはいけない。それは無駄にコストをかけるし、仕様もないものをつくっても誰も検証できない。
またそれはプロジェクトの片隅に残り、誰もメンテナンスしたくないから、作った当人がメンテナンスしなければいけなくなる。
10. Expect and Accommodate Change
常に適応性、柔軟性、機敏性を持つようにする。すべてのものが、変わる可能性を持っている。
まとめ
すごく特別な至言ということでもなく、ああその通りだね、というような内容ではありますが大事な内容です。つい技術的なことを追っていくと、それがビジネスを支える一つとしてやっていることが抜けてしまうことはあるので、これらを忘れないようにしたいものです。