こんにちは、開発部の永井です。
ご存知の方も多いかと思いますが今回は「Googleのデザイン原則」を読んでの感想です。

今から4年前の2008年のポストから Google の User Experience Team でデザインに関する10の定義を作成。

http://googleblog.blogspot.jp/2008/04/what-makes-design-googley.html

1. Useful: focus on people - their lives, their work, their dreams.
2. Fast: every millisecond counts.
3. Simple: simplicity is powerful.
4. Engaging: engage beginners and attract experts.
5. Innovative: dare to be innovative.
6. Universal: design for the world.
7. Profitable: plan for today's and tomorrow's business.
8. Beautiful: delight the eye without distracting the mind.
9. Trustworthy: be worthy of people's trust.
10. Personable: add a human touch.

1. 使える: 人々の生活、仕事、夢にフォーカスする
2. 早い: ミリ秒でも早くする
3. シンプル: 簡略化することの重要性
4. 魅力的: 初心者にも上級者も引きつける何かをつくる
5. 先進的: 新しいものを生み出すことに意欲的になる
6. ユニバーサル: 世界のためのデザイン
7. 有益: 今日、明日のビジネスのことについて考える
8. 美しい: 心を乱さず目にやさしいものを
9. 信頼性: 人々の信頼を勝ち取れるものになる
10. 人柄: 何か人間らしさを加える

デザイン原則では上のガイドラインに対するもう少し詳細な解説がされています。
http://www.google.com/about/corporate/company/ux.html

このページはGoogleの会社情報の理念の一つに置かれています。
利用者にとってはGoogleのサービスがGoogleであり、ここで表現されていることがGoogleらしさなんですね。
関連記事として紹介されていた次のページも良かったのでリンクを。

この10の原則が出来る過程で重要とされた「Googleが掲げる10の事実」
http://www.google.co.jp/intl/ja/about/corporate/company/tenthings.html


改めましてGoogleのデザイン原則を読んで考えたこと。

原則ひとつひとつ気づきがあり興味深いのですが、私の気づきとして最も大きかったのは原則そのものではなく次の一文です。

「Google ユーザー エクスペリエンス チームは、この 10 原則の間の最適なバランスを追い求めて絶え間ない努力を続けています。」

"最適なバランスを求める" ここに興味を惹かれ考えさせられました。

例えば、何かを実現するために何かを犠牲にすることはあります。
例えば、サービスの内容や世の中の流れによっては力を入れるべき事項が変わってくることはあります。

この中で成される判断(デザインに関する判断)において、関係者が理解できる共通の複数の軸を持っていること。

アジャイル開発で使うトレードオフスライダーを連想しました。
原則ひとつひとつの意味も大きいですが、「最適なバランスを求める」これもものを作る上での強力な武器だと感じました。

三三でデザインの原則的なものを作ったらつくるものや開発そのものはどんな風に変わるのか考えみたり。

これといってネタがないので卓球の話をしようとしたら最近卓球もしていなかった kuma ですみなさんこんばんは。
GW は楽しめましたか？

今日は社内の技術者支援制度の一つを紹介したいと思います。

■技術書が買えるよ！

社内には geek seek という技術書購入補助制度があります(厳密には勉強会にも補助が出るのですが省略)。

仕事に必要なものは申請すれば買えますが、いつも仕事に直結した本ばかり買うわけでもないですしね。
むしろそれ以外の方が多かったりします。

一ヶ月あたりの限度額は存在しますが、技術書は総じて高価なものばかりですのでこれは本当に助かります。

え、技術書は全部会社が買ってくれるって？それは羨ましい。
それはそれで一つの理想ではありますが、買った本は会社の物。
技術書大好きエンジニアには少し寂しいですね。
エンジニアであれば、一度はダンコーガイ氏の様に壁一面を埋め尽くす本に囲まれたいもの。

