サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
会話術
medium.com/@katzchang
みなさん、進捗どうでしょう?最高ですか?そんなことないよね!なぜならあなた達は呪われている。事前の計画よりも、常に、3倍の期間が必要になる。常にだ!!この呪いは強力であり、解放されるのは難しい。我々はどうすればよいだろうか? パーキンソンの呪いある資源に対する需要は、その資源が入手可能な量まで膨張する パーキンソンの法則 — Wikipedia ある仕事の作業量を見積もったとしよう。機能Aの追加に2週間程度必要そうだ、とする。順調にいけば、再来週には動き出し、価値が出せそうだ。ペースを作り、粛々と仕事を進めていこう。 ところが、現実的にはそんなに上手くはいかない。新しく導入するライブラリがうまく動かないとか、くだらないtypoに悩まされて半日失ったとか、既存コードの改修箇所が想像してたより多かったとか、何らかの別の仕事をやらなければいけなかったり、もしくは休暇が必要だったりとか。当初計画よ
色んなマネージャがいる。何をやる仕事だろうか?役に立ってる?要らないだろ?って話をまとめたい。 チームを助けるどうやって?1on1でお互いの理解を深めていく? 皆さん知らないかもしれないが、この世界は実は、売上とそれを支える進捗が救いなんだ。進捗の源泉はアーキテクチャでありドメインモデリングでありシステム設計者だ。マネージャではない。 経営方針を伝えるそんなもん、直で伝える方が絶対にいい。伝え方が上手くないならなおさらだよ、早めに経験値を稼ごう。 チームメンバはでかいビジョンは理解してるけど、具体的なアクションが見えないかもしれない。伝わってるか否かを観察して、次はもっと上手くやろう。マネージャの出る幕はない。 人事評価をする人事評価はお互いの納得が最低条件であり、丁寧にやらないといけない。マネージャは納得させることができるだろうか? 元エンジニアのマネージャなら、しばらくは保つかもね。で
VOYAGE GROUPでは技術力評価会という制度でエンジニアの技術力を評価している。そのやり方を紹介しつつ、よくあるトラブル、そしてそこに込められた想い…。我々はどこに行こうとしているのか。その全貌が明らかになる。 (この文書は エンジニアのマネージメントで悩んでいる人が集まる会 #3 での発表資料をもとに加筆・修正しています) 技術力評価会の実装VOYAGE GROUPでのエンジニア職評価は4グレード制を採用しており、グレード1, 2の人が評価対象者、グレード2,3,4の人が評価者となる。つまり、グレード2の人は評価される方もやるし、評価する方もやることになる。 人事評価は「能力」「実績」「CCFB」で決定されるということになっている。ここでいう「能力」について評価しようっていうのが技術力評価会の領域というわけだ。つまり、人事評価制度のすべてではないし、ここだけで給料が決まるわけでもな
春なので、新卒者が現場に入る時期ですね。弊チームでは、配属初日に何かの機能のデプロイをしてもらうということを数年間続けているので、その話をします。 なぜ初日が大事なのか「開発者として何かをデプロイするという行為は価値提供につながるから」というのが理由だ。他の行為、例えばアーキテクチャやドメインの把握、ミーティングから名刺交換に至るまで、そいつらは成果を出すためのオマケにすぎない。あ、名刺交換が役に立つかはわからん。 新卒者向けにもやるし、中途採用や社内異動、インターンの受け入れのときもやっている。 まあとにかく、デプロイするっていう我々の仕事を一回りすることで、成果を上げていくリズムを作ることに役立つはずだと考えて、続けている。 アイデア自体は新しいものではなく、昔どこかで読んだ記憶はある。 準備は?初日のタスクとしてどれが良さそうかを選ぶくらいだ。過去に選んだものとして、例えば: UIの
VOYAGE GROUP -> New Relic -> Splunk, climber, skier, ajito.fm talker. My own view.
採用の話がだいすきなみなさんこんにちは。@ryuzee です。 アジャイル開発をはじめた当初はだいたいパイロットチームを作って、そこでうまくいくと組織内に横展開していくパターンが多いと思いますが、そのときに困るのがスクラムマスターです。… では、始めよう。 スクラムマスターの役割についてアジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか? 私もそう思うので、プロセスを守らせる方針は取らないし、プロセスを守らせるスクラムマスターは信用していない。 自分の組織でアジャイルがうまくいっていることを示す兆候は何か?また自分の働きが成功している兆候は何か? 事業としてうまく行っていること、そしてみんなが自由に働けていること。 追跡しないといけないメトリクスはあるか?もしそうだとしたら何の目的でど
なんか色々やってて、カオスながら面白い感じのバランスを保ってると思ってるんだけど、パターンを見出せているわけではない。なので、とりあえず列挙してみます。 朝にやること書く帰りにやったことを言う全てのメンバーは強い権限を持つ直接話す初日デプロイ実績だけみる、目標を決めない見積もり: すぐできる、1週間、1ヶ月、いっぱいもとに戻せるエラーを出してから抑制するslackはpublic channelでメモは雑に説明はホワイトボードでちょっとデプロイインスタンスを捨てるやったほうがいいと思ったらやるgithub issueにメモってくmakefile自動化はすぐにしなくていい退職情報は速やかに共有謝らなくていいのよ…そのうち、それぞれ少しずつ解説していきたい。 ↓チームメンバーが書いた記事です。合わせてぜひ。
エンジニアの評価観点についてという文章を書いたのが2014年12月、3年半前。それから変わったことってある?ってたまに聞かれることはあったけど、最近質問しがちなことが出てきたので、まとめてみる。 基本的には動けば👍変数の名付けが微妙とか処理コストに無駄があるとか、細かいことはいいんだよ。とりあえず意図通り動いていることが確認できればよしという雰囲気は強くなった。つまり、 どう動かしたいんだっけ?どう確認したんだっけ?という2点をみていくことになる。 どう動かしたいかは解決したい課題ということで、ビジネス要件だったり負荷対策だったり。どう確認したかは自動テストだったり目視確認だったりモニタリングだったりでカバーされているかをレビューしていく感じにしている。 今後有り得そうな変更とその対策は?今はまあそれで動くとして、将来的にそのままという状況はほとんどない。ということで、変更に強いかどうか
普段仕事をしてるとき、いろいろなことに気を使いながら仕事をしてると思う。たとえばissueには、その背景、やりたいことや期待する効果、制限事項、認識している副作用やリスクの情報等などを書くような運用ルールを作っているチームは多いらしい。しかし、私たちのチームではそういうルールはない。それでうまくいくんだっけっていう話をよく質問されるので、考えてみた。 コードの品質をカバーするためのコメント私たちは、常にわかりやすいコードを書けるとは限らない。解説として、コメントが役立つ場面はある。 ちょっと待ってよ「よし、Why notを書こう!」と言って上手く書けるのは、そうとうに経験を積んだ人だ。そして、経験を積んだ人は大体問題ない。悪いコードほどコメントが必要だが、良いコメントが書けるくらいならコードはもっと良くなってる。鶏と卵じゃん。 コメントについて議論する暇があったら、コードについて議論したほ
コードから不吉なにおいがしてきたなーと思うことはよくあるだろう。リファクタリングの機運かもしれないし、YAGNI原則を思い出して踏ん張るときかもしれない。では、いつリファクタリングをやるべきか、どのようにコードを整理していくべきだろうか? リファクタリングには方針が必要リファクタリングの目的は、コードの拡張性を高めることだ。ここではそういうことにしよう。Open-Closed原則に従うように、凝集度を高め、結合度を低くするようにやっていけばいい。つまり、何か既存機能を変更するときはたった1箇所だけの変更で済むとか、もしくは新しい機能を足すときには既存機能を触らないで済むとか、そういう状態であれば比較的マシなコードになりえるよねっていうことです。 では、あらゆる変更に対してOpen-Closedであることはできるのか?おそらくそれは難しい思う。なので僕らは、経験的に「どの辺に変更が入りそうで
土日や祝日にフルタイムで技術カンファレンスがあるとして、例えば参加しますよね、そのときにどうするか考えようという提起です。 カンファレンスは疲れるセッションを黙って座って聴いてるだけでもそれなりに疲れるし、せっかく参加するなら登壇者の人を捕まえて話をしたり、他の参加者と議論したり、もしくはワークショップセッションに参加したりとかしますよね。聴いてるだけみたいな参加の仕方をしても「あとで資料だけみればいいや」程度の価値しかないから。なので、フルタイムで1日参加するとそれなりに疲労するわけです。楽しさとは別に。 土日2daysなカンファレンスの場合、前の週フルタイムで働き、土日に疲労し、次の週またフルタイムで働くとか、たぶん働きすぎなので、最低でも次の月曜とかは休みたくなるのが人間ってものだと思います。私はそうする。 平日カンファレンスの参加は休暇を使いますか?CROSS 2016に登壇したと
開発手法など、一通り学んだが実際に使っていないものは多少なりあると思う。それらについて掘り起こしてみたい。 スクラム開発認定スクラムマスター研修には研修会場ホストという立場で数回立ち会った。認定外の研修も幾つか受講した記憶がある。書籍もそれなりに読み、Scrum Gathering Tokyoなどのコミュニティにも顔を出し、まあそれなりに色々考えて捉えてきた。でも、自分のチームでは使っていない。スクラム開発というアイデアに矛盾があるからだ。 そもそもスクラム開発ではチームの自律的な行動を良しとしており、それに対する”フレームワーク”を提供しているということになっている。イテレーション、バックログ、ふりかえり、デイリーミーティング(いまだに「朝会」って言ってる人いないよね?)、そしてそれらのお作法。誰が言ったかわからないが、それぞれの作者の意図を察するためには「守」が大事らしい。守破離の「守
http://i2key.hateblo.jp/entry/2017/05/15/082655 Cost:大抵人件費でありチーム体制は頻繁に増減はない(固定) * コストはエンジニアリングの場合、大抵、人件費に跳ね返るが体制は基本的には固定であり頻繁に上下するものでないので固定になるケースが多い。 * 学びまでのリードタイムの人件費と見るのであれば、少ないにこしたことはない。結果的にコストはリードタイムそのもの。 開発だけを見ると、もしかしてそうかもしれない。では運用まで考えるとどうなるだろう? 現状、とりあえず動いているサービスがある。スループットはサーバ1台あたり10krpm(kiro-request/minute)とでもしてみよう。しかし、あなたは多少なり改善できるアイデアがあり、やってみなければわからないが、それでも多少なり改善できると思っている。さて、あなたは手を出すべきか? な
「社会人インターン」と称して2週間はてなのMackerelチームで働いてきましたので、その感想をつらつらと書きます。 おしゃれ感を演出している青山オフィスビデオチャットをいい感じに使ってるはてなといえば本社は京都ですが、東京のど真ん中、青山にもオフィスがあって、以前からビデオチャットでいい感じに中継したり会議したりしてる話は大昔からどこかに上がってた記憶がある。 Mackerel開発チームも東京、京都、その他にメンバーが散っていて、ビデオチャットは大活躍だった。朝会はそれぞれ zoom.us を立ち上げてみんなでビデオチャット。会議室で京都メンバーを交えた打ち合わせをするときは、備え付けのカメラとマイクで会議室の全景を写しつつ、大型モニターには京都の会議室の様子を写しているーというのが日常風景らしい。 こんなスペースでもビデオチャットできる用意がある先日 gitlab.com のトラブルで
一言で言うと、「やってほしいことを言いましょう」みたいなことを書きます。 さて、Vaingloryというスマートフォン向けのゲームがあります。 ジャンル的にはMOBAで、3人が1チームとなり、チーム同士で対戦します。知り合い同士でパーティを組むこともできるけど、気軽に楽しむにはソロで適当に申し込むと、30秒くらいでいい感じに3 vs 3を組んでくれて、ゲーム(=試合)が始まります。 勝った試合しか記憶しない先日サービス開始から3周年を迎え、e-sportsなどと言われるジャンル的にも世界大会があったりしてそれなりに盛り上がってるようです。 限られたコミュニケーション手段、それが問題だオンラインな見知らぬ人同士3人でチームを組むわけで、戦略上、何らかのコミュニケーションが必要になります。ゲームではピンと呼ばれるコミュニケーション手段が用意されています。知ったパーティーだとゲーム外で音声チャッ
自社会場で開催したりして、それなりの回数を参加したり聴講したりした経験があるので、なんとなくまとめていきます。 Jeff Patton, 認定スクラムプロダクトオーナー研修VOYAGE GROUP会場で4-5回くらいは開催してる。会場係としてお手伝いしつつ、内容をなんとなく聞いている。 印象に残ってるのは、プロダクトオーナーは開発者に対して、いろんな手段を使って実現したいもののことを伝えるのが仕事だということ。ドキュメントだけ書きゃいいってもんじゃないし、かと言って会話すりゃいいってわけじゃない。やり方はそれぞれの関係性によるが、とにかく、伝えるというのが大事らしいぞっていう。 研修の進め方も面白くて、毎回ちょっとずつ違いがあって、改善してるんだなーっていう印象がある。 手法の一例として彼はユーザストーリーマッピングというものを提唱していて、そのトレーニングもある。いろんな人に感想を聞くと
界隈のお前らに対してメールを送りまくってるトニーモリス(Tony Morris)氏が Twitter を始めてしまったので、せっかくなのでミートアップイベントでもやることにします。 日時は 2016–01–22金曜日の夜、場所は VOYAGE GROUP 社内バー AJITO です。詳細は http://connpass.com/event/23729/ へ。つまらなくても楽しめる、くらいの気持ちでご参加ください。 ググれこんな雑なイベントを気楽にできちゃうのが、 VOYAGE GROUP 社内バー AJITO の魅力だと思います。そんな AJITO 情報を #ajiting Advent Calendar 2015 でチェックしましょう! ということで、この記事は #ajiting Advent Calendar 2015, 4日目のエントリーでした。あしたは masartz!
VOYAGE GROUP では、職種問わず全クルーが Slack アカウントを持っており、コミュニケーションの基盤の一つになっています。ということで、voyagegroup.slack.com でいい感じにコミュニケーションしているための秘訣を、mm便利、jpi便利、#_${user}チャンネル便利の3本立てで紹介したいと思います。 この記事は VOYAGE GROUP Advent Calendar 2015 の、12/1のエントリです! mm便利例mm の最大の利点は、入力が簡単過ぎることです。 Slack はemojiサポートが充実していて補完なんかもすごく便利なんですが、 mm の素早さにはかないません。たとえばスマートフォンで mm と入力してもらえると、圧倒的便利さがご理解いただけるはず。 最近では社外の人とのコミュニケーションでも mm を自然に使ってしまうこともあるらしいで
いわゆる `新しい` MacBook を使ってみたので、その感想を書く。それ以前に持っていたのは MacBook Air 2011 Midなので、その比較になってるかもしれない。 さよなら ChromeChrome を捨てて、 Safari に乗り換えた。 アクティビティモニタを立ち上げると「平均エネルギー消費」という項目で、どのアプリケーションがどんだけ電池を食ってるかが見れる。 Safari は45程度に対して、 Chrome は200を超える。推定残り時間も、電池残量95%の状態で3時間程度しかなくなってしまう。今は Safari で書いている。これで、カタログスペックである9時間程度は持つようだ。 Safari は若干キーバインドが違うので、「前のタブを表示」「次のタブを表示」のみ、 Chrome に習って ⌥⌘←、⌥⌘→ に割り当てなおしている。設定方法はシステム環境設定のキーボ
この記事は 家庭を支える技術 Advent Calender 2014, 12/09の記事です。 自信を持って家庭を支えてるとは言えないなーと思い、最初は参加するつもりはなかったのですが、まぁそれはそれで書くことはあるということで、家畜ポイントについて書くことにします。 ここで言う「家畜」とは「社畜」の家庭版で、家畜ポイントは家庭に貢献すると貯まり、家庭をないがしろにすると減ります。減りすぎると大変なことが起こります。では、家畜ポイントを減算させる主な行為についてみてみましょう。 毎日のように残業する帰りが遅いってやつです。かと言って朝に何するというわけでもなく、普通に出勤する。それにより稼いでいるかどうかは、それほど関係ありません。仕事と私のどっちが大事なのってやつです。 休日に一人で出かける出かける理由が勉強会だろうが遊びだろうが、大した問題ではありません。勉強会は仕事と同じような扱い
このページを最初にブックマークしてみませんか?
『Kazunori Otani – Medium』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く