組織の"わからない"に対する不快感 - Konifar's ZATSU
組織の中で何らかの歪みを感じる時、その根っこにはある人が関係する物事について「わからない」「知らない」という感覚があることが多い。 例えば「なんでこんな非論理的な意思決定するのか。アホじゃないのか」と感じた時、本当にアホなこともあるかもしれないが、判断材料となる情報が正しく伝わっていなくてそう感じるだけということも多い。1対1で色々聞いていくと「なるほど、たしかにそれならそうなりますね」と納得できるのに、情報が欠落しているだけで不和を生むのだ。 情報だけではなく、人格も同じである。仲のいい人から言われる冗談は笑ってやりとりできても、よく知らない人から同じことを言われると嫌な気持ちになることもある。 組織において、こういった「わからない」が積み重なると雰囲気が悪くなっていく。「あのチームは」「あの人は」といった形でわからないものを自分とは違うものとして表現して、一体感がなくなるのだ。なんだか
プロダクト開発における納得感 - Konifar's ZATSU
これを読んだ。 medium.com とてもよかった。特にココ。 エンジニア出身ならわかると思いますが、企画はもちろんデザインナーエンジニアも、「なぜつくるのか」「今後どうするのか」ということはとても関心のあることで、そこの納得感はチームのパフォーマンスに直結するといっても過言でないです。 わかる。自分も納得した上で作りたい。納得感なくても素早く作ればええやんと思われるかもしれないが、ふとした時につらくなるし何か起きても提案する気も起きなくなる。特に小さい組織だと納得感重要。 自分でもちょっとしつこいなと思うくらい納得できるまで質問することがある。「この機能なんで最初のリリースに入れるんでしたっけ？」とか「これをつける目的は○○で合ってますか？」とか。相手を信用していないわけではなくて、納得して取り組みたいので気になったところを質問するのだ。聞き方をもっと工夫すればよかったと後で反省するこ
納得感のある決定事項の共有方法 - Konifar's ZATSU
意思決定の場にいない人に対して決定事項を共有する際、いくつか気をつけておくといいなぁと考えていたことを雑にまとめておきたい。 決定する前から進捗をちょっとずつ共有しておく 決定前の話なので後の祭りかもしれないが、いきなり結果をドーンだと相手を戸惑わせることがあるので事前に議事録を共有したり中間で説明する機会を作ったりするとよい 背景と前提条件を伝える なぜやるのかわからないまま結果だけ共有すると納得してもらいにくい。決定する上での前提条件を知らないと余計な反発をうむこともあるので注意が必要。それまでずっと考えてきた当事者は気づきにくいが、びっくりするくらい前提知識が違うことがある。相手は何も知らないものとして、イチから説明した方がよい 決定までの経緯を伝える 結論より経緯の伝え方が重要。どのような議論があってそんな決定になったか、完結に伝えましょう 捨ててきた選択肢も伝える 結果に至るまで
Androidの設計と取捨選択 - Konifar's ZATSU
楽に開発するためにAndroid全体の設計をしたいという思いは、わりとどの開発者も持っている気持ちだと思う。 設計というのは昔から色々揉まれてきて、今はMVPだMVVMだ、DDDだと盛り上がっている。 そもそも、Androidというフレームワークに限定された環境で、わりとよくある実装が多い中で、未だにこれだけたくさんの人が困っているという状態がおかしい。おかしすぎる。そろそろAndroidでこういうの作りたいならこう作るでしょ、みたいなベストプラクティスが確立しているべきじゃないのかという気がする。 あくまで個人的にはだけれども、DataBindingが主流になるのであれば双方向バインディングを使ったMVVMが一番しっくり来る。ただ、MVVMだとViewModelが太ってきてどうすんのみたいなことになるかもしれない。また、通信やキャッシュ部分は別のクラスにわけようとかそういう指針はどちらに
無駄な議論を減らすために使ってる言葉 - Konifar's ZATSU
雑にまとめるので何かあったら直接言ってほしい。⇒ @konifar チームで仕事をしていると、なんかあんまり意味のないことで議論している事態に陥ることがある。こういうのは議論の中心にいるとわかりにくいが、少し引いて眺めてみると「それそんなに重要なんだっけ？俺たちはこんなに時間使って何を決めようとしてるんだっけ？」という状態になってることも多い。 例えばAとBどっちがいいですかね？という意見の時、正直どちらでもいいと皆が思ってるのにAとBのそれぞれのいいところや懸念点なんかを皆で話しこんでしまっているみたいな。こういう時に難しいのは、単に「それどっちでもよくないですか？」みたいな言い方をすると場が凍って空気が悪くなるという点である。もちろんそういう本質的なことを言ってくれる人はありがたい存在なんだけど、言うタイミングが少し遅くなると「俺たちはなぜこんな無駄な時間を…」みたいな感じになることが
Androidでよくあるめんどくささ - Konifar's ZATSU
最近Androidを楽に開発するためにはどういうクラス構造にすればいいかを考えている。 巷にはMVP、MVVM、MVC、FLUXなど様々な設計が溢れているが、サンプルコードを見てもなかなかイメージがつきにくい。理由はサンプルが簡単すぎるからだ。シンプルなTODOアプリではメリットよりコード量の増加や見通しの悪さといったデメリットの方が目についてしまい、どうしても『なぜ』その設計や構造が必要なのかを理解しにくい。理解できても1週間後には忘れている。 Android開発においてなぜ設計が議論されるかと立ち返ってみると、考えることを少しでも減らしたいからだと言える。わかりやすいところで言えば、複雑なライフサイクル、画面回転を考慮したデータのロードにエラーハンドリング、その状態に応じた画面表示あたり。Androidの開発をする上で、考慮しなければいけない事象はバージョンアップのたびに増しており、そ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