geek seek ではそれが可能です。
あくまでも給与補助という扱いなので(多分)、この制度で買った本は自分のものになります。
読みたい技術書なんていくらでも出てくる訳で、amazon のウィッシュリストが技術書
で埋まってしまったあなたは是非一度弊社に来てみませんか？
買いたいだけ買ったら後は(ry

最近はプログラミング ASP.NET 4という本を買いました。
まだ読んでる最中ですが良い本ですね。ASP.NET 開発者は必読かと。
しかお値段9450円。本当に助かります。

しかしマイクロソフト公式解説書はどんどん分厚くなりますね。


写真ではわかりませんが横幅もかなりあります。
これは良い枕になりそうです。

こんにちは。次世代アプリグループのyokotaです。

今回は、先週の土曜日に弊社で開催された、第4回CVアップ実践会（スマフォアプリのDL･登録率アップ）のレポートです。


当日はこんな感じでやっておりました。


初の社内開催の外部の参加者も招いた勉強会。よその勉強会に行くと、たまに飲み物を置いてくださっているところもありますが、弊社の場合は飲み物に加えてなぜかお菓子が置いてありました。新しいｗ

■CVアップ実践会とは？

コンバージョン・アップ研究会さんが主催されているイベントで、どちらかといえば、マーケティングなどを専門とされている方々が集まるもののようですね。
今回はスマフォのコンバージョンアップというお題で、最近弊社でリリースされたばかりのEightのユーザビリティテストをやってみようということになりました。

UXは最近弊社内でも話題になりつつあるテーマでもあり、その実践手法をグループワークで体験できるとのことで参加させてもらった次第です。

■内容

内容は、ユーザビリティテストを行うグループワークがメインです。


3〜4人を1グループとして、実際に使っている姿を観察するフェーズと、質問をするフェーズを何回か繰り返します。
ここからここまでやってみてください、と細かくタスクが切られていました。


観察中は配られた用紙にがしがしと書きこんでいき、そこで得られた気づきに対して質問をしていきます。
最後にこれらの結果を受けて、今後どう改善したらいいかをグループごとに検討し、提案する、という流れでした。

ちなみに、優秀な提案をしたグループには、商品としてこんなものが授与されました。

どーん

そのほかにも、最近の事例報告なんかもトピックとして用意されていて、普段参加するような開発系の勉強会とはちょっと違う方向でのお話として大変興味深かったです。

■まとめ：

そんなこんなで、この後二次会、三次会まで続いたらしい勉強会でしたが、僕の気づきをまとめて締めたいと思います。

暗黙の前提、固定観念に気づいた

弊社の場合、新規アプリ開発というよりは一つのアプリに新しい機能を充実させていくことが中心なので、長年いればいるほど固定観念や不文律のようなものが染み付いてしまいます。これはアプリの仕様に圧倒的な知識を持てる一方で、おかしなことに対して慣れが発生し、鈍感になるというデメリットも伴います。もちろん、そうならないよう、新たに入社された方には機能面での違和感など上げてもらうことで、固定観念化を防ぐ努力はしていますが、それでも鈍くなっている部分をおかしいと再確認できたり、ユーザからしたらそりゃそうだわ、と思わされることがワークショップ中も何度もあり、非常に新鮮な気持ちになりました。

問題設定大事、超大事。

今回のテストのきっかけとして挙がっているEightは、リリース直後わりとメディアにも取り上げてもらって、さらにその後も何度か露出はあったはずなのに、どうして使ってる人が増えるカーブが緩いのだろう、というところから始まりました。こういう問題設定ができないことには、適切なテストを始めることができません。ただ単純にやってみよう、だと得られる気づきはぐっと少なくなってしまうように見えました。まずは、問題設定することが大事ですね。

まずはログより始めよ

問題設定するには、何はなくともログの充実が必要だと感じました。何が課題かを発見するのもログを元にしないと始まらないし、発見した問題が解決されたか測るのもまたログです。自分が担当しているサービス・機能を振り返って、こういうところはまだまだ甘いかなーと思いました。

とはいえ、ログもすべてではない

ユーザビリティテストから得られる気づきは、想像するより断然多かったです。
どのボタンが押されたかなんかはログでも取れますが、そのログが押されるまでのドラマは、その場に居合わせなければ目にすることはありません。たとえば、入力フォームを見て、長さがどのくらいあるのかスクロールしてみて長いとやめてしまうなんて動き方は、ログでは取れません。そもそもボタンを押す前に閉じてしまっているので、どこにも現れないまま気づくことのない情報です。それが目の当たりにできるのは大きいなと思いました。

後半は文字だらけになってしまいましたが、以上、つらつらと思ったことを書かせていただきました。
講師の方々、参加者の方々、そして準備してくださった弊社のメンバー、みなさまありがとうございました＆お疲れさまでした！

こんにちは。
三三開発部アーキテクチャ・インフラグループの藤倉です。

私の肩書きはアーキテクチャ・インフラグループのリーダーということになっていて、立ち位置としてはアーキテクト的なところです。開発業務としては、基本的にはモデリングやフレームワーク、ミドルウェア関連、DB、インフラ辺りまでを主に担当していますが、場合によってはアプリケーションの開発まで手を出します。
今回はそんな私の最近の業務を少しだけご紹介します。

■ 3 月某日：インフラエンジニア双六をやる

我が三三開発部では毎夕読書会を行なっています（先日レガシーコード改善ガイドを読了しました）が、木曜日だけは勉強会と称して各個人が技術ネタを持ち寄って共有しています。更に月に一度は勉強会の後にピザ会という時間を設けています。このピザ会のネタは何でもよいのですが、ある時は勉強会の延長戦で議論を継続したり、ある時は自分たちの設計に関する課題を真面目に話しあったりしています。
先日のピザ会では一部で話題沸騰中の「インフラエンジニア双六」を開発部メンバが入手したということでみんなでやりました。



まずは各メンバで手分けをしてルールを理解したり駒を作ったり、サイコロを組み立てたりしました。そうこうしているうちに注文したピザも到着して双六開始です。私は自分が糊付して綺麗に仕上がったキャラクタの駒を使いたかったのですがじゃんけんに負けて断念。同僚が組み立てた少し汚れてしまったものを使いました。



私がインフラを担当し始めたのは当社に転職してきてからなので、インフラエンジニアと自称するにはあまりにおこがましいのですが、それでも各マスに書かれた内容には一喜一憂します。途中で購入した i○ドライブのお陰でデスマゾーンも無難に乗り切り暫定一位になるも、最後の最後で逆転されました。



デフォルトルールではかなり難易度が低く設定されているので、次回以降は三三ローカルルールで難易度を上げてみたいと思いました（アイテムの買い占めとか辞めていただきたい）。

■ 3 月 6 日：起業家甲子園に参加する

当社が協賛している起業家甲子園に参加してきました。
起業家甲子園「三三賞」受賞チームにインターンシップ参加権を提供


プロジェクトのメンターもされていた勝屋さん（勝屋久事務所代表／プロフェッショナルコネクター）作
いつ見ても独特の世界観が魅力的です

元々は開発部が管轄するイベントではありませんが、技術的な見地から審査を手伝って欲しいと言われての参加です。
大変高い志をもって事業に興味を持つ学生の方々のプロジェクトにはそれぞれ唸らせられるところがありとても迷いましたが、三三としては舞鶴工業高等専門学校のチーム CrowdFlip を選びました。



我々の審査基準としては、ビジネスアイデアに重きを置くとよりも、難しい課題をいかに技術を使って解決しているかという観点を大切にした結果です。CrowFlip はすでに動作するモノがあり、技術で人々を幸せにしたいという思いが伝わってきました。



また、最後の懇親会では軽食をいただきながら会場に来ていた多くの方々とも交流することができ、いろいろな刺激をもらうことができました。

■ 毎日：性能向上に悩む

冒頭でも紹介した通り、私も必要となればアプリケーションを書きます。昨年から開発を担当していたあるアプリケーションで当初計画していた性能が出せずに先日まで悩んでいました。アプリケーション単体で動作させているときには特に問題はなかったものの、本番環境ではそれ以外の多くのプログラムやサービスが稼働しています。それらの実行と合わせると急激に DB への負荷が上がってしまうという現象がありました。

落ち着いて考えたらなんて事はなかったのですが、その他諸々のアプリケーションやサービスで使われるリソースと私が開発したサービスで使うリソースを単純に足し算して予想してしまっていたのが誤りでした。それぞれの要求がお互いに干渉し合い、それぞれのリクエストを処理する時間が微妙に増えたため、結果として単位時間辺りの到着クエリ数が処理可能クエリ数を上回ってしまいました。最近は Ajax で細かいリクエストを大量に送ることが多いので、この辺りの計算はきちんとしておく必要がありますね。

同時ユーザ数 × 単位時間辺りの発行リクエスト数 × クエリ実行時間 ／ コア数

ものすごく単純化しましたが、この計算式で得られる値サーバが単位時間辺りに処理するべき計算時間です。この時間が単位時間を超えているようであればそもそもサービスとして成り立っていないのですが、もう一歩踏み込んでクエリ実行時間がどこまで延びると破綻するかを考える必要があります。

私の場合は、単体で動作させたときのクエリ実行時間は平均すると 200ms 程度だったのですが、他のサービスと影響しあうことでこの時間が 600ms を超えてくるとかなりリソースを圧迫され始め、その結果さらに実行に時間がかかるようになりました。1,000ms を超えたところから完全に破綻し、到着リクエストが処理可能リクエスト数を上回ります。その結果サーバの応答はどんどんひどくなるばかりです。

この程度まで定量的に見えていれば、後はその課題をどのアプローチで解決するかを考えれば良いわけで、サーバセットの追加を検討してもよいでしょうし、キャッシュの有効期限を伸ばすという方法でもよいかもしれません。今回はキャッシュで逃げることができたので追加のコストはかからずに事無きを得ました。

こんにちは、開発部でテスターをやってます @dany1468 です。
好きなレガシーコード改善パターンは仕様化テストです。

メールの誤送信って

怖いですよね、開発部だとそこまで外部の人とのやり取りって無いんですが、パートナーさんとかとやり取りし出すと、宛先増えたり、添付したり、ちょっと社内に転送したりって事が増えます。
弊社は、セキュリティ事故は特に致命的なので、メール誤送信防止の啓蒙活動も熱心にやってます。

とはいえ、

やはり開発者足るもの意識ばかりに頼るより、システムでカバーしたいところですよね。

そんな訳で、

非常に簡易なもので、かつ gmail のみではありますが、少しだけ誤送信防止に役立つツールを作りました。
特に gmail ってアドレス補完が効きすぎるせいで、アドレスが似てると間違えて送ってしまったりしがちです。

Gmail Address Checker

このツールは Google Chrome 拡張として動作します。

Gmail Address Checker 拡張ページ

設定としては、一つのドメインを設定できて、そのドメインがホワイトリストの働きをします。例えば以下のように弊社のドメインを入れると、それ以外は警告対象としてフォーカスを失った時に背景色を変えます。アクションやタイミングは迷いましたが、これぐらいでいいのかなと。

オプションページ

判定結果

一応背景色も変えられますが、これは同じ色に慣れてしまった時に気分を変えるためです。

作成のポイント

bitbucket に全てコードは公開してますので見ていただけると分かりますが、本当に拡張機能の基本的な仕組みしか使っていません。

https://bitbucket.org/dany1468/gmail_address_checker

gmail のページで実際に処理を実行する content scripts (gts.js)と設定を保存するオプションページ (options.html)があり、設定情報が保存されたローカルストレージの値を content scripts に渡すためだけのバックグラウンドページ (background.html)があるという構成です。バックグラウンドページも非常に簡素なつくりです。（この辺は説明省きますが、複雑な事はしてないです。）

肝心の警告判定ですが、gmail はアドレスの前に名前を出して表示する場合があるので、その部分がちょっと残念です。正規表現の今一さが露呈してる。。（その前に細かい不具合ありそうですが。）

後は非常に単純でメールアドレスをカンマでスプリットして、逐次判定してるだけですね。Chrome 拡張だと JavaScript の新しい機能が使えて楽ですね！

作ってみて

超暫定版を作ったのはちょっと前で、その時は社内の数名に使っていただいたりしたのですが、結果として会社としては有償のツールを導入する事でより根っこの部分で誤送信を防止しようとしています、結構助けられます。

今回作ったツールはそういう意味では、ホントにちょっとした気づきでしかないのですが、少しでも何かのお役に立てればいいですね。

また、Google Chrome Extensions はテスト用のツールとして社内用に作成したりもするのですが、HTML+CSS+JavaScript で作成できる手軽さは素晴らしいです。ドキュメントも豊富に揃っていますので、未経験の人も是非軽い気持ちで作ってみると良いと思います。

＃最後になりましたが、貴重な週末の時間にオプションページ作成を快く引き受けてくれた嫁に感謝します。