採用基準についてトレードオフスライダーを使って議論した - @kyanny's blog
開発者の中途採用をやっていくにあたり、「チームの誰もが採用担当」というポリシーでインタビューやコードテストのレビューなどをみんなでやってきたが、「どういう人を採用すべきか？」についての認識が合わなくなってきたと感じたので、認識を合わせるために議論の場を設けた。議論を進めるためのツールとしてトレードオフスライダーを使ってみた。うまくいくか確証はなかったが、事後にアンケートをとったら過半数からフィードバックをもらえ、全て好意的だった（五段階評価で4と5が半数ずつ）ので、まぁまぁうまくいったのだろうと受け止めて、もろもろ公開します。 使った資料はこちら。 以下、意図とか進め方とか学びとか。 最終的な目標は「採用基準についての認識が合うこと」なのだが、全員の認識・見解が一致することなどありえないと思っていて、むしろ各人の認識がどれくらいズレているのかを明らかにすることのほうが重要だと思っていた。そ
Kaizen Platformで行っているOnboardingプロセス - Kaizen Platform 開発者ブログ
Kaizen PlatformでSRE Group Managerをしている前田 (@glidenote)です。4月ということで転職や部署異動など新しい環境で働いている人が多そうなので、今回はKaizen PlatformのEngineering GroupとSRE Groupが行っているOnboardingプロセスを紹介したいと思います。 TL;DR Kaizen Platformに入社してくれた人に最速でPerformanceを出してもらうためにOnboardingプロセスを策定し、運用、日々改善している 入社してくれた人が自身のOnboarding Planを自分で作成し、CTO、メンターとで定期的に期待値の調整、振り返りを実施し、齟齬が発生しないようにする ランチスケジュールを組み毎日別々の人と、別々の場所にランチに行き、一緒に働く人たちとオフィス周辺の情報を知ってもらう 入社した
マネジメントの秘伝のタレ - Flicker's Style++
今回は私が今までチームマネジメントやヒューマンマネジメントを通して学んだTIPSを整理してみたいと思います。 マネジメント(≒コミュニケーション)を支える技術について都度メモして、自分への戒めとして利用していたものを箇条書きにまとめました。 ある特定の状況だけでしか適用できないものが多いですが、応用はいろいろ効くと思っています。 マネジメントの立場にこれからチャレンジしていきたい人の一助になればと思ってます。 ※自分向けのメモを整理しただけなので、一般的にこうあるべきという内容ではありません。 会議編 -全員の参加を促そう 全員の発言機会が均等になっているか常に意識しよう 一言でも意見を言うことによって、その議題を決めたという意識を持てる - 自分自身(チーム自身)で決めたという感覚に落としもう 「決められたこと」ではなく、「自分たちで決めたこと」という意識を促そう その決定が実行されなか
マツダ先生（仮名）の思い出、あるいは議論の仕方を習ったことのない人はやっかいだということ - みやきち日記
あたしが小学5〜6年生だったときの担任・マツダ先生（仮名）は、クラスで話し合うとき生徒にたったひとつのルールを課しました。そのルールとは、「意見を言うときは、必ず理由を言わなければならない」というもの。これは鉄の掟で、例外は許されませんでした。今にして思うとこれはすばらしい教育で、あたしはマツダ先生にものすごく感謝しています。 このルール下だと、「今度クラスのレクリエーション時間でどんなスポーツをやるか」なんて議題で話し合うとき、ただ各自で 「バスケがいいでーす」 「ソフトボールがいいでーす」 「ドッジボールがしたいでーす」みたいに提案だけしていきなり採決ってのはダメなわけ。提案するには、絶対に「なぜ自分はクラスでこのスポーツをやるのがいいと思うのか」を言わなきゃいけないんです。 そうなってくると、「自分がバスケが好きだから」クラス全体でバスケをするべきだなんて言えないわけですよ。いくら小
無駄な議論を減らすために使ってる言葉 - Konifar's ZATSU
雑にまとめるので何かあったら直接言ってほしい。⇒ @konifar チームで仕事をしていると、なんかあんまり意味のないことで議論している事態に陥ることがある。こういうのは議論の中心にいるとわかりにくいが、少し引いて眺めてみると「それそんなに重要なんだっけ？俺たちはこんなに時間使って何を決めようとしてるんだっけ？」という状態になってることも多い。 例えばAとBどっちがいいですかね？という意見の時、正直どちらでもいいと皆が思ってるのにAとBのそれぞれのいいところや懸念点なんかを皆で話しこんでしまっているみたいな。こういう時に難しいのは、単に「それどっちでもよくないですか？」みたいな言い方をすると場が凍って空気が悪くなるという点である。もちろんそういう本質的なことを言ってくれる人はありがたい存在なんだけど、言うタイミングが少し遅くなると「俺たちはなぜこんな無駄な時間を…」みたいな感じになることが
「工数一日」は「明日できる」じゃない！エンジニアと非エンジニアのギャップとは - paiza times
Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ！』 こんにちは、谷口です。 ディレクターやプロジェクトマネージャーといった非エンジニア職の方々は、エンジニアとコミュニケーションをとることに難しさを感じたり、考え方にギャップを感じたりしたことがある方もいらっしゃるかと思います。 「エンジニアとわかりあえない…」「エンジニアが何を考えてるのかわからない…」という方のために、エンジニアとのトラブルのもととなるやりとりや、気を付けるとよいことを考えていきますので、非エンジニアの方々の参考になればと思います。 ■「どれくらいでできる？」はその場で決められるものではない 非エンジニアとエンジニアのもめごとの原因で多いのが、スケジュールに関することです。 非エンジニア「この機能どれくらいでできる？」 エンジニア「一日でできます」 非エンジニア「じゃあ明日リリース
冷たい怒り - アンカテ
ある種の心理的な状態を描写して、それをひとつの概念として確立したいと思います。とりあえず、私はそれを「冷たい怒り」と名づけました。 伝統的な慣習で惰性的に続いているものに関連して起こることなので、例として社員旅行を使います。 日本では、こういう伝統を守ろうとする人たちは、「社員旅行はよい」と主張しないで「社員旅行に文句をつける奴は悪い奴だ」と主張する傾向があります。権力のある人から、繰り返しそれを受け続けると、社員旅行の好き嫌いと関係なしに、「社員旅行に文句を言えないことに対する怒り」がたまってきます。この怒りはどこに向かうかと言うと、社員旅行が好きな人ではありません。「社員旅行に文句を言うな」と言った人でもありません。「社員旅行に文句を言う人」に向かって吐き出されます。これが「冷たい怒り」です。 「冷たい怒り」を持った人に「社員旅行をやめるように訴えよう」と言うと、「社員旅行はよくない。
メールに返信をしないアメリカ人のメンタリティ - Thoughts and Notes from CA
「メールでアメリカ人に問い合わせをしているが返信がこない」、というのは外資系企業に勤めていればよくある話。その内容が難しければ難しい程、返信率は悪くなる。もちろん、日本人でもレスの遅い人、しない人はいるが、度合いの問題。アメリカ人の場合はかなり気合をいれて、しつこくプッシュしないと返事がもらえないことが多い。 一番良いのは電話をすることで、電話をしてみると「おぉ、あの件ね、見た見た」みたいな感じで話が進むことが多い。メールで聞いていることを一々電話しないといけないのはかったるいし、時差や言語の問題があって容易ではないし、そもそも「お前、見てるんなら返信くれよ」という思いもある。 でも、そういうことで頭を痛めている人は、理解しておいたほうが良い彼らのメンタリティがある。それは「何度もプッシュされないということはきっと大事なことではないんだ」という考え方だ。メールを出して返信がしばらくこないも
マネージャとのつきあいかた - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
今の会社で 7 人のマネージャと仕事させてもらい、自分もマネージャになったこともある。その経験をふまえてマネージャとのつきあいかたを書いてみる。マネージャは日本的な「上司」と若干ニュアンスが違うので注意。上司というよりは役割の異なる同僚。 目的 マネージャとうまくつきあうことで以下を得るのが目的。 困ったときに助けてもらえる。マネージャ自身のマネージャのちから、マネージャの人脈を借りる プロジェクトの進め方、デザイン等。基本的に好きにやりたい。細かく口を出されない。 キャリアプランゴールを共有し助けてもらう 大きな 2 つの方針 初期の段階で信頼関係を築き、以降のつきあいを楽にする バランスのよい情報共有を目指すが over-communication よりにたおす マネージャの視点 マネージャの視点を意識すると何を伝えるべきかが見えてくる。マネージャがあなたについて知りたいのは プロジェ
【イラッとされない】指摘をするときに気をつけたい4つのポイント - リクナビNEXTジャーナル
Photo by decoded conference 初めまして、konifarと申します。普段はエンジニアとしてアプリの開発をしながら、仕事で感じた悩みや工夫したことを『Konifar’s WIP』というブログにつらつらと書いています。 今回は 『チーム内で人に指摘するときの工夫』をテーマに、自分の経験から感じたことをまとめてみようと思います。この 『指摘する』ってのが結構難しいなぁと感じることが多いんですよね。うまく言語化できず感情的になってしまったり、空気が悪くなることもしばしば。性格も年齢も得意分野も違うメンバーが集まる中で、どうすれば思ったことを指摘しつつ気持ちよくコミュニケーションできるのか、自分の経験から感じたことをまとめてみます。 遠慮のしすぎは禁物！ チームは“指摘”で前進する 以前アプリのバグを出してしまったときに、後輩からこんな言葉を言われたことがあります。 「レビ
エンジニアの「できない」という言葉の裏側 - Konifar's WIP
「ここ、こんな感じにできませんかね？」と言われたエンジニアが、「うーん、それはちょっと厳しいですね。できないです」と返すみたいなやりとりは結構見かけます。 この「できますか？」⇒「できない」というやりとりなんですが、「できない」という言葉にはいくつか裏が考えられます。言葉足らずだっただけでちょっとした調整をすればできるよね、というケースもあるので、「できない」という言葉の裏側をまとめておこうと思います。 先に補足しておくと、「エンジニアの人の言葉が足りなすぎるでしょ」という意見ももちろんあると思います。こういうコミュニケーションは、お互いの信頼度によっても変わってくるので難しいところです。お互いが相手に伝わるように意識すべきだと思うんですが、 エンジニアから「できない」と言われた時にどういう意味で言ってるのか想像しやすくなればいいなという思いで書いておきます。 ちなみに、「（できるけどやり
30代で部長になった私が泣かされた「年上の部下」の実在サンプル７人衆とその上司としての接し方 - ひかる人財プロジェクト
私は今の会社に中途で就職したのですが、入社して一年後に部長になりました。38歳でした。中小企業でしたがそこそこ社員数もいましたし、老舗の会社ですので当時私より「年上の部下」は必然的にかなりの人数存在していました。 私は部長になった日から今日まで様々なやっかみや嫌がらせをぶつけてくる中々手強い「年上の部下」に対峙してきました。最近はその人数も減りほとんどいなくなりましたし、私も少しは認めてもらえてきたので、今思えばいい思い出ですが当時は相当泣かされたというか苦しめられました。 その時現実にいた「年上の部下」のタイプと、その人たちに当時「改めて欲しいこと」を指摘した時などによく返ってきていた面倒臭いセリフをいくつか紹介します。その後で私がその人たちに少しでもモチベーションを上げて業務にあたってもらうためにどう接したか、私を認めてもらうためにどう接したかも紹介します。 最近人事異動があってまさに
「進捗どうですか？」より2015倍捗る「困ってますか？」 - Qiita
概要 お願いした作業の進捗を聞くときには「進捗どうですか？」より「困ってますか？」と聞くほうが何倍も捗るよ、というお話。 タイトルの2015倍は冗談です。念のため。 「進捗どうですか？」はダメです あけましておめでとうございます。ところで皆さん進捗どうですか? ・・・いやー、流行りましたね。 この「進捗どうですか？」はtwitter上で使うと「最近どうよ、忙しいの？」程度の挨拶で面白みがあるのですが、実際に仕事で使うとなんのいいこともないと思うのです。 質問攻め いいことがないと思う理由は、「進捗どうですか？」は質問攻めになりやすいと思うからです。「進捗どうですか？」の先に待っているやりとりはだいたいこんな感じです。 「進捗どうですか？」 「進捗ダメです。」 「どこがダメなの？」 「単体テストが遅れています」 「どれくらい遅れてるの？」 「えーと・・・、0.5日分くらいです」 「項目数でい
何かのときにすっと出したい、プログラミングに関する法則・原則一覧 - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 デメテルの法則 別名最小知識の法則。デメテルは、豊穣の女神。アスペクト指向などの研究であった「デメテルプロジェクト」に由来。 基本的な考え方は、任意のオブジェクトが自分以外（サブコンポーネント含む）の構造やプロパティに対して持っている仮定を最小限にすべきであるという点にある。 単純化して説明すると、オブジェクトの"メンバーのプロパテ
「話のわかりやすい人」と「わかりにくい人」のちがい
前職の時から、私は「話のわかりやすさ」にはかなり個人差があると感じていた。 何故話のわかりやすい人と、わかりにくい人がいるのか？最初はよくわからなかった。「生まれつき」なのか？「訓練」なのか？しかし、いろいろな人と話すと、要は「サービス精神」のちがいなのではと思うようになった。 巷には色々と「話し方講座」があふれているが、細かいテクニックよりも、結局のところ「相手の立場から自分の話を見ることができるか」ということに尽きると思う。したがって、以下の8項目が重要であるとの結論になった。 「話のわかりやすい人」と「わかりにくい人」のちがい 1. 「結論」から話すか、「過程」から話すか 例 「今日の打ち合わせの結果どうだった？」と聞かれたとき 話のわかりやすい人は「うまくいきました」「イマイチでした」と結論から話します。 話のわかりにくい人は、「最初に○○の議題が有りまして、XXさんが○○と報告し
WhatsAppはなぜ欧米で成功したのか（なぜ日本では成功していないのか） - FutureInsight.info
Future Insightを独自ドメインで運用はじめましたが、これを機会に積極的に寄稿なども扱っていこうと考えています。今回は友達のDSさんに「WhatsAppはなぜ欧米で成功したのか（なぜ日本では成功していないのか）」というホットなテーマで寄稿いただきました。 WhatsAppはなぜ欧米で成功したのか（なぜ日本では成功していないのか） FacebookによるWhatsAppの買収が話題になっています。金額もさることながら、ここ数年盛り上がっている「ウェブ VS ネイティブ」「パソコン VS モバイル」の文脈でも語ることができるトピックなので、特に関心が高いようです。 ただWhatsAppが日本ではそこまで普及していないために「なんでWhatsAppが流行ったのかわからない」という人も多いようなので、私の考えをまとめたいと思います。 WhtatsAppの成功を考えるときに、面白いポイント
情報共有の必要性について
本エントリは、社内向けに書いた記事を公開するものです。 なぜ情報共有するのか みなさんご存知の通り、コーポレートサイトにて、以下のように謳われています。 意見やアイデアは、ミーティング、社内SNS、メールなどで積極的に発言しましょう。不採用かもしれないと思っても、他のアイデアと合わさることで新しいものになることがあります。そのために、すべてのアイデアに耳を傾けると同時に、頭に浮かんだことをどんどん外に出しましょう。 また、インターネットで表現し続ける、コミュニケーションし続けることを楽しんで、自分たちが一番のユーザーであることを心掛けましょう。 大切にしてほしいこと | 採用情報 | 株式会社paperboy&co. このことからもわかる通り、様々なことに関してアウトプットを行い、広く共有することは、我々みなに求められていることです。 組織面からの理由 他にも理由があります。それは、我々が
仕事でPDCAサイクルを回せている人は、夫婦間でもちゃんとPDCAサイクルを回した方がいいような気がする: 不倒城
いや、タイトルの時点で完結しているのだが。 以下は、私の家庭でなんとなく実施していること。一般的に有効なのかどうかは知らない。 「今お互いに対して不満に思っていること、不安に思っていることは何かないか」という話は、夫婦間で割と頻繁にしている。 私の奥様は、最近はだいぶ改善したとはいえ、昔は随分いろんなことを「溜め込む」方だった。色んな思いや不満が溜まりはするのだが、それを言語化することが苦手だったのである。 私は察しのいい方ではないので、話してもらわないと何がよくないのかがさっぱり分からないし、何を直せばいいのかもさっぱり分からない。かといって、ただ単に「不満なことあったら話して？」と言うのは、「分からないことがあったら質問して？」と同じで、ろくな言語化を引き出せない。 そこで、結婚後暫くしてから、敢えて業務的に、決まったテンプレートで不満の抽出を図るという方法をとってみた。一通りの不満は
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
OKR (目標と主な結果)
http://www.hanako-no-blog.com/entry/2014/04/18/083816
