このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや
自分が会社員だった時の転職活動、必ずしも毎回全部できていたわけではないけど、一応こういうステップを意識していたなぁ、というノウハウのシェア。 ①1度に1社だけを受ける。エージェントではなくリファラルで紹介者を見つける。2社以上を同時に受けるのはちょっと大変かなと考えていた。 ②紹介者に社内の課題を聞いて、イシュー度（本当に解く価値があるか？）やCan（自分のスキルや経歴に合う領域か？）とのマッチングを確認する。 ③カジュアル面談やリファラル食事会で社内課題やカルチャーをヒアリングする。なるべく違う立場のメンバーに来てもらって、見え方や意見のズレを探り、正確な状況を把握する。必要に応じて事前にNDAを締結する。 ④外部事例をリサーチしてその会社にマッチする解決案を考え、提案資料にまとめて送る。入社後に期待される動きの1つを先に実施し、③の参加者が投下した時間コストはこの成果物でお返しとする。
gakukentのブログ もともとは新座ストロングサッカークラブと自分の趣味を書き込むサイトでしたが最近はＦＢばかりになり、どちらかというと昔のがくけんとのブログの記録を残しておくためのサイトですかね。 2004年と古い話ですが、良い話なので、アップしちゃいます。 2004年9月11日に新座市サッカーフェスティバルにて 清雲清純氏（元・ ユース日本代表監督、JFF-UNITED 監督、当時 大宮アルディージャ ＳＳＣ代表の高校の後輩です。）による指導者講習会にて聞いた話を以下の通りメモしました。ご参考にしていただければ幸いです。 以下は清雲さんの話・・・ 今日は、一人の男についてお話したいと思います。 私（清雲氏）が小野と初めて出会ったのは、１９９７年、ユ一ス（Ｕ２０）日本代表監督になって彼を合宿に召集した時ですが、彼は挨拶のときから、きちんとしており、他の選手とはちがっていました。 代表
数年前から業務上では同僚に通りの良いあだ名がない場合、極力「さん」付で呼ぶように意識している。新卒やインターンの大学生を無条件で君付けで呼ぶみたいなのをやめたいと思ったのだ。 呼称から暗黙の権威勾配が生まれることは少なくない。例えば、上司が部下を君付けで呼び、部下が上司をさん付けで呼ぶという光景はよく見られる。上下関係が前提にあり、逆転させると違和感を感じるはずだ。こういう暗黙の権威勾配は双方の心理に染み付いてしまい、構造を変えるのが難しくなる。 逆に、我々のIT業界では、新卒やインターン生が数年後に自分の上司になることも珍しくない。流動性が高くて素晴らしいことである。その時に呼び方を「君」から「さん」に変えるのもおかしな話である。そもそも上下関係によって呼び方が変わるのはナンセンスだと私は思っていて、仕事の上ではお互い一人前の大人でリスペクトしあいたいし、個人的にフラットさを志向している
GitLabで学んだ最高の働き方。気持ちよく働くための組織と個人のテクニック（後編）。デブサミ2022 2022年2月に行われたイベント「Developers Summit 2022」で、GitLab社で働く伊藤俊廷氏と佐々木直晴氏が実際の体験を基にした働き方についての講演「GitLab社で学んだ最高の働き方」を行っています。 実際にオールリモートで働く二人の講演内容は、多くの示唆に富むものになっています。ここではその内容をダイジェストとして記事化しました。 この記事は前編と後編の2部構成です。いまお読みの記事は後編です。 1on1のアジェンダ例 これが実際に、私とマネージャーの1on1（一対一のミーティング）のアジェンダ例です。1時間やっています。 私のマネージャーのアジェンダの特徴として1個目に雑談と書いてあるので、アイスブレイク的にも雑談を毎回議題としてやっています。お互いの趣味のこ
今日は「GitLabで学んだ最高の働き方」ということで発表していきたいと思います。 私、伊藤と佐々木はGitLabでソリューションアーキテクトをやっている者です。 GitLabは、オンプレミス用のソフトウェアと、GitLab.comも長年やっておりますのでぜひ使ってください。去年めでたく上場しましたので、さらにいろんな機能を追加して強力なDevOpsプラットフォームとして展開していきたいと思っています。 このセッションで共有したい内容の背景、これは個人的にGitLab社に参画した理由のひとつでもあるのですが、製品が魅力的であることともうひとつ、GitLabはご存じの通り、ご存じない方もいるかもしれませんが、従業員全員がリモートワークをしている企業です。 そこなら最先端のやり方での働きができるのではないか、という仮説が私の中にありまして、入社しました。 で、実際どうだったかというと、はい、最
いつでもどこでもモノがトドク、世界的な物流ネットワークを創りたい、207株式会社のイナバです。 207の1on1、めっちゃ良いんです！！ 先日の忘年会で業務委託の方に「207に所属していて良いところは何か？」とお聞きして「1on1、めっちゃ科学されていて良いですよね」という話題に上がるくらいには良いです！ 私自身、業務委託で色んな会社を見ているのですが、たしかに207の1on1は凝っていると思います。 という事で、本記事では「どんな質問を」「どんな意図で」しているのかを代表にインタビューしてきたのでまとめていきます。 1on1をやる目的 そもそも1on1を実施してよかった点ですが、たくさんのメリットの中でも特に、 - 認識のズレをなくす - 信頼関係を構築する - アラートの早期検出 みたいな効果を享受できています。それぞれ、どういう意味かをご説明していきます。 認識のズレをなくす 業務上
以前社内に書いたポエムなんだけど年に1回くらい引用したくなるので公開した tl;dr; 質問をする時はゴールを提示する【MUST】 理由1 理由2 コンテキストを詳しく共有する【SHOULD】 期待してた結果(expect)と実際の結果(actual)を書く【IMO】 2020/7/22 12:30追記 2020/7/22 19:00追記 tl;dr; テンプレ 【質問内容】 【やりたいこと or 今困ってること or 質問の意図】 質問をする時はゴールを提示する【MUST】 なにかやりたい けど実現できない、うまくいかない それで質問する って感じに、質問をする動機としてまず やりたいことありき のはずなので、それを提示すべきです 理由1 質問される側（以下回答者）は質問内容がふわっとしていると色々なケースを想定して回答を組み立てます *1 例「Aの場合は～だけど、Bの場合は～」 こうい
1 on 1 (ワンオンワン) とは1対1のミーティングの事。ここでは毎週もしくは隔週で行われるマネージャとその部下(direct reports)であるソフトウェアエンジニアの 1 on 1 に焦点をあてる。よく 1 on 1 で何を話したらよいか分からない。話題がない。と相談されるので僕の思うところをまとめてみる。 僕はマネージャもソフトウェアエンジニアのどちらも経験があるので両側からの視点を提供できると思う。 マネージャ編 マネージャは 1 on 1 を部下のために開催しなければならない。自分のための時間ではないことを肝に銘じよう。部下には話したいことを何でも話してもらう。事前に「1 on 1 は君のための時間だよ」と説明しておこう。 1 on 1 が始まったら「何か話したいこと、気になることある？」と問いかけよう。焦ってはいけない。じっくりと待ってみよう。 たとえマネージャとしてプ
1on1.md これは私が支援先に提供した、1 on 1 に関するノウハウや、思いを述べたドキュメントを元にしています。企業の枠を超えて共有したいことが多いので、ここに貼ります。 概要 世の中には 1 on 1 の本があるようですが、とりあえずは『1 on 1 で 何を話すのか？ マネージャ/ソフトウェアエンジニアの立場から - サンフランシスコではたらくソフトウェアエンジニア』を読んでもらえればよいと思います (higepon さんに感謝!)。 1 on 1 は 1 対 1 で話すミーティングで、基本定期的にやります。上長とメンバーとの間で行うのが基本です。 グループ/チームでのミーティングを補完するためのものです。 みんなの前では話しづらい、込み入った内容を話します。 チームとして行っているタスクの進捗確認に 1 on 1 を使うのは避けましょう。それは 1 on 1 の目的に沿ってい
はじめに もう1年近くの前の話になりますが、去年の今頃、僕は小学校のPTAの会長をやっていました。 そしてその頃、一番頭を悩ませていたのが、次年度のPTA会長の選出です。 このエントリでは、なぜそんなにPTA会長の選出が大変なのか、そして、PTA会長をスムーズに選出するためにどういう工夫をしたのかについて書いてみます。 【もくじ】 はじめに PTA会長選出が大変な理由は「自ら立候補することが必須」だから お通夜状態のまま校長室で深夜0時超え！？ 僕はさっさと帰りたかったから手を挙げた そもそもなんで立候補制なの！？ 人はなぜ、「お通夜状態」になってしまうのかを考える 「お通夜状態」を避けるための3つの鍵 会議開始！最初は積木式自己紹介でアイスブレイク PTA会長の仕事内容をプレゼン ちょっと脱線：実際のところ、PTA会長の仕事ってどうだったの？ 思っていたほど大変ではない（本当に！） 校長
最近心がけていることとして、「良かったことは良かったとはっきりフィードバックする」ということがある。 自分がリーダーやマネージャのポジションになった時に、方針やメッセージを打ち出す、チームの開発フローを改善するなどを行うことがあった。この時、何もフィードバックが返ってこなくて、結局良かったのか、それともあまり興味がないのか、実は不満に思っているのか、どれなのかわからず、非常に不安に思ったという経験がある。 逆に自分が伝えられる立場になった時を考えてみると、何かが行われた時、気になることはよくフィードバックするけど、良かったなと思うことは心の中で思うだけでフィードバックしないことが多いと感じた。 そこで最近は、「良かったことは良かったとはっきりフィードバックする」ように心がけている。はっきりフィードバックするというのは、どこが良かったかを出来る限り具体的に相手に伝えるということである。伝える
リモートワークへの努力とは何なのか 僕が去年の11月にKaizen Platformに転職したこともあり、知り合いから「自分たちの会社でリモートワークを始めた/始めたい」関係の話を聞くことが多くなってきた。転職してまだ半年くらいだけど、僕たちの会社の取り組みや、それに対して僕が考えていることを書いてみる。 ここに書いてあることはKaizen Platformの他のメンバーと見解が違う場合がある。かつて弊社の技術顧問だった@naoya_ito氏はこれらの文化の土台を築いたが、彼はそれをルールとして縛ることはせず、ガイドラインとして残した。だから多様な見解があり、僕たちはそれを良しとして仕事をしている。 Kaizen Platform という会社にいる。この会社は文化的にリモートワークが根付いていて、働く場所と時間の制約がない。 時間や場所の制約がないので、同じ時間に同じ場所にみんなが集まるこ
自分が会議を設定する時は必ず決めていることがある。 と言っても、そんなに特別なことはない。2点守るだけだ。 アジェンダとたたき台を用意する 予定の時間は厳守 アジェンダは、GoogleDocsで作っておく。 項目は会議によって少し変えたりするけども、だいたいこんな感じ。 参加者 資料 目的 ゴール 注意点 たたき台 目的とゴールとたたき台が重要。 目的が明確じゃない会議は要らないので、そこを箇条書きで整理して最初に伝えるようにしている。 ゴールは目的と似ているが違う。ゴールは、これが達成できたらこの会議は成功だよという指標になる。 ゴールが明確じゃないと会議がダラダラしてしまう。目的を具体化して会議で到達するべきラインを明文化したものがゴールという感じ。 注意点には、進行しやすくするための工夫を書く。例えば、今回はこういう面からの指摘はいったんナシでお願いしたいとかそういうことを書いておく
「Slackを入れるとSIerはどうなるのか？」 しばらくブログを休んでいたので少しだけ自己紹介をしよう。アプレッソというベンチャー企業を立ち上げて、セゾン情報システムズという会社にexitした。そしていまはアプレッソの社長として仕事をする傍ら、セゾン情報システムズのCTOの仕事もしている。どちらかというといまはセゾン情報の仕事の比重が高いから、リアルの世界では「セゾン情報の小野」と思っている人の方が増えてきていると思う。 「このままでは、SIに未来はない。だから変わらなければならない。」 「当社の社員は言われたことしかできない。」 SIerの経営者と会話していると、よくこんな言葉を耳にする。 自分たちの未来を悲観している人たちが、未来を明るくできるのだろうか？ だから私は、喜びと驚きのポジティブスパイラルで、SIerはどんな風に良くなるのか、壮大な実験をしてみようと思った。 その第一弾と
マイクロソフトの DevOps テクニカルエバンジェリストになる前から、ずっと不思議だったことがあります。 それは、「アメリカのエンジニアの生産性の高さ」です。素晴らしいサービスは大抵彼らから生まれていますし、彼らを見ているとアウトカムも生産性も非常に高く感じます。 私は個人的にこの秘密を解く旅の途中にいます。私はインターナショナルチームに所属しているのですが、同僚と一緒に働いたり、ハッカソンをしたりして気づいた１つの仮説について共有したいと思います。 気軽に「聞けないこと」が生産性を阻害しているのでは？ 以前私は「米国のエンジニアはコンピュータサイエンスを専攻している人が多くすごく優秀で、さらに英語が出来るので、技術収集するのも楽だから相当アドバンテージがある」と思っていました。 英語に関してはそうだと思いますが、彼らの個々の人がそんなに優秀かというとそうでもないことに気づきました。それ
これまで、江戸前セキュリティ勉強会やまっちゃ445勉強会を中心に、IT勉強会で懇親会の担当をする機会に多く恵まれてきました。 その中で、懇親会を企画する際に、気をつけたほうがいいと思ったこと、これまでうまくできなかったことを、 参画から5年（もうすぐ6年）の節目で、一度まとめておきたいと思います。 色々と教えて頂いたid:ripjyr id:vulcainに多謝！ 予約者数 勉強会参加者の6割が入る箱を探す (9/23追記)上記人数は規模に応じて想定割合は変更する。上記の数字は勉強会出席者が100人の場合の想定 (9/23追記)下記は一例（勉強会参加者が多いほど人数が読みづらいけど、多いほど懇親会出席率は低くなる傾向があると思う） 勉強会参加者＜ 70人 → 0.7-0.8 勉強会参加者＞ 100人 → 0.55くらい(少し少なめ） 当日になってキャンセルが出るのは日常。経験則では5-10
チャット・Issue Tracker・メール等の非同期コミュニケーションツール上で返事をはやく返す チャット・Issue Tracker・メール等の非同期コミュニケーションツール上で自分の状況をこまめに報告する 目安としては、 1 on 1 チャットは 30 秒以内・パブリックチャットのグループ mention （@here みたいなやつ）は 1 分以内・パブリックチャットの mention なし不特定多数向けメッセージは 3 分以内・それ以外のものは 24 時間以内に返事をするとよい。これより遅いと、「自分が返事をしないせいで相手を待たせてしまい、ストレスを与えたり仕事が進まない原因を作っている」ということになってしまう、と思っておくのがよい。 1は第一には「相手を待たせない」ためだが、まめに返事をしてあげていれば逆の立場になったとき自分もまめに返事をしてもらえることがあるので、自分自身
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
