「もったいない」マインドが逆に効率を悪くする。フロー効率とリソース効率から考えるチームで仕事をする理由 - Qiita
「もったいない」マインドが逆に効率を悪くする。フロー効率とリソース効率から考えるチームで仕事をする理由チーム開発プロジェクト管理マネジメント はじめに 前回、なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのかの記事において、プロジェクト型の人員規模を柔軟に変化させる開発スタイルに関して、理論的なスケジュール削減の限界について考察しました。その際に、チーム型開発や組織とソフトウェアの紐付けについても示唆しました。 今回は、チームでソフトウェアを開発することに関して、「フロー効率」と「リソース効率」という観点から考察し、なぜ私たちはチームで開発するのか、あるいはなぜプロジェクト型を採用するのかについての考え方を深めていきたいと思います。 そして、組織における効率性の価値観が異なると、新しい効率性に関して理解をする前に「もったいない」と感じてしまい、新しい文化を取り入れづらくして
予算の作り方｜和田洋一
経営の重要なツールである予算につき私見を書いてみる。 世に予算を「正確に策定する」議論は多く見受けられるものの、なぜ予算を建てるかに対してストレートに述べたものはあまり見ない。 「なぜ」がなければ「どのように」は導けない。 予算とは経営からのメッセージ予算は、スタッフの行動を促すための仕様書 CEOは、これを肝に銘ずるべき。 「見通し」で予算数値を作る人は経営していないと宣言しているのと同じ。 一方、単なる気合を書いてしまう人も、メクラ運転になるのでハタ迷惑。 仕様書は以下の二つの機能を持つ。 ① 経営の方向をメッセージとして打ち出す 予算は言語表現であると割り切る。 ・大幅増益としたい場合 会社や置かれているステージによって「大幅」を表現する数値は異なり（30％増、倍増等）、スタッフの感覚と一致しなければ効果は半減する。 ・次年度以降の飛躍のため、あえて踏み固めることを伝える場合 前年度
41歳のエンジニア、マネージャーからICへのキャリアチェンジ | おそらくはそれさえも平凡な日々
最初にお断りしておくと、このエントリは驚くほど僕固有の私的な話に終止するので、他の人の参考にはならないでしょう。 ICというのはIndividual Contributorの略で、最近だとHashiCorp創業者のあのMitchell Hashimoto氏が、HashiCorp社内でICになるというのも話題になりました。日本でも、こにふぁーさんがそういう動きをしていたりして、ちょいちょい聞くようになってきた印象です。 今回の僕の転職は、言ってしまえば、自分が培ってきたソフトウェアエンジニアとしてのスキルを活かして世界の舞台で戦いたいという気持ちを抑えきれなかった、という幼稚な理由です。自分が求めているものがLaunchableにはあるように感じて入社しました。 振り返ってみると、最近の自分の転職における決め手は「自分を一番必要としてくれるところ」という側面が強かったと感じています。その結果
チームに浸透させるのが近年では難しくなっている - id:onk のはてなブログ
昨日「動いたけどチームメンバーを説得するのが面倒で、秘蔵のブランチになってしまう」って言ったけど、この気持ちはどこから出てくるのか。 分かりやすい Cons があると、反発が予想できて、その反発を解決するところまで労力を割くほどの気持ちが無いので困る。「直ちに問題になるわけじゃないが、どちらかというとやった方がいい、でもリスクもある」という選択肢を選べずにズルズルと現状維持に向かう圧力は、ある。チームの同質性が高いうちはほとんど困らないんだが、人数が増えたり、別の職種が増えたりするごとに「面倒」さはどうしても増していく。 我々の信念として以下を持ってはいるが、現状維持に向かう圧力がある中で変化を加えるのはそこそこ労力が要り、閾値を超えると変化が発生しなくなってしまう。 業務・開発フローは「変えることは無条件に正しい」くらいに思って良いと思っています。 素早く変えてもし仮にダメだったら素早く
サイバーエージェントとメルカリにみる組織強化システムの構造的分解
これはなにか サイバーエージェントとメルカリの「採用前〜退社後」という一連のエンプロイー・ジャーニーに内包されている組織強化システムを構造的に分解するポストです。 メルカリのCuture Doc公開に際して、実際に起きたことを懐かしく思いツイートしたら予想外の反響をいただいたのですが、その中で私のもうひとつの古巣でもあるサイバーエージェントのことを引き合いに出して貶すような引用リツイートも見られました。 退職時、進太郎さんに1 on 1の時間もらって最後の挨拶したときに貰った「まあ株式会社インターネットみたいなものだから」という言葉を忘れない。2年半前のことなので、今に始まったポーズじゃなくて昔からのスタンス。 Culture Doc | 採用情報 株式会社メルカリ https://t.co/1kTYHh0wVN pic.twitter.com/d3qJwUExcB — きょすーけ | D
「リモートで組織内のサイロ化が進む」「全員出勤日を設けるなど工夫する必要がある」コロナ禍でMicrosoftがフルリモートになった影響を調べた調査の結果が出た
n @_sh0he1 - ビデオ通話・対面などの同期コミュニケーションが減り、チャット・メールなど情報量が少ない非同期コミュニケーションが増えた - グループ内にリモートに転向した同僚がいると、オフィスに残った同僚でも同様の変化が見られた（！） (2/n) n @_sh0he1 結論：リモート化は組織内のサイロ化を進める、質と量で劣る非同期コミュニケーションの増加を招き、労働者のアウトプットに長期的に影響する恐れがある。また、ハイブリッド型勤務でも”全員出勤日・リモート日”を設けるなど工夫しないとリモートの悪影響を受けることがわかった。 リンク Nature Human Behaviour The effects of remote work on collaboration among information workers - Nature Human Behaviour Using
テックリードの抱えるプレッシャとキャリアパス - 貳佰伍拾陸夜日記
テックリードを過去に3年くらい, まだ「テックリード」という名称が社内で正式に制度化されていない頃も含めると6年くらいやっていて, 今はテックリードを若者に譲っていわゆるエンジニアリングマネージャ(社内での名称はいまのところ「グループチーフエンジニア」)をやっている. 現役テックリードの悩みを経験者として聞くと「そうそう, あるある」と思う一方で, まとめてみるとそれらは実はその先のキャリアパスに綺麗につながっていることに気づいた. 以下, 社内向けに書いたテックリードの抱えるプレッシャのまとめに, キャリアパスの話を加筆したもの. テックリードの悩み テックリードとして意思決定していくのはプレッシャだよねという話題が出た. テックリードに限らずあらゆる意思決定者に共通のことだとも思う. ぐいぐい引っぱっていくリーダタイプなのか, みんなの意見をうまいことまとめるサーバントリーダタイプなの
自走するエンジニアが育つ組織の作り方
ピナクルズの CTO をしている渋谷です。「現場向け動画 DX」を実現するための SaaS『tebiki』を開発しています。 今回は、マネージャー向けに「もしメンバーに自走してほしいなら、個人のメンタリティに期待するのではなく、組織で相互にアドバイスし合うプロセスを構築したほうがいい」という話をしたいと思います。 エンジニアの求人サイトを検索してみると、求める人物像や歓迎するスキルに「自走力のある人」と書いている企業がたくさんヒットします。 これだけ書いてあるということは、自走する能力を備えていることがもはやエンジニアの必須条件のように思えてきます。 ですが、自走するかどうかはその人個人のメンタリティよりも外部要因のほうが遥かに大きいと私は考えています。どんなに自走できる人でも、ほとんどの場合で権限移譲された範囲までしか自走はできないからです。上司の知らないうちに「新サービスリリースしてお
新人PM「あるある失敗」を回避せよ！『プロダクトマネジメントのすべて』共同執筆、小城久美子さんの視点 | キャリアハック（CAREER HACK）
プロダクトマネージャー（PM）の必読書！新刊『プロダクトマネジメントのすべて』共同執筆者、小城久美子さんを取材。小城さん自身も経験した「PMのあるある失敗談」をもとに、新人PMがいかに最初の壁を突破していけるか、考えました。 プロダクトマネージャーってなんだろう？ 小城さんは、及川卓也さん率いるTablyにてプロダクトマネジメントの体系化、書籍執筆に携わり、個人的にもコミュニティづくりに取り組んできたと伺いました。そのなかでも、新人PMがぶつかりやすい壁も体系化されているのでしょうか？ そうですね。とくに今回出版した書籍『プロダクトマネジメントのすべて』では、プロダクトマネジメントをはじめてする人を想定しながら執筆したので、新人PMの方にとって役立つ心構えや考え方をまとめています。 プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで ま
アジャイルと契約 / Agile Contracts
忙しい人向けダイジェストをこちらに用意しました。 https://www.agile-studio.jp/post/agile-contracts
Atomic Scrum 個人の生産性を最大化する方法
デブサミ2021の登壇内容 チーム開発における原則としてScrumは浸透しつつあります。一方で個人単位の行動管理・タイムマネジメントについては方法論が確立されていない状況があります。今回は、Scrumの原則を個人単位の行動管理に適用した上で、実装事例としてNotionを活用した方法を紹介します。
「NO HARD WORK!」を読んで、“説明責任”と、“コンテキストスイッチコスト”について思いを巡らせた - Magnolia Tech
NO HARD WORK! 無駄ゼロで結果を出すぼくらの働き方 (早川書房) 作者:ジェイソン フリード,デイヴィッド ハイネマイヤー ハンソン発売日: 2019/01/31メディア: Kindle版 「リモートワークの達人」を書いたジェイソン・フリードと、ディヴィッド・ハイネマイヤー・ハンソン(DHH)の「NO HARD WORK!」をようやく読んだ。 2018年に原著が出版され、去年日本でも翻訳が出た、二人の最新作だ。 ちなみに、原題は「It Doesn’t Have to Be Crazy at Work」となっていて、「リモートワークの達人」のときもそうだったけど、原題の方がいいなと思う。 なお、「リモートワークの達人」の感想エントリはこちら。 blog.magnolia.tech 今回は「仕事だけに忙しく、クレイジーに働きすぎない」というテーマだ。世の中の働き方がそうなっているこ
私が出会った最高のEMたち - 言いたいことはそれだけか
[2020.12.8 追記] ブコメでEMが何かわからないと書かれていたので補足。EM = Engineering Managerです。EM菌ではありません！！！ [追記ここまで] 今の会社でお世話になったEMの人たちのマネジメントがとてもよかったので育休で全てを忘れる前にメモを残す。EMの話題はよく見かけるけれど、マネジメントされる側の視点で語られることがあまりなかった気がするのでいい記録になるかもしれない。 前提 自分: メンバー（マネジメントされる側）。Androidエンジニア。ある程度放置されても自走できる。 EM: 一人ではなく複数。（歴代という意味。同時に複数人のEMにマネジメントされたという意味ではない。）彼らはみなAndroidエンジニアではないがモバイルもしくはフロントエンドのエンジニア。なので技術の相談はしないが、開発業務そのものについてはとても詳しい。 組織: エンジ
Early Work
初期の作品 --- Early Work Paul Graham, October 2020 これは、Paul Graham： Early Work を、原著者の許可を得て翻訳・公開するものです。 <版権表示> 本和訳テキストの複製、変更、再配布は、この版権表示を残す限り、自由に行って結構です。 (「この版権表示」には上の文も含まれます。すなわち、再配布を禁止してはいけません)。 Copyright 2020 by Paul Graham 原文: http://www.paulgraham.com/early.html 日本語訳：Shiro Kawai (shiro ＠ acm.org) <版権表示終り> Paul Graham氏のエッセイをまとめた『ハッカーと画家』の 邦訳版が出版されました。 出版社の案内ページ Amazon.co.jp サポートページ 2020/10/20 翻訳公開
プロジェクトを成功させたければ人を信用してはいけない 大学教授が考えるプロジェクトマネジメントで重要な3つのこと
年に一度のプロジェクトマネジメントに関するイベント「Backlog World 2020 re:Union」。今回「プロジェクトリスク＆クライシスマネジメント」のテーマで登壇するのは、数多くのシステム開発の現場でプロジェクトマネージャーに従事し、現在は広島修道大学で教壇に立つ佐藤達男氏。前半はプロジェクトマネジメントに必要なことなどを、現場を知る人間の目線で語ってもらいました。 プロジェクトマネジメント論を教える現場経験豊富な大学教授 佐藤達男氏：みなさん、こんにちは。今回のテーマは「プロジェクトリスク＆クライシスマネジメント」です。とくに、プロジェクトマネジメントの中でも、リスクと危機管理にフォーカスして話をしたいと思います。 あらためまして、佐藤達男です。出身は東京で、もとはSI企業で多くのシステム開発プロジェクトでプロジェクトマネージャーを経験。そのあと、全社のプロジェクトを統括する
Google re:Work - マネージャー
イノベーション イノベーションを起こすためのスキルを習得し、業務に活かす方法を学びます。
【Google re:Work】マネジメントで悩むすべてのエンジニアが見るべき完全無料テキスト | DevelopersIO
エンジニアにとって、正解が分かりづらいマネジメント業務ってとっつきづらいんですが、その良き羅針盤となってくれるテキスト「re:Work」の紹介です。 「エンジニア天国な会社にしたい。したくない？」 「したい。けど、どうやって？わっしょい的な雰囲気で？」 今年の6月あたり、クラスメソッドAWS事業本部コンサル部で合宿を予定しているんですが、その合宿でやるネタを考えているときに知ったのが、この「Google re:Work」。 正解が見えづらい組織運営において、「良いチームとはなにか？」「採用で気をつけるべき点」「ビジョンがもたらす効果」など、マネジメントの頻出課題をギュッと凝縮して詰め込んだこのコンテンツがむっちゃ有用だったので、紹介します。 Webコンテンツとして完全無料なので、今マネジメントで悩んでいる人も、これからマネージャー目指そうとしている人にも参考になる点多いと思うので、一度気軽
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイルなチームをつくる ふりかえりのガイド / A Retrospective Guide
要はアジャイルは行き当たりばったりってことですか？
スケジュールの付き合い方
