『入会のしおり』全36ページの冊子を作成しました

先日、サイタカメラ教室(グループレッスン事業：詳しくは先日のプレスリリースをご覧ください。)で配布する全36ページの冊子『入会のしおり』を作成しました。
弊社のデザイナーは私1人で、普段はWebのデザイン作業をメインとしていますが、まさかコーチ・ユナイテッドに入社して結構しっかりめのエディトリアルができるとは思っていなかったので、改めて紙とWeb、両方のデザインができてよかったな、と実感しました。

と、同時に個人的にも久しぶりの紙案件を通じ、エディトリアルデザインとWebデザインにはそれなりに違いがあるということを再確認したので、まとめてご紹介しようと思います。
これから両方をマスターしたいという方や、転向したいと考えている方の参考になれば幸いです。

紙とWebの違い一覧

ザーッと箇条書きしてみると、

・完成物の見せ方

紙）紙の選定などを除き、デザイン開始から一貫してその形でユーザーに情報を届ける。

Web）デバイスのサイズや、ページ中の機能により形が変わるので、文字組み・段組みに対するある程度のこだわりを捨てる必要がある。また、エディトリアル出身デザイナーは、「A4サイズといったサイズ概念がない」ということを始めに理解しておかないと、最初から躓く。

・カラーモードが大きく違う。CMYKとRGB

紙）印刷における色の表現方法はCMYK。
インクによる光の吸収を利用して色を表現している(減法混合)ため、RGBと比較すると、色域が狭いので、鮮やかな色はくすむ。
各印刷会社の色見本の確認がとても重要。鮮やかな色や金色や銀色などは特色を使うことでカバーするしかあない(通常特色はオプションとなり、費用が高くつく)。

Web）ディスプレイにおける色の表現方法はRGB。
ライトの発光を利用して色を表現（加法混合）している。デザイン作業中の色がそのまま反映されるので、CMYKと比べると特に気を使うことはない。
しかし、CMYKのような特色が使えないので、本物の金色銀色や、蛍光色は表現できない(素材を使うか、それっぽいのを作るしかない)。

・ベクターとラスター

紙）コンピュータ内部で表現した画像。拡大縮小しても荒れることがないのが特徴。

Web）ドットを集めて構成された画像、劣化に注意が必要。

・dpi

紙）dpiとは、1インチあたりのドット(点)量。
印刷物の場合、多くの印刷会社が推奨している350dpiに解像度を指定する。

Web）一方ディスプレイの場合は72dpiに解像度をして作業を進めていくのが一般的。

・単位

紙）印刷を考慮し、mmに単位設定して作業するのが一般的。
線やテキストはpt を使うことが多い。

Web）pxが一般的。

・フォントの扱い

紙）使えるフォントがとても多く、商用利用無料のものも多い。

Web）デバイスに左右される&まだまだ日本語Webフォントのハードルは高い印象。日本語サイトで見出しなどに特殊なフォントを使用する場合、画像に頼らざるを得ないのが現状。

・レイアウトの仕方

紙）1文字レベルで細かに調整。段組も自由自在。

Web）後のコーディングや、デバイスの違いを考慮。大胆なことがし辛い。

・プレビューの仕方

紙）実際に刷って仮製本をする。意外と時間がかかる

Web）すぐブラウザ(モニタ)で確認できる。

・デザイン完成後のアクションとゴール

紙）文字校や色校はとても大変。入稿時に急に不安になることも。(鍵しめたかな…で何度も確認したくなる感じに近い。)
ここまでの険しい道のりを経て印刷された現物を見たときの感動は一入。つまり印刷したらひとまずゴール。

Web）デザイン完了後はコーディング作業に突入。
ここからがスタートかもしれません。多角的な検証を元に、更新され続けるのが当たりまえ。

でもデザインすることは変わらない

このように紙とWebにはなかなかの違いがあるわけなのですが、たとえ媒体が異なっても、ユーザーへのメッセージを"形"に設計するというデザインの本質は変わりません。

従って、『情報の整理』や、『情報の整頓』、『ヴィジュアルの規則性(反復)』、『色使い(魔法使い的な”使い”)』といった基本原則はどんな媒体にも通用します。

違いを理解し、各媒体に対して目を肥やしていけば、紙とWeb、両方をデザインすることはそこまで難しくはないと思います。

個人的にはWebデザイナーも紙領域を(その逆も然り)できた方が、双方様々な部分で応用が利くと思いますし、デザイナーという立場でチームに貢献できる度合いが増す=モテると思っているので、デザイナーは臆することなく双方の作業をどんどん経験するべきだと思います。

余談ですが、この『入会のしおり』は、私がコーチ・ユナイテッド株式会社にフルタイムで入社してから2ヶ月経った後にスタートした案件でした。
入社以来、新規自社メディアのデザイン、スマホサイトリニューアルといったヘビー案件を経て、今回の本気紙案件をこの短い期間で行えたことは、デザイナーとしてとても恵まれた環境だなと感じました。

冒頭でお話しした通り、デザイナーは私1人だけです。
弊社は、Webも紙もデザインしなくてならないことがまだまだ沢山あります。今後控えているデザイン作業案件は、スタートアップのインハウスらしい、バリエーション豊かで、やり甲斐のあるものばかりです。
Webも紙も問わず、デザインすることに夢中になれる方、是非、一緒にデザインの力とマインドで、課題解決・サービス成長の起爆剤になりましょう！

この記事で、少しでも弊社に興味を持っていただけたのであれば、お気軽にご連絡ください。お待ちしております！

「サイタ」の次となる新規サービスを、1年で10個育てたいデザイナー募集！

スマホ経由CV数2.2倍に

数ヶ月かけて、進めてきた「サイタ(cyta.jp)」のリニューアル結果が出てきたので、今回はその設計思想とプロセスについてお話できればと思います。

結果から言えば、大成功でした。もはやサイタも、今はスマホのアクセスがほとんどですが、そのスマホ経由のCVRが2.2倍までupしました。そこで今回は、そんな「サイタ」での事例を、CtoCサービスを中心とした中規模~大規模サービス事業者にとってもいくつか参考になる部分があるのではと思い、記事を書いてみることにしました。

CtoCサービスのCVRを上げるのはなかなか難しい

「サイタ」でも、CVRはずっと抱えていた課題でした。しかも、 SEOによる集客が中心である「サイタ」のようなサービスでは、検索エンジンネガティブなことが起きる可能性のある、リニューアル案件は、なかなかやろうと思ってもリスクが高く動きにくかったので、まずは1ジャンル使って検証してみることにしました。

小さく試して、大きく展開。

リリースまで1週間、結果の検証3ヶ月というスケジュールで、「サイタ」のドラムジャンルのとあるテンプレを総入れ替えしました。

検証する部分は、

・CVRがどのくらい上がったのか

・入会率に影響はあったか(急激に落ちていないか)

・LTVの初速は落ちていないか

・SEOは落ちていないか

の4つのポイントでした。これを全て計測するには3ヶ月かかってしまいます。

ページの内容は、特定の駅で学びたいコーチを選ぶのみ、というコミュニケーションから、サイタの説明をバリバリやって、「選びたい人は先生選んで、わからない人はお問い合わせしてください。」というコミュニケーションに変更したものでした。

すると、このテンプレのランディング経由のCVRが2.8倍まで上昇したのです。また、入会率やLTV、SEOにも影響はなく、「これは、イケる！」と確信したのです。

「先生選び」という選択肢を減らすUX設計

もともと、「サイタ」では、「学びたいジャンルは決まっていても、どの先生に何を習ったら良いかはわからない」という問い合わせが多く、電話でコンバージョンすることがよくありました。「サイタ」では、2014年からコールセンターを本格稼働させて、サービスを伸ばしていきました。

これは、CtoCサービスの多くが直面している課題だと思います。ただし、「ユーザーが本当に求めているのは、こういったプラットフォームか？」ということを考えたときに、無理に先生を選ばるという選択は、「No.」でした。この思想を、今回の「サイタ」のスマホサイトリニューアルの目玉にしました。

料金体系や、サービスの仕組みをまず明確に伝える

ユーザーによりサービスを深く理解してもらわなければ、CVまでたどり着きません。サイタの流入元はOrganic検索が多く、「ドラム教室」や「ドラム　レッスン」といったようなクエリです。彼らが検索するにあたってどういった情報を求めているのか？ということを徹底的に考え、「どのようなレッスンを・どのくらいの料金で・どこで」出来るのかということが重要だと考えました。

ファーストビューには、その要素を盛り込みました。これまでは、「ドラム教室」や「イラストレータ　講座」などと検索すると、まずは地域を選んでください、先生を選んでくださいというコミュニケーションで作り込んでいたのですが、ユーザーが一番欲しがっているのは、「どのようなレッスンを・どのくらいの料金で・どこで」というイメージだと考え、このように画面を設計しました。

コーチを、より魅力的に伝える

また、リニューアルにあわせて、コーチの個別ページ(スクールページ)をリニューアルしました。よりコーチが魅力的にうつるように、そして写真も顔写真だけではなく、作品の写真やレッスンイメージの写真など、多くのアプローチで「レッスン感」を出せるように意識しました。

メリハリのある導線設計が一番大変だった。

このようにして、CVRを2.2倍まで上昇させることに成功しました。しかし、これらの画面の要素が重要であることはそんなに難しく考えなくても分かっていたのですが、これをサイト全体の構造を崩さずに、そしてOrganic流入を減らさずに行うというのは、とても大変でした。

「サイタ」では、各ランディングページをそれぞれ流入比率やコンバージョン率を細かく分析し、導線設計を丁寧に行いました。次回は、どうやってSEO評価を落とさずに導線設計をしたのか、そしてウェブサービスのバリューを崩さないことを意識したのか。というお話しをできればと思います。

この記事に興味をもっていただけた方は、likeとかシェアとかしていただけると、記事を書くモチベーションが上がります。笑

スクール事務局サービスである「サイタ」において、どのようにしてエンジニア以外のスタッフを「サービス開発者」に巻き込んでいったか、という話をします。

なお、ここでいう「サービス開発者」とは、必ずしもプログラミングできる開発者のことを指してはいません。日々生まれ続ける事業データを見つめ、新たな仮説と切り口とたて、業務改善やシステム仕様変更提案や開発プロジェクト起案、遂行管理を担当する、必要とあらば自らできる範囲で手を動かすことのできるメンバのことを言います。

現在、サイタでは、「エンジニア」でないポジション(マーケティングやユーザサポートなど)で join した約15名のうち、半数以上が SQL を記述/運用し、サービス開発や業務改善に役立てています。また、簡単な修正であれば Pull Request まで送ってくるスタッフが4名居ます。

先日、「ユーザ側の『ITイノベーター』こそ、急いで育成するべきだ」という記事が話題になっていました。この記事では、「ユーザ側におけるITの教育が不足している」ことを指摘していますが、私たちの取り組みは、ユーザ(業務部門)側でのIT教育(「教育」というとおこがましいのですが)を定着させる活動だったとも言えます。

2年ほどの取り組みを振り返ってお話してみますので、ひとつの事例として、参考になるところがあれば幸いです。

チームの名前を変えた

私がサイタを運営しているコーチ・ユナイテッド社に参加したとき、エンジニアチームは “Dev” チームと呼ばれていました。まずは、これを “Tech” チームと改めました。

その経緯は、サイタの現場に参加してみて、「Development = 開発という営みは、エンジニアだけの特権ではない」と強く感じるようになったためです。

事実、サイタの事業システムは、(現在のところ)オンライン動画教材のようなレッスン提供そのものの媒体ではなく、オフラインでのレッスン体験を提供するための(コーチやスクール事務局スタッフにとっての)業務支援システムです。「より受講生/コーチに近い、日頃コミュニケーションをとっているスタッフこそサービス開発に参加して欲しい」という思いを込め、チームの改称をおこない、その経緯を社内で共有しました。その後も、全社会の機会などで折を見て同じことを伝えています。

実際のところ、この改称がすぐに社内スタッフの行動の変化に伝わったか、というと、短期的には何の変化もなかったように思います。しかしながら、後に紹介するいくつかの施策とその反応に対し、良い影響があったのではないかな、と考えています。

ちなみに、私は、サイタに来る前に開発会社を営んでいたのですが、そのときのとある取引先企業様(社員数100名以上)において、そこで働いているプランナー, エンジニア, デザイナーたちが、全員同じ「業務推進部」に所属していたことに衝撃を受けた記憶があります。思えばこれも「全員が開発に参加する」という目的に即した命名だったのかもしれません。

全社員向けに技術勉強会をやった

よくある「社内勉強会」を、全社員を対象におこないました。一例として、これまでに実施してきた社内勉強会は、以下のような内容です。

• サイタを支えるデータ群(どのような事業データがあるのか)
• SQL勉強会(事業を支えるデータ群に、どうアクセスするか)
• サイタを支えるサーバ群(リリースとかdeployって何やってんの)
• サイタのメール配信の仕組み(ちゃんと届けるために、何やってるか)
• ソフトウェアテスト勉強会(「新機能リリース前にみんなでやったテスト」の裏側)

同じ内容の勉強会を複数回開催したこともありましたが、SQL勉強会はとくに好評で、回を重ねるうちに、テーブル結合、集約関数やサブクエリの利用など、多少踏み込んだ内容まで進んでいきました。発表資料を共有しておいたところ、後から入社したスタッフがそれを見て自習したこともあったようです。「体験レッスンの申込から初回架電までの時間と、レッスン実施、入会には相関があるはず。このテーブルのコレとコレをつなげて取得したい。ここまでは書けたんだが、なんか数字が肌感と合わない。オカシイ、何が違うんだ」といったような具体的な質問がきたときには、嬉しかったですね。

また、いろいろ相談されてつくった分析用のクエリを、社内共有のドキュメントに貼り付けておくことで、他のスタッフもそれを参考に、さらに深い分析をする姿も見られました。もちろん、この分析や仮説検証視点でのクエリの蓄積は、 Tech チームにとっても、大いに学ぶところがありました。

「何もナマ SQL をみんなで覚えなくても、Tableau などの BI ツールを入れれば良いのでは」という見方もあるでしょうが、そこは何にコストを払い、何を得るか、タイミングとケースバイケースの判断でしょう。

そもそも社内に「データを見て、数値で語る」という文化が無いことには、phpmyadmin だろうと、Tableau だろうと良い効果は得られないと思います。社内向けの技術勉強会は「どういうデータがあるのか」「何に、どうアプローチするのか」という点において、エンジニアもそうでないスタッフも同じ空間、同じ土台で問題意識と前提知識を共有することができました。結果として、サービスをよりよくしていくための武器を全スタッフにもってもらうという、良い文化づくりのきっかけができたのではないか、と考えています。

開発プロジェクト情報をオープンにした

過去のサイタでは、ユーザサポートスタッフは、機能改善提案を上げるまでで一段落、あとはただ技術チームの対応を待つ、でもエンジニアが実際に開発に着手しているかどうか/どういう優先度判断をしているのかわからない、という状態がたびたび発生しておりました。これは、ユーザサポートスタッフにとってフラストレーションになっていたことは否定できず、健全なチームとは言い難い状況だったと思います。

そこで、当時使用していた ITS(Issue Tracking System) であり、開発情報ドキュメント管理 wiki でもあった Redmine へのアクセス権を、全スタッフに対して付与しました。その結果、Issue の仕掛りや調査状況がオープンとなり、社内コミュニケーションツールとして使っていた Yammer で、徐々に Redmine 上の URL がやりとりされるようになっていきました。これにより、「ココがエンジニアリングコストがかかるところであれば、Issue を分けて、ココだけ先にリリースしても良いんじゃないか」といった、サービス改善のための、より建設的なコミュニケーションもできるようになりました。

業務部門とシステム部門は、とかく壁を作ってしまいがちです。「組織を分け、役割をキレイに分担した状態」は、私たちのような小さなチームでは、尚更多くのコミュニケーションロスを生み出してしまいます。お互いが「聞かないと教えてくれない」「聞いてくれないと、教えようがない」という雰囲気になってしまうくらいであれば、オープンにできることはオープンにして、建設的なコミュニケーションができる状態をつくっておくのが好ましいでしょう。もちろん、「見える場所にあるんだから、勝手に見ろ」ではなく、「見える場所にあるものを、みんなで見て活用する」ように丁寧に運用することも大切です。

Redmine はその後、GitHub に移行しましたが、エンジニア以外のスタッフが Issue をつくったり、オリジナルの LGTM 画像をつくって送ってくるなど、変わらずにオープンで健全な運用ができていると思います。

技術に限らない勉強会をやった

社内勉強会は、「学習する組織」のためにも、定期的に開催すべきですが、技術勉強会がネタ切れ＆発表の準備も大変になってきたので、エンジニア以外のスタッフも自分の業務改善や趣味を活かしたフリートークを発表できる機会に、徐々に移行しました。

幸いにも、当社には、DJ, ドイツ語コーチ, グルメ, 薄い本作家, 現役ミュージシャン, サッカーが好きな人など幅広い発表ネタを仕込めるスタッフが在籍しているため、技術 or 社内業務改善ネタ1件、趣味ネタ1-2件の社内勉強会をコンスタントに開催していけるようになりました。

技術勉強会単体のときとは雰囲気を変え、冒頭から飲食あり(もちろんアルコールも!)でカジュアルに楽しめるような空間になるように工夫しました。フリートークとはいえ、業務ネタのセッションを交えることで、自ずと業務に関係する話題も絡まるものです。こういった時間を共有することで、普段考えていることをオープンに話し合う雰囲気づくりの一助になったのではないかと考えています。

行動指針を打ち出した

経営陣で話し合い、以下のような行動指針を打ち出しました。

• 会議10回より、リリース1回
• 「やる」と「やり切る」は大違い
• 相手目線で考えよう

このステートメントには様々な視点が入っていますが、とくに前者2つについては、私たちの「社内全員サービス開発者体制」の価値観をうまく表現してくれていると思います。

ちなみに、この行動指針は「もっと覚えやすく」「日常業務で会話に出せるような」という思いで改訂を経た第2版となっております。ここでは、これ以上は語りませんが、私たちのコーポレートサイトでは、もう少し追加の説明が読めますので、よろしければご覧になってみてください。

受け入れテストフェーズを仕組み化した

過去のサイタでは、新機能のリリースにあたっての、リリース前テストは Dev チームに委ねられており、エンジニアチーム内で十分な動作確認をおこなってからリリースするという流れになっていました。この流れでは、リリースまでの時間は短縮できていたのですが、リリースされた後に問い合わせを受けて初めて新機能に触れるサポートスタッフも多くなってしまい、結果としてサポート品質の低下に繋がっておりました。

そこで、スタッフ向けのリリース前機能の動作確認環境を整備し、大きめの機能リリースでは、リリースに先立ち、ユーザサポートチームに網羅的なシステムテストを計画/設計/実行してもらうプロセスを作りこみました。

システムテストを設計してもらうにあたって、テストの目的や、テスト計画の立て方については何度か個別にサポートしましたが、今では、プロジェクトによっては、1,000を超えるテストケースの実行計画を立てて実行してもらえるまでになりました。実行計画のドキュメントひとつ見ても、外部のテスト専門会社に発注するのと遜色ないレベルでの計画/実行ノウハウが定着してきているように感じています。

ユーザサポートチームで受け入れテスト相当のテストを計画し実行することは、リリース前の新機能の理解や、仕様の検討漏れの発見にもつながります。この取り組みの結果(リリース後のバグの発生件数や問い合わせ内容を見ている限りでは、)リリース品質とユーザサポート品質の双方に良い結果をもたらしているようです。

パイロットとなるシチズンデベロッパーを育成した

「シチズンデベロッパー」という言葉が一般的なものなのか自信が無いのですが、ここでは、普段はシステム利用部門(当社の場合、ユーザサポート)の業務にあたりながらも、必要に応じてアプリケーション開発にあたることができるスタッフのことを指すものとします。

ここまで紹介してきたような様々な取り組みを実施していくうちに、SQL を覚えたり、GitHub の Issue にコメントしてきたり、文言変更程度であればソースを検索して「ここをこう改修するだけなんじゃないか」と手を動かしてみたりするスタッフも現れてきました。

そこで、そのスタッフに個別で SQL づくりの補習サポートをしたり、GitHub で Pull Request を送るまでのフローを覚えてもらったり、その手順を可能な範囲でマニュアル化してもらったりする、という取り組みを始めました。同時に、開発環境セットアップのハードルをできるだけ下げられるようなツールとドキュメントの整備を進めました。

今も、私の席の後ろでは、ユーザサポートスタッフのひとりが、Atlas で build された VM を起動し、「ダッシュボードに表示するKPIの集計条件を変更する」「レッスン予約手続きをする際の、ユーザへの表記文言を微調整する」などの Issue の解決に当たっています。サービス成長という目的意識の高さが、学習ハードルを跳ね除けているのを感じます。

まだ道半ばではありますが、先導役となるシチズンデベロッパーが次々と成果をあげていくことを目のあたりにすることで、サポートスタッフのなかでも「これくらいの修正であれば、自分でもなんとかできるのではないか」という流れになることを期待しています。

「サイタ エンジニアブログ」を「サイタ 開発者ブログ」に変えた

社内の取り組みを積極的に社外に公開していくということは、採用広報の目的が第一義と捉えられがちですが、社内のスタッフにとっても「うちの会社は、こういう会社なんだな」という認識をもってもらう上で大事な取り組みと考えています。

「エンジニアブログ」をエンジニアだけのメディアとはせず、サイタをつくっているスタッフ全員の発信の場と捉え、先日「開発者ブログ」と改称し、Webマーケティング担当やデザイナーからの記事も公開していくようにしました。

対外的に語れる様々な表現をスタッフ全員がもつことで、「全員がサービス開発者であり、自分もサービス開発をしているひとりなんだ」という当事者意識にもつながるのではないかと考えています。

まとめ

以上、サイタの「社内全員サービス開発者体制」構築プロセスの一部を紹介させていただきました。

ひとつひとつの取り組みには、そもそもの人数規模や事業フェーズを含め、うまく機能するための前提条件や文化・文脈があったと思いますが、様々な取り組みを相互に補完しあわせ、時間をかけて取り組んできた結果、今のような体制ができてきた、と考えています。

何よりも、全体としてこのような取り組みがうまく機能してくれているのは、サービスの向かう先のビジョンや全社目標を、メンバー全体で共有できていることによると思います。

これからこういった体制づくり文化づくりに取り組まれる方へのオススメとして「Fearless Change アジャイルに効くアイデアを組織に広めるための48のパターン」という本があります。チーム内で新しい取り組みを成立させていくための様々なパターンが網羅的に挙げられていますので、ぜひご参考になさってみてください。

ちなみに、業務部門での「ITイノベーター/シチズンデベロッパー」が、小さな修正や改善を推進してくれることで、エンジニアスタッフが、よりエンジニアリングの深いところや、研究開発にコミットする時間を確保することができたことも大きな成果といえます。このような変化を経て、私自身も改めて「今後、技術チームをどうしていきたいか」「会社の技術戦略はどうあるべきか」を考えることができました。

今回は、社内の全員サービス開発者体制構築に向けての取り組みをメインにお話させていただきましたが、また機会があれば「技術チームとエンジニアひとりひとりに、どう向き合ってきたか」をお話できればと思います。

この記事が、どなたかのヒントになることがあれば幸いです。

それでは、また。

@tmtysk

新しい「学びのカタチ」を世の中に広めていきたいエンジニアwanted！

はじめに

こんにちは、「サイタ エンジニアブログ」は、今回から「サイタ 開発者ブログ」として、エンジニア以外からの記事も掲載していくこととしました。「サイタ」がどのようなメンバーで、どのような文化で開発/運営されているかを少しでも知っていただければうれしいです。

さて、今回はサイタの事業開発チームの中で社内勉強資料として使われれているものの一部を投稿させていただきます。

この記事では、「cyta.jp」時代には、もう手をつけられなくなっていた、カスタムキャンペーン設定を、サイタカメラ教室(ca.cyta.jp)でまるっと整理することができたので、それについてお話しさせていただきます。

Google Analyticsについての説明はここでやる必要はないと思いますが、このカスタムキャンペーン設定は本当に大変なんです。事業が始まって1年以上経過していれば、もう使いこなすことは不可能と言って良いと思います。

事業拡大期には、「打ち手」の正しい判断と効率化/定型化が必要。

事業「立ち上げ」期の仕事の進め方：「とにかく手を動かせ」

事業立ち上げ期は、analyticsを含めて、何も準備する必要はありません。とにかく行動あるのみ。目の前のサービスを作ったり、ユーザーを作ることに集中するのがベストだと思います。あまりにも実績や結果がないので、その結果を作らなければ今後何も動くことができません。

事業「拡大」期の仕事の進め方：「非効率な業務は全部捨てる」

ただし、事業拡大期には、上記のような仕事の進め方をすればするほど、視野が狭くなり、サービスが思うように成長しなかったり、仕事を分業化できず、小忙しくなってしまいます。

これまでやってきた施策をレビューし、効率性をどんどん高くし、仕事を定型化し、メンバーや事業規模を拡大し続けるのが大事なのではないかと思います。

Google Analyticsのキャンペーン設定をきっちりとできれば、サービスは必ず伸びる。

そこで今回は、Google Analyticsのキャンペーン設定という部分について説明できればと思います。

カスタムキャンペーンで実現できること

上図は、実際に設定完了したAnalyticsのキャンペーン管理画面です。

これまでは、Adwordsであれば、Adwordsの管理画面。YahooであればYahooの管理画面。各メディアは各メディアの数値を集計して管理をしなければならなかったものが、一元管理できるようになりました。

各媒体を木、各個別施策を実として考えると、これまではそれぞれの木を見ながら、身を間引きして、悪いものは外し、良いものは残して伸ばす。ということをやったり、木自体を伐採して他の木に栄養を与える。というようなことをやっていました。

それが、「カスタムキャンペーン機能」を活用することで、リアルタイムに一元管理されるので、マクロに施策を捉えることができます。大きな木の幹を一つにできるようなイメージです。

例えば、

• 「広告自体、あんまりうまくいってないんじゃないの？」
• 「外部メディアからのアクセス、最近増えてるから、もっと増やしたほうが良いんじゃない？」
• 「いろんな広告で、リマーケティングやってるけど、全体的に調子が良くないから、リマーケティングだけ一旦止めてみない？」

といったような議論ができるようになります。

Analyticsならではの、「リアルタイム性」と、「各種統計情報」のストック。

AdwordsやYahoo listingは反映に1,2時間かかる場合が良くあります。各マーケティングツールなども、時間がかかるものが良くあります。しかし、Analyticsは、1秒単位でユーザーの情報を記録しているため、新しい打ち手をやった時に、「5時間後に判断する」というようなことができるようになります。

これまでは、1週間や2週間かけていたような施策のレビューを、朝やって、夜レビューというように1日の中でできるようになることで、事業開発のスピードがガンガン上がります。

あた、アナリティクスは、すべてのユーザーの行動履歴を同じようにまとめているので、各施策を比較するのにはとても便利です。滞在時間や直帰率など、ユーザーの傾向を見ながら、新しいアイデアを膨らます材料にすることもできます。

キャンペーン管理できるようになるために：「パラメータ」の機能と考え方。

カスタムキャンペーンに対応させるのは、とても簡単

URLの末尾に、Analyticsが指定するルール通りにパラメータを設定するだけで、管理可能になります。URLがめちゃめちゃ長くなりますが、がんばって耐えましょう。短縮URLや他のリダイレクトされるような分析ツールなどにも対応しているので、とても便利です。

パラメータのルール作りがとても重要

細かい仕組みなどについては、こちらの 「Google Analyticsのカスタムキャンペーンについて」を見ながら勉強してください。

ここでは、簡単に説明しますが、

• Source
• Medium
• Campaign

という3つの要素があります。これは自由にユーザーが割り当てることができます。広告管理での、「アカウント」「キャンペーン」「広告グループ」というような構造をイメージしていただけるとわかりやすいと思います。

ここで重要なのは、

• 「パラメータ」を変更すると、データは引き継がれない
• すべての施策ごとに、パラメータを設定しなければならない。

ということです。事業拡大期にパラメータ管理を行う上で、以上の2点が重要になります。

バナーの色合い、種類、キーワードの部分一致完全一致設定、タイトルの変更など、施策数は1年で軽く数百、数千の単位になると思います。これにすべてパラメータを割り当てなければなりません。とてもじゃないけれど、サービス開始から数年経ったサービスで設定するのは不可能です。立ち上げ期はそんなことをやっている暇がないので、この、拡大期の一番初めにやるのが大事なのです。

僕の場合、上記のようなルールで管理しています。

特に重要なのは、utm_campaignの部分。管理画面を開くと、一番最初に現れる部分です。(下の図です)

ここの名付けルールを間違えると、後で新しい施策をやった時に、MECEにならずやりなおし、とならないように注意します。

utm_campaignのルール付け

サイタカメラ事業では、上記のように名付けるようにしています。

• 媒体名(サービス名)ごとでの管理
• キーワード広告やバナー広告、メールなどの横断的な媒体種類別の管理
• インタレストマッチや、リマーケティングなど、施策分類別での管理

といったようなことができるようになります。施策番号やクリエイティブ番号にもルールをつけていけば、将来的には、コミュニケーションパターンや入稿するキーワードや配信ターゲット別などにも管理できるようになります。

別運用シートでかならず管理する。

まとめ

新しい施策にチャレンジして、成功するには、たくさんのチャレンジの種を育てないといけません。その育てる種の一つが、GoogleAnalyticsのカスタムキャンペーン管理だと思います。また、種であると同時に、後任担当者への情報共有ツールにもなります。新規事業を成長させる段階では、人を増やす場面も多いと思います。状況に応じた施策の行い方をおこなうことで、事業スピードも数倍高まるのではないかなと思います。

先日、サイタの MTA を全面的に SendGrid に移行しました。移行後数ヶ月経ち、今では安定運用のフェーズに入っております。実は移行直後はなにかと色々あったのですが、その辺りのゴタゴタも含めて、移行の顛末をお話したいと思います。

なぜSendGridなのか

これは、約1年前の検討記事をご覧いただいたほうが良いのですが、当時いろいろ比較した結果、私たちの業務上必要な要件を(APIレベルで)十分に満たす、最後の選択肢だったからです(現時点でも、ざっと調べましたが、他の有力な選択肢は挙がってきませんでした)。加えまして、前記事をポストした後、日本での代理店である構造計画研究所の担当者さんよりコンタクトをいただいており、たびたび facebook 経由でメッセージをする機会もあったものですから、漠然とサポートに対する安心感を抱いておりました。

なぜこのタイミングで移行したのか

結論から言えば、けっきょく運用が大変になってきた、ということになります。

背景としては、おかげさまで、サイタのレッスン実施量が前年に比べて倍以上に増大してきているということが大きく影響しています。当社のメール配信は、主としてオフラインでのレッスン実施という行動を支えるための、リマインダーや意思確認が目的ですので、レッスン量が倍になったことで、メールの配信量は数倍以上に増加してきました。各種施策での一斉メール配信についても定常化してきたため、いよいよシステム運用が大変になってきました。

具体的には、とくに一斉メールとレッスン実施数が重なる曜日や時間帯について、一部ドメインから deferred 応答で嫌われるということがたびたび発生しておりました。運用担当者としても、deferred 発生時の backoff time をどう調整するか、そもそも送れなかったメールがレッスン実施のために重要なものなのであれば、調査復旧以前に電話などメール以外の連絡方法でサポートしなければならないのではないか、などの調査/サポート/判断をたびたび迫られることになってきました。こういった状況が「運用の人的コストを本当に下げられるのであれば、外部運用に移行しよう」という決断を後押ししてくれました。

さらに言うなら、サイタでは昨年後半より新規事業立ち上げの仕込みをおこなっており、ちょうどこの事業の立ち上がりに合わせて、チームの編成をいろいろ見なおしているところでした。私自身「やるなら、今だな」と納得できるタイミングだったと言えます。

どう進めたのか

かねてより facebook メッセージでやりとりしていた担当者さんに、「相談させてください」とコンタクトしつつ、昨年頭より寝かせてあった米国アカウントでの、仕様の読み進めと検証環境の開発をおこないました。対面での相談の機会に備えて、ある程度確認するポイントを絞っておいたほうが良いと考えたからです。進めていく上で、2点ほどハマったので、ざっとまとめます。

日本でやるならおとなしく日本アカウント作ったほうがよい

構造計画研究所さんのサイトからサインアップすると、数日でアカウントが使えるようになり、ダッシュボードにもアクセスできるようになります。このダッシュボードにある日本語のドキュメントが、とてもわかりやすく構成してある(個人の感想です)ため、本家のマニュアル見ながら唸るよりも、とっととコレをみればよかった、と感じました。構造計画研究所さんでアカウントを作っておけば、サポートのときも同じダッシュボードが共有できるようで、そういった面でも日本アカウントにしておくのが安心です。

Bounce をメールで受け取ることはできない

私たちの元々の運用では、個別のメールの Bounce を Return-Path に設定したアドレスへのメールで受け取り、これをパースして Bounce 処理をおこなっていました。SMTP API を使えば良さそう、ということはわかっていたのですが、検証していても Bounce メールは戻ってきてくれないですし、実際に送信されたメールを見るに、SendGrid 側で Return-Path を追加しているようだったので、「ウチの要件の場合、単に MTA を切り替えるだけではダメだな」と感じていました。

SendGrid の仕様を読んでいくと、Event Notification という機能があり、これを設定しておくことで配送成功/失敗の各種イベントが受け取れることがわかりました。Event Notification は HTTP でのコールバックで受け取ることができ、このコールバックで SMTP API で仕込んでおいたパラメタを受け取ることもできそうだったので、この機能が使えるのではないか、と考えました。プロトタイプレベルの実装でも問題なく動いていたので、SendGrid の方との打ち合わせでこの設計方針について意見交換し、諸々不安な点も解消できたので、この方向で行こう、という判断ができました。

ちなみに、担当の方との打ち合わせで使ったのは、以下のようなドキュメントでした。

けっきょく、切り替えに当たり、若干の追加開発を伴うことになりましたが、個人的に API とお話するのは嫌いではないので、楽しみながら開発と切り替えの準備を進めました。

どう切り替えたのか

もともとオンプレのメール配信環境において、postfix の transport(5) によるリレー配送をおこなう構成にしてあったので、切り替えのハードルは比較的低かったです。まずは一部のドメイン宛のみ SendGrid 配送に切り替えて様子見し、新旧の MTA を混在させた状態で数日様子見をしました。問題なく運用できそうだったので、最終的にリレー先の MTA を一気に SendGrid へ振り向けることで切り替えを完了しました。

それでもハマった

切り替え後は、ダッシュボードの Activity 機能で処理状況を確認していました。数時間は問題なくメールが流れていたようで、胸をなでおろしていたところ、一部のドメイン宛のメールが軒並み deferred 応答になっていることに気がつきました。前回、Mailgun に切り替えたときと同じ状況です。恐らく最初から、このドメイン相手では deferred になっていたのでしょうが、相手方からのメッセージが broken pipe と表示されており、どうも情報が少ない。状況をみるに、宛先ユーザー特有ではなく、宛先となった当該ドメインに対するすべてのメッセージでこの応答になっておりました。

実際に送られているメールのSMTPヘッダの構成確認や、アプリケーションを介さない手元からの送信試験などで切り分けを進めましたが、SendGrid 経由のときだけ相手方に嫌われているような印象だったため、SendGrid サポートに連絡をとりました。幸いにも、導入前に相談に乗っていただいていた方が、直接切り分け作業にご協力いただけたので、数時間ほどで宛先方の要因: SendGridアカウントに割り当てられたIPアドレスを拒否されているのではないか、という話に至りました。さらに、異なる帯域でのIPアドレスを追加し、ラウンドロビンで配送しわけることで、当該ドメインへのメールが通り始めるのであれば切り分けできる、というご提案をいただき、即時IPの追加を依頼しました。

さらに数時間後、この追加IPからの配送ではメールが正しく送られることを確認できました。これで完了か、と思っていた矢先、今度は別の宛先ドメインで追加したIPを拒否されるという地雷を踏んでしまいましたが.. そういった切り分けや別IPの割り当てなどのご対応を随時メッセージでやりとりできたおかげで、対応は深夜にまで及んだものの、完全切り替えから24時間以内にひと通りの問題が解消、というところまで行き着くことができました。サポートの方は、切り替え初日から異なる帯域のIPの即時割り当てや切り分けの調整で、米国側ともやりとりしていただけたようで、このスピード解決は本当にありがたかったです。

その後

切り替え後3ヶ月ほど経ちますが、非常に順調に稼働しております。なにより、たびたび(あまり予期できないタイミングで)発生する deferred と個別に付き合わずとも、かなりいい感じに早めに再送してくれているところは、本当に助かっています。切り替え当初は Activity を見ながら「おお、こんなに早く再送かけちゃうんだ」と、そのノウハウに感動しました。連日大量のメールを捌いているのは伊達じゃない。

また、サポートの方とは、何かあるたびに、気軽にコンタクトできますし、利用状況や Reputation も気にかけていただけているので、なんとも言えない安心感があります。ちなみに、自前のオンプレでは 96% 前後だった Reputation も 99% 以上を維持できています。

まとめ

スタートアップのような小さなチームでやっていると、インフラエンジニアを専任で確保するのは難しいですし、とはいえインフラ系でハマると調査と解決に孤独な戦いを強いられることになります。そういう状況が頻発してしまうようなフェーズにおいて、インフラ業務の技術的な部分をがっつり相談できる SaaS のユーザサポートはとてもありがたいですし、SendGrid のサポート体制には本当に助けられました。

サービス開発にあたって、運用の部分でラクをできる SaaS は数多くありますが、エンドユーザ向け機能の商用環境に投入するとなると、なかなかハードルは高いものです。SaaS の提供元が海外企業だったりすると、なおさら情報が少なく万一の際にどこまで自力で対応できるのか、本当にコストメリットが出るのか、などの理由で、どうしても二の足を踏んでしまいます。そもそも、移行による価値を予想/確信しにくいからかもしれません。

少ない人数でサービス運営をしているからこそ、サポートの存在はありがたいです。自分が本当に費やすべきエンジニアリングに対する時間を確保するためにも、SaaS を選ぶときには、サポート体制にしっかり目を向けることが重要、そして、この価値観/視点は(機能検証と利用コストのみを気にしていた)去年の自分にはなかったな、と思う次第です。

こういったメールサーバ運用の話はあまりお見かけしないのですが、どなたかの参考になれば幸いです。それでは、また。

補足

当社のメール配信周りの運用について、先日、AWS Startup Tech 夏のLT大会 2015 at dots.でお話させていただきましたので、こちらの資料もよろしければどうぞ。

オフライン行動を支えるメール配送管理 at サイタ - SlideShare

@tmtysk

このたび、コワーキングスペース茅場町 Co-Edo（コエド）様の会場をお借りして、 “スタートアップチームコミュニケーション術報告会” と題した勉強会を開催しますので、この場を借りて告知させていただきます。

サービスの開発現場では、エンジニアやデザイナ、事業プロデューサなどの役割を超えた、オープンでフラットなコミュニケーション文化が重要ですが(と筆者は考えていますが)、イベントという形式で、スタートアップチームに特化したチーム内コミュニケーションの実態が共有される場はあまり無かったように思います。

今回の報告会では、「あのアイコン」のブログでおなじみのKonifar氏ほか、事業フェーズやチーム規模の異なるスタートアップのエンジニアを登壇者に迎え、各社の社内コミュニケーションフローや開発プロセス、トライアンドエラーの実態に迫ってみたいと考えています。

参加申込は connpass でおこなえます。多くの方のご参加をお待ちしております。

@tmtysk

去る 2015/6/5 に、当社オフィスにて「神南エンジニアリング勉強会Vol.1」を開催しましたので、そのレポートをします。

「神南エンジニアリング」とは、渋谷区神南地区にお勤めまたは出没しているWebエンジニアのためのコミュニティで、2015年5月に活動を開始しました。 主な活動内容は以下のようなものです。

• Slackでおしゃべり
• ランチに行く
• 勉強会をやる
• 飲みに行く

当社は少数のエンジニアチームでやっておりますので、かねてから情報交換を求めて、近隣の会社に突然声をかけては、ランチを口実に話をする、という行為に及んでおりました。そういったことを重ねているうちに「意外と神南地区に同じくらいの規模のチームが多いな」ということに気づきはじめ、「じゃあ、全員同じコミュニティで交流できるようにすれば、もっと有意義だし、面白いし、ひとりランチ難民になるリスクも下がるじゃないか」ということで、このようなコミュニティ活動を開始した次第です。

さて、今回の勉強会は、初回だったのでクローズドに企画(というわりに、connpass でしれっとイベントページを作っていましたが)していたのですが、嬉しいゲストもあり、総勢11名参加での開催となりました。

勉強会のテーマは「各社のサービス環境共有会」ということで、参加各社から15分程度の発表+質疑応答というメニューで進行。各社の開発プロセスや利用ツール、改善へのアプローチや試行錯誤など、多少踏み込んだところまでが垣間見える、非常に有意義な会でした。

以下、勉強会の様子を簡単に紹介します。

STORES.jp 運営の Bracket 社さんからは新卒エンジニアMさんの、初発表でした。冒頭のメニューから、「発表内容がちゃんとしている..!」と会場がざわつき、残りの発表者2名が急いでスライドを修正追加するという事態に。

スライドは、こちらからどうぞ。

2番手、コーチ・ユナイテッド社(当社)からは私が発表しました。開発プロセスや稼働環境の話に加えて、先のブログでも紹介した Twilio の話などをご紹介しました。

スライドは、公開版として少し削ってありますが、よろしければこちらからどうぞ。

最後にLiB社からYさんが発表。社内での Slack コミュニケーションの様子や、おひとりで開発を支えてこられた時代から編み出された改善の手法など、非常に参考になるお話が聞けました。

スライドは、こちらからどうぞ。

勉強会後の懇親会でも、発表内容に関する質問や意見が交わされており、とても楽しい時間となりました。ご参加の皆様、ありがとうございました。

さて、「神南エンジニアリング」は、ローカルな活動をしておりますが、こういった勉強会についてはオープン開催ができる時期がくるかもしれません。そのときには、またこちらのブログなどで紹介させていただきたいと思います。

@tmtysk

CtoC サービスで個人間の待ち合わせ用電話システムを実現するのに、Twilio を使ってみたらとても面白くて簡単だった、という話を書きます。(Twilioさんから何かもらってるわけではないですよ。)

当社の習い事サービスは、オンラインでの申し込みから始まりますが、実際のレッスンはオフラインでおこなわれます。つまり、会ったことがない個人と個人に、時間通りに予定の場所で出会ってもらうというのをコーディネートするわけですが、これは、なかなか簡単にはいきません。

待ち合わせといえば携帯電話が便利ですが、携帯をつかった待ち合わせは、お互いの電話番号がわかっていることが前提。これからレッスンを受ける/教える相手とはいえ、見知らぬ相手と、携帯電話番号を交換してしまうことに抵抗を感じる方は少なくないと思います。

そこで、Twilio です。

Twilio は、電話や SMS を Web サービスに統合できる API サービスなのですが、上記のような当社の課題にうまくフィットしてくれました。

具体的には、以下の図のように、お互いの電話番号を知らなくても、通話ができるシステムを構築しました。(開発時のイメージにつき、裏紙手書きはご容赦ください。)

Twilio は、サインアップして、050 番号を取得して、着信時のリクエスト先(上図の 2 の接続先 URL)を設定すれば準備完了。サイタのシステム側では、発信者番号から当日のレッスン予定を検索し、4 の応答(TwiML と呼ばれるXML形式)を返してやるだけでした。

TwiML では音声読み上げを指定できます。たとえば以下のような応答です。

<?xml version="1.0" encoding="UTF-8"?>
<Response>
  <Say voice="woman" language="ja-JP">
    お電話ありがとうございます。
    こちらはサイタ事務局、お待ち合わせ専用ダイヤルです。
  </Say>
  <Say voice="woman" language="ja-JP">
    ヤマダタロウさんへお繋ぎいたしますので、このまま少々お待ちください。
  </Say>
  <Dial callerId="+8150xxxxxxxx">+8190xxxxxxxx</Dial>
  <Say voice="woman" language="ja-JP">
    お電話ありがとうございました。 
  </Say>
  <Hangup/>
</Response>

実際に読み上げさせてみると、日本語の読み上げは、やや違和感はあるものの、実用上問題ないレベルです。(アプリケーションを組み上げる前に、幾つかサンプル応答を返すモックサーバーを用意してやって、句読点による読み上げかたの違いや、よく使う漢字の読みの正確性を確認したりしました。(読み上げだけならテストするツールがあったような気も。))

ちなみに、講師などは、1日に複数のレッスンを抱えていることもあります。そこで、当日のレッスン予定が複数ある場合は、プッシュ信号を送ることで、接続先を選択できるようにしました。このときの応答は、以下のようなものになります。

<?xml version="1.0" encoding="UTF-8"?>
<Response>
  <Say voice="woman" language="ja-JP">
    お電話ありがとうございます。
    こちらはサイタ事務局、お待ち合わせ専用ダイヤルです。
  </Say>
  <Gather timeout="60" action="https://example.com/example" method="POST" finishOnKey="#">
    <Say voice="woman" language="ja-JP">
      ヤマダタロウ様の、本日のレッスン予定は、5件です。
      これからご案内する番号をダイヤルし、最後にシャープを押してください。
      10時00分からの キムライチロウさんへのお電話は、1。
      11時00分からの キムラジロウさんへのお電話は、2。
      16時30分からの キムラサブロウさんへのお電話は、3。
      20時00分からの キムラシロウさんへのお電話は、4。
      21時00分からの キムラゴロウさんへのお電話は、5。
      を押し、最後にシャープを押してください。
    </Say>
  </Gather>
  <Say voice="woman" language="ja-JP">
    お電話ありがとうございました。 
  </Say>
  <Hangup/>
</Response>

Gather という動詞で、受け取ったプッシュボタンの送信先を指定してやります。冒頭の図でいえば、4 と 5 の間に、ひとつ API を追加して、このボタンに応じた電話の中継先を返してやるイメージです。

追加した API(URL) での応答は、接続先は決まっているので、以下のような簡単な内容となります。

<?xml version="1.0" encoding="UTF-8"?>
<Response>
  <Say voice="woman" language="ja-JP">
    キムラジロウさんへお繋ぎいたします。このまま少々お待ちください。
  </Say>
  <Dial callerId="+8150xxxxxxxx">+8190xxxxxxxx</Dial>
</Response>

なお、実際にシステムを構築し、検証してみたところ、上記 1 の発信先 050 番号は、複数電話番号から同時にかけても話中になること無く、通話可能であることがわかりました。当初、複数の電話番号を取得しておき、ユーザーごとに電話番号を動的に割り当てるような運用が必要になるかも(そうなると、電話番号が毎回変わるのでユーザーが混乱しそう)と考えていたのですが、この仕様のおかげで、単一の電話番号で運用できます。電話番号毎にかかる月額料金も最小限で済みますね。

こちらの機能は「待ち合わせ専用ダイヤル」としてリリースしました。リリースして1ヶ月ほど経ちますが、大きな問題もなく運用できています。こういった電話を使用したシステムのリリースは初めてだったので、どれだけスムーズに受け入れられるか心配でしたが、ユーザーにとっては Web のシステムよりも電話システムのほうが馴染みがあるのかもしれませんね。

システム側では電話着信ログを取得することもできるので、これまで把握できていなかった、「実際にどれくらいのユーザーが(待ち合わせのために)電話による通話を利用しているのか」を見ることができるようになりました(そして、想像していた以上に利用されることもわかりました)。これは、レッスンまでの各種誘導のコミュニケーション改善効果を測る指標としても使えるかもしれません。

公式サイトのハウツードキュメントを見ると、他にも電話連携のための様々な機能が利用できることがわかります。電話と繋がるWebシステムって楽しいですね。電話会社出身の筆者としては、こんなシステムが、ここまで手軽に構築できてしまうことに驚きです。数年前までは、こういったものを独自構築したら、機材設備含めて数百万円以上のプロジェクトだったのではないでしょうか。

というわけで Twilio で、簡単に電話連動サービスができてしまったというお話でした。

それでは、また。

@tmtysk

毎年思うのですが、花見のシーズンってすぐに終わっちゃいますね。今年は、オフィスから徒歩圏内の代々木公園で2度ほどお花見ランチができたので、だいぶ春を味わっている感があります。花粉つらいですが。

さて、社内文書を晒すシリーズ第2段。今回は、社内のコードレビュー運営について書いてみたいと思います。

早速ですが、以下が、当社の定期コードレビュー運用に関するドキュメント(無修正)です。

定期コードレビュー

目的

言語化されていない、コーディング/設計ノウハウや文化/価値観の洗い出しと共通認識の形成

哲学

• レビュー対象はコードであり、プログラマではない
• コードレビューでは、設計やコードの修正を求めない
• 自分のことは棚に上げ理想論を振りかざすのが善、現実論は聞き流す程度に
• 発言が善、沈黙は悪

運用の設計

• 週1、30min
• 進行は当番制
• 進行役が、責任をもって、開催までに、レビュー対象のコミットやコードを選定する
• 選定の候補は、自薦もしくは他薦で事前に募る。この募集プロセスも進行役の役目
• 毎回5min、KPT (Keep, Problem, Try)のふりかえりをする
• 随時レビューは、これまで通りおこなう

このドキュメントを書いたとき、つまりコードレビューを定期的にやろう、と思い至ったときに考えていたことは以下のようなことでした。

• コードレビューが個人攻撃の場にならないようにしよう
• かといって、現実を見つめて傷を舐め合うような場にはしたくない
• むしろ前向きで、かつ、プログラマであることが楽しいと思えるような場にしよう

こういう当初の考えというものは、口頭で伝えたところで流れていってしまいがちですし、自分自身忘れてしまうので、自分の気持ちを整理する意味もこめて、ドキュメント化するようにしています。また、こういったドキュメントは、書きっぱなしになって忘れられることもままあるため、プリントアウトしたものをデスクの前の窓に貼っています。こうしておくことで、たびたび目に入ります。

既にこの運用になって、進行の当番も何周かまわっていますが、今のところ、当初の目標から外れること無く運用できているように思います。

なお、このドキュメントを書いたり、コードレビューを運用するにあたって、いろんな会社さんのやり方を参考にさせていただいています。

たとえば、「自分のことは棚に上げ、理想論を振りかざす」というフレーズは、以前 Google さん主催の Startup Tech Night に LT 参加した際に、スピーカーの足立さん(カブク)が仰っていたものです。コードレビューを楽しむという点において、このフレーズのキャッチーさは素晴らしいなと感銘を受け、早速当社でも使わせていただきました。

また、各人が自身の仕事を持っていると、コードレビューのような時間をしっかり確保することは、ついついなおざりになってしまいがちです。そこで、当社では、定期コードレビューの時間を bot から Slack に通知させるようにしました。

このアイデアをいただいたのは、ご近所スタートアップ Bracket さんとのランチのときです。(その節はありがとうございます。また行きましょう :)

さて、書き出すと、もうちょっと補足したいところ(とくに「設計や修正を求めない」の箇所)や、じっさい運用してみて思ったこと、変えていっていることなども書きたいのですが、長くなってしまいそうなのでまたの機会にしたいと思います。

当社としてはわりと普通のことを書いているつもりですが、こうやっていろんな会社さんのやり方を取り入れつつ、「うちはこうやってるよ」を晒していくことで、同業者さんに少しでも参考にしていただけるところがあれば嬉しいです。

最後に、毎回の告知で恐縮ですが、当社では、開発を楽しみつつ、現場をぐいぐい改善していきたいエンジニアを絶賛募集中です。よろしければ、ぜひ募集をご覧になってください。

それでは、また。

@tmtysk