Konifar's ZATSU

私はのび太の味方じゃないわ、悪の敵よ

無駄な議論を減らすために使ってる言葉

雑にまとめるので何かあったら直接言ってほしい。⇒ @konifar

チームで仕事をしていると、なんかあんまり意味のないことで議論している事態に陥ることがある。こういうのは議論の中心にいるとわかりにくいが、少し引いて眺めてみると「それそんなに重要なんだっけ？俺たちはこんなに時間使って何を決めようとしてるんだっけ？」という状態になってることも多い。

例えばAとBどっちがいいですかね？という意見の時、正直どちらでもいいと皆が思ってるのにAとBのそれぞれのいいところや懸念点なんかを皆で話しこんでしまっているみたいな。こういう時に難しいのは、単に「それどっちでもよくないですか？」みたいな言い方をすると場が凍って空気が悪くなるという点である。もちろんそういう本質的なことを言ってくれる人はありがたい存在なんだけど、言うタイミングが少し遅くなると「俺たちはなぜこんな無駄な時間を…」みたいな感じになることがある。かと言って指摘しないと時間の無駄だしチーム全体としてもよくない。

大事なのは、なんかこの議論無駄じゃない？と思った時に柔らかく指摘する言葉の引き出しを持っておくことだと思う。自分がわりとよく使う言葉をまとめておこうと思う。

  • 「絶対にこっちがいいみたいなこだわりある人います？いなければとりあえずAでいいんじゃないですかね」
  • 「目的は◯◯ですよね？今話してることは目的からちょっと遠そうな気がするんで、次いきませんか？」
  • 「それぞれやってみたらどのくらいかかるんですか？1日くらいなら両方やっちゃえばいいんじゃないですか？」
  • 「正直やってみないとわからないのでやってみましょう」
  • 「すみません、問題はなんでしたっけ？」
  • 「どっちの結論になったとしても、やること変わらなくないですか？今すぐやっていくぞ」
  • 「自分は絶対こっちがいいです。強い反対意見のある人いますか？」
  • 「これ情報少なくて今決めにくそうなので、この会議では決定するために必要な情報は何かだけ認識合わせましょう」
  • 「これ今全員で話す必要ありますか？もしなければこのあと何人かで話した方がよさそう」
  • 「時間かからなそうだし、やってみて怒られたら戻せばいいんじゃないですか？」
  • 「2~3時間くらいでできると思うし、PullRequest出しとくんで動いてる物見ながら話しましょう」

小さなチームだととにかく行動した方がいいことも多い。実は議論する時間に作業したら終わるくらいのボリュームのこともある。もちろん組織の風土によって変わるだろうけど、無駄な議論は減らしていきたいというのは共通の問題意識だと思う。それぞれの雰囲気に合わせてやんわりと「俺たちが今話してることはみんなそんなに大事に思ってるのか？議論した結果行動が変わるのか？とにかく行動した方が早いんじゃないのか？」ということを指摘しあえれば最高の環境になるんじゃないかと思う。

ちなみにこれは個人の意見だけども、逆に凍りつきやすい言葉は「そもそも」で、言われた方はわりとイラッとすることが多い印象。使うときは代替案の提示が必須だと思う。

期待値のコントロール

どんな状況においても、期待値のコントロールができる人は強い。

期待値のコントロールと言うと、口でごまかしていい感じに丸く収めることでしょと思う人かもしれない。たしかにそういうやり方を取ることもあるが、本質は違う。自分の主張も相手の主張もある中で落としどころを決めなければいけない時に、お互いに納得できる方法を常に考えて相手に動いてもらうということだ。

ここで重要なのは、自分が変わることをいったんあえて考えずに相手を動かすことに頭を使うことだ。仕事ではよくあることだが、相手の期待に応えようとなんでもかんでも自分が解決しようとする人がいる。余裕があるうちはいくらでもやればいいが、自分のキャパを超え始める時にはやり方を変えなければいけない。すなわち、自分の立場を主張しつつも相手も満足させるということだ。ブチャラティのような辛さがあるが、期待値のコントロールを念頭におくといろいろと生きやすくなる。

仕事をしていて「なんであいつはこんなこともしてくれないんだよ」と思うことがあるかもしれない。しかし、それは相手からすると十分にやっている状態なのかもしれない。自分の期待値が相手に伝わっていないのだ。こうなるとお互いに不幸だ。すれ違いでイライラが募って、知らないうちに険悪になる。大人の険悪さというのは子どもの喧嘩よりタチが悪くて、腹の探り合い、本音と建前が入り混じる。これは一緒に仕事をする上では健全とは言えない。

仕事だけに限ったことではない。学校の先生、病院の医師、コンビニの店員すべてで、期待値の相違によるいざこざは発生する。

大人であれば、期待値はコントロールできるようにしたい。逆にそれができないとつらい。細かいところでいうと「あの人は17時に帰る。けど8時には会社にいる」みたいなキャラを定着させるというのもその1つだ。

期待値のコントロールが難しいのは、相手に譲歩してもらわなければいけないこともあるというところにある。伝え方、タイミング、それまでのコミュニケーションなど工夫しないといけないことも多い。「それは私の仕事じゃないです」みたいな言い方をしてしまうと相手は受け入れてくれない。素直に物をいうのは大事だけれど、言い方には注意を払う必要もある。チャットならエモーティコンを使ってやわらかく伝えるのも手だ。

逆にめんどくさいと思うかもしれないが、まぁトータルで見ると期待値コントロールのコストの方が低い。期待値のコントロールがうまくいっていないと感じたら、自分が期待していることと相手が期待していることを聞き出して素直にぶつけ合わせてみるのがいい。最初に「俺はあの時とかむかついてた。あなたも言い方むかついたら言ってくれ頼む」とか言うと、意外と打ち解けていい雰囲気になったりするのでオススメ。

Androidのプロダクトにguavaを入れたくない

雑に考えをまとめるので間違いがあったら教えてほしい。むしろguava入れたら最高だったけど？みたいな話があったら聞きたい。

guavaの何が嫌かといえば、一言で言えばその大きさである。便利そうなものがガッツリたっぷり入っている。まぁ実際便利だし、使いたいクラスもある。けどそれ以上にデメリットが大きいと感じてしまう。

デメリットの1つはアプリ自体のサイズの増加。メソッド数はproguardで削減できるとはいえ、ビルドの時間には影響するだろうなぁ嫌だなぁと感じてしまう。

もう1つはロックインの問題。guavaを導入したい理由はいろいろあると思うけれど、たぶんguavaのほんの一部の機能を使いたいだけってのがほとんどだと思う。自分は、それだけのためにguava入れて大丈夫？最初は軽い気持ちだったんです…みたいなことにならない？と不安に感じてしまう。

特にチームで開発する場合、guavaのような便利でマッチョなライブラリを入れてしまうと各人のコードにブレが生じがちだ。ある人はguava最高じゃんどんどん使うぞという思考で開発してくるかもしれないし、またある人はguavaはこの機能だけ使おうなみたいな認識でいるかもしれない。もちろんコード規約やチーム内の認識あわせで工夫できる部分ではあるけれど、意外と苦労する部分だったりする。そしてそういうブレのあるコードが一度マージされると、それを皮切りにしてどんどん統一感がなくなっていくこともある。

これはguavaに限った話ではなくて、ライブラリをどう選定するかという指針の話かもしれない。自分は何でもできるマッチョなライブラリは敬遠する傾向にある。用法用量を守って正しくお使いくださいという話ではあるのだけれど、経験上そういう指針を維持していくのはわりとコストがかかると感じている。便利なものを見つけたら喜んで使ってしまうのは人の常なのである。ライブラリは提示した課題をスマートに解決してるものがいい。余談だが、最近のButterKnifeはわりと太ってきたと感じることもある。

guava入れるなら、まずは何を解決したいのかを明確にしたい。そしてそれはguavaじゃないといけないのかをよく考えたい。正直、guavaじゃなくても自作できることが多いんじゃないかと思っているし、あるいはguavaの一部機能だけを切り出したライト版もいくつかあるので検討してもいいかもしれない。

余程の理由がない限り、guavaをプロダクトに導入したくない。

Google I/Oで発表されたConstraintLayoutで感じたこと

Google I/Oで発表されたConstraintLayoutはわりと衝撃だったので感じたことを雑にまとめておこうと思う。

ConstraintLayoutはより簡単にレイアウトを組むために登場した新しいViewGroupという理解である。詳細は、圧倒的当事者意識によって書かれた以下の記事にまとまっている。

qiita.com

tech.recruit-mp.co.jp

ConstraintLayoutは、UI Builderを使ってGUIで簡単にレイアウトを組むことができる。簡単に、というと少し語弊があるかもしれない。正確に言えば、「簡単にレイアウトを組むことができるようになるかもしれない」という可能性を秘めたレイアウト。今はまだツールも少しバギーらしいが、これからの進化に期待という感じ。

もしConstraintLayoutが進化していくとしたら、Viewの作り方が従来とはガラリと変わるのではないかと思っている。というのも、ConstraintLayoutのxmlのattributesを見てみると、これは人間の手で修正するものではないなと感じたからだ。~absoluteX、~absoluteYのようなやばそうな属性もあるし、位置関係を表すconstraintLeft~などの属性もRelativeLayoutよりも複雑な印象。

まず感じたのは、細かいところ修正したいときにxml修正するのしんどそうだなという不安だった。俺たちはいつまでxmlを書かなきゃいけないんだよと思う一方で、Viewを思った通りに作れるGUIインターフェースは信じきれていないのだ。これはswingのGUIを作るときにプレビューと実物がだいぶ違ったりと裏切られてきた経験によるところが大きい。Android StudioのUI Builderを信じて使ってみるべきなのかまだ判断がつかない。

ConstraintLayoutをUI Builderで作ることの売りとして、自動的にネストの少ないxmlを生成してくれるというパフォーマンス上のメリットが挙げられている。自分はこれがあんまりピンときていない。そもそもネストによるViewの描画速度はそんなに神経質にならなければいけないほど大きいものではないと思っているからだ。もちろん、RecyclerViewのアイテムなどの繰り返し箇所や、アニメーションが絡むところは意識する必要がある。しかし、I/Oの例に挙げられたようなViewでは気にしなくてもいいんじゃないの？というのが正直な感想である。

やはりConstraintLayoutの価値というのは、GUIで簡単にレイアウトを組むことができるようになるかもしれないというところにあると思う。今後ConstraintLayoutが主流になっていくことを考えて、UI Builderと仲良くなって何かあればフィードバックを送るのがいいかもしれない。

Viewの表示、非表示の切り替えや画面の回転など細かい部分を考えると、RelativeLayoutやLinearLayoutの方が楽なこともありそうだが、まずはConstraintLayout + UI Builderでできることを把握してデザイナーさんに共有することで、逆に無理をしないViewを作るように心がけるのもありかもなぁと思った。

あと個人的に気になったのは、ConstraintLayoutのattributesの名前が~Start、~Endではなく~Left、~Rightだったことだ。あれ…？RTLは…？と思ったが、これは何かしら仕組みが用意されていると信じたい。

以上！

Google I/O 2016 初日キャッチアップ所感

Google I/Oは現地には行かず日本で鬼のように寝て朝からざっとキャッチアップした。速報がたくさん出ていて圧倒的感謝というしかない。

いくつか感じたことを雑にメモしておこうと思う。

Firebase Cloud Messaging

GCMじゃなくてFirebaseでプッシュ通知を受け取れるというやつ。FacebookのParseを思い出したが、管理画面見てみたらほぼParseと同じだった。Parseといえば、GooglePlayの入っていない廉価端末や海賊版端末でもプッシュ通知を受け取ることができたところが最高だったが、Firebaseでも可能なんだろうか。海外だと水道は通ってないけどAndroid端末は持ってるみたいな人もいて、そういう人は1000円くらいで買える端末を使っていたりする。そういう端末にもプッシュ通知を届けられるのはわりとアツい。

Firebaseの他の進化

なんかFirebaseいろいろ進化してた。AnalyticsがついたりBugTrackingがついたり、Fabric要らなくなるのでは？と思ってしまった。個人的にはあまりに全部のせの仕組みは好きじゃないので、モジュールで分けてくれたりするとありがたい。Parseみたいに「もうみんな死ぬしかないじゃない！」ってなるのも嫌だし。とはいえ、I/Oのセッションを眺めてもFirebaseに力を入れている感じだし一度がっつり使ってみないとなと思った。

Instant apps

インストールしなくても検索結果からアプリが使えるという謎技術。どういう仕組みかはよくわかってないけど、バイナリを落として使うらしい。バイナリ落とすとなるとネットワークよわい環境だとどうなんだろうかと思った。どこかでアプリの実態があって、端末はシンクライアントとして動作するという方法よりはサクサク動きそうなのでいいのかもしれない。気になるのは、今までWeb版を作っていたところをInstant appsにした方がいいのかよくわからんというところ。まぁiOSも考えるとWeb版は作っといた方がいいのかもしれないが、Instant appsでアプリのインストール率を上げて継続率も高めるみたいなことを考えた場合、どう棲み分ければいいのか考えないといけない気がする。

あとInstant appsの登場で、ネイティブの立ち位置がよくわからなくなった。自分は今までWebの進化がすごすぎてこれはまたWeb回帰していくんだろうなぁとぼんやり考えていた。最近のGoogleのWebサービスや海外のECサービスなんかを触っているとわかるが、もうアプリとほとんど見分けがつかない。ブラウザさえあれば動作するWebでここまでできるならWebでええやんと思っていた。けどInstant appsでアプリをWeb側に持ってくるみたいなことになってきたので、これどうなんの？というのが正直な感想である。

Android Studio 2.2

なんかいろいろ速くなったらしい。Layout DesignerはStoryBoardみたいな感じなのかなと思ったけどまだよくわからない。自分は「考えるな、感じろ」みたいな感じでxmlだけでガーッと組むことが多くて、そのやり方に慣れてしまったのでなんともいえないところ。こういうのは、便利な機能が信頼できないと使わなくなっていく。Instant runもそうだった。しかし、使ってフィードバックしないとIDEも進化しないので、みんなで育てていこうな！みたいな心持ちでやっていきたい。

まとめをざっと見て感じた印象でしかないので、間違いもあるかもしれない。

ちなみにAndroid Nはニッキ飴がいいと思います。赤坂からは以上です。

設計とアプリの規模の話

設計はアプリの規模が大きくならないかぎりは変に意識する必要がないのでは？という意見についてはその通りだと思う。面倒なのは、アプリの規模とはなんなのか、大きな規模とはどのレベルなのかという認識が人によって認識が違うところで、そこを合わせないかぎり議論は食い違ってしまうことが多い。

例えばHello WorldのアプリでModelを意識する必要はない。Hello Worldの文字を自由に変えられるようにするアプリだとしても同様である。では、一覧と詳細だけのあるアプリではどうなのか？自分の考えでは、特に必要ではない。たしかにAndroid独特のめんどくささはあるが、1つの一覧、詳細の表示だけであれば、ゴリゴリ書いてもさして問題にならないからだ。むしろ逆にその方が開発のスピードは上がる。

DroidKaigiの公式アプリはどうか。あれは逆に面倒な設計はない方がいいと思っている。ガッツリと癖のある設計を入れると、初見で理解するハードルは上がるからだ。

書いていて思ったが、たぶん設計という言葉自体に対するイメージが人によって異なるのが問題なのかもしれない。自分のイメージはたぶんただのクラスやパッケージ構造の話にすぎない。アプリ開発において3回以上発生しそうな実装をどう書くべきかというルールを決めることで、実装時に余計なことを考えなくて済む。そうして実装のスピードを上げていく。どこにロジックを書くべきか、命名はどうするべきかといったことに頭を使うのはなるべく避けたい。

アプリ開発では、正直そこまで複雑なことをすることはない。複雑だと感じるとすれば、それはフレームワークの独特さに対する学習コストが高すぎるというだけだと思う。アプリの規模がサンプルアプリレベルの小ささであれば設計など意識しない方が早い。

規模というとエンジニアの人数を思い浮かべることもあると思うが、1人で開発していれば設計は要らないというのは違うと思う。あくまで自分の指針はアプリ開発独特のめんどくささを考えなくて済むためにはどうすればいいかという話なので、1人で開発していてもアプリが複雑なのであれば必要だ。そして大概の場合アプリは自分にとって複雑になる。

設計はアプリの規模が小さければ要らないとは言っても、規模や複雑さはほとんどの場合において閾値を超えてくるので最初から設計を意識しておいた方がいいと思う。

Androidでよくあるめんどくささ

最近Androidを楽に開発するためにはどういうクラス構造にすればいいかを考えている。

巷にはMVP、MVVM、MVC、FLUXなど様々な設計が溢れているが、サンプルコードを見てもなかなかイメージがつきにくい。理由はサンプルが簡単すぎるからだ。シンプルなTODOアプリではメリットよりコード量の増加や見通しの悪さといったデメリットの方が目についてしまい、どうしても『なぜ』その設計や構造が必要なのかを理解しにくい。理解できても1週間後には忘れている。

Android開発においてなぜ設計が議論されるかと立ち返ってみると、考えることを少しでも減らしたいからだと言える。わかりやすいところで言えば、複雑なライフサイクル、画面回転を考慮したデータのロードにエラーハンドリング、その状態に応じた画面表示あたり。Androidの開発をする上で、考慮しなければいけない事象はバージョンアップのたびに増しており、それをいちいち個々人で考えていては開発のスピードも品質も落ちてしまう。

設計は、それら多くの考えなければならないことを減らすためにある。指針を決めてそれに沿って開発することで、イニシャルコストは増えるがその後はあまり考えなくて済む。interfaceやパッケージスコープなどJavaの言語仕様で実装を強制することでミスを減らすこともできる。

逆に言えば、Android開発の現場において何が面倒くさいかを吐き出しておけば、その設計で何が楽になるのかがイメージしやすい。単純なTODOでは役不足。どんなケースがあるのか雑にメモしておこうと思う。

  1. 一覧のロード中に画面の向きが変更された時にそのままロードと表示させたい。
  2. 一覧のロード中に画面が閉じられた時にロードを中止したい。
  3. 一覧でいいねを押してからタップして詳細を開いた。
  4. 一覧でロードエラーが発生した時にリトライしたい。
  5. オフライン状態で一覧画面を開いた。
  6. 一覧のデータが0件の時は大きなレクタングル広告を表示、1件以上の時はフッタにバナー広告を表示したい。
  7. 一覧の上部に特集一覧を表示する時、2つのロードをいい感じにしたい。
  8. 一覧の2つ目と8つ目にネイティブ広告を表示したい。表示の速度も考慮してプリロードもしておきたい。
  9. メッセージ画面でメッセージを送信する時、リクエストが成功する前に画面に表示させたい。
  10. メッセージ画面でメッセージを送信失敗した時、リトライしたい。
  11. 低ネットワーク環境下では低画質の画像を表示したい。
  12. wi-fiにつないでいる場合のみ、プリロードして表示を高速化したい。

たぶんもっといっぱいあるけどこのへんで。