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

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

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

UXことはじめ

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

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

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

「共感力」の必要性

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

１DAY１UXの習慣化

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

毎日考える工夫

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

まいにちUXノート

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

書き方

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

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

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

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

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

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

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

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

配布してます(pdf形式)

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

やってみて思ったこと

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

さいごに

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

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

リンク

• 発表登壇資料： まいにちUX
• まいにちUXノート； Dropbox - まいにちUXノート.pdf
• 登壇イベント：UX JAM 4 -UX Girls Special!- - connpass
  
• UX MILK : UX MILK | クリエイターのためのUXメディア

---

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

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

こんにちは！今月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」という情報の集約場所を作る

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

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

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

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

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

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

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

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

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

c16e.com

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

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

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

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

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

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

まとめ

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

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

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

---

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

iOSアプリをローカルサーバーと通信させて実機デバッグする方法

お久しぶりです、社内で「ラブライブ、紅白出場おめでとうございます」と声をかけられる田村(@Utmrer)です。

私はiOS/Androidのクライアントサイドとサーバーサイドの実装をどちらも担当しているのですが、「ローカルサーバーで開発してるAPIを使いながら、アプリも開発する」ということをよくします。

その時に、アプリ側で通信するhostを本番環境のhostから自分のPCのローカルIP(192.168.1.XX, 10.0.1.YYなど)に変更してローカルサーバーとアプリを通信させていたのですが、IPv6サポートの流れからか、iOS9では出来なくなりました。*1

ローカルサーバーと通信出来ないとぶっつけ本番でデプロイする恐怖や、変更する度に開発環境にデプロイする煩わしさと戦わなければいけません。
それらを避けるためにiOS9でもローカルサーバーと通信する方法をご紹介します。

TL;DR

• IPアドレス指定での通信が出来なくなったのでローカルホスト名を使う
• hostnameを使ってhostの設定を自動化すると楽ちん
• ATSの設定もScriptで自動化出来る

Macのローカルホスト名を確認しよう

Macのローカルホスト名はシステム環境設定アプリから共有を選択すると表示されます。
このnozomi.localの部分があなたのローカルホスト名で、アプリが通信するhostです。

VagrantやMAMPで起動してるローカルサーバーのlocalhost:port(ex. localhost:8888)へ、Macと同じローカルネットワーク上のiPhoneのSafariからnozomi.local:8888という感じでアクセス出来るかと思います。

iPhoneからローカルサーバーと通信する

前項で確認した*.localのhostを本番環境のhostと置き換えればアプリとローカルサーバーが通信する準備が整ったのですが、App Transport Securityの影響でAllow Arbitrary Loads=YESにしてない場合は*.localのローカルサーバーとは通信は出来ない状態でしょう。
この設定も自動化して行きたいので環境別のhost設定からATSの設定まで自動化して行きましょう。

Info.plistにhostを持たせる

まずはこのようにInfo.plistに本番環境のhostを設定しておきましょう。 ServiceHostというKeyにexample.comという本番環境のhostが定義されています。

このServiceHostの値をビルド時に自動で設定します。サンプルコードではdiffを出したくないのでPreprocess Info.plist Fileを有効化しました。 Preprocess Info.plist Fileについて詳しくはこちら

ローカルホスト名はhostnameコマンドで取得できるのでBuild PhasesでScript追加してDebug Configurationの時だけInfo.plistを上書きするようにします。

Preprocessed-Info.plistを編集しているのでビルドの度にdiffが出てイライラすることもありません😊

そしてこのようにInfo.plistからhostを呼び出せばConfiguration毎に異なるhostへアクセス出来ます。

ATSの設定に*.localを含める

上記のようなATSの設定をしている場合、*.localはATS例外に含まれていないので通信できません。
*.localのhostもScriptでATS例外に追加しましょう！

上記のScriptをBuild Phasesに追加すると*.localもATS例外に追加出来ます。 Delete処理が入っているのはDerivedDataにPreprocessed-Info.plistのキャッシュが残っている場合があるからです。

ATSの環境別設定とPlistBuddyについてはこちらもご覧ください。 tech.connehito.com

今回ご紹介した内容を設定してあるサンプルプロジェクトも作ってみたのでもし良ければご覧ください。 特にBuild Phases辺りが肝です。 github.com

終わりに

以上で「iOS9でもローカルサーバーと通信する方法」&&「環境別の設定の切り替えを自動化」は終わりです。
「ﾅﾆｿﾚｲﾐﾜｶﾝﾅｲ」なところや、もっと簡単な方法があるよ〜って方は是非教えて下さい！ランチしながらPlistBuddyについて熱く語りましょう。

*1:App Transport Security and IP addresses in iOS9 - Stack Overflow

【1コマンドでOK】MySQLユーザーに贈る、スロークエリ解析の始め方

こんにちは！

CTOの島田(@tatsushim)です。前回の私の記事ではインフラ構成について触れました。
インフラを構築したらその運用が必要になりますね。今回は社内で行っているDBのスロークエリ解析について紹介したいと思います。

時間がない人向けに要点を3つにまとめると

• ママリでは定期的にクエリの見直し時間をとっている
• その理由は、レスポンスタイムがユーザーの滞在時間に大きく影響するため
• pt-query-digestを使うとカジュアルにクエリログを解析できるから初心者にもオススメ

という感じです。それぞれについて解説していきます。

定期的にクエリの見直しをする

現在ママリでは、定期的にクエリの見直しをする時間を開発スケジュールに入れています。
それは、レスポンスタイムがユーザーの滞在時間に大きく影響するためです。
ORマッパーでコードを書いていると気づかないうちにスロークエリを発行してしまいがちなので、 定期的に対策を行うことで問題を未然に防いだり、コードを書く際にも発行クエリへの意識が向くようになりました。

スロークエリを解析してみる

元々MySQLにはスロークエリの閾値を決めて吐き出す機能がありますが、
どのクエリから対策をすれば良いかの取捨選択を行う際に、そのログを目grepするのは辛いので社内ではpt-query-digestを利用しています。

pt-query-digestとは

mysqlのslow queryのログ等を集計し、改善が必要なクエリを上位に並べてくれるツールです。

pt-query-digestで解析する

インストール

• pt-query-digestコマンドを使うために、percona-toolkitをインストールする
• mac環境でbrewが入ってれば、コマンドは以下のみ

brew install percona-toolkit

実行する

• 以下コマンドで集計結果が出ます*1
• pt-query-digestコマンドの引数にはスロークエリのログ(ここではmysql-slowquery.log)を渡します。

pt-query-digest mysql-slowquery.log

結果を見てみる

• 結果には改善が必要なクエリが上位に出力されます。なので基本は上から潰していきます。
• 頻度や実行時間を確認することができます。以下が1つの具体的な例です。*2

Attribute    pct   total     min     max     avg     95%  stddev  median
============ === ======= ======= ======= ======= ======= ======= =======
Count         19      44
Exec time     25     75s   514ms      3s      2s      3s   956ms      2s
Lock time      1     7ms   128us   263us   155us   214us    37us   131us
Rows sent     85   2.77M  20.33k 105.50k  64.42k 101.89k  38.80k  92.42k
Rows examine  26  36.57M 243.30k   1.40M 851.03k   1.39M 543.75k   1.03M
Query size     1  72.24k   1.64k   1.64k   1.64k   1.61k       0   1.61k
String:
Databases    foo
Hosts        10.1.0.193 (8/18%), 10.1.3.127 (6/13%)... 
Users        bar
Query_time distribution ← クエリの実行時間の分布
  1us
 10us
100us
  1ms
 10ms
100ms  ############################################
   1s  ################################################################
 10s+

• このサンプルの場合、1sを超えることが多いクエリになっていますね。ここを改善すれば大きな改善になると思われます。

おわりに

いかがでしたでしょうか？ インストールから実行まで2コマンドでできるので、カジュアルにトライしてみると今まで見落としていたスロークエリが見えるかもしれません。
弊社ではスロークエリを減らし、レスポンスタイムが改善されたグラフを見て一緒に(･∀･)ﾆﾔﾆﾔしたい方を募集中です。

参考サイト

pt-query-digest

*1:--typeを指定することで、PostgreSQLのログ等にも対応が可能です。詳しくは参考サイトをご覧ください。

*2:中身はサンプルです。実際の解析結果ではありません

本当に使える！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