1on1は必ず議事録を残す(ときどき公開だってする) - よこなのへたのよこずき
これはFOLIO Advent Calendar 2019 16日目の記事です。 昨日は@grimroseさんのScala.jsとcatsとその仲間たち - Qiitaでした！ 昨年の秋から、リーダーとして採用とかチームの健康診断(?)とかをやっています。 難しいしなかなか上手くいきませんが、自分よりずっとベテランなメンバーの皆にアドバイスや見守りをいただきつつ1年生を終えました。 書籍や先人のブログ、周りからの声なんかを参考に見よう見まねでやってきましたが、何をするにも意識していたのは「前回との繋がり」がなくならないようにすることです。 ふりかえりや月次報告会のように、数週間に1度行うようなアクティビティはどうしても前回の記憶が薄れがちです。それでも、毎度新しい気持ちで望むのでなく、あくまで連続したイベントの中の1回と意識することで よいことや成長の積み重ね 課題やもやもやの経過観察 を
計画性とか言う前に考えて欲しいこと：101回死んだエンジニア：エンジニアライフ
いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。 なぜそのプランがうまくいかないか IT業界にいると、うまくいかないプロジェクトの話を腐るほど聞く。そういう話については、語り尽くせぬほどネットに出回っている。今更私が語ることでもなさそうだ。今回のコラムでは、IT系のプロジェクトでなぜうまくいかないかではなく、どうすればうまくいくかということを考えてみようと思う。 と、その前になぜ計画というのを立てるのだろうか。計画を立てるというのは一つの手段に過ぎない。物事を成すにあたって、まず行動してみる、考えながら行動する、という手段もある。時と場合によって、これらを使い分けるのが最善ではないだろうか。 もし、計画を立てて行動するのが常に最善と考えるのであれば、まず行動する、考えながら行動するという、二つの手札を使わないことに
進捗管理は「遅れ」か「残り」か - 現場のためのソフトウェア開発プロセス - たかのり日記
久しぶりに記事を書くなぁ。 しばらく忙しかったので、サボってました・・・ そしたら、年が明けてしまったよ。 さて、話は変わって、私はSEPGのリーダとして、いろいろなプロジェクトの進捗を見ることが常です。 そのような中で、 「進捗は何日（もしくは、何人日）遅れ？」 と聞くことは多い。 これは、顧客からも、そのような進捗報告を求められることが多いし、WBS線表では、遅れ日数が進捗を把握する対象となるため。 でも、進捗は、遅れだけ管理していても回復しない、というのが私の感覚。 遅れだけ見ていると、遅れが拡大していることには気づきにくい。 「タスクAは、3日遅れ」という進捗状況ならば、そのタスクは3日経てば完了しているはずだが、多くの場合は完了するまでに3日以上かかる。 そのような場合、「タスクAは、あとどれだけかかかるの？」という質問をすると、3日遅れであっても「5日ぐらい」という回答になるこ
チームファーストがプロダクトを殺す。｜市谷 聡啓 (papanda)
プロダクトづくりには2つのモードがあると思う。チームファースト(Team Fisrt)と、プロダクトファースト(Product First)。チームファーストは、チームとしての状態がより良くなることに重きを置き、その基準でプロセスや活動、評価、時間軸の最適化を行う。 一方、プロダクトファーストは、成果を重視する。具体的にはプロダクトの開発だったり、事業としての目標達成を活動の中心に据える。もちろん2モード間でゼロイチということではなくて、判断基準をチームとプロダクトのよりどちらに置くのかという考え方である。 まず一つの結論として、2つのモードの間でどちらかが正義で、一方がダメだとかそういう捉え方ではなくて、どちらも局面によって必要になる。何らかのプロダクトを軸に事業をスタートアップしようとする局面なら、まずはプロダクトが無いと始まらない、プロダクトファーストを取る場合が多いだろう。あるいは
なぜ目標設定が大切なのか？エンジニアが見逃しがちな２つの着眼点
エンジニアの目標設定において、重要でありながらついつい忘れてしまいがちなのが「キャリアビジョン」と「スタンス」です。この2つの要素は、エンジニアとしての人生を充実させるのにとても重要です。ところが目標設定というものは日々問われるものではないので、個人で日常に落とし込むのが難しい側面があります。しかも必要な要素を見落としたまま目標を立ててしまっているケースが、かなりあるのです。 ここでは「次回の目標設定をどうしよう？」と悩んでいるエンジニアの方に、効率的で完成度の高い目標設定のつくり方を伝授したいと思います。エンジニアの方がついついやってしまいがちなミスなども具体的事例を交えて、解説します。目標設定の作成に悩んでいたエンジニアの方は、是非活用して頂ければ幸いです！ １．目標設定の重要性一般的なビジネスパーソンにとって目標設定は、成功への道標であり、モチベーションの根源でもあります。例えば、「
月間38億ＰＶを支える“チームの力”とは [片桐孝憲] | ISSUES | WORKSIGHT
起業を思い立ったのは高校生のときなんですよ。親元を離れて一人暮らしをしていたせいか、いつも友だちが家に遊びに来てくれました。みんなで将来のことを考えたり、他愛もない話で盛り上がったり。それが無性に楽しかったんですね。こういう状態をずっと続けるにはどうすればいいだろうと考えて、思いついたのが会社を作ることでした。 23歳で起業して、最初はホームページ制作や企業システムの受諾開発をしていたんですが、営業力や技術力も実績もなかったので、しんどい割に儲からない。このままだと一緒に働いている人が辞めてしまうのではないかと心配になりました。どうせやるなら人気があるモノを作りたかったし、すごいチームを作りたかった。すごいチームを作るためには、すごいプロダクトが必要だと思いました。それでできたのが「pixiv（ピクシブ）」だったんです。 コミュニティが少しずつでも着実に成長していくことが重要 pixivは
![月間38億ＰＶを支える“チームの力”とは [片桐孝憲] | ISSUES | WORKSIGHT](https://cdn-ak-scissors.b.st-hatena.com/image/square/d7021e866e806a35fd93c6cc9e84e86d0c99a6b0/height=288;version=1;width=512/https%3A%2F%2Fwww.worksight.jp%2Fwp-content%2Fuploads%2F2014%2F01%2Fmanagement_katagiri-1_main-300x201.jpg)
％の進捗報告は何かを隠している - 室長のひとりごち
プロジェクトの進捗報告で％を使っているプロマネを見るとき、 「このプロジェクトマネージャは何が問題を抱えているのかもしれない」 と思うのです。ではどのような問題を抱えていると思っているかというと、 進捗を％で把握しても意味がないことを知らない ％で報告することで進捗を誤魔化したい の2つ。 進捗は％で把握しても意味がない 進捗は ％で把握しても意味がありません。例えば、2つのWBSがあって、1つが期限３日前に完了していて、2つ目が３日遅れているとトータルではプラスマイナス０でオンスケになってしまうんです。正しい進捗は、３日遅れですよね。 WBS１ |計画|□□□□□| |実績|■★□□□| WBS２ |計画|□□□□□| |実績|■■■■■|■■■ 進捗管理で進捗を正しく把握するには 「完了の個数/完了予定の個数」 で把握しないと意味がありません。 そこでどうしようかと悩みやすいことは「完
やりなおせる失敗は、失敗ではない｜深津 貴之 (fladdict)
CXOとしてよく言うフレーズに「やりなおせる失敗は、失敗ではない。どんどんやれ」があります。 企業が成長するにつれ、意思決定は遅くなり、失敗を許さない文化が少しづつ生まれてきます。 ところが、この世に存在する大半の問題は、実はそれほど重要ではありません。なぜかというと、ほとんどは失敗しても、やり直しがきく問題だからです。そういった問題について、全体会議で延々と議論するのは、あきらかにリソースの無駄です。 では、なぜ企業の意思決定がどんどん遅れてしまうのか… それは2つの大きな原因があります。 恐怖が組織を動けなくする1つは、組織が成長し安定するにつれ、リスクをとったことのない人、ダメージ・コントロールの未経験者が増えていくことです。ぬるま湯で育った人間は、未知の冒険を避けるものです。 もう1つは、過去の失敗を学習しすぎた場合。こちらは、すべての意思決定が「最悪の不祥事」と同等の基準で、判断
チームが上手く失敗するためにマネージャーの私にできること
私は現在、フロントエンドエンジニア5人のチームのマネージャーと、職種混合8人チームのスクラムマスターを担当しています。どちらの役割においても、チームがより自律的で効果的になることを意識して関わっています。 ところで、心配性な私はチームが将来出くわすであろう失敗やトラブルを予測して先回りで対策しようとする傾向にありました。 この案件は〇〇さんが担当したら苦戦するかもしれないから、△△さんにヘルプはいる準備をしておいてもらおう ふりかえりの開催は面倒臭がられるだろうから、自分が開催する役目をしよう この人とあの人は相性が悪くて上手く進捗しないだろうから、別々のチームにしよう 実例ではないのですが、例えばこんな感じです。 こういったリスクヘッジや環境整備などは、本の言葉を借りるなら「未来や人間関係の不確実性を減らすこと」と言えそうで、マネージャーの仕事であるように感じていました。 一方で、その不
新人に何か教えるということ - teruyastarはかく語りき
マネジメントにおける「当事者意識を持て」という言葉の死 | クラウドワークス社長 吉田 浩一郎のブログ 例えば、（相手が新卒であったとしても） 「あなたの考えたとおりに自由にやってみてください」 「わからなければ私なりの考えは持っているので聞いてください。その上で参考にしてもいいですし、自分の思うやり方でやってみても良いです」 ・目標の合意プロセスを経た上では、 ・一人一人の手段は一切の制限無く自由を持たせる サービスの最低限の質とか、コンプラとかをきちっとサポートする前提で、これすごくいい。 僕はこれまで人に何か教える時、 「今いるあなたの現在地点から、あるべきゴールまでを共有し、僕のやり方、考え方を一方的に喋りますから、今必要なものだけ汲み取ってください。一度に覚えなくてもいいし、また何度でも説明します。それでも基本的にあなた自身のやり方、反論を尊重します。やってみたら素人や新人の方が
新任マネージャーに贈る言葉
ぼくの大切な友人でもある優秀なエンジニアが、マネージャーを引き受けることになったと聞きました。いろんな事情がありなかなか大変な決断だったらしいのですが、どうせやるならがんばってほしい、うまくいってほしいという老婆心を（おっさんなのに）発揮して、ぼくが初めてマネージャーになったときのことを思い出しつつ、勝手にアドバイス的なことを書こうと思います。 自社でWebサービスを運営する会社の開発チームのマネージャー、という前提で書いています。 読むといい本はじめての課題に挑むとき、賢い人は先達の知恵が詰まった「書籍」による知のショートカットを試みます。読んでおいて損はない2冊を紹介します。 新版 はじめての課長の教科書ベタなタイトルですが、「マネージャーになるとはどういうことか」を一般論で語ってくれるわかりやすい本です。まずは読んでおいて、会社や環境に合わせて理解を修正していくとよいでしょう。 チー
自分プロジェクトを挫折せず続ける技術 - 個人開発をはじめよう！ - Lean Baseball
職業としてエンジニアをやりたい・やってるけど（サーバーサイド→アプリエンジニア, インフラ→機械学習エンジニア的な）ジョブチェンジをしたいという方は結構いらっしゃると思います（かつての私もそんな人達の一人でした*1）. エンジニアをやりたい, 別の領域のエンジニアにジョブチェンジしたいというときに, 仕事終わった後, 週末などに個人学習をする 勉強会やイベントに参加したりコミュニティーのメンバーになって仲間を増やす 一念発起?して自分でWebサイト・サービスやiOS/Androidアプリを作ってリリースする といった, 「自分プロジェクト」言い換えると「個人開発」をすると思いますが, これって中々続かない事多くないですか? 少なくとも私は上手く行かなかった時期がありましたし, 今は上手く行ってるものの, たまにこの手の相談を受けます. そんな中, 奇しくも今年の4月に「個人開発をはじめよう
やらせるとまかせるはことなる - β2
やらされ感があって嫌だというのはよく聞くけど、任され感があって嫌だというのは聞かない。逆に任され感は嬉しいという文脈で使われていることのほうが多いイメージだ。 仕事を頼むときに、「やらせる」のと「任せる」というのは何が違うか。 やらせるときには、あとで自分がチェックして改善することを無意識に考えている。良くいえば、まずは相手が自分の頭で考えてもらって、上がってきたものを直す過程で指導もできるという感じだ。なんだか寛容でできる上司っぽくてよく聞こえる。でもこれは間違いだ。実際は上司として「事前に色々考えるのが面倒くさい」とか「指示して漏れや間違いがあったら怖い」のがほんとうのところだ。 任せるとなると、頼む側の振る舞いはかなり変わってくる。 精神的に、胆力がないとなりたたない。すごく変なもの、ダメに思えるものがあがってくるかもしれない。大外しするわけにはいかないから、業務の背景、結果として実
チーム開発の成功に大切なこと - Tech Blog
こんにちは、サーバエンジニアのひっしーです。 この７月でTimersに入社して１年の自分が、この度プロジェクトマネージャ(PM)にチャレンジします。当然、強制ではなく自身の希望で、プロダクト開発に関わる様々な経験を積んでみたいという気持ちからです。そしてそれをGoしてくれる会社、なんて柔軟なんだ…ありがとうございます。 というわけで今回、エンジニアからPMまで経験する私がチーム開発について書いてみます。 Timersのプロジェクトチーム体制 １年かけて学んだ、成功のために大切なこと ポジティブ 日々の会話 自責 Timersのプロジェクトチーム体制 Timersでは、プロジェクトを推進するにあたり各プラットフォームからメンバーが集まりチームを組織します。 プロジェクトマネージャ(PM) デザイナー Androidエンジニア iOSエンジニア サーバエンジニア 基本的に各プラットフォームから
少人数のチームなので全員同じKPI担当にしたらサービスも組織も成長した話 | yusukehiruta.com
この記事は、Pepabo Managers Advent Calendar 2016の14日目の記事です。 13日目は、取締役兼EC事業部部長兼インターネット汁というポッドキャストで一緒にMCをしているホシハヤトさんの「山田くんと一緒に考える「組織の成長段階における最適なマネジメントとは？」〜 2016 年に購入してよかったものを添えて〜」でした！ はじめましての方からインターネット幼馴染まで、皆さんこんにちは、蛭田悠介（37歳）会社ではヒルティという可愛い呼び名で殺し屋のような顔面とのギャップ萌えだけで何とかここまでやっきた少し毒のある蠍座の男です。 ということで最近の私は何をしているかというとグーペというサービスのマネージャーをしています。 2016年のグーペ まずグーペを簡単に説明しますと、月額1,000円から誰でも簡単にホームページが作成できるウェブサービスです。 リリースは200
良いProduct Managerと良いTech Lead - ワザノバ | wazanova
http://engineering.foursquare.com/2014/01/30/good-tech-lead-bad-tech-lead/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約3時間前 A16ZのBen Horowitzが、1996年にNetscapeのDirector of Product Managementだったころに、「Good Product Manager, Bad Product Manager」という名エントリーを残しています。また、これに倣って、FoursquareのJason Liszkaが、「Good Tech Lead, Bad Tech Lead」をまとめています。 自分達のあるべき姿を律するため、かつ、悪い手本にならないようにという自戒の意味をこめて、気に入った
効率的で課題解決的な態度にひそむ罠について - 下林のエンジニアブログ
この記事は「はてなディレクターアドベントカレンダー」の18日目の記事として書かれました。 id:shimobayashiと申します。数年前からはてなという会社でディレクターという肩書で働いています。コードも書いてますけどね。 今回はディレクターアドベントカレンダーということで、マネージャー的な側面から表題の件について書いてみることにしました。 さて、一般的に効率的であることと課題解決的であることは良い態度とされていると思います。 実際にはこの2つが重なると、現在の課題についてのみ話すようになりがちです。なぜなら、効率的であろうとするほど話題を絞りがちですし、課題解決的であるほど課題について考えがちだからです。会議の場なんかでは顕著ですね。 そうなると「ここがうまくいってないよね」という会話しかせずに「ここはうまくいってるね」という会話はしなくなりがちです。そうした会話が続くと段々と自己肯定
エンジニアが自由研究に時間をかけるべき理由
ここ数年でWebエンジニアを取り巻く環境は劇的に変わったと思う。 具体的に言うと、知的好奇心とやりがいを求めて仕事を選ぶことが当然になったように感じる。 Webエンジニアを取り巻く変化 5年半前、私が新卒で就職した時はまだ、エンジニアでも長時間労働はあたりまえで、エンジニアはビジネスサイドが考えた要件に従ってサービスを実装する人だ、という認識が強かったように思う。 一緒に大学院を卒業した優秀な友人たちはみんなメーカーか大手SIerに就職し、それこそWeb企業を就職の選択肢に入れている人はめずらしかった。 その後、リーンスタートアップやアジャイルの導入によって、エンジニアがサービスを考えて、実装・リリースし、データを取り、そのデータを元にまたサービスを改善していくことが当然となり、エンジニアという仕事はよりクリエイティブなものとなった。 また、オープンソースのプロダクトは当然のように色々なサ
「ボトムアップの見かけはとても重要」 - ninjinkun's diary
この記事はProduct Manager Advent Calendar 2日目の記事です。 先日Japan Product Manger Conferenceに参加して、ポケモンGOの開発元であるNianticでPMをされている河合さんのセッションの中で印象的な言葉があったので書き留めておく（セッションの詳細はプロダクトマネージャーに必要な資質って何ですか？ 元グーグルのPM対談 | HRナビ by リクルートで読める）。 会場からの質問で、「開発者に仕事を任せる際に、上からやることをお願いするトップダウン型と、開発者が自発的にアイデアを出してくるボトムアップ型があると思うが、どちらがいいと思うか」（うろ覚えだけど、だいたいこんなニュアンスだったはず）という質問に対し、河合さんは一呼吸置いてから「ボトムアップの見かけはとても重要」と回答されていた。 これはPMの中では既に実現方法（おそら
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
チームワークって何？
