本当に使える！PHPerなら知っておきたい便利な配列関数79選！！ ver.2015

こんにちは、出前館愛用者の金城です。怠惰に過ごしたい休日といえば、deliveryですよね！！

さて、秋も深まりつつある今日この頃ですが、この場を借りてPHPにおける連想配列について書いてみたいと思います。
私達コネヒト開発陣一同は、親しみと敬意を以って連想配列に日々接しております。
このブログをご覧にいらっしゃるみなさまも、きっと日々の生活の中で・・・職場で、家庭で、あるいは気の置けない旧友との心温まる交流の場面でも、連想配列に夢中で居る事と思います。

そんな彼らについて、php.netを覗いてみると、このような記述があります。

配列で使用する便利な関数がたくさんあります

あの「一体、何に使うんです・・？」といった関数も標準で多く用意されていることで名高いPHP語をして曰くところの、「たくさん」です。
どんなものかとワクワクしますよね。

そこで、今回は「どんな関数があるのだろう」を見ていきたいと思います！
単に50音順に並べても分かりにくいので、公式リファレンスをベースにして、(主観で)7つのグループに分けながら「たくさんの」関数を紹介してみたいと思います！
見たこともない、まして使ったことのない(あるいはこの先も使うことのない!)関数が、きっと1つはあるはず・・？

ほとんどJSが書けなかった新米デザイナーが、ベンチャー入社半年で学んだチーム開発で大切な「7つのおもてなし」

こんにちは！デザイナーのきよえし(@kiyoe_furuichi)です。
この度10月でConnehito.incに入社して半年が経ちました！めでたい！
ほとんどJSが書けなかった私も今ではフロントもごにょごにょするデザイナーになりました。

良いタイミングなので今回のエントリーは、半年の間に学んだことの共有として、 デザイナーもできる、チーム開発で大切な「おもてなし」についてご紹介したいと思います。

チーム開発における「７つのおもてなし」

0. どうして「おもてなし？」

入社した当時を振り返った時、自分の開発過程やメンバーとのやりとりを見ていかに早く自分のタスクをこなせるかを優先した"オレオレ"デザイナー だったことに気づかされました。その衝撃をきっかけに、"チームとしてサービスを作り上げる"にはどうすれば良いのかを意識して考えるようになったんです。
それから、チーム開発で大切なことはメンバー全員が他のメンバーのことを考え、気持ちよい実装を行えるように気遣う「おもてなし」の心を持って開発を行うことが大切だなあと感じるようになりました。
現在もまだまだ模索中ですが、今回は、今の私が考える「おもてなし」について以下にまとめてみます。

「7つのおもてなし」

1. こまめな共有・把握
2. 思考の過程を残す
3. 互いをねぎらう
4. ”伝える”コメントに
5. 楽しむ工夫をする
6. 会話からインプットする
7. できることを増やす

これから具体例をいくつかご紹介しますが、実際に過去に行った会話を抜粋しています。

1. こまめな共有・把握

おもてなしのポイント

メンバーがそれぞれ今何に着手しているか、次に何をするのかを共有・把握をする。開発が滞ることがないよう、メンバーそれぞれの状況を気遣うことが大切！

具体例

私：次タスクAに着手する予定ですが、もしかしてエンジニアさん的にタスクB先にやっておいたほうがコンフリクトせずスムーズにすすめられそうですか？？

エンジニア ： あ、そうだねー！タスクBを先にデプロイしたいかも！先行して実装しておいてもらえると助かります！ありがとう🙏

私：かしこまりました！実装しておきますー！

声かけを行ったり、メッセージで前もって確認しておくなど、同じタスクを受け持つ実装者が次に着手するものを把握しておきましょう。(いつどのタイミングで上がってくるのかまで分かっておくと◎) 把握しておくことによって、"もしかするとこっちを先に着手したほうがいいかも"、といったような気づきが生まれたり、逆も然りで、共有しておくことによって、メンバーも気づきを得て、お互いのことを気遣ったタスクの順序づけをすることができます。それによって、滞ることなく、気持ち良い開発が行えるようになります！

2. 思考の過程を残す

おもてなしのポイント

仕様や実装に必要な情報だけでなく、その時何を考えてこうなったのか、思考の課程をメモとして残しておくようにする。未来の自分、チームが当時を振り返る際に大切な手がかりになる！

具体例

ディレクター：この機能なんだけど、なんでこの色になったんだっけ？

私：えっと、、記憶ちょっと曖昧なのでメモの確認させてください！

私：(確認してみよ〜)

[メモ]：要素Aのカラーリング、イメージ的には淡いピンクが適しているんだけど、要素Bとかぶるからナシ。色々試した結果、淡い紫にすることに。ちょっとネガティブな印象を与えるかも、数値とFBで振り返ってみて要検討

私： ディレクターさん、イメージ的には〜なんですが、一方で〜・・・

ディレクター：なるほど、だよね。ここやっぱピンクにした方がいいかも。例えばさ〜・・・

毎日いろんな新しい機能を実装していると、どうしても記憶が曖昧になったり抜け落ちることがあります。 リリース後の機能を振り返るためには、何を考えてこの機能になったのか、文脈を理解した上でレビューをしなければなりません。でもそれって結構難しいんですよね…。 なので少しでも思考を思い出しやすくするために、未来の自分、メンバーのおもてなしとしてメモとして残しておきましょう。

3. 互いをねぎらう

おもてなしのポイント

メンバーの頑張りをねぎらう声かけ・感謝の気持ちを伝えることを大切に。チームの結束はここから生まれる！

具体例

「LGTM！」

LGTMとは、Looks good to meの略語で、いいね！の意味合いでつかう言葉です。よくエンジニア界隈でPull Requestのレビュー完了時に使われていますね！ 私たちもレビューの完了時に、レビュワーが実装者に対して労いの言葉として「LGTM!」を送っています。

主にこのサイトを利用しています : LGTM.in/g

「おつです！」

機能をリリースしてSlackで全体に通知する際、メンバー全員が実装者に対して「おつです！」「おつ！」「おつかれさまですー！」など労いの言葉をかけるよう心がけています。

このように、お互いを労うことはチーム間の信頼関係を築くうえでとても大切です。 実装していただいたことへの感謝の気持ちを持って開発を行ないましょう。

4. "伝える"コメントに

おもてなしポイント

ミスコミュニケーションを起こさないよう、相手に言葉の内容が”まっすぐ伝わる”文章でメッセージを送る！

大きな開発の終盤になったりすると、それぞれ自分のタスクの実装で余裕がなくなりがちです。そんな時はどうしてもレビューやメッセージのコメントが荒くなり、ミスコミュニケーションが起こりやすかったりします…！

そんな課題を簡単に解決するのが、emoji・顔文字です！ 使うと文字が与える単調さがちょっとだけ緩和されて、どんなときも安定感のある”伝わる”コメントをすることができます。

具体例

before

ここ実装抜けもれあります、よろしくお願いします。

after (emoji)

ここ実装抜けもれあります、よろしくお願いします 🙏✨

after (顔文字)

ここ実装抜けもれあります、よろしくお願いしますヽ(=´▽`=)ﾉ

ちょっとやわらかい印象になりますよね！

5. 楽しむ工夫

おもてなしのポイント

チーム全体がポジティブに開発できるよう、ちょっと楽しくなる工夫を取り入れてみる。 単調な作業の中に、クスッとさせるおもしろさを取り入れるのも、相手の気分を明るくするおもてなしの一つ！

開発を行っていると、バグが出たり、謎のレイアウト崩れなど、ちょっとした闇が稀に襲ってくることがあります。 そんなとき、気分がちょっと上がるものがあると嬉しいですよね！

具体例

ドラゴン

チーム全体ではバグのことをドラゴンと呼んで楽しんでますw ちょっとバグfixドラゴン退治が楽しくなりました。

元ネタ : バグをドラゴンと呼ぶ運用を始めて1ヶ月くらいたった - Konifar's WIP

Reactionの投げ合い

最近、SlackのReactionが頻繁に飛びかってます！ よくわからないemoji(笑)だったり、ランチや夕飯の時間帯になると食べ物のemojiがつくことが多いです。

ラーメンション

@ramention kiyoeshi

ラーメン + メンション。大体週末にramentionしてチームでラーメン食べにいきます。

寿司🍣

最近、寿司(🍣)のemojiでReactionするとなんかくる？！？！？？？？！(謎)

このような、ちょっとしたことだけど、見てるだけでちょっとクスッとなるような工夫があると、チームがより明るくポジティブな雰囲気となって良いアウトプットを生み出すことにつながっていくと考えています◎

6. 会話からインプットする

おもてなしのポイント

それぞれのメンバーの視点から見るチームの課題をインプットし、もっとチーム開発をより良くするための鍵を積極的にさがしてみる！

開発を行っていると、目の前にあるそれぞれの課題をこなすことに精一杯で、視野が一方向になりがちです。なので月一程度に、ラフに1to1ランチをするのがおすすめです！

具体例

もっと仕様詰める段階でサーバサイドも見たいです！その方がロジックの工数の見積りだったり、ここはこうじゃない？みたいなところが言えるので後々の出戻りがすくなくなるかと！

7. できることを増やす

おもてなしのポイント

ちがう役割の領域にトライする。一歩踏み入れてできる範囲を増やすことによって、単純なコードなどでの手戻りなどが短縮されるため、お互いに工数を減らせることにつながる。

具体例

サーバーサイドエンジニア：フロントが簡単なViewを表示するロジックが書けると結構助かるかも！

サーバーサイドエンジニア：新しいページをつくる際のRoutingをぱぱっとできるようになってくれると助かります🙏

iOSエンジニア：ストーリーボードでViewを少し作れるようになってくれるとネイティブのUI部分任せられるから助かるかも。

こういったように、役割のちがうエンジニアさんから、"できるとうれしい"部分を日頃から聞いてストックしています。 休日などにコードを読んでみたり、書いてみたりして覚えることで、お互いの手間が省くことができるようになります。 できないところは教えてもらいつつ、自分のできる領域を広げることにトライしてみましょう。

まとめ

以上、「7つのおもてなし」いかがでしたでしょうか。

人の温かみのある、なくてはならないサービスであり続けるために、チーム開発をする上で「おもてなし」の心はとても大切だと考えています。 この半年、開発をしていて思うのは作り手のテンションがユーザーさんにも伝わるということです。 ポジティブな感情はよいサービスを生み出す原動力。少しの心遣いで、チームの雰囲気が良くなり以前よりもっと楽しく開発を行えるようになりました！

チーム開発で大切なことは、 メンバー全員が他のメンバーのことを考え、気持ちよい実装を行えるよう「おもてなし」の心をもった開発を行うこと です。 みなさんも、「おもてなし」について今一度考えてみませんか？
最後まで読んでいただきありがとうございました！

---

コネヒトではエンジニアさん、デザイナーさん、デザイナーさん、デザイナーさんをWANTEDしています！ 全チームメンバーが手厚くおもてなしします♡ お待ちしておりますー！
www.wantedly.com

Plistを操作するPlistBuddyでiOS9のApp Transport Securityの煩わしさから開放される

こんには！コネヒト所属のラブライバー兼エンジニアの田村(@Utmrer)(26歳)です。 先日母にラブライブレードが見つかりこの世の地獄を味わいました。

さて、iOS Developerの皆さん、PlistBuddy使ってますか？ PlistBuddyはMacに最初から入っているPlistを操作するコマンドで、弊社のiOS開発で活躍しまくりのコマンドです。
今回はPlistBuddyでiOS9から対応が必要になったApp Trasport Security(以下ATS)の煩わしさから開放される方法をご紹介します。

開発環境のドメインとATSの設定にかかる問題

先日iOS9がリリースされ、ATSの設定をしていたDeveloperの方も多いと思います。 サービスで使用しているドメインがすべてSSLに対応している場合は必要ありませんが、対応していない場合はNSExceptionDomainsにホワイトリストで指定しなければいけません。
しかし、問題になるのが開発環境のドメインをInfo.plistに追加するかどうかです。

開発環境のドメインを本番環境のサブドメインにしている場合はNSIncludesSubdomainsで大丈夫ですが、まったく違うドメインの場合はNSExceptionDomainsに追加する必要があります。
しかし、開発環境のドメインをNSExceptionDomainsに追加するのには抵抗があります。 なぜならInfo.plistはunzipすればすべての人が見ることが出来るので、開発環境のドメインを公開することは望ましくありません。

そこで活躍するのが複数のPlistをMergeして1つのPlistにするPlistBuddy Mergeコマンドです。

PlistBuddy Mergeで環境別にATS例外を設定する

開発環境のドメインを以下のようなPlistにしてInfo.plistとは別に用意しておきます。

そしてBuild Phasesに以下のようなScriptを追加することによってDebugのConfigurationでビルドした時のみ、開発環境のドメインをInfo.plistに追加する事ができます。(Preprocess Info.plist FileをYesにする必要があります)

これでDebugビルドの時だけNSIncludesSubdomainsに追加するとか、間違えてReleaseビルドに開発環境のドメインを含めてしまうなどのミスや煩わしさから開放されます。 atsPlist="${SRCROOT}/YourApp/development-ats.plist"の所をatsPlist="${SRCROOT}/YourApp/${CONFIGURATION}.plist"とすれば複数のConfigurationで別々のドメインを設定することだって出来ます。やったね！

おわりに

弊社のiOS開発では他にもPlistBuddy SetでBundleVersionにcommit hashを含めたり、外部ライブラリのDebug Modeを切り替えたりしています。
「PlistBuddyでこんなScript書いてるけどすげー便利だぜ」というのがある人は是非教えてください。

参考文献

PlistBuddy(8) Mac OS X Manual Page

インフラエンジニアがサービスの0→1を創る際に意識した、たった1つのこと

こんにちは！

CTOの島田(@tatsushim)です。 先日mamari tech nightというエンジニア向けのLTイベントを社内で開催しました。 その際にママリのインフラ構成について発表したのですが、当時を振り返り大事だなと思うことがあったので、今回はその学びを共有したいと思います。

完璧なインフラ構成は必要ない

結論からお伝えするとサービスの立ち上げ時に「完璧なインフラ構成は必要ない」というお話です。

ママリの最初のインフラ構成

実はママリの最初のインフラ構成は以下のような構成になっていました。*1

構成は1台のEC2インスタンスのみで、もちろん、DB(MySQL), Apacheなどは全部入りです。 しかしインフラ構成はしばらく変えず、アプリケーションの機能開発にリソースを割きました。

そのインフラ、本当に今必要？

サービスを創る際、1エンジニアとしてはそのサービスを滞りなく運営するために必要なインフラを整えます。 その際、例えば以下のようなケースを考えます。

• サービスがもしヒットしたら膨大なトラフィックが来るはず
• ユーザーランキングの集計ロジックは重いから、キャッシュサーバーたててキャッシュしておかないと
• ユーザー数が100万になったときにも耐えられるようなインフラ設計にしておかなければ

しかし上記はほとんどのケースでサービスのリリースからある程度経ったあとに必要とされる機能です。 実際は多くの場合以下のようになると思われます。

• サービスがもしヒットしたら膨大なトラフィックが来るはず
  → 多くのケースで、期待した程膨大なトラフィックがそもそも来ない
• ユーザーランキングの集計ロジックは重いから、キャッシュサーバーたててキャッシュしておかないと
  → ユーザー数が数千人程度の集計ならMySQLで十分なレスポンス速度が出る
• ユーザー数が100万になったときにも耐えられるようなインフラ設計にしておかなければ
  → サービスによるが、100万人まで数ヶ月〜数年かかる。

最後のケースはまず1万人いってから考えても遅くないかもしれません。

リリースから1年後のママリのインフラ構成

リリースから1年後はサービスの成長に伴い、大規模なトラフィックをきちんと捌ける構成になっています。

しかし最初からこのような構成にするのは金銭的にも人的にもコストが高いです。 よってサービスの芽が出てから必要に応じて構築すればよく、
リソースの少ないスタートアップにおいてはサービスの本質的な機能の開発にリソースを割くべきです。

「やらないこと」を決めるということ

開発に限ったことではないですが、「やらないこと」を決めることが大事だと日々痛感しています。
1日が本当にあっという間に過ぎていく中で、如何に本質的なことにエンジニアのリソースを投下できるかが勝負の分かれ目だと感じています。

最後に

最後まで読んでいただき、有難うございます。 このブログのフィードバックや、ウチはこうやってるよ！という話を一緒にさせてもらえると嬉しいです。
この記事を読んでくださったあなたが「やらないこと」をどう決めてるか是非教えてください。

*1:この構成からスタートした理由はインフラ代の節約が主な理由です。

継続率を落とさずに160%成長させたプッシュ通知での最強グロースハックのコツ ママリQ

こんにちは。コネヒトでディレクターをやっています松井と申します。

今日は、ママリQにてプッシュ通知を使って継続率を落とさずに160%成長させたグロースハックについて紹介したいと思います。

ママリQのダウンロードはこちらから。

iTunes の App Store で配信中の iPhone、iPod touch、iPad 用 ママリQ-妊娠,出産,子育てや妊活の疑問を話せるママ友が欲しいママのアプリ

ママリQ 妊娠,出産,子育て,妊活、ママの疑問をママ友が解決 - Google Play の Android アプリ

継続率を上げるにはユーザーのマインドシェアを勝ち取ること

どのようなアプリでも毎日起動され続けることがアプリのゴールとなっていると思います。 ただユーザーが自発的にそのアプリを起動しよう！と思い立って起動されるアプリはとても数が限られていますよね？

Facebook、Twitter、Instagram、ニュースアプリあたりはとても利用頻度が高いとは思いますが、 それ以外の中で毎日起動するものはその人の一日の中で「大切なもの」という認識をされているからだと思います。

そこで私は

毎日起動され続ける = ユーザーの頭のなかを占めている割合が大きい

つまり

マインドシェアを勝ち取ることが重要

という仮説を立てました。

ユーザーのマインドシェアを勝ち取るのにプッシュ通知は効果的

さて、ユーザーのマインドシェアを勝ち取るにはどのようにしたらよいのでしょうか？ いくつか解決アプローチはあると思いますが、1つの施策として効果的なのはプッシュ通知だと思います。

ただ、一筋にプッシュ通知をやればいいんだ！とは行きません。 みなさんもユーザーとしてアプリを利用していて、「この通知ほんとうざいな〜」と感じたことがあるのではないでしょうか？

プッシュ通知は一歩施策の方向を間違えると継続率や最悪のケースは退会、アプリ削除まで起きてしまう諸刃の剣になってしまう可能性があります。

しかし、これから説明する事例のようにユーザーにとって価値のある情報を提供できればこそ、継続率を落とすことなくユーザー数を大幅に成長させることが出来ます。

そのためにはユーザーにとってママリはこういう時に立ち上げると便利なんだ！と体験してもらうことで、 ユーザーの生活の中で深く記憶に刻まれる必要があります。 その結果としてマインドシェアを勝ち取ることができるのです。

では、いつ、どんな時にプッシュ通知をすればよいのでしょうか？Connehitoでのプッシュ通知の施策の設計についてお話したいと思います。

PHPでブラウザテストの自動化！ Facebookの作ったツール「php-webdriver」で人生がときめく (サンプルコード付き)

こんにちは、コネヒトでPHP書いたりしています金城(@o0h_)ともうします。烏龍茶が好きです。

(テスト自動化おじさんの弊社内におけるイメージ)

突然ですが！ 皆さんも、自分の実装についていまいち自信が持てない時はございませぬか。
「あの実装・・頭をよぎる不安・・眠れない夜・・・・」そんな気分で毎日を過ごしていませんか？
「誰かに許して欲しい、安心をください」。
そんな時はテストを書きますよね。緑色が好きな人、この界隈には私だけではないはずです！

ただ、どうしても検査しづらいな〜どうやって試せば良いかな〜と悩ましい時もあるのではないかと。
「エンドユーザーが直接触るのってブラウザでしょ、だったら実際にブラウザを使った操作が滞りなく可能なら問題ないよね・・」とか、考えたことありませんか？
ここで闇堕ちしたプログラマは、ぽちぽちとhttp://localhostを開いたGoogle Chromeをマウスで弄って、束の間の平穏を得るのです。(身に覚えがあります)

ただ、これって恐ろしく面倒くさいし不安定だし絶対に毎回やらない手順です。
誰か勝手にやってくれ！

それ、Seleniumでできるよ

「ブラウザの操作をプログラマブルにしたい、しかもPHPで書きたい」。
それを実現する技術がございます。 百聞は一見にしかず、ということで「PHPがブラウザを動かしているサマ」を実際にご覧ください。

最初にCakePHPのテストコマンドを実行させた以降は、キーボードもマウスも一切触っていません。こういった、「ページを開いて→指定した要素をクリックして→フォームに値を入力して→送信ボタンを押して→フォームの送信結果をみる」という操作及び検査ができるのです。
しかも、非常にシンプルかつ短い行数のコードで実現で！！
実際に上記動画にて叩いたコードを参照しながら、ご紹介したいと思います。

サービスの成長を止めたらあかん！『よりよいCSS設計』を考えよう！

はじめまして！デザイナーのきよえし(@kiyoe_furuichi)です。 ママリ、ママリQ のUIデザインとフロントコーディングを担当しています。最近暑すぎて溶けそうです。スイカたべたい！

さて今回は、爆速で拡大成長中のママリが行っている『よりよいCSS設計のための開発手法』についてまとめてみました。

『よりよいCSS設計』を考える

「あれ？スタイル効かない…!importantしよ♡」

身の回りでこのようなことは起きていませんか…？ 意図しないことが頻繁に起こる場合『CSS設計』の見直しが必要かもしれません。

私たちは普段からサービスを成長させていくにあたって『よりよいCSS設計』とはなにかを考え、チーム内で検討し、改善をおこなっています。
そんな私たちが実践している開発手法や取り組んでいることについて、いくつかご紹介していきたいと思います。

きっかけ

はじめに、私が『よりよいCSS設計』を考えはじめたのは、他のエンジニアさんと一緒にフロント開発をすることになったときに自分の不甲斐なさを感じたのがきっかけでした。
これまでひとりでデザイン/フロント実装を受け持っていた経験しかなく、他のエンジニアさんが書いたコードをレビューする、また私が書いたコードをレビューして頂くことが初めてのことでした。そこでいかに自分の書き方が負の遺産を生み出す書き方をしていたかを知って、悔しくなったので改めてCSSのことを勉強し直しました。
それを機にCSSの書き方や、設計について深く興味を持つようになり、今ではサービスにとってそれが『よりよい設計』であるか、またその設計がユーザー体験(開発者含め)、にとってどう良いのかを考える『CSSおねえさん』へと進化しました！

CSS Architecture

私たちの考える『よいCSS設計』の定義は、色々検討した結果、1番納得感のあるPhilip Waltonさんが提案するCSS Architectureをベースとして考えることにしました。

CSS Architectureでは、以下のようなCSS設計をする上で目指すべき4つのゴールを掲げています。 他にもバッドプラクティスの改善方法など、よりよい設計のためのポイントがいくつか提案されています。

1.『予測しやすいこと』

追加や更新をしたスタイルがちゃんと期待通りに振る舞うことのできる設計にしましょう。 そのスタイルが意図していない箇所に影響を与えないようにすること。

2.『再利用しやすいこと』

スタイルは、ボタンやフォームなど機能ごとに細かく分離した設計にしましょう。 再利用性のあるコードを書くことで再度同じUIを作成する場合、新しく追加する手間がなくなります。

3.『保守しやすいこと』

要素を追加・更新したことによって、既存のスタイルをリファクタリングするようなことが起こらない設計にしましょう。

4.『拡張しやすいこと』

サイトの規模が大きくなっても、複数の開発者がメンテナンス・管理しやすい設計にしましょう。

これらをまとめると、『メンテナブルな設計』が、よいCSS設計のゴールであると考えられます。 CSSは書くのがかんたんな分、破綻しやすいので運用・管理をしっかりと考えた設計にすることが大切ですね。

ちなみにCSS Architectureはどんな環境で設計するにおいても(他言語においても)参考になるお話なので、読んでおくと幸せになれるかもしれません！

参考 :
CSS Architecture
Hiroki Taniさんの日本語訳 CSS Architecture

私たちが実践している『CSS設計の開発手法』

私たちの開発環境では、CSSの設計ガイドラインとしてFLOCSS(フロックス)、コーディング規約にGoogle HTML/CSS Style Guideを採用しています。 ただ、これらに完全に準拠しているわけではなく、それぞれの考え方をベースとして自社の環境に合うものを取捨選択しています。

FLOCSSを用いたCSS設計

ママリではつい先日、CSS設計のガイドラインとしてFLOCSS(フロックス)を採用しました。 現在は要素の追加・変更時などに、FLOCSSに沿った設計となるようリファクタリングを行っています。

FLOCSSとは？

BEMの命名、MCSSやSMACSSのレイヤー設計などの考え方を組み合わせた『CSS設計ガイドライン』です。メロン本で有名ですね！ CSS ArchitectureがCSS設計の目指すべきゴールで、FLOCSSは破綻しやすいCSSをコンポーネント(部品)として扱うことによって、再利用性や保守性を高めるCSSの設計ガイドラインです。

参考 :
FLOCSS
CSS設計の教科書 (メロン本)

FLOCSSを使うメリット

個人的に使ってみて感じたものですが以下のメリットがあるかなと思います！

• 学習コストが低いこと。とりあえずメロン本を読めば大丈夫！
• 日本製なのでほかのガイドラインと比べて取り組みやすかった。
• OOCSSをベースに作られているので、エンジニアにとっても構造の理解がしやすい
• Objectは先頭に .c-* や .p-* などのプレフィックスをつけるので直感的に構造の把握ができる。

コーディング規約

Google HTML/CSS Style Guideとは？

Googleが提案するHTML/CSSの『コーディング規約』です。命名規則、インデントやスペースの開け方などが細かく定められています。

参考 :
Google HTML/CSS Style Guide
「Google HTML/CSS Style Guide」を適当に和訳してみた |

コーディング規約は、Google HTML/CSS Style Guideを採用しています。 コードの書き方も『よりよいCSS設計』を目指すことにおいて考えるべき要素のひとつと考えています。特に複数の開発者がコードを管理する場合、『コードの読みやすさ』を考えることはとても大切です。
インデントやプロパティの記述などが揃っているだけでも全体のコードを読んで理解するまでの早さって結構変わるんですよね。
現状単独での開発行っているとしても将来的にメンバーが増えることが見込まれるのであれば、何かしらの規約を設けて『オレオレコード』とならないように整形するのがベターかとおもいます！

社内コーディング規約

他にも社内でのコーディング規約として以下を定めています。

たとえば、

• サイズの単位は基本的に px で書く。
• class名で使用する単語はなるべく省略しない。
• Role of threeにのっとって、各違う箇所で３回同じ要素を使用する場合は、再利用することを検討する。(リファクタリング)
• jsで使用するclassはスタイルを適用するclassとは別に付与する。
• jsで使用するclassはわかりやすく先頭に .js-* プレフィックスをつける。

他にも、開発の中でこれは？というものがあれば都度相談しあって、ルールを更新しています。

『よりよいCSS設計』を生み出す

さて、いかがでしたでしょうか。 今回ご紹介した内容が、みなさんの『よりよいCSS設計』を考える上で、お役にたてると幸いです。

私たちも模索をしながら日々『よりよいCSS設計』について改善を行っています。 現段階で、これだ！な答えはまだありませんが、実装する中で意識していることがあります。

『もし明日から10人、100人のエンジニアを採用して共にママリの開発をすることになったとき、ひとりひとりが容易にコードを理解できる設計であること。いかなるときも、成長のスピードを止めないために、バトンを渡しやすい環境を維持し続けること。』です。

例えば、明日から新しいエンジニアがジョインしてくれるかもしれない → ここの要素ちょっとわかりずらい気がするからコメントをしっかりめに書いておこう。みたいに この先、どうなっていくかを想像してコードを書くことができるようになると思います。

ゴールとしては『メンテナブルな設計』を目指すことに変わりはないですが、なぜそれが必要なのかを意識的に想像することで、もっと普段から『よりよく』書けるようになれると思います。

その小さな積み重ねや、コードは一時的な実装のために書くのではなく、サービスの成長のために書く、といった想いを持つことは自然と『よりよいCSS設計』を生み出すことにつながるのではないでしょうか。

今後も引き続き『よりよいCSS設計』について考えていきたいと思います！

また、みなさんもあらためて考えてみませんか？

おわりに

Connehito.incではいけてるエンジニアとデザイナーを募集してます！
爆速で拡大成長中のサービスのCSS設計をいっしょに構築しませんか？？

ぜひラフにランチでも〜！よろしくお願いします！

www.wantedly.com