Kikuchy's Second Memory

技術のこととか、技術以外のこととか、思ったことを書き留めています。

モジュール設計のGood UI/ Bad UI

Poem

意図しない誤操作を誘発したり、意図する操作を実行することが困難だったりするUIのことを、私はBad UIと呼んだりしています。

一度プロダクトとしてBad UIが出来上がって、出荷もされてしまうと、使う側はプロダクトのUIを変えることができないので、どうにか利便性を向上させようと工夫をこらします。

で、ここがBad UIのBadたる所以ですが、利便性を上げようとしても、どうも頓珍漢な方向に人間を導くのです。
時々Twitterなどで見かける、説明書きのシールが所狭しと貼られたセブンカフェのコーヒーメーカーとかが顕著な例だと思います。


http://twicolle.com/wp-content/uploads/2015/01/B8f9m6aCAAAnInF.jpg
引用元: twicolle.com


どうも人というのは、安易に言葉による説明を行いがちな気がします。
セブンカフェの例であれば、言葉で全てを表示しようとするから、上記写真のように愉快な悲惨なことになるのではないでしょうか。

ではBad UIの反対のGood UIはどんなものかと言いますと、私個人としてはレゴブロックが一番よいUIであると思っています。

http://s3-ap-northeast-1.amazonaws.com/topicks/article_thumb/21181_original.jpg
引用元: http://topicks.jp/21181

いかにも組み合わさりそうな、凸部分に凹部分があります。
それらをを押し当てれば、想像通り、二つのブロックがくっつく。
そこに言葉はいらない訳です。見るか触るかすれば機能と使いかたを想像できます。
説明不要＆期待通り。それがGood UIだと考えています。



さて、プログラミングについても同じことが言えるのではないでしょうか。

ある働きをするクラスやメソッドの入力値にかかる制約を、「ドキュメントコメントに書いているから」とそれで満足していませんか？

// Bad API


/**
 * 日時から曜日を算出します。
 *
 * @param year     年。正の整数
 * @param month 月。0-11の値、1月は0、12月は11
 * @param day      日。1以上31以下の整数
 */
public String nameOfDayOfWeekFromDate(int year, int month, int day) {
    ...
}

/**
 * 曜日が休日かどうか判断します。
 *
 * @param dayOfWeek 曜日名。"mon", "tue" などの省略形
 */
public boolean isHoliday(String dayOfWeek) {
    ...
}

...

// 書いた人以外の人が読んだらどう思うでしょうか。
// 引数に数値ならなんでも入っちゃうけど大丈夫？
// 10月なんだろうけれど、1を引いている意図は？
// 戻り値は一体どんな形式？
String dow = nameOfDayOfWeekFromDate(2016, 10 - 1, 20);

// 引数には曜日入れるっぽいけれど、どんな文字列入れていいの？
if (isHoliday(dow)) {
    ...
}


あるいは、レゴブロックのように「組み合わさるからOK」というインターフェースにはできないでしょうか。

// Good API

/**
 * 曜日を表現します。
 */
public enum DayOfWeek {
    MONDAY,
    TUESDAY,
    ...
}

/**
 * 日時から曜日を得ます。
 *
 * @param date 日付
 */
public DayOfWeek dayOfWeekFromDate(Date date){
    ...
}

/**
 * 曜日が休日かどうか判断します。
 *
 * @param dayOfWeek 曜日
 */
public boolean isHoliday(DayOfWeek dayOfWeek) {
    ...
}

// 引数はDateをとる…日付が必要なんだな。考えることが少なくて良い。
// 戻り値は曜日を表すわけだな。表現形式とか気にしなくていい。
DayOfWeek dow = dayOfWeekFromDate(new Date());

// DayOfWeekオブジェクトしかはいらないから、これを入れよう。おっ、ちゃんと動くぞ！
if (isHoliday(dow)) {
    ...
}

レゴブロックの凹凸に相当するもの。

型です。

intやStringなど、汎用的すぎる型で必要なデータを取りそろえようと思ったら、制約条件をコメントに書くしかない、使う人に読んで理解して記憶して気をつけておいてもらわないといけない。
すなわち、使う側の人間に認知的負荷をかけなければいけない、ということになります。

そこで、もう少し表現を特殊化した型を用意してはいかがでしょう？
「この引数にこのメソッドの戻り値が当てはまるから入れて見る」という、ほとんど考えなくてもできるような作業でも、その結果として適切に動く可能性を飛躍的に向上することができるのです。
しかもチェックするのはコンパイラ。わざわざ人の力を借りる必要はありません。

全てが型でどうにかなるわけではないですが、それでも使える範囲で使っていきたいものです。

最近ではKotlinやSwiftが型でnullableであることを表現できる（Optinal型）ようになっているので、null値を許容するのかしないのか、安全なのかそうでないのか、これも是非とも型で表現したいですね。してくださいマジで。

Androidオールスターズ２で発表してきました

Poem Android

硬めのお話は会社ブログで書いた通りです。
↓ よんでね

developer.diverse-inc.com


が、ブログの趣旨から外れるから会社ブログに書けなかったけれど誰かに伝えたいよもやま話があるので、つれづれと書いておきます。
自分が忘れないように。

続きを読む

いつの間にか今年が８ヶ月分終わっていたのでまとめる

Poem

技術的Tipsはqiitaに書く時代になったので、ブログの更新がすっかり抜け落ちておりました。

今年が始まってからいつの間にか半年以上経ってしまっていたので、なにをしていたのか振り返りたいと思います。
主に自分のため。

