タグ

ブックマーク / konifar-zatsu.hatenadiary.jp (9)

  • ドキュメントが更新されない問題 - Konifar's ZATSU

    むかし、この国が深い森におおわれ、そこに太古からの神々がすんでいた頃から語り尽くされているドキュメントが更新されない問題について雑に書く。 実態が変わったのにドキュメントが更新されない問題はいつどの時代も絶えない。これにいちいち憤りを感じるのは不幸になるだけなので、何かしら対処を考えておかねばならない。パッと思いつくのは次のようなものだろうか。 使う 使わないから更新もされなくなる。定期的に使われるように設計して、そもそも使わない場合は消した方がいい いっそ参照回数が少ないドキュメントは自動でアーカイブしちゃうみたいな硬派なスタイルの方がいいのかも 詳細に書きすぎない 細かいところを書きすぎると保守できない。骨組みだけ大事にして、細かいところはフロー情報として分けて書くのがよい 管理者を置く ちゃんと更新されるようロールを作る。属人化しないようにロールを引き継ぐ設計も必要 個人的にはあんま

    ドキュメントが更新されない問題 - Konifar's ZATSU
  • 成果が出ていても変化がないと飽きる - Konifar's ZATSU

    幸せについて気出して考えていたら「組織の成果と幸福を高めるには信頼の文化が大事」という研究の話をGLOBISの動画で知ることになった。 発表者が言うには、コミュニケーションの中で信頼を生みやすい3つの質問があるとのこと。そのうちのひとつが「日々の仕事で学びや変化はありますか?」というもので、「人間は好成績を納めていても変化がないと飽きる」という言及があり、これはすごいわかるなーと思った。 成果を出しているとある程度は満たされていくが、それは必要条件であって十分ではない。成果を出しつつ、自分の経験やスキルの切り売りをしている感覚でこのままでいいのか悩んでいるという人も意外と多いと思う。成果が出ないと萎えてくるので成果を意識することは必要だが、同じくらい変化し続けることにも目を向けなければならない。 一方で、変化は疲れるから今のままでいいよという人もいると思う。そういう人はそのままで全く問題

    成果が出ていても変化がないと飽きる - Konifar's ZATSU
    Watson
    Watson 2021/09/06
  • 組織の透明性を高めるための情報を受け取る側のスタンス - Konifar's ZATSU

    組織の透明性を高めるためには発信側の工夫が不可欠だが、情報を受け取る側のスタンスも認識を揃えておいた方がよい。 自分の経験上、こういうスタンスでいるとよいんじゃないかという話をざっとまとめておく。 情報は常に100点ではないもの オープンになった情報は常に完璧な状態というわけではないという姿勢でいた方がよい たとえばSlackでシュッと投げ込まれたタスクや事業の方針に対して、背景がわからずモヤッとしたみたいな経験はあるかもしれない 複雑な話ではこういうことが起きがちで、わからないことがあると人は不安になる とはいえ、完璧を目指して情報が公開されるのが遅れたり公開されなくなったりするのはよくない 情報を公開する側は、実は結構緊張していたりする そのため、情報を受け取る立場としては、「情報は常に100点な状態ではなくむしろ100点に近づけていく部分も皆でやるんだ」くらいのスタンスでいた方がよい

    組織の透明性を高めるための情報を受け取る側のスタンス - Konifar's ZATSU
    Watson
    Watson 2021/09/06
  • 自分の勉強や開発をできなくなった - Konifar's ZATSU

    最近夜や休日に自分の勉強や開発をできなくなった。 夜や休日にそんなことせずに業務時間内でやるべきでしょという意見もあると思うが、自分の場合は以前は苦もなく自然とやれていた。それが今はできていない。 理由は明確で、自分が集中できていないからである。背景には育児家事の話はもちろんあるが、時間が取れていないわけではない。 息子は睡眠エリートで毎日2~3時間昼寝をするし夜20時半には寝ている。寝ている時間に何かをすればよいのだが、手が付かない。イメージとしては、1日のMPを使い果たしている感じ。こういう感覚は育児に関係なく経験していて、集中できなくなってしまう時期はあった。 なので「育児家事で時間が取れない」というのは正確ではなくて、「自分が集中できていない」というのが正しい気がする。これは自分の考えであって、家庭にもよるとは思う。家事育児の事情は当に家庭によって全然違う。子どもが生まれたことで

    自分の勉強や開発をできなくなった - Konifar's ZATSU
    Watson
    Watson 2021/08/16
  • Slackの内容を見落とさない工夫 - Konifar's ZATSU

    Slackに慣れてない人は、流れが速すぎてメンションされていても見落としてしまう...という悩みがあると聞いた。そこで、Slackの内容を見落とさないために工夫できることを雑にまとめておくことにする。適当に書いていくので、自分にマッチしそうだと思ったら使ってみるといいかもしれない。 あまり見てないチャネルから抜ける いつの間にか参加しているチャネルが増えがち。チャネルが増えると未読が増えて、次第に未読を気にしなくなってしまう。このチャネル見てないし見てなくても実は問題ないなと思ったらエイヤとLeaveしてみるとよい。自分は定期的に10個くらい抜けたりする。 Mute機能で未読を無視するという手もあるけど、個人的には無視するくらいなら見なくていいはずなので抜けた方がいいと思っている。 スターを使う いわゆるお気に入り的なやつ。 スターをつけておくと、右上のスターボタンから一覧で確認できる。

    Slackの内容を見落とさない工夫 - Konifar's ZATSU
    Watson
    Watson 2019/12/04
  • 物事を前に進めるためのTips - Konifar's ZATSU

    物事を前に進めるのが上手な人がいる。時に手を動かし、時に人を巻き込み、時にファシリテートし、まるでブルドーザーのように問題を解決していくのである。そういう人を何人か見てきて、物事を前に進めるための小さなTipsみたいなものがいっぱいあるなぁと感じているので雑にまとめておく。 何が解決すれば物事が早く前に進むかを考える 自分がリードしたり誰かに決めてくれとせっついたりする 誰が意思決定者かを把握する 人を集める時は直接声がけした方が確実か考える 誰に何をいつまでにお願いしたいかを明確に伝える 期日の認識を揃える。期日が決まってなければ決めてしまう チャットで返事が欲しい時は個人メンションする 期限が近づいてきたらリマインドする 伝え方を工夫する 相手が気になるであろう懸念点と解決策を先に自分で補足する 提案する時はいくつかの案を用意した上でこれがベストだという自分の意見を伝える どうしましょ

    物事を前に進めるためのTips - Konifar's ZATSU
  • プロダクト開発における納得感 - Konifar's ZATSU

    これを読んだ。 medium.com とてもよかった。特にココ。 エンジニア出身ならわかると思いますが、企画はもちろんデザインナーエンジニアも、「なぜつくるのか」「今後どうするのか」ということはとても関心のあることで、そこの納得感はチームのパフォーマンスに直結するといっても過言でないです。 わかる。自分も納得した上で作りたい。納得感なくても素早く作ればええやんと思われるかもしれないが、ふとした時につらくなるし何か起きても提案する気も起きなくなる。特に小さい組織だと納得感重要。 自分でもちょっとしつこいなと思うくらい納得できるまで質問することがある。「この機能なんで最初のリリースに入れるんでしたっけ?」とか「これをつける目的は○○で合ってますか?」とか。相手を信用していないわけではなくて、納得して取り組みたいので気になったところを質問するのだ。聞き方をもっと工夫すればよかったと後で反省するこ

    プロダクト開発における納得感 - Konifar's ZATSU
  • どういう時に仕事を辞めたくなるか - Konifar's ZATSU

    まだ現職辞めへんで!!ということを最初に宣言しておきつつ、どういう時に仕事/会社を辞めたくなるかを考えてみたい。 朝眠いとかだるいとかそもそも働きたくないとか5000兆円欲しいとかそういうやつではなく、基的にはやる気がある状況でもふと環境をリセットしたくなるというか、ああなんだかめんどくさいなーと感じるみたいな、比較的ライトな感情の変化の話である。人によっては「にゃーん」とツイートしたり、シャワーを浴びながら「つらい…」とつぶやいてしまったりするアレだ。 なんでこんなことを考えてるかというと、最近TL上で「この人が辞めるのマジか」とか「この人が入社したのかすげえ」と感じることが何度かあり、全然そんな素振りを感じなかったのにやはり一期一会なのだろうかと思ったことがきっかけである。仕事を辞めるのにポジティブな理由だけということはまずないという持論がある。 自分にも感情の波みたいなものがあって

    どういう時に仕事を辞めたくなるか - Konifar's ZATSU
    Watson
    Watson 2019/09/13
  • Androidの設計と取捨選択 - Konifar's ZATSU

    楽に開発するためにAndroid全体の設計をしたいという思いは、わりとどの開発者も持っている気持ちだと思う。 設計というのは昔から色々揉まれてきて、今はMVPだMVVMだ、DDDだと盛り上がっている。 そもそも、Androidというフレームワークに限定された環境で、わりとよくある実装が多い中で、未だにこれだけたくさんの人が困っているという状態がおかしい。おかしすぎる。そろそろAndroidでこういうの作りたいならこう作るでしょ、みたいなベストプラクティスが確立しているべきじゃないのかという気がする。 あくまで個人的にはだけれども、DataBindingが主流になるのであれば双方向バインディングを使ったMVVMが一番しっくり来る。ただ、MVVMだとViewModelが太ってきてどうすんのみたいなことになるかもしれない。また、通信やキャッシュ部分は別のクラスにわけようとかそういう指針はどちらに

    Androidの設計と取捨選択 - Konifar's ZATSU
  • 1