レビュワーを"憑依"させて Pull Request をセルフレビューする - Konifar's ZATSU
メンバーと1on1をしていると、「うっかりミスが多くて Pull Request で毎回コメントをもらってから気づくのを何とかしたい」という相談を受けることがある。 まず、そういう認識を持てていることが素晴らしい。課題意識があるのであれば、どう補正していくかを一緒に考えることができる。 自分がオススメしているやり方は、レビューを依頼する前に徹底的にセルフレビューすることである。巷でよくやられている方法ではあるが、どういうやり方かを雑に書いておく。 レビューを依頼する前に レビュワーになりきって 自分の Pull Request を自分でレビューしてみる 頭にレビュワーが思い浮かぶのであれば、その人を "憑依" させるイメージ 「この人はここでこういうコメントしそうだな」と思ったら、 先回りして PR上にコメントしておくか、突っ込まれないようにコードやコードコメントを改善する タイトルや説明
意思決定できる人の手順の型 - Konifar's ZATSU
意思決定できる人は進める手順の型みたいなものを持っているように見える。逆に意思決定が遅かったりできなかったりする人は、進めるときに型のうちの何かが欠けているのかもしれない。 体系化された話は書籍で語られつくされているとは思うが、思考整理のために雑にまとめてみる。 最後は決めるだけだという考えを持つ 目的や満たしたいことを明確にする 最終的な決め方や期日を明確にする 選択肢を広げて考える 今は意思決定しない、という意思決定も選択肢に入れる 意思決定の軸を明確にする 軸をもとに定量/定性データを集める 軸をもとに選択肢を評価する 自分はこうしたいという"推し"を決めてたたき台にする ここまでの話をドキュメントにしている ここまでのプロセスに時間をかけない 意見を聞く人を見定めてフィードバックをもらう 最初に明確にした決め方で意思決定する 意思決定できない場合は決め方と期日と意思決定軸を再定義す
目標設定とは何か - Konifar's ZATSU
目標設定むずかしいよね。正直嫌いとか意味がわからんと言う人も多いと思う。自分は適切な目標設定は必要なものだという腹落ちはしてるんだけど、なぜむずかしいかとかはうまく説明できなかった。 そんな時に EM.FM Re8. 本当に意味のある目標設定 でMBOの歴史から色々と話していてさすがだなー面白いなーと思ったので、自分もそもそも目標管理とは何なのかﾁｮｯﾄ調べてみることにした。 学術的にきちんと学べたわけではないので少しこわい部分もあるけれど、こういうのは誰かのためになるかもしれないし書いてみる。もし間違いや補足があれば教えてもらえると嬉しい。 目標管理の起源 目標管理の起源は欧米の研究者の中ではよく論じられているテーマらしい 諸説あるが、アリストテレスが 「成功するには目的意識を持て」 と言ったのが最初という説もある この起源とは関係ないが、Googleでは「効果的なチームを可能とする条件
仕事のインパクトを大きくしようとすると人を巻き込む必要がある - Konifar's ZATSU
マネージャーではなくとも、ある程度高い成果を期待されている人にはマネジメント能力を要求される。そういう話を雑に書いておきたい。 1人でガッと進められる範囲の仕事のインパクトには限界があり、あるレベル以上に達すると、誰かに何かを依頼したりチームを超えて足並みを揃えたりする必要が出てくる。 ここで要求される能力には、チームビルディング、ネゴシエーション、ファシリテーション、スケジューリング、ロードマップ作成といったものも含まれる。マネージャーロールではない場合、「これってマネジメントなのでは？」と感じることもあると思う。それに対する自分の答えは「Yes」である。仕事のインパクトの大きさを広げようとすると、マネジメントと同じようなスキルはプレイヤーにも必要になる。結局 Manage (なんとかする) 能力も技術と捉えて磨いていく方がよい。 つまるところ、いわゆるマネージャーとプレイヤーの違いは、
共通認識を揃えて前置きの謝罪を減らす - Konifar's ZATSU
不要な摩擦を減らすために、一言謝罪を入れてしまいそうになることがある。特にテキストコミュニケーションで多い。たとえば以下のような一言である。 「横からすみません」 「忙しいところすみませんが」 「休日にメンション失礼します」 「もう認識されていたらすみません」 「行き違いだったら申し訳ないんですが」 「自分の認識違いだったらすみません」 こういうちょっとした気遣いはとても重要で、それ自体を否定することはない。ただしやりすぎは健全ではないと思っていて、こういった謝罪による前置きは減らせるようにしていきたい。たとえば有休や育休を取る時には、ただの前置きだとしても謝罪はしない方がよいと思う。過度な気遣いは文化の形成においてマイナスに働くこともありうる。 これをどう解決するかというと、共通認識を揃えておくことが必要だと思う。 例えばSlackで「深夜にメンションすみません」という謝罪は、Slack
仕事で親切と言われ始めたら注意 - Konifar's ZATSU
仕事において親切と言われ始めたらちょっと注意したほうがいいと思っていて、その話を雑にまとめておきたい。 親切と言われるともちろん悪い気はしないんだけど、同時にやばいなと感じることがある。親切と言われる背景には、「本来その人がやるべきでないタスクを拾っている」場合があるからである。 誰かがやらなければいけないのだけれど、毎回同じ人がやることになってたりすると属人化するしあまりよくない。チームで捌けるように工夫できないか検討したほうがいい。 実は突き詰めると意味のない仕事だったと気づいたり、自動化で解決したり、他の人でもできるようにドキュメントにまとめて共有したり、そういうことができてないから毎回手を動かしてしまう。結果、親切に映って感謝はされるんだけれど、本当は効率よく仕事ができてないことを反省しなければならなかったりするのだ。 もちろん状況による。あと信頼関係を築くためにあえて親切な動きを
オンラインコミュニケーションでの相手での心遣い - Konifar's ZATSU
インターネッツでは毎日がエキサイティングである。これを見て、たしかに〜わかることもある〜と思った。 「コミュ障エンジニア」の他の特徴として、Slackやプルリク等での文章のやりとりにおいて「断定形/詰問形/命令形が非常に多い」というのがありまして、「違います/〜しましたか/〜してください」みたいな、ビジネスマナーを理解できてない稚拙な言葉遣いをしてしまう傾向が見受けられますねｗ(^.^;)— 勝又健太@テック系Youtuber (@poly_soft) October 20, 2018 たぶん嫌な気持ちになることが何度もあって、ひとしきり考えてからちょっと尖った言葉を選んだのだろう。コミュ障かどうか、稚拙かどうかは置いておいて、たしかに「ちょっと言い方変えた方がいいのになー」と思う人はいるよね。そういう人とのコミュニケーションに慣れていないと、気をつかってしまったりイライラしたりしてちょっ
新人の正論を取り込む準備と心構え - Konifar's ZATSU
最近新しく人が入ってきて、今まで手がつけられていなかった部分に対する正論をストレートにぶつけてきてくれて思わずにやけてしまった。 そう、新しい人には感じたことをそのまま言ってほしい。まだ自分が成果を出せるかわからないタイミングで正直に思ったことをぶつけるのはすごく勇気がいることだとは思うけれど、新しい旋風を巻き起こしてくれた方が嬉しいし、それをうまく取り込むのは既存メンバーの役割だと思っている。 正論をうまく取り込むには準備と心構えが必要だと思っていて、それをざっとまとめてみる。 社内ブログやSlackチャネル、定例など意見を言いやすい場所を用意しておく 感じたことは率直に言ってほしいと期待している役割などを伝えておく 口だけみたいになるのでは、という不安はいったん気にしなくていいと伝えておく 個人ではなく仕組みに対してという伝え方を意識してほしいと伝えておく 言ってくれたら、まず素直に感
SHIROBAKOと後輩の門出 - Konifar's ZATSU
これはSHIROBAKO Advent Calendar 2017最終日の記事である。 3年くらい前、ちょうどSHIROBAKOが放映されていた頃、職場にスペイン人のインターンがやって来た。彼は自己紹介で「日本のRPGはすごい！日本の会社でゲームを作りたくて日本に来ました！」と言っていた。宮森にとってのアンデスチャッキー、遠藤さんにとってのイデポンのような存在が、彼にとってはテイルズやFFだった。 最初はたどたどしかった日本語もみるみるうちに上手くなった。Android開発の勉強も同時並行で、今思い出しても大変だったと思う。「速く描くには上手くなる。上手く描くにはいっぱい描く。いっぱい描くには速く描く」と杉江さんが言っていたが、実際にやるのはとても気力がいるし大変なことだ。 彼にはまわりを明るくする不思議な魅力があった。バグをドラゴンに見立て、リリース直前に「もう少し狩りに行くぜ」と言って
モブオプスなかなかよかった - Konifar's ZATSU
最近opsチームに入って、まずは業務を知ることにした。 ドメイン知識とツールの習熟が必要な業務がまあまあ多くてキャッチアップに時間がかかりそうだったので、モブプロ*1ならぬモブオプスをやってみたらどうかと思い実行してみたところ、なかなかよかったのでざっと記録に残しておこうと思う。 やったこと モブプロの説明をする 入社したばかりでキャッチアップ中の人がドライバーとなってops業務を行う ベテランの人は助言や補足をする 自分(開発・ops初心者)はわからないところを聞く 業務の1つが終わる、または1時間経ったら終了 よかったこと opsの業務に対してツールが追いついておらずマジで工夫して何とかしてくれてるのだなということがよく理解できた ツールを改善するにあたり、業務を効率よくキャッチアップできた メモとして書いていったものがそのまま手順書にできそう ドライバーも知識の確認になってよかったと
採用基準における「地頭のよさ」とは何か - Konifar's ZATSU
どんな人を採用するかという会話の中で、地頭がいい人がいいよねという話になった。 なんとなく言いたいことはわかるが、同時に「地頭がいいって何だろうな」という話にもなり、結局結論は出なかった。 出なかったんだけど、やはり採用を強化する上で採用基準が明確じゃないのはよくないので、「地頭のよさとは何なのか」について雑に書きなぐって整理しておきたい。ちなみにこれを書いてる今も「何なんだろうな？」と思っているのでうまくまとまるかはわからない。 問題解決能力なのかなと思ったが、地頭のよさというのはその一部な気がする。問題を解決するためには色々なプロセスが求められるが、地頭のよさはそのうちのひとつでしかない。 じゃあもう少し分解して「問題定義」と「問題解決」にしてみると、なんだか問題定義の能力の方が地頭のよさに近いんじゃないかと思えてきた。思い返してみると、地頭がいいなーと感じる人って、会議中の発言でも何
Google I/O 2018初日キャッチアップ所感 - Konifar's ZATSU
普通にぐっすり寝て朝起きてからTLと公式ブログあたりを見ながらキャッチアップした。現地のみなさんには感謝しかない :pray: 色々あったので雑に所感をまとめておきたい。間違いもあると思うので何かあれば優しく指摘してくれると嬉しい。 App Bundle developer.android.com 新しいapp publishingの仕組みで、ユーザーがダウンロードするアプリのサイズを小さくできるのがメリットっぽい。公式ページの Stop managing multiple APKs という力強いタイトルが印象的だった。 自分の所属しているKyashのアプリでは、multiple apkで5個のアプリに分割することでアプリサイズが1/3くらいになっていたのだけど、それも必要なくなるのか。「Good bye Multiple apk」というPRを作る日も近い。 このApp Bundleの目指
無駄な議論を減らすために使ってる言葉 - Konifar's ZATSU
雑にまとめるので何かあったら直接言ってほしい。⇒ @konifar チームで仕事をしていると、なんかあんまり意味のないことで議論している事態に陥ることがある。こういうのは議論の中心にいるとわかりにくいが、少し引いて眺めてみると「それそんなに重要なんだっけ？俺たちはこんなに時間使って何を決めようとしてるんだっけ？」という状態になってることも多い。 例えばAとBどっちがいいですかね？という意見の時、正直どちらでもいいと皆が思ってるのにAとBのそれぞれのいいところや懸念点なんかを皆で話しこんでしまっているみたいな。こういう時に難しいのは、単に「それどっちでもよくないですか？」みたいな言い方をすると場が凍って空気が悪くなるという点である。もちろんそういう本質的なことを言ってくれる人はありがたい存在なんだけど、言うタイミングが少し遅くなると「俺たちはなぜこんな無駄な時間を…」みたいな感じになることが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