1月〜4月

昨年からYYC Androidアプリのリニューアルをしていました。
とにかく勉強と開発しかしてなかったです。

あと、年の初めにこんな目標を立てました。

が、どちらもほとんど手をつけておりません。
機械学習はTensorFlowを触ったくらい。DTMはMacにGaragebandを入れたくらい。
何もしていないとも言う。

5月〜6月

有難いことに勉強会に出る機会をいただいて、何度か発表させていただくなどしました。
わざわざ聞きに来てくださった方に何か新しいものを持ち帰ってもらおう、と考えられるようになりました。


qiita.com


あと、趣味と実益を兼ねる形で、仕事で使うライブラリを個人で開発してたりしました。
スターをいただけて嬉しかったです。

github.com


仕事ではひたすらRxJavaいじってたり、Kotlinいじってたり、Jenkinsおじさんになっていたりしました。


あ、あとErgoDox買いました。

タッチタイピングできないくせに無刻印を買ってしまったので、仕事の作業効率がガタ落ちしました。
今は家に持って帰って、時々練習しています。
しかし確かにこれで仕事してた間は肩が凝らなかったです。


7月〜8月

Androidオールスターズで発表させていただきました。
こんなにも発表資料がなかなか出来上がらなくて頭を抱えたのは、大学院の研究発表のとき以来かもしれません。


仕事の方ではiOSの開発案件に携わったり（私が直接コードを書いている訳ではないのですが）、Android開発以外のやることが増えてきました。
多少Swiftの知識もついてきた気がします。

これから

個人のサイドプロジェクトで作りたいものがいろいろあるので、まずは早く帰ることを目指します。
勉強したい、さわりたいものは以下。

  • React.js
  • TensorFlow
  • SpringBoot
  • Scala

あと、技術ネタではないものをブログに書きつけて、とにかくアウトプットする習慣をつけたいと思います。

職業人としてのエンジニアの3類型

Poem

ポエムです。

知人から「人は金では動かない（ので人件費をどう使ったらいいのか悩んでいる）」という話を聞きました。
が、金で動くことももちろんあり得る訳です。
そもそも人間は何で動くかといえば、感情を動かされるもので動くのではないかと私は思っています。

そう仮定した上で、職業人として、社会でビジネスをしているエンジニアの感情を動かすものはなんだろうと考えたところ、
エンジニアという仕事をしている人には、主に3つの感情を動かすもののパターンがあるんじゃないか、と思ったのでした。

Engineering Apprentice


ゴール実現型

「海賊王に、俺はなる！」的な人。
人生を賭して実現することが定まっており、エンジニアリングはその手段、という人。
仕事をする主目的は、人生の目標実現。
感情を動かすものは、自分の理想に共感するものや人。

会社の事業内容にとてもこだわるか、自分で事業を立ち上げていたりする。
技術に明るい人もいれば、そうでない人もいる印象。


職人型

技術を極めることに楽しみを見出したり、技術力を認めてくれることに嬉しさを感じる人。
仕事をする主目的は、技術の勉強をすることか、技術力を発揮すること。
感情を動かすものは、好奇心や承認欲求。

自分の勉強になるか、自分の腕を振るえればなんでもいいので、事業内容などはさほど気にしないし、正直どうでもいいこともある。
勉強は欠かさないので、技術に明るい人が多い印象。
エンジニアらしいエンジニア。CTO業している人やマサカリストが多そうな気がする。

生活のため型

お金を稼ぎたい人。
仕事をする主目的は、生活や遊びの資金のため。
感情を動かすものは、報酬や費用対効果（労働での疲労に対してどれくらい稼げるか）。

たまたま人よりエンジニアリングができてお金を稼げるからエンジニアしている。
仕事は楽であることに越したことはない。
勉強する意欲は高くないので、技術に明るい人は少ない印象。


誰がどの型、ということはなく、誰しもどの要素も持っていて、それなりの割合でまじりあっていると思います。
が、その人が持っている一番強い要素がわかれば、だいたい「どんな人」という印象は外さないのでは。

例えばあるエンジニアを見つけて、この人を雇いたいと思ったとして、パターン別に以下のアプローチをすれば、雇える可能性が高くなるかもしれません。

  • ゴール実現型 -> 事業のビジョンを語って共感を得る
  • 職人型 -> 事業の中で勉強の機会があるスキルセットを提示して興味を引く、その人のスキルセットが欲しいことを説く
  • 生活のため型 -> 短い勤務時間、高い報酬を提示する

会社の人間関係をエンジニアリングする『Team Geek』

Books

会社で上司さんに勧められたので読んでみたら面白い本でした。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか


どんな本か

ギークが気にしない（意図的に気にしたがらない）ことがらとその対応策を、ギーク向けに解説した本です。

「ソース中にコメントを残す意味」などテクニカルに近い話題も書かれていましたが、主に解説されているのは人間関係のアドバイスでした。

コンピューターのエンジニアリングよりはるかに難しい人間関係…
それを「避けて通れない課題」とした上で、ギークのような精神構造を持った人間がどうすれば課題に対処できるのか、を論じています（そしてこれこそが、この本のコアバリューではないかと感じています）。


一般的なオライリーの技術書、といった感じで（読みやすいかどうかはともかく）読みなれた読み味ですので、エンジニアの方ならあまり時間をかけずに読み終えることができると思います。

学ぶところは多かったのですが、特に記憶に残った以下の三つについて、詳しく書かせてください。

続きを読む