はじめに PMの実態 よくあるケースと処方箋について PMが全部把握したいマンになっているケース 処方箋 PMがタスク持ちすぎなケース 処方箋 PMがコミュニケーションのハブになっているケース 処方箋 おわりに はじめに プロダクトマネージャーをやっていると楽しい一方で、MTGや問い合わせ多くて、忙しすぎるという声をよく聞きます。 そこで本来集中すべきことは何かと、それを阻害する忙しさにどう対処するべきかまとめてみました。 PMの実態 組織内でPMが大変そうと思われる。周りからなりたくない職種と思われるのは危ないサインだと思います。 プロダクトマネージャーというとミニCEOと呼ばれたり、花形とか言われますが、実態としては割と忙殺されていて、職場でも「あの人すごいと思うんだけど、なりたいかと言われると、、、」 みたいに見られているのが多いんじゃないかと思います。 PMが忙しいパターンとそれぞ

2018年4月25日にはてなさんのオフィスでプレゼンしたときの資料です。 ※このスライドは、2017年1月に公開した資料 ( https://speakerdeck.com/makoga/regional-scrum-gathering-tokyo-2017 ) に「社外評価者」の取り組みなどを追加し…

最近メンタリング制度のことや、技術組織のことについて興味がある。最近「エンジニアリング組織論への招待」という本が出版されて話題になっていたので読んでみた。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング 作者:広木 大地技術評論社Amazon この本は、エンジニアリングで重要なのは「どうしたら効率よく不確実性を減らしていけるのか」ということと述べている。その考え方に従って、思考方法、メンタリング、チーム運営、組織運営といったプログラミング以外でのやるべきことについて、様々な背景も含めて教えてくれる。 全部読んでみたところ本当に良い本であった。メンタリングや組織運営といった、なかなか汎用化や言語化がしにくい分野を、納得のできる形で言語化されていて本当にすごい。僕は最近はメンタリング制度について考えているので、特にChapter2のメンタリングの技術の章が一番

自分が先輩社員となり、チームを持ち、すぐに直面する問題といえば「エンジニアの育成」問題です。 私は7年間システムエンジニアとして働いてきた中で早い段階で多くのメンバーを育てる機会に恵まれました。メンバーの中には文系出身の新人や技術に尖った新人、数年間くすぶっていた中堅若手と様々な境遇の人がいました。 性質がそれぞれ違うなかでどのように"プロ"として育て上げたかを紹介したいと思います。 育成のきほん まずは下記の図を見てください。これは「1分間リーダーシップ」(Paul Hersey, Kenneth H Blanchard/1985年) で取り上げられているSL理論 (Situational Leadership)というメンバーの能力とモチベーションに応じて発揮すべきリーダーシップを表した図です。 S1の状態から順に2,3,4とリーダーシップを変更させていくことが望ましいとされています。

世間一般ではデザイナーは一括りに語られがちですが、デザイナーも千差万別、一人一人に個性があり、異なる価値観を持っています。この多種多様なデザイナーを一種類にまとめて扱うことは、デザイナーとのミスマッチに繋がり、デザイナーを擁する組織のマネジメントにとって、深刻な問題を引き起こすこともあります。 自分自身は経営者兼デザイナーとして仕事をし、今まで多くのデザイナーを見てきました。その私の経験則でいえば、デザイナーは大きく4つのタイプに分類できると考えています。例えば採用面接などで新たにデザイナーと出会った際には、まずはこの4タイプを手がかりにして、その方の理解を深めていったりします。 私が考えるデザイナーの4つのタイプとは、縦軸に「挑戦的」「保守的」、横軸に「感覚的」「論理的」を置いた4象限で表現できます。以下がその図です。 ここからは、理想実現型、成果追求型、共同作業型、実務遂行型の順に、そ

開発チームのチームリーダーやってたときってどんなこと考えながらやってた？って相談があって、僕がチームリーダーやってたときはこういうことに気をつけてたよ。って話をした。今は僕はリーダーは後輩にまかせて、自分はシニアエンジニア的な立場でコードを書いたりウロウロしたりして楽しく過ごしてるんだけども。 4つの混ぜない やってるときは特に考えてなかったけど、今になって考えるとこういうこと気にしてたなーってのね。数は、単に4つ思い出した。ってだけ。 帽子を混ぜない エンジニア出身のチームリーダーって、こんな帽子をかぶってることが多いかな: 組織マネージャの帽子で 後輩の育成や組織としての成長を考えたり 開発リードの帽子で クオリティの最後の砦みたいな役割や、チームの外との調整をやったり プロジェクトマネージャの帽子で プロジェクトをどうやってうまく回していくかを考えたり なので「今の自分の気持ちはどの

大手メーカーで働いていて、こっちの会社が設計、外注先が完成品の製造（組立調整）って関係の中で、作り方を伝えるだけじゃなくて「どうしてそうなってるのか」も伝えた方がいいなと最近しみじみ思うことがある。 組調の手順は、ないと作れないので必ず外注先に伝えられる。でも「なんでそういう手順になっているのか」「どうしてここの調整を頑張る必要があるのか」、さらにその背後の「この製品はどういう目的で存在しているのか」「どういう原理で目的を実現しているのか」といった意図や理屈もちゃんと伝えた方がやっぱりいいなという。 自分は設計じゃなくて検査の部門で働いている。検査で不良にすると外注先から「どうしたらいいですか？」と直接聞かれることになる。誰でもわかる不良（寸法が違うとか欠品とか傷とか）じゃなくてその製品の構造や原理を知ってないと不良箇所が特定できないということもよくある。「僕は検査の人だからそんなの関係な

こんにちは、らくからちゃです。 システム業界に身を置いておりますと、色んなお客様とお仕事をさせて貰う機会があります。システム構築はお客様との二人三脚。お客様の作業効率が弊社の作業効率に直結することも多いものの、横から『こうしたほうがええんとちゃうの？』とも言い出せず、悶々としてしまうときがあります。 そこで直接は言いづらい『ここらへん考えてみてほしいなー』という点について、だらだら適当に書いてみます。ありきたりのことしか書きませんが、どこかのプロジェクトの燃焼速度が多少なりとも遅くなれば幸いです。 例題 例えば、上司からこんな風に指示されたものとします マーケの部長が、修理案内の通知を封筒に詰めて送る作業をやってくれるひと探してるんだけど、お願いしてもいい？ 宛先と対象商品と諸々が書かれたA4用紙が1000人分くらい来るからさ、宛先が東日本なら茶色、西日本なら白色の窓付き封筒に入れて糊付け

他社社長が盛り上がってるみたいなんですが、そこの言説だけが広がっていってもアレだなぁと思ったので、単に自分がやってきた経験値とかを書いてみた。銀の弾丸欲しい。 お前誰よ 零細ITシステム会社経営 従業員5人、エンジニア数だと6人（私自身が含まれる） 会社は設立して4年弱 自社サービスを作っているが、今のところの収益構造は受託・SESが100% 10年ぐらい名古屋でコミュニティ活動に関わってきている（ただし、ここ2年ぐらいは忙しすぎて、ほぼ勉強会に行けてない） 色々やってきて至った基本的な考え方 会社という組織を前提とするのであれば「雇用契約」による利害関係で考えるのがシンプル。 会社は利益を上げたい 利益を上げる手段としては、良いエンジニアが必要（それだけではないが、この話題の本筋ではないので割愛） 良いエンジニアを育むには学習が必要 目的は利益であって、エンジニアの勉強は手段。エンジニア

ブログを数年ぶりに書くことにした。 前回書いたのが2年前の9月。今日までの間、何度か書こうとも思ったけど精神的に無理だった。 悪いことが現在進行形で起こっている最中にそれを文章にして再確認をするなんて、正直とても耐えられるものじゃない。 それでも今になって文章にしようと思ったのは、やはりここ数年で起こったことを自分なりに整理をつけたいと思った、というのが理由としてひとつある。理由はもうひとつあるが、それは後で書く。 なにも嵐が過ぎ去ったから、というわけではなくて、むしろまだど真ん中なわけだが、ひとまず現状を記録しておきたい、という欲求に駆られて久しぶりに自分の言葉をキーに打ち込んでいるというわけだ。 その前に前提条件。 知っている人は知っているが自分はあるベンチャー企業でエンジニアとして働いていて、入社して今年で4年目になる。 まあ、ぶっちゃけて言うと散々な4年間だった。 まず自分が入社し

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 前置き 私のキャリアは少し変わっています。 この業界に新卒で入ってから十数年は、大手ゼネコン的SIerにて、ほぼ一貫してプロジェクトマネジメントをやってきました。最終的には100人月程度の案件を回していたので、中堅クラスではあったと思います。それなりに経験も積んだとは思いますが、あれ、そもそも私って人の管理をやるためにIT業界に入ったんだっけ。。というレーゾンテートル的な理由で、プログラマーに転身しました。 そんなわけで、おそらく日本のIT業界におけるプログラマーから管理職に至るという一般的なキャリアパスを逆行している形になります。 そ

近所の通りを歩いていたら、信号が黄色から赤に変わりはじめたのに、交差点に突っ込んできた乗用車があった。強引に右折して進んでいく。歩道近くの歩行者たちは、あわてて身をひき、皆がひやりとした。車のドライバーは、年配の男性だった。みたところ団塊の世代くらいか。車種はそれなりの中型車だった。 何を怒っているのだろう。わたしは思った。あきらかに、何かに腹を立てているかのような、乱暴な運転だった。別に渋滞でもなく、忙しい通勤の時間帯でもない。だから別のことに腹を立てているのだ。 それにしても、彼は何に怒っているのか。立派な車も持ち、たぶんきちんと家庭もあり、年齢から見て、日本の高度成長の栄光と共に生きてきたはずだ。年金だって、それなりにもらっているだろう。多くの若い人から見れば、うらやむべき境遇ではないか。 もちろん、日常生活には腹の立つ場面はたくさんある。出がけに夫婦げんかでもしたのか、あるいは、好

サービスを開発していると、スピードが重視される。 そのこと自体にはまったく問題はなくて正当なことだと思っている。 ユーザーに対して一刻も早く価値を届けるためには必要なことだ。 そもそも、自分がいる Web 界隈ではこの点について異論のあるサービス開発者はあまりいないんじゃないかと思っている。 ただ、それを達成するための方法になると途端に意見が分かれはじめて、人によって重視することが全然違ってくる。 ある人は「スピード感が大事」と言い、ある人は「ちゃんと作ったほうがトータルでは速い」と主張する。 しかし、こういうときに意識される品質と速度についてのトレードオフは、実際には完全なトレードオフではないと思っている。 技術力のある人はある程度急いで作ったとしても一定以上の品質のコードを書くし、意図的に品質を落としたとしても速度はあまり上がらない。 逆に、技術力が高くない人が時間をかけて作ったとして

先日、某SIコンサル社にいる方が、まだ転職を悩んでるという前提でのカジュアル面談に臨んだ。その人の転職理由というのは、僕が受託の会社から転職した時に言っていたこととそのままだったので、是非、本面接に進んで欲しいと思った。 その一方で、受託からWebサービスに来る人に、よく言うことして、 「受託からWebサービスに来ると、ファンタスティックな案件がなくなってつまらないかもしれないですよ」 と言う話をする。これはどういうことか？というと「技術的チャレンジ」を求めるならば、筋の良い受託の会社にいる方が楽しくて、Webサービスはコードを書いている瞬間から技術的なレガシーを産んでおり、先々に渡って最初の選択の影響を受けるので、あなたの技術力の定義が「話題の言語でコードを書けること」であるならば、Webサービスはあんまり勧めません、という話をする。 当時僕がいた会社は、技術の共通化がまだ進んでおらず自

wadap.hatenablog.com 先日、こんなエントリーを書きました。割とエンジニアやデザイナーの方は経験したことがある会議ではないでしょうか。このワードに反応されていたので、少し掘り下げてみたいと思います。 「ノーアジェンダ・どうしましょうか会議」とは もうこの名前に全てが詰まってはいるので、経験したことがある人はすぐにわかるとおもうのですが、以下の点が揃っているとまさにその会議かと思います。 アジェンダが用意されていない とりあえず関係がありそうな人を呼ぶ 会議が始まり次第「どうしましょうか」的な空気が流れる ダラダラ長い 丸投げ感満載 というところでしょうか。会議そのものに主催者側の専門性があるものでは起きづらいのですが、自身が理解できない or 経験の無い領域の話になるとわりとこういう会議になりがちなのかなと思います。 会議の傾向 そしてこの会議が始まり「どうしましょうか」

マネジメント 新しいチームのあり方を探求 就活 就活生必見！サイボウズの疑問 ティール組織 会社の「あたりまえ」が変わる 多様性 100人100通りの個性 ワークスタイル 働き方、生き方、もっと自由に 青野慶久 サイボウズ社長の想いと覚悟 キャリア 人生の「積み上げ方」を見直す 複業 複数の「本業」をもつ働き方 人事制度 多様な働き方を支える仕組み マンガ サクッと手軽に読める！

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 私は昨年７月からサンフランシスコにあるAsanaという会社でエンジニアをしています。アメリカの大学でComputer Scienceを専攻し、昨年卒業しました。 エンジニアを指導する立場の人こそ読んでほしい、新卒エンジニアが1年間で上司に感じた５つのことの著者と私は新卒エンジニアで１年経ったところという境遇が似ている一方で、私は上述の記事に書かれているような不満を一度たりとも感じたことがありません。 この記事では、H_Craneさんの５つの上司に対する不満点と対比して、私がこの１年間で感じたAsanaの良い点を５つ列挙することで、どうい

リモートワークへの努力とは何なのか 僕が去年の11月にKaizen Platformに転職したこともあり、知り合いから「自分たちの会社でリモートワークを始めた/始めたい」関係の話を聞くことが多くなってきた。転職してまだ半年くらいだけど、僕たちの会社の取り組みや、それに対して僕が考えていることを書いてみる。 ここに書いてあることはKaizen Platformの他のメンバーと見解が違う場合がある。かつて弊社の技術顧問だった@naoya_ito氏はこれらの文化の土台を築いたが、彼はそれをルールとして縛ることはせず、ガイドラインとして残した。だから多様な見解があり、僕たちはそれを良しとして仕事をしている。 Kaizen Platform という会社にいる。この会社は文化的にリモートワークが根付いていて、働く場所と時間の制約がない。 時間や場所の制約がないので、同じ時間に同じ場所にみんなが集まるこ

オープンセミナー2017@岡山での発表スライドです