君へ、 つい最近まで、南米で3ヶ月ほどデータエンジニアとして仕事していた。Tシャツで帰ってきて震えた。寒くて。 僕にとって2019年は、あんまりいろんなことが無かったくせに、いや糞ヒマだったからこそ、いろいろ考えることが多い1年だったと思う。最後の3ヶ月以外は、基本的にヒマだった。 過去に僕はベルリンで1年ほど働いていたこと*1があり、まあ結論からいうと音を上げて、日本に逃げ帰ってきた。何がそんなにしんどかったかというと、ベルリンは十分英語で生活できるとはいえ、ドイツ語関連のトラブルシューティングに付き合ってくれるドイツ人の友人を作ることができなかったというのが大きいが、そういう人間関係を構築することが出来なかったことも含めて、当時所属していた会社の上司および同僚と上手くいかなかったのが致命的だった。 とくに、エンジニアの同僚氏、つまり君は、まったく許せなかった。 あれからもう3年も経ち、
ほとんどの人はだれかと恊働しています。マネージャーやリーダーであるなら、この割合はより大きくなります。 筆者は、仕事の重要な要素のひとつを「進捗を出すこと」と定義しています。そして進捗を出すには、進捗をただしく把握することも重要になってきます。 しかし「進捗を把握する」と言っても、想像以上に難しいと感じる場面が多々ありました。たとえば、 進捗はどうですか？ → 進行中です／〜をやっています なにか問題はありますか？ → とくにないです 〜までに終わりそうですか？ → たぶん大丈夫だと思います というようなやりとりは一般的なコミュニケーションだと思いますが、あまり有用な情報は得られていません。 この記事では、自身の経験則をもとに、進捗にまつわる良い情報をゲットするための具体的な質問を考えてみました。 なぜ進捗を把握すべきなのか 話の前に、なぜ進捗を把握すべきなのでしょうか。 それは良い計画づ
NTT Com オンボーディングハンドブック
オンボーディング ハンドブック #このサイトについて #NTTコミュニケーションズ(以降、NTT Com)社内で製作したオンボーディングハンドブックの内容を、より一般化して広く公開するものです。 ソースコード #本書のソースコードは https://github.com/nttcom/onboarding-handbook で公開しています。 ライセンス #NTT Communications Corporation 作『オンボーディング ハンドブック』は クリエイティブ・コモンズ 表示 - 非営利 - 継承 4.0 国際 ライセンス で提供されています。 関連ハンドブック #リモートワークの働き方に特化したリモートワークハンドブックや、チームビルディングのプラクティスをまとめたチームビルディングハンドブックも参照ください。 読み始める #こちらから本編に進めます。 はじめに
チームで仕事するとき、みんなもう少し自分の存在、自分のリアクションがチームに与える影響を自覚した方がいい。 例えばミーティングでブレストしているとき、議論が前に進むのは、あるときふと場に出されたアイデアに対して、誰かが"それいいですね"って言った瞬間である。アイデアを出したとき、その人にはふつう、確信なんてほとんどない。僕なんか自分の意見に自信なんかなくて(大体みんなそうなのだ)、言ってみて、まわりの反応を見て、あ、なんか良さそうだ…と思ったときにやっと前に進むことができる。みんな、自信なんてないのだ。だからアイデアは、場に出されたときはまだ、波際の砂のお城のようにやわらかである。 しかし、あるアイデアに対して、それいいね、と声をもらったとき。いい顔が見えたとき。姿勢が前のめりになってくるとき。そのときとあるアイデアは、はじめて光るのだ、形になる可能性を見せるのだ。 * 逆に言えば、議論に
社内情報共有についての考え方 - An Epicurean
タイトルのようなエントリを社内に向けて書いたので、手直しして社外に放流するものである。 社内で情報共有フローやガイドライン整備などを進めている。ルールは少ないに越したことはないので「ルール作り」にはしたくなくて、考え方やガイドラインみたいなところに留めて、文化や共通言語を醸成していきたいとも考えている。 これは、今後組織が大きくなる上で、「スピードを落とさないため」に必要だと考えている。新しく入ってきた人が立ち上がりを早くパフォーマンスを発揮してもらえるようにしたい。 オンボーディングの整備は大事で、それもやっていかないといけない。でも今のフェーズではどうしても未整備の部分も多い。そういう荒地を楽しんで走破できる自走力があって、自分で決めて整備もできて、組織と一緒に成長してくれる人を採用していきたい。なので「自走しやすい環境」を整えたい。そのために必要だと考えている点が以下の3点です。 デ
『いいヤツの話』
gakukentのブログ もともとは新座ストロングサッカークラブと自分の趣味を書き込むサイトでしたが最近はＦＢばかりになり、どちらかというと昔のがくけんとのブログの記録を残しておくためのサイトですかね。 2004年と古い話ですが、良い話なので、アップしちゃいます。 2004年9月11日に新座市サッカーフェスティバルにて 清雲清純氏（元・ ユース日本代表監督、JFF-UNITED 監督、当時 大宮アルディージャ ＳＳＣ代表の高校の後輩です。）による指導者講習会にて聞いた話を以下の通りメモしました。ご参考にしていただければ幸いです。 以下は清雲さんの話・・・ 今日は、一人の男についてお話したいと思います。 私（清雲氏）が小野と初めて出会ったのは、１９９７年、ユ一ス（Ｕ２０）日本代表監督になって彼を合宿に召集した時ですが、彼は挨拶のときから、きちんとしており、他の選手とはちがっていました。 代表
Page Scrolling Vertical Scrolling Horizontal Scrolling Wrapped Scrolling
GLAYを25年率いたリーダー論がここに。 「“全部自分の責任です”っていうリーダーを、俺は信用しない」TAKUROが語るリーダーの哲学 日本を代表するロックバンド・GLAY。 今年でデビュー25周年を迎え、10月2日には15枚目のアルバム『NO DEMOCRACY』のリリースを控えています。 そんなモンスターバンドを率いてきたギタリスト・TAKUROさんは、2005年に設立した事務所「loversoul」の代表取締役であり、その後自主レーベル「loversoul music ＆ associates」、現「LSG」も立ち上げています。 今回新R25では、常にリーダーという立場でバンドや会社を牽引してきたTAKUROさんに、「リーダーとは何か？」というテーマで取材を行いました。 TAKUROさんの考える「カリスマとは？」「責任の取り方とは？」「20代ですべきこととは？」。深いお話をたくさん
「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法/product management rsgt2023
4プロダクトを成功させようと悪戦苦闘しているものの、プロダクトの行く末についてプロダクトオーナーやプロダクトマネージャといった一部の人の意思決定に依存しすぎてしまっていると悩んでいるチームが、彼らと共にプロダクトマネジメントを実行できるようにするセッションです。「プロダクトオーナーがボトルネック」という状況から、おさらばしましょう。 概要 https://confengine.com/conferences/regional-scrum-gathering-tokyo-2023/proposal/17655 発表者 https://twitter.com/_N_A_ https://note.com/mryy
Scrum Fest Osaka 2023 https://confengine.com/conferences/scrum-fest-osaka-2023/proposal/18546 「Fun Done Learnのうた」はこちら https://developers.kddi.com/b…
これまで私はプロダクトマネジメントやデザインディレクションを行う立場として、BtoBにBtoC、iOSにAndroidにWebにWatchOSにIoT、ゼロイチにグロース。様々な分野、プラットフォーム、フェーズでサービスを開発する機会に恵まれてきました。 その中で一緒にチームを組んだフロントエンド、サーバーサイド、iOS、Android、インフラ、データ、様々なエンジニアの方を思い出しながら「ああ、心強いな」と感じた色々なタイプの特徴を、リスペクトの想いを持って、プロダクトマネージャーやデザイナーの視点でまとめてみました。 それではいってみましょう。 目的にフォーカスしている 要件をただ実装するのではなく、ビジネスの目的はなにか、ユーザーが真に求めているものはなにか、なにがサービスの生死を分けるのか、技術は目的を達成するための手段だと客観的に捉え、真の目的に対して解決策を提案し続けてくれる
チームでどうやって活躍するか、まだイメージがついてない、振られた仕事をやっているだけで、仕事をしている間は忙しいけど、確認待ちになるとすぐ暇になってしまう、というメンバーの悩みを聞いていた。 巨大なチーム、巨大なプロダクトだと、すぐに全容を把握するのは難しい。その中で、この範囲なら触れています、任せてください、という庭を作るとよいのでは、という話をした。 思いつきで話したわりには意外といいことを言ってるなと思ったので掘り下げて書いてみます。 庭とは 現代では、庭のある家に住んでる人は少ないかもしれない。うちは実家が田舎だったので庭があって、ボールを蹴って回ったり、石をめくってアリを観察したり、隣の家の庭との境界もゆるくて、冒険と言って隣の家の庭で遊んだりしていた。 大人になってからの庭というと、池袋で遊んでた人が「池袋は俺の庭」と言ったり、JR新宿駅の東口を出たら椎名林檎の庭があることが知
デブサミ2020夏の発表資料となります。 当日発表しなかった資料についても参考資料として最後に追加しております
こんにちは。シニアスクラムマスターの天野 @ama_ch です。 サイボウズの開発組織において、今後の成長を加速させるためには、組織の基本単位をスクラムチームのような自律的な小さなチームにしてスケールさせることが非常に大切だと考えています。サイボウズは比較的スクラムが普及している組織ではありますが、組織内のすべてのチームがスクラムを採用しているわけではありません。 フレームワークとしてスクラムを採用するかどうかはチームの自由です。しかし、健全なチーム環境を整えることはすべてのチームにとって重要です。チームやチームワークに関する情報は巷に多く存在しますが、我々のようにすでにある程度の規模で活動しているプロダクト開発組織で、チーム環境を整えるために実践的に使える情報がないことが悩みでした。 そこで、これまでのチームに関する学びと実践を踏まえ、サイボウズの開発組織の文脈において、スクラムを実践し
2014年から10倍に拡大したクラスメソッド。私達は急成長する中でいくつもの悩みや課題を抱えてきました。本記事では私達が抱えていた組織の悩みをお伝えし、またその解決策として私達が開発しているProfllyというサービスをご紹介します。 はじめに 私がクラスメソッドに入社したのは2014年1月。当時は社員数も50人程度で、オフィスは東京にしか無く、和気あいあいと仕事していました。しかしその後組織は急成長。2017年末には100人、2019年頭には200人と急増しました。現在では日本本社だけで350人、グループ全体で500人弱と、2014年から比べて10倍に成長しています。 多くの企業が経験することだと思いますが、クラスメソッドも急成長する中でいくつもの悩みや課題を抱えてきました。本記事では私達が抱えていた組織の悩みをお伝えし、またその解決策として私達が開発しているProfllyというサービス
Pull Requestを小さくする戦略 - 開発チームのパフォーマンス向上のための第一歩 - Agile Journey
Agile Journeyをご覧の皆さん、こんにちは。ZOZOの御立田です。 私が所属する株式会社ZOZOは、「世界中をカッコよく、世界中に笑顔を。」を企業理念として掲げ、ファッションEC「ZOZOTOWN」、ファッションコーディネートアプリ「WEAR」などの各種サービスの企画・開発・運営や、「ZOZOSUIT」「ZOZOMAT」「ZOZOGLASS」などの計測テクノロジーの開発・活用をおこなっています。また、カスタマーサポート、物流拠点「ZOZOBASE」を運営しています。 ファッションコーディネートアプリ「WEAR」やショップスタッフの販売サポートツール「FAANS」を手がける、私が所属するブランドソリューション開発本部では、「開発生産性を3倍に」を目標に掲げ、多くの改善を進めています。 「開発生産性」をどのように定義するかには議論がありますが、まず私たちが向き合ったのは「仕事量の生産
19歳で転職した私が気づいた、すれ違わないチーム開発をするために必要なこと - SMARTCAMP Engineer Blog
こんにちは！！！スマートキャンプ、エンジニアの吉永です。 私は8月にスマートキャンプに中途入社し、今月で3ヶ月目となります。 前職では受託開発を主にした小さな企業に未経験で入社し、そこで一年間フロントエンド、バックエンド問わず開発したり、テックリードのような業務も行ったりしていました。 小さな会社なので部署というような区切りはほぼ無く、社長含め全てのメンバーがエンジニアといったようなエンジニア集団の環境で、日々開発タスクをこなしていました。 しかしある時期をきっかけに、外部の方と協力する機会が増え、エンジニアだけがいる環境から様々な人間が関わる環境へと変わっていき、とあるプロジェクトを進めている最中、私達エンジニアサイドと、企画サイド、デザイナーサイドでうまく噛み合わず、スケジュールが大幅に遅れてしまいました。 そして、このことをきっかけに私自身がエンジニア以外の人間に対して苦手意識を持っ
エンジニアリングマネージャー業の抽象度マッピング / Abstraction mapping of engineering manager's job
エンジニアリングマネージャー業の抽象度マッピング 〜EMの成長プロセスとそれを支えるアジャイル〜 2023.01.11 #RSGT2023 Yoshiki Iida
新刊『チームトポロジー』発売のお知らせ
みなさんこんにちは。@ryuzeeです。 言いたいことはタイトルに書いたとおりなのですが、2021年12月1日に、新刊『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』が発売になります。 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計著者／訳者：マシュー・スケルトン、 マニュエル・パイス、 原田 騎郎、 永瀬 美穂、 吉羽 龍太郎出版社：日本能率協会マネジメントセンター発売日：2021-12-01単行本：280ページISBN-13：9784820729631ASIN：4820729632 原著はMatthew Skelton、Manuel Pais氏の『Team Topologies: Organizing Business and Technology Teams for Fast Flow』で、翻訳は株式会社アトラクタのアジャイルコーチ（いつ
プロダクトデザイナーのスキルマップを考えてみた
何でも屋が増えてもスケールしない「UXが付く肩書きがもつ不安感 」という記事で、UX デザイナーが『何でも屋』になっているのでは？という疑問を投げかけました。ひとりのデザイナーとして様々な分野に関わりたいと思うものの、UX の文脈で求められるスキルと知識の幅は広いので、すべてをカバーするのが極めて難しいです。また、ひとりですべてを抱え込むと、組織が求める品質とスピードに応えることができない場合があります。 初期は複数の役割を受け持つことになりますが、プロダクトと組織が成長していかなければいけないときも同じように何でも携わるというやり方が適しているとは限りません。専門性を伸ばしていくことでより高度な提案とアウトプットができますし、互いの弱みを補いながらチームとして動く意味も増していきます。 デザイナーをひとりしか雇えない環境では数多くの分野に精通している人のほうが良いですが、そういう人ばかり
アルカイダに負け続けた米軍が勝つ組織になれた理由は「7500人で毎日90分の電話会議」にあった | サイボウズ式
ITは、世界を便利にする一方で、複雑にもします。 このことは、市民を守る責務を担う人にとって難しい問題です。現代の戦争において、敵はあらゆる技術を利用して、予測不可能で「カオス」な存在となっているからです。 スタンリー・マクリスタル元米軍司令官の話によれば、国際テロ組織であるイラクのアルカイダは、その典型だったといえます。 マクリスタルさんは、2003年から5年間に渡って、イラクのアルカイダに挑みました。多くを失った経験を通じて、組織変革と適応性は決して高尚なゴールではないこと、むしろ戦争で勝利する必須条件であることを学んだのです。 ITによって複雑化する社会、アルカイダに勝つために米軍が迎えた変化、新たな世界で組織が生き残るための教訓とは。マクリスタルさんとサイボウズの代表取締役社長青野慶久が話します。
Kyashの@konifarです。最近雑なアウトプットが減っているなと感じているので、自分が所属するチームでやった『チームラーニング』という催しについて書きます。 チームラーニングとは マッキンゼーでプロジェクト開始時に行っているチームビルディングイベントらしいです。 働く時間帯や環境、自分の不得手などを共有することで、チームで働きやすい状態を作ろうというものですね。 バズってた「チームラーニング」をやってみたら、チームの生産性上がりそう という記事がSlackチャネルに投げ込まれたのを見て、これはよさそうだと思い実施してみることにしたのでした。 あとで同僚の@ussyに教えてもらったのですが、マッキンゼーでのやり方や効果はMcKinsey Careers: Inside the team learning – one tool to create balance で紹介されています。もし
「アジャイルやスクラムはソフトウェア開発に適用するもの」というイメージが強いかもしれない。しかし、イーロン・マスク氏が率いるTeslaやSpaceXでは、電気自動車やロケットというハードウェアにもアジャイルやスクラムの考え方を取り入れ、これまでのモノ作りでは考えられないような短期間で新しいバージョンの製品をリリースするサイクルを確立している。そして今、その先を目指そうとしているという。 認定スクラムトレーナーとして活躍し、MicrosoftやAmazon、TeslaやSpaceXでアジャイル導入支援の経験を持つAgile Business InstituteのCEO、Joe Justice（ジョー・ジャスティス）氏が2022年7月に開催された「Agile Tech EXPO 2022」の基調講演に登場し、その「凄さ」を紹介した。 「アジャイルは何もソフトウェアだけのものではありません。もち
リモートワークの幻滅期を乗り越えろ｜倉貫義人
ここにきて多くの企業がリモートワーク（テレワーク／在宅勤務）に取り組み始めてますね。10年近く前からやってる身としては隔世の感があります。 取り組み始めた皆さんのために私たちも何か出来ないかと考えて、拙著「リモートチームでうまくいく」を期間限定で全文公開しました。 これまでリモートワーク反対されていたり、躊躇されていた企業が今や待ったなしの状況で、取り組まざるを得なくなっていますね。その結果、満員電車に乗らなくてもよいし、時間も有意義に使えたりして「リモートワークいいね！」という意見も多く出ています。 一方で、企業側としてはチームワークや仕事の進め方、労務やセキュリティなど、あまり準備しきれずに始めてしまったことで、実務上の課題があぶり出されてくる頃です。 同時に、リモートワークで働く側も「集中できていい！」と言ってた人が、「やっぱり寂しい」などと言い出たり、色々と現実的な課題が襲ってくる
Introduction {#intro}
Introduction A code review is a process where someone other than the author(s) of a piece of code examines that code. At Google, we use code review to maintain the quality of our code and products. This documentation is the canonical description of Google’s code review processes and policies. This page is an overview of our code review process. There are two other large documents that are a part o
A Texas-based company that provides health insurances and benefit plans disclosed a data breach affecting almost 2.5 million people, some of whom had their Social Security number stolen. WebTPA said…
How to write code review comments Summary Be kind. Explain your reasoning. Balance giving explicit directions with just pointing out problems and letting the developer decide. Encourage developers to simplify code or add code comments instead of just explaining the complexity to you. Courtesy In general, it is important to be courteous and respectful while also being very clear and helpful to the
スライド概要 なぜ、安定したチームが必要なのか？ 安定したチームを維持しづらい時代に、どうすればよいのか？ ダイナミックリチーミングを意識して組織を成長させ、弾力的で柔軟な構造を作ったり、ダイナミックリーチングを可能にするために既存の組織を調整して、安定したチームが維持しづらい時代を乗り越えるためのヒントになればと思います。
Google が How to do a code review のドキュメントを公開しました。いくつかのセクションのうち、レビュアーのための1つ Speed of Code Reviews を読んで、読み取ったものをメモします。 ※ 日本語に翻訳されたプロジェクトがあります: Google エンジニアリング・プラクティス ドキュメント | eng-practices なぜコードレビューは早くするべきか？ Googleは、”個人”の開発者のコードの書く早さを最適化するのではなく、開発者の”チーム”が一緒にプロダクトを作る早さを最適化する。個人の早さは重要だが、チーム全体のベロシティほど重要ではない。 レビューが遅いとき、次のことが発生する: チーム全体の速度が低下する レビューにすぐに反応しない人は個人として別の仕事を完了できる。ただし、他のチームメンバーの機能開発やバグフィックスは、レビ
Team Topologies
Organizing business and technology team-of-teams organizations for fast flow: book | training | consulting
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
無能な同僚と働くということ。 - WETな備忘録
だれかの進捗をうまく把握できないときのフレーズ集 - Qiita
チームで仕事をするなら、リアクションし続けよ｜森 一貴（Mori Kazuki）
GitLabで学んだ最高の働き方 Developers Summit 2022-02-18
「“全部自分の責任です”っていうリーダーを、俺は信用しない」TAKUROが語るリーダーの哲学｜新R25 - シゴトも人生も、もっと楽しもう。
チームにノリをもたらした時にいた「二人目に踊る人」の共通点
同じチームにいて最高に心強かったエンジニアの特徴をまとめてみた - Qiita
チーム開発で活躍するために、自分の庭を作れると良い - hitode909の日記
心理的安全ジャーニー Slackで安全を実装する5つの手法
開発チーム作成ガイドを公開します - Cybozu Inside Out | サイボウズエンジニアのブログ
クラスメソッドが抱えていた組織の悩みを解決したProflly | DevelopersIO
「Asana、Jooto、Wrike……、無料で使えるカンバンボードを徹底比較！」――急遽テレワークを導入した中小企業の顛末記（172）【急遽テレワーク導入！の顛末記】
チームラーニングでチームの共通認識を揃える - Kyash Product Blog
アジャイルやスクラムでも遅い？ TeslaやSpaceXがイノベーションを生み出せる理由
TechCrunch | Startup and Technology News
How to write code review comments
ダイナミックリチーミングから学ぶ 不確実な状況に適応し続けるための チーム作り | ドクセル
Speed of Code Reviews を読んでのメモ - miso_soup3 Blog