読者です 読者をやめる 読者になる 読者になる

コネヒト開発者ブログ

コネヒト開発者ブログ

ESLintを途中で導入したときの.eslintrcの設定と運用方法について考えた

f:id:dachi023:20160401044514j:plain

こんにちは。花粉症に悩まされているエンジニアの安達(@ry0_adachi)です。

前回は運用中のサービスへのwebpackの導入についてお話しさせていただきましたが、今回はESLintの導入と運用方法について話していきたいと思います。

Linterを途中から導入したときの課題

複数人の開発メンバーがいる状況下でLinterがあるとコードの書き方が統一できたり、定義忘れなどでの不要なエラーを未然に防ぐことができます。
便利なツールなのでプロジェクトの途中からでも入れたい!と思う方は少なくないかと思いますが、その際に高確率で発生する問題があります。

既存のコードでエラーが出る

全く出ないということはほぼ無いかな、と。行末にスペースが紛れてしまったりとか気をつけていてもたまにやってしまったりします。
そんなわけでLinterを途中から導入した際に発生したエラーとどう向き合って、今後エラーを無くしていくためにどう運用していくかを考えることにしました。

ESLintとは

今回導入したのはESLintというJavaScriptのコードの書き方をチェックするためのLinterです。
主にインデントのズレ、未定義 or 未使用の変数がある、セミコロンが無い、などを検知して警告やエラーを出してくれます。

どんなプロジェクトにも合わせられる

大げさかもしれませんが、割と本当です。それくらいESLintは柔軟です。

  • ルールはそれぞれ独立しているので個別に設定することが可能
    • on/offが選択できる
    • 警告 or エラーを選択できる
  • 独自ルールを定義できる
  • 標準で多くのルールがある
    • 標準のルールだけでも十分にLinterとしての威力を発揮してくれます
  • プラグインが豊富
    • 各種フレームワークにも対応できる

JSHintなどの他のLinterとの大きな違いとしては独自にルールを作成でき、プラグインとして追加できることです。
これによって柔軟性が大幅に高まり、独自ルールがあるような場合にも合わせることが可能になっています。

運用方法を考えて実践する

1. とりあえずrecommendedだけ

ESLintには推奨の設定が用意してあります。.eslintrcに下記のように定義します。

envは該当の環境で定義される変数を自動で定義済みである状態にしてくれます。browserならdocumentとかですね。それによって未定義の変数でエラー、とならなくなります。
browserifywebpackを使用している場合はcommonjsもtrueにしておきます。

まずはrecommendedで怒られるエラーだけを直していくのが良いと思います。
その後ルールを後追いで追加して、という形にした方がエラーの修正にかかる時間を分散できるから。という理由です。

2. 見つけたら直してもらう

プロダクトコードの修正などで実装する箇所でエラーが出ていたらついでに直してもらうようメンバーにお願いします。そうすることでプロダクトの開発をしながらでもエラーの数も減っていき、少しずつコードも綺麗になっていきます。

機能やコンポーネントごとにファイルが綺麗に分割されているのであれば触ったファイルの全てのエラーを直す、というやり方が可能です(きっと1ファイル数十行、とかなので)。
もしそういったやり方が少し難しいな、と感じたら関数ごとに直していく、など一度で直す範囲を狭めるのがライトでいいんじゃないかなと思います。

コネヒトでは事前にファイルを分割するというリファクタリングを行っており、短いコードが多いので、もしエラーがあればファイルごとに直すようにしています。

3. 足りなければルールを追加する

もし必要なルールが増えた場合は追加します。
例としてセミコロンがないとエラーになるようにしてみましょう。

これでセミコロンを忘れた場合に怒られるようになりました。そしてこれを「ここまでやれば十分!!」となるまで繰り返します。
一度追加したルールはその後も怒られる対象なのでせっかく直したのにまたエラー...ということはないでしょう。

4. 綺麗なコードを目指して

後は2と3を繰り返していくだけです。
最後まで頑張るのが何よりも大事ですので根気よく続けていきましょう。

まとめ

  • Linterをプロジェクトの途中から導入すると既存のコードでエラーが発生しやすい
  • ESLintは柔軟性が高く様々なプロジェクト、プロダクトに対応するための設定が可能
  • まずはrecommendedのエラーを消すところから始めて、直し終わったらルールを足す→エラーを消す、を繰り返す

余談ですが、最初から導入できるのであればそちらの方がいいですよ!!

最後に

いかがでしたでしょうか?ドキュメントだけではなかなか運用が難しいコーディング規約もツールで自動チェックができるようになります。簡単に導入できるのでまだ入れていない方はぜひこれを機にチャレンジしてみてください。

fastlaneとTravisでいい感じのタイミングでアプリを受け取る

お久しぶりです、3/31, 4/1は仕事ですが、4/2はバルト9へ行く田村(@Utmrer)です。 今回は弊社でのfastlaneによるアプリ配布についてお話します。

アプリ配布の通知メールの回数を減らしたい

開発段階のアプリを社内やテスターに配布する処理を何かしらのScriptで書いてCIで実行し、自動化している人は多いかと思います。 弊社も一時期配布を自動化していましたが、2つの問題がありました。

  1. RC, AdHoc, Development等、複数の環境のビルドが必要である
  2. PushしてCIが回るだびに通知メールがくると煩わしい

という感じで毎回複数環境のBuildを実行するのは時間が掛かり過ぎる、メールを送ってアップデートを促したいが「頻繁にメールが来ることによって、メールを無視することが普通になる」とアップデートしてもらえない、と問題を抱えていたので都度手動で配布してましたが、「fastlaneが便利らしいぞ」という話を聞いたので、Travisで自動化することにしました。

証明書をリポジトリに含める

Travis上でアプリをビルドするために証明書を書き出します。 f:id:Utmrer:20160320223115p:plain キーチェーンからiPhone Distribution: Your Name (Team ID)、そして今回はDevelopmentのBuildも配布するのでiPhone Developer: Your Name (Team ID)p12を書き出します。 WWDRCAはTravisなら最初から入ってます。

各環境のlane等をFastfileに定義する

最終目的なFastfileはこんな感じになります。

fastlane_version "1.61.0"

default_platform :ios

platform :ios do
  before_all do
    ENV['KEYCHAIN_NAME'] = "TempKeychain.keychain"
  end

  desc "Build for AdHoc"
  lane :build_adhoc do
    sigh(
      app_identifier: "com.example.app.adhoc",
      adhoc: true,
      skip_certificate_verification: true,
    )
    ENV["PROFILE_UDID"] = lane_context[SharedValues::SIGH_UDID]
    gym(
      clean: true,
      workspace: "App.xcworkspace",
      scheme: "Adhoc",
      use_legacy_build_api: true
    )
    deploy_crashlytics
  end

  desc "Build for Debug"
  lane :build_debug do
    sigh(
      app_identifier: "com.example.app.dev",
      development: true,
      provisioning_name: "Debug",
      skip_certificate_verification: true
    )
    ENV["PROFILE_UDID"] = lane_context[SharedValues::SIGH_UDID]
    gym(
      clean: true,
      workspace: "App.xcworkspace",
      scheme: "Debug",
      use_legacy_build_api: true
    )
    deploy_crashlytics
  end

  desc "Build for Release"
  lane :build_release do
    sigh(
      app_identifier: "com.example.app",
      adhoc: false,
      provisioning_name: "Release",
    )
    ENV["PROFILE_UDID"] = lane_context[SharedValues::SIGH_UDID]
    gym(
      clean: true,
      workspace: "App.xcworkspace",
      scheme: "Release",
      use_legacy_build_api: true
    )
    deliver(
      force: true,
      skip_screenshots: true,
      skip_metadata: true
    )
  end

  desc "Import Certificates"
  lane :import_certificates do
    return unless Helper.is_ci?

    create_keychain(
      name: ENV["KEYCHAIN_NAME"],
      default_keychain: true,
      unlock: true,
      timeout: 3600,
      lock_when_sleeps: true,
      password: ENV["PASSWORD"]
    )

    import_certificate(
      certificate_path: "./certificates/distribution.p12",
      certificate_password: ENV['PASSWORD'],
      keychain_name: ENV["KEYCHAIN_NAME"]
    )

    import_certificate(
      certificate_path: "./certificates/development.p12",
      certificate_password: ENV['PASSWORD'],
      keychain_name: ENV["KEYCHAIN_NAME"]
    )
  end

  after_all do |lane|
  end

  error do |lane, exception|
  end

  def deploy_crashlytics
    crashlytics(
      api_token: "YOUR_API_TOKEN",
      build_secret: "YOUR_BUILD_SECRET",
      groups: 'tester_group',
      notifications: true
    )
  end

end

build_adhoc/build_debug/build_releaseがそれぞれの環境別のBuildを作成し、Crashlyticsへアップロードするlaneです。
ENV['PASSWORD']は「ちょっとパスワードとかcommitに含めるの嫌だなぁ〜」って時に、コマンドで暗号化して.travis.ymlで定義した環境変数です。
fastlaneでiOS Dev CenterやiTune Connectに接続するために必要なFASTLANE_USERFASTLANE_PASSWORDと合わせてこのようなコマンドで暗号化します。
travis encrypt PASSWORD=CERT_PASSWORD FASTLANE_USER=APPLE_EMAIL FASTLANE_PASSWORD=APPLE_PASSWORD
詳しくはこちらをご覧ください。
Encryption keys - Travis CI

ちょっとハマったところはprovisioning_nameを指定するところです。ここでprovisioning_nameを指定しないと、新しいProvisioning Profileを次々に生成し、iOS Dev Centerがかなりカオスになりました。

Travisでいい感じのタイミングでBuildする

f:id:Utmrer:20160321115901p:plain さて、それぞれの環境のlaneが出来たので、それぞれをいい感じのタイミングで実行しましょう。
弊社のiOSプロジェクトはgit-flowで開発しており、新しい機能はfeaturebranchを作り、実装が終わるとdevelopbranchへmerge、リリースのタイミングになるとそこからreleasebranchを作って全体的な機能の確認をし、問題が無ければmaterへmergeされるというflowをとっています。

  1. 新しい機能の実装が一旦完了した段階でみんなに開発環境アプリをインストールしてもらいたい
  2. 新しいリリースを申請する段階でみんなにAdHoc環境アプリをインストールしてもらいたい

という2つのタイミングがアプリを配布したいタイミングなので「featurebranchをdevelopbranchへmergeしたタイミングで開発環境アプリ」「masterbranchへreleasebranchをmergeしたタイミングでAdHoc環境アプリ」を配布することにしました。あとmasterへmergeされたタイミングでiTunesConnectにもアップロードしちゃいましょう。
その仕様を満たす.travis.ymlはこんな感じになりました。

language: objective-c
osx_image: xcode7.2
env:
  global:
  - LANG=en_US.UTF-8
  - LC_ALL=en_US.UTF-8
  - secure: COMMAND_DE_ANGO_KA_SHITA_PASSWORD_TOKA
script:
  # YOUR_TEST_SCRIPT
after_success:
  # Deploy Release/AdHoc App
  - "[[ $TRAVIS_PULL_REQUEST == 'false' ]] && [[ $TRAVIS_BRANCH == 'master' ]] && fastlane import_certificates && fastlane build_release && fastlane build_adhoc"
  # Deploy Debug App
  - "[[ $TRAVIS_PULL_REQUEST == 'false' ]] && [[ $TRAVIS_BRANCH == 'develop' ]] && fastlane import_certificates && fastlane build_debug"

本当はDeploymentを使ってDeployしたかったのですが、Deploymentではうまくfastlaneが動かなかったのでafter_successで実行しています。
$TRAVIS_PULL_REQUESTの判定でPushした時だけ実行するようにし、$TRAVIS_BRANCHの判定で特定のbranchでlaneを実行するようにしています。
ここの処理はもうちょっと綺麗に出来そうですね、Circle CIならもうちょっと綺麗だった気がします。
これでdevelopへmergeした時に開発環境アプリが、masterへmergeした時にAdHoc環境アプリがテスターに届くようになりました!

おわりに

この機能の実装に50 commit以上かかってしまって、完成した時の達成感がかなり大きかったです!(証明書辛い…)
fastlaneは社内でテスター募集をする時にboardingを使ったりしてるのですが、もうちょっと色々触ってみたいですね。(dg add-devices的なのをSlackからやったり)
それと今回はCrashlyticsから新しいアプリがメールで行きますが、出来ればSlackに何かしら通知したいですね。弊社の人はメールクライアントよりSlackにいる時間が長いのでSlackに通知した方がアップデートしてくれそうです。
もっと良い配布方法や.travis.ymlの書き方をご存じの方は是非教えて下さい!ではでは👋

実践してみてわかった、ビジネスチームと一緒に「技術で勝つ」チームを創る3つの方法

f:id:tatsushim:20160303174817j:plain

こんにちは

CTOの島田(@tatsushim)です。 今回はビジネスチームのメンバーと一緒に「技術で勝つ」チームをどう創るかという点についてご紹介させていただければと思います。

勝ちたい!

突然ですが、Webサービスを創るからにはそのサービスをNo.1のサービスにしたいと思っています。しかし数の勝負では大企業に勝てません。
日本の3人に1人のママが利用するmamari事業を支えているのはたった11名の社員です(2016年3月4日現在)。 少数精鋭で戦うために、弊社ではビジネスチームにも積極的に技術を使ってもらっています。 技術を使ってもらうメリットには以下のようなものがあります。

  • エンジニアとコミュニケーションしやすくなる
  • ビジネスissueからの要求でエンジニアのリソースを取ることが減る
  • 全員が「技術」で解決しようという思考になる

以下、実際に私達が今実践している3つの工夫について、解説していきます。

「技術で勝つ」チームを創る3つの方法

1.タスクリスト(issue)はGitHubで一元管理する

実は弊社は開発だけでなく営業のようなビジネスissueもGitHub上で管理しています。
具体的には

リポジトリ名 用途
Sales 営業系の案件管理や情報共有
Review 行った施策の振り返り
Direction サービス全体のディレクションや組織運営に関わること

というリポジトリが存在しています。 それらをGitHubにすることで以下のような恩恵がありました。

  • GitHub管理下なので、関連する開発issueにメンション(ref.)を飛ばしやすい
  • Assigneeを利用することで「誰がボールを持っているのか」を視覚化することができる
  • チャット(Slack)上で流れてしまっていたログをGitHubに記録として残すことができる

2.GitHubとSlackとの連携を密にする

GitHubに統一すると上記のようなメリットがある一方、人によっては少し慣れない部分もあると思います。 弊社ではHubotを通してGitHubへのアクセスをSlackベースにすることでそのハードルを下げています。

f:id:tatsushim:20160303175640p:plain

上記の例はcreate issue [リポジトリ名] issueのタイトルというコマンドでissueを作成し、そのissueに対してSlack経由でコメントしています。

3.SQLリストを作って共有する

f:id:tatsushim:20160304150645p:plain

メンバー全員にDBのリード権限を与えてデータを自由に見てもらっています。 そして一度「この集計データがみたい」というリクエストをもらったらそのSQLをエンジニアが書いて、それを用途別にGoogleSpreadSheet等にまとめています。 それらを参照しつつ、コピペして実行するだけでも「こんなデータが見れるんだ!」という体験がSQLへの関心を高めてくれています。

その結果今では自分でSQLを書き、Google BigQueryからデータを取り出して、エンジニアの手を借りず仮説検証を一人で回すメンバーも出てきました。

以上をやってみて、感じた変化

f:id:tatsushim:20160304161554j:plain

弊社のKPT MTG*1はフルタイムのメンバー全員で行っているのですが、 技術の話題を出してもスムーズに良いディスカッションができています。 その結果、問題点に対してエンジニアの枠内で最適化するのではなく、会社全体の問題として捉え解決に向けて取り組むことができていると思います。

おわりに

最後まで読んでいただき有難うございました。 今回触れたトピックについてより良い方法やご意見がある方は、はてぶコメントやTwitter等でいただけますと嬉しいです。

*1:KPTとはKeep/Problem/Tryの頭文字をとった、振り返りの為のフレームワークです

webpackを運用中のサービスに素早く導入する

f:id:dachi023:20160218152829j:plain

はじめまして!

2月から入社したエンジニアの安達(@ry0_adachi)です。

私からはwebpackを導入する際に行ったことをご紹介していきます。
webpackに乗り換えることのメリットって何だろう?という方や、運用中のサービスがGruntやgulp、browserifyで近いうちにwebpackに乗り換えたいなぁ、と考えている方の参考になれば幸いです。

webpackとは?

ざっくり言うと「コード間の依存を解決するためのツール及びビルドツール」です。
AはBに依存している、といった状態の時にAの書かれているファイルに対してBのファイルを結合して参照できるようにするのがwebpackの仕事です。

なぜwebpackなのか

なぜ私がwebpackを導入しようと思ったか、についてですが2つ大きな理由があります。

モジュールロードシステムの導入

ファイルを跨いだモジュールの呼び出しを行うための仕組みは他の言語では初めから当たり前のように実装されている機能ですが、残念なことにJavascriptに追加されたのは最近になってからのことです。
ES2015からはimport/exportが使えるようになっていますが、現在Connehitoで運用しているサービスのコードはES5で実装されています。
そこでwebpackを利用することでWebアプリでもモジュールロードを可能にして依存性を自動で解決しよう!と考えました。

複数のファイルをまとめて出力したい

browserifyというwebpackに似たツールがありますが、こちらは1回のビルドで1つのファイルしか出力できません。
今回は複数のファイルを出力したかったこともあり、複数ファイルの出力が可能なwebpackを選びました。

現状を理解する

webpackに限ったことではありませんが、既存のサービスに対して手を加える場合、どのような作りで何をしているのか、を理解している必要があります。
まずは手を動かすよりも先にコードをしっかりと読むことにしました。

コードを読んで分かったこと

  • CommonJS, AMDに対応していない
  • 外部ライブラリはパッケージ管理をしていない
  • gulpでファイルを結合して圧縮をかけている

上記がwebpackを導入する前の状態でした。
また、既に運用中であることや、まずは導入してから徐々にwebpackで管理する領域を広げていこうという思惑もあったので、今回は Javascriptをwebpackでビルドする ことをゴールにします。

今回やること

  • CommonJSに対応させる
  • ライブラリをnpmでパッケージ管理する
  • webpackでファイルを結合して圧縮をかける

いざ、webpack

それでは導入にあたって行ったことを順を追って説明していきます。

1. CommonJSに対応させる

CommonJSというのはJavascriptの標準APIの仕様を策定している文書、プロジェクトのことです。
その中でモジュールのロードはrequireとexportsでやりますよ、と定義されています。
そして、これはES2015のimportとexportに非常に似ています。そんなこともあり今後ES2015に書き直した時に修正が簡単なようにCommonJSのモジュールロードの仕様に対応することにしました。
やったことは となっているコードを とするだけです。非常に簡単ですね!
これだけ?と思われるかもしれませんが、これだけです。モジュールロード最高ですね。
この作業をファイルの数だけ繰り返してmodule.exportsに既存のコードを詰め込んでいきました。
module.exportsを書いたコードはrequireを使うことで呼び出せるようになります。

2. ライブラリをパッケージ管理する

使っているライブラリも一緒にrequireしたいのでnpmで管理することにしました。
ConnehitoではBackbone.jsを採用しているのでnpm経由でインストールしてみます。

# 依存するunderscore.jsも一緒に入れます
$ npm install --save underscore backbone

インストールが無事終わったらrequireを使って呼び出すコードを書きます。 これでBackbone.jsとunderscore.jsが使えるようになりました。
他にも使用しているライブラリがいくつかあったのですが、そちらも同様にnpmで入れ直してrequireする、とするだけでした。 本当に良い時代です。これでライブラリがパッケージ管理されるようになり、簡単にrequireもできるようになりました。

3. webpackでファイルを結合して圧縮をかける

いよいよgulpのビルドタスクをwebpackへ移行します。
とりあえずwebpackをインストール。

$ npm install -g webpack

ファイルの結合に関してはbrowserifyのように依存解決と一緒にやってくれるので特にやることはありません。
というわけで、基本的な設定と圧縮するための設定を用意してあげます。 圧縮するだけならこれだけでOKです!短くていいですね!
そして、ついに実行する時がきました!webpackコマンドを叩いてみましょう!

$ webpack

2つのビルドされたJavascriptファイル(bundle-hello.js、bundle-backbone.js)とそれぞれのソースマップが無事生成されてwebpack移行第1弾が完了です!
他にもファイル監視やES2015のトランスパイルなど、webpackにやってもらいたい仕事がたくさん残っているので第2弾も現在計画中です...!

まとめ

Javascriptをビルドするだけ、という形で導入してみました。
今回はサンプルコードでのご紹介だったので直したのは一箇所でしたが、実際はexportsをサービス全体に埋め込んでいったので、今はどこからでもrequireで使いたい機能が呼び出せちゃいます。
初めから全てを移行するのではなく少しずつ移行することで敷居も下がって導入しやすいので非常にオススメな方法です!!


webpackとES2015を使ってJavascriptを書きたい!
そんなフロント好きなエンジニアの方はConnehitoへ遊びに来て私と今後のモダンなフロントについて語り合いましょう!

www.wantedly.com

PHP7にCakePHP2.xが来るぞ!!!!!

f:id:connehito:20160205104322j:plain

来るぞ!!!

ご無沙汰しております。
コネヒトでPHPを書いている金城 / @o0h_です。
タイトルの通りですが、CakePHP 2.xが次期バージョンの2.8でPHP7に対応!(!)という話を小耳に挟んだので、喰いついてみました。

PHP7 Compatibility!!!

f:id:connehito:20160204202829p:plain

CakePHP、PHP5時代と次世代への断絶

新しい世界・・・・怖いのかな・・・めちゃくちゃ大変なの??
という事には、(実際に使うかは別としても)興味を持つ人も多いのではないかな!!!と思いました。
かくいう私もその1人、さればとGithubを眺めながら「何が起きたか」を探って参りました。
CakePHPが通った道のりを紐解くことで、「PHP7に飛び乗るための覚悟」を少し育めたらなと思います。

続きを読む

まいにちUX - 新年からはじめる1DAY1UXの習慣 -

f:id:connehito:20160112191659p:plain

あけましておめでとうございます! 新年1発目の記事は、デザイナーのきよえし(@kiyoe_furuichi)が担当いたします。今年もどうぞよろしくお願いします!

さて、前回の私の記事では「チーム開発でのおもてなし」について触れましたが、今回は12月に登壇させていただいたUX MILKさん主催の「ゆるく学ぶUXイベント UX JAM 4 - UX Girls Special -」にてお話した内容をまとめてご紹介したいと思います。

UXことはじめ

突然ですが、みなさん「共感力 (Empathic ability)」という言葉をご存知でしょうか? UXをデザインする上で大切な力だと言われていて、私も日々、機能の新規開発やUI設計などを行っている中で共感力の重要性はとても感じます。

ざっくり説明すると、共感力は「他人の感情を理解する力」という意味を持ちますが、UXでの共感力は「サービスを利用するユーザーさんの視点と同じ目線に立ち、目的に達するまでの過程で感じる感情を自分ごとのように感じ取ることのできる力」のことをいいます。
この力を高めることにより、ユーザーさんにより近い感覚でサービスに関する問題や発見・気づきを得ることができ、より良いサービス体験へ改善するためのアイデアの質を向上させることができます。

今回はその「共感力」を高めていくためにはどうすれば良いのかを私なりに考え、実践している内容をまとめてみました。

「共感力」の必要性

ユーザーさんがより便利に・気持ち良くサービスを利用するための機能をリリースしたにも関わらず、想いに反しフィードバックではネガティブな意見が多かった。。なんてことはあったりしますよね。そんな時、設計・デザインに関わった自分はこう思うわけです、「共感力が足りてなかった…」と。ユーザさんの視点になりきれずに良いものを作ろうとすると、こういった失敗につながることがあります。
そんな共感力は、理論やツールの使い方うんぬんではなく感覚的なものですので、経験を積み、地道にコツコツ身につけていくものだと個人的に考えています。とにかく自らが多くのUXに触れてみることが身につけるための唯一の近道なのかなと思います。

1DAY1UXの習慣化

「UXに触れる」というアクションは、実はすでにみなさんも毎日の生活の中で行っています。 例えばコンビニでコーヒーを買う、定食屋さんでランチを食べるなど。WEBを介さなくても世の中のサービスを利用するシーンにおいてUXという考え方は必ず存在します。
そこで私はそれを1つ1つ意識し体験することで「共感力を鍛えるトレーニング」になるのではと考え、1日に1つでもUXを体験する「1DAY1UX」の習慣化にチャレンジしてみることにしました。

毎日考える工夫

毎日続ける工夫として、迷ったのがUXのアウトプット方法です。 UXを可視化するツールとして、有名なものでいうとカスタマージャーニーマップ(以下CJM)がありますが、事細かにまとめると数時間かかってしまうので毎日は続かない。。と感じ、自分なりに毎日続けられる工夫を考えてみました。そこで最近はじめた小さな習慣をご紹介したいと思います。

まいにちUXノート

f:id:connehito:20160114091526p:plain

「まいにちUXノート」というものを作ってみました。普段の生活で体験したUXを書き留めておくためのノートです。 CJMを少しシンプルにしたもので、5分でユーザーさんの体験を可視化できるようにしました。難しいことを考えずスラスラと書くことができるので、これなら毎日続けられそうです!

書き方

ノートは以下のようになっていて、CJMと同じく「行動」と、それぞれの課程で感じた「気持ち」を書き、その下に、時々の「感情の変化」を5段階で書けるようにしました。

f:id:connehito:20160112170714p:plain

具体例を見ながらイメージを掴んでいただければと思います。

例1 とある日のコンビニUX -お弁当編-

f:id:connehito:20160112152727p:plain

コンビニに入り、商品を探す。そして手に取ったお弁当をレジで購入し、温めてもらう。 このように普段の何気ない行動を書き出していきます。

例2 とある日のコンビニUX -コーヒー編-

f:id:connehito:20160113235243p:plain

次はコーヒーを買うことをゴールとした場合に、途中で離脱したパターンです。 お弁当編も然り、レジに並ぶ際に混んでいるとネガティブな感情になり買う気持ちが薄れてしまっているようです。

例3 とある日のランチUX -パスタ屋さん編-

f:id:connehito:20160113234719p:plain

ふらっと散歩した際に見つけたパスタ屋さん。 接客から商品まで大満足のお店でした。ご飯屋さんが比較的UXを考える上で分かりやすいかもしれないですね。

配布してます(pdf形式)

「まいにちUXノート」のデータは以下にて配布しています。使ってみたい!という方はどうぞ!
Dropbox - まいにちUXノート.pdf

やってみて思ったこと

1DAY1UXを習慣にしてから、自然と意識して自分の行動や気持ちの変化を考えるようになったのと、それから、私がもしこのサービスを提供する側だったらここはこう解決したい、といったところを想像するようになりました。
まだこのトレーニングが実際に生かされているかまでは分かりませんが、この取り組みを続けていくことより「共感力」を高めることはできると感じたのと、こういった小さな積み重ねが大事なので、続けていこうと思います!

さいごに

いかがでしたでしょうか。
今回私がご紹介した「まいにちUXノート」を利用した1DAY1UXの習慣のように、みなさんも日々の生活の中でUXを考える工夫をしながら、こつこつ「共感力」を高めてみませんか?もっともっと、ユーザーさんの目線に近い視点でサービスをより良くするデザイナーを目指していきましょう!

それでは、2016年もよろしくお願いします!
最後まで読んでいただきありがとうございました!

リンク



コネヒトではエンジニアさん、デザイナーさん、デザイナーさん、デザイナーさんをWANTEDしています! 一緒に300万人が使うサービスのUXをより良くしていきませんか?
www.wantedly.com

スタートアップ入社1ヶ月で実践した「低コストでデキる!開発を加速させる情報共有」の始め方

f:id:fortkle:20141210080057j:plain

こんにちは!今月12月から中途入社したエンジニアの高野フォートクル (@fortkle) です。

今日は、私が入社して実践した情報共有に関する取り組みのうち、効果があったものを「『低コストでデキる!開発を加速させる情報共有』の始め方」と題して共有したいと思います。

tl;dr

  • 関係者全員が情報共有ツールを使える環境を整える
  • 「この1ページだけ見ればOK」という情報の集約場所を作る
  • slackの分報でそのページの質をチェックし、足りない部分を更新してメンテナンスする

Connehitoの状況

まずは私が入社した直後のConnehitoの状況を列挙します。

人数 CTO 1名 + 開発者(エンジニア・デザイナー) 3名
ドキュメント GithubのPRに詳しく仕様は書かれているが、ドキュメントとしてまとめていない
情報共有
ツール
Slack, Docbase(あまり活発には使われていない, 全員分のアカウントがない)

当時は人数も少なく、1つのプロダクトにつき担当者が1~2名だったので、自分自身が知っていれば全く問題がありませんでした。つまり、情報共有の必要性が低かったのです。

また、スタートアップのため完璧なドキュメント作成はしない意思決定をしており、ユーザーに価値のあるサービスの提供を優先して日々の開発業務を進めていました。

これから発生が予想される問題

Connehitoが運営しているママリママリQは、いま物凄いスピードで成長をしており、やりたい施策も日々増えてきています。それに伴って開発者が増えていくことは容易に想像できますが、現状の情報共有のままでは今の開発スピードを維持したまま開発チームをスケールさせることが難しくなる事が予想されます。

具体的には下記のような問題が発生する可能性があります。

  • 会社の 開発フローや開発文化を理解 するのに 時間がかかる
  • 既に効率化された方法があるのに 共有されなかったせい無駄な時間 を使ってしまう
  • 新しく入ってきた人が、 「なぜ」 現在の実装・設計になっているか理解できない  

「開発を加速させる情報共有」の始め方

上記の問題に対して、あまりコストを掛けずに効果のある施策をできないか考えた結果、下記取り組みを実施し効果がありました。順を追って説明します。

1. 情報共有のための環境を整える

チャットツールがいかに有用か、という話は他の記事に譲るとして情報共有ツールを使うことは非常に重要です(ここでいう情報共有ツールというのは、Qiita:Teamやesa.io、Docbase等のブログとWikiを組み合わせた様なツールをイメージしています)。

Connehitoでは以前からDocbaseを使っていたものの、契約プランの関係で全員にアカウントを発行することができていませんでした。

情報共有ツールは一部で導入しても効果が出にくいので、私が入社して数日経ったタイミングでCTOに相談し、 開発者全員分のアカウントを発行できるプランまでアップグレード してもらいました。
 
~余談~
情報共有のもたらすメリットから考えると月額数千円は低コストだと思いますが、このあたりの交渉が難しいこともあると 思います。その場合は私も参加している「情報会議」という情報共有のコミュニティで話し合いがされているので、ぜひそちらの情報を御覧ください。

さて、こうしてConnehitoでは開発者全員がslackとDocbaseを使えるという環境が整いました。

2. 「この1ページだけ見ればOK」という情報の集約場所を作る

言葉より先に見てもらったほうが早いと思うのでまずはご覧ください。

f:id:fortkle:20151224155818p:plain

こちらはDocbaseに用意した、いわば「Connehito開発まとめページ」です。

開発に関するドキュメントや日々の業務で使っているツールなど、入社時に知っておきたい情報を全て網羅する目的で作成されています。 またそれだけでなく、日々の開発で使いそうな便利なリンク集やテスト用アカウントの共有などにも活用されています。

このページの良い所は 既存の資産を活用できる点です。

例えば、Connehitoではコードレビューを投資と捉え、時間をかけてしっかりと行っているため、Github上で行ったPR/コードレビュー周りの情報がそのままドキュメントとして有用なケースが多くあります。

新たに仕様書を作成するのではなく、このまとめページからGithubのPRに「仕様書/設計書」としてリンクを貼ることで、新しく入ってきたエンジニアが「PRに仕様が書いてないか検索してみよう」と思う状態を作り出すことができます。

新しく入社した開発者はこのページを一通り見ることで、頭のなかにConnehitoでの開発に関する情報の「インデックス」を作ることができるのです。

3. "分報"を活用して、情報共有を促し、陳腐化を防ぐ!

"分報"という手法をご存知でしょうか?少し前にバズっていた下記記事に詳細が書かれています。

c16e.com

私が入社してお試しで導入してみたところ、記事にあるように「10分以内に課題が解決できる」や「個人の学びが自然とチームに広まる」など効果を感じることができました。また、記事とは別にもう1つ効果がありました。

それは、「まとめページの質をチェックすることができる」 点です。

新しく入ってきた人は、個人の分報チャンネルを渡され、まとめページの「はじめての方へ」の項目をこなしていきます。当然、ドキュメントは書かれた瞬間から古くなっていくので、項目通りに進めていて問題が発生することがあります。

経験的にこういったとき、これまではたとえ問題が発生していたとしてもそのまま放置されることが多かったのですが、分報を導入することで作業が見える化され、「質問するほどではないけど詰まったところ・違和感を感じたところ」が共有されるようになりました。

その結果として、「○○さん、その詰まったところの更新おねがい!」とか「△△の記述が足りなかったので追記しておきました!」といったやり取りが行われるようになりました。

これで、低コストでドキュメントが陳腐化することをある程度防ぐことができるようになりました。

まとめ

「ドキュメントを残す」という作業はたしかに重要ではあるものの、そのコストは意外と大きなものです。特にスピード感を持ってフットワーク軽く進んでいかないといけないスタートアップにとって、その作成コストはある意味、死に直結する可能性もあり、無視できないものです。

一方で、成長途中のスタートアップにとって組織の拡大と情報共有の課題は解決すべき問題です。今回はそういったスタートアップでも出来る低コストかつ効果のある手法の1つだと思います。

同じような問題を抱えている方はぜひ試してみてください!


「わたしはこんなやり方でやってましたー!」というアツイ情報共有トークをしたい方はぜひ一緒にランチでも行きましょう!お待ちしております!