組織の「バラバラ感」はなぜ生まれる？ メンバーの一体感を高める「創造的対話」の取り入れ方 | SELECK [セレック]
リモートワークが促進され、また一方ではD＆Iが進み多様性のあるチームが歓迎されるこの時代において、改めて組織におけるコミュニケーションの在り方が問われている。 今回お話を聞くのは、「組織の専門家集団」株式会社MIMIGURIの代表取締役Co-CEOである安斎 勇樹さんと、株式会社ツクルバの共同創業者であり、現在は対話の場づくりツール「emochan（エモチャン）」を展開する株式会社KOUの代表も務める中村 真広さん。 ▼会議や1on1に導入することで、スムーズな対話を実現するemochan お二人に共通するのは、「対話」によって組織が抱える課題を解決するアプローチを試みてきたことだ。 対話とは、表には見えない互いの「前提・価値観・思考」を理解しようとするコミュニケーションを指す。その対話がさらに深まると、共に前を向いて新しい価値を生み出そうとする「創造的対話」が生まれ、それが創造的なアウト
![組織の「バラバラ感」はなぜ生まれる？ メンバーの一体感を高める「創造的対話」の取り入れ方 | SELECK [セレック]](https://cdn-ak-scissors.b.st-hatena.com/image/square/8dbf66d8efd757c9606b4259b1230f52c604605c/height=288;version=1;width=512/https%3A%2F%2Fdpd29bjwmgbr8.cloudfront.net%2Fwp-content%2Fuploads%2F2022%2F03%2F17163426%2Fbddeb2a9999638e1058ffce1f0a641c3.jpg)
Team Topologies(by Manuel Pais)のキーポイント
この記事について CaSEというPodcastを時々聴いているのだけど、その最新話がTeam Topologiesの著者であるManuel Pais氏のゲスト回だった。すごく学びが多く、同じ悩みをもつ人も多いと思ったので内容や思考を整理してみたものを記事化してみた。ちなみに書籍のTeam Topologiesは読んでいません。 “two pizza” チームの挑戦 話はAmazon CTOのVerner Vogelのインタビューから始まる。2006年頃にジェフベゾスがTwo pizzaチームの話をしたのは有名だが、面白いのはAWSはまさにプラットフォームチームをX as a Serviceモードにした結果になっていて、意図的ではないにしろトポロジーを体現していたのだと思った。これは後半のプラットフォームチームの話にも繋がってくる 本題に戻ると、Two pizzaサイズで自己組織化に向かった
組織開発の意思決定透明化のために ODDR を試すことにしました | DevelopersIO
こんにちわ。てぃーびーです。 最近システム開発界隈でたまに話題をみかける「ADR」。 ADR は Architectural Decision Records の略で、アーキテクチャーの意思決定を決まったフォーマットで記録し続ける手法です。アーキテクチャーの意思決定後、時間の経過とともに当時のアーキテクチャーを設計した人が異動や退職で不在になり、後任が現在の設計を検討する上で、なぜ現状のアーキテクチャーになっているか確認したい、といったときがこの記録が活用される典型的なケースです。それ以外にも人の記憶は不確かなため、意思決定をした本人にとっても記録は便利です。 そういった必要性に関して niku さんの以下の記事が参考になります。 2020-05-19 ADR(Architectural Decision Records)を書くと決めた理由を自分の言葉で書き出した｜ヽ（´・肉・｀）ノ｜no
僕がピープルマネジメントを学んだ本たち
はじめに 僕はかれこれ２０年くらいピープルマネジメントに関わっているのですが、以前いた会社はとても小さな地方企業だったので人材育成や教育なんて仕組みは全く無く、独学しか方法がありませんでした。そこでマネジメントやリーダーシップに関わる本を片っ端から読んで実践で試してきた、という経緯があります。本当はちゃんとした教育を受けたほうが良かったんだろうな、とも思うのですが、まぁそこはタイミングや状況があるので仕方がないですね。 そこで今日は、僕がピープルマネジメントを学ぶために読んで、実際に影響を受けた本をご紹介したいと思います。古典からトリッキーなものまで、思い入れがあるものをチョイスしました。 僕がピープルマネジメントを学んだ本たち マネジメント[エッセンシャル版] - 基本と原則 マネジメント[エッセンシャル版] - 基本と原則 posted with AmaQuickat 2021.11.
コードレビューとPull Request、そしてその承認機能の副作用について考える - 時計を壊せ
用語 レビュアー 対象となるコードをレビューする人のことを指します。 レビュイー レビューを受ける人、つまりレビューする対象のコードを書いた人のことを指します。 tl;dr アプリケーション開発業務におけるコードレビューはコードの正しさや質そして一貫性を保ち、それらと同時にコードに対するチームとしての共有知を作り上げる良いプラクティスだと思います アプリケーション開発チーム内でのコードレビューにおいてPull Requestを使ったレビューのスタイルは一般的ですが、Pull Requestの承認は実際にはほとんど意味がないのではないでしょうか？ ほとんど意味がないにも関わらず、承認の有無によって業務フローが左右されることでそれが権威的に扱われてしまいオーナーシップを希薄化させ、結果的にコードレビューのコストが増加したりそれを行う目的を見失ってしまっていることはないでしょうか？ Pull R
50人で評価額2,100億円を越えたNotionに聞く、少数精鋭のプロダクト組織のつくりかた：連載「クリエイティブ組織の要諦」第3回｜designing
50人で評価額2,100億円を越えたNotionに聞く、少数精鋭のプロダクト組織のつくりかた：連載「クリエイティブ組織の要諦」第3回 本記事は、組織イノベーションの知を耕す学びのメディア『CULTIBASE』との共同企画で、双方の媒体に掲載されています。連載『クリエイティブ組織の要諦』では、デザイナーをはじめとしたクリエイティブ職の組織作りのヒントを得るため、注目企業にインタビューを重ねています。デザイン組織立ち上げを支援してきたMIMIGURI CO-CEO ミナベトモミを聞き手に、組織デザイン／組織開発の両面からヒントを探っていきます。 第3回に登場するのは、『Notion』を開発するNotion Labs（以下、Notion）です。2020年4月に企業評価額約2,100億円に達した際、従業員数は50〜60人だったという同社（2020年7月時点）。つい先日の2021年10月9日（日本時
サイバーエージェントとメルカリにみる組織強化システムの構造的分解
これはなにか サイバーエージェントとメルカリの「採用前〜退社後」という一連のエンプロイー・ジャーニーに内包されている組織強化システムを構造的に分解するポストです。 メルカリのCuture Doc公開に際して、実際に起きたことを懐かしく思いツイートしたら予想外の反響をいただいたのですが、その中で私のもうひとつの古巣でもあるサイバーエージェントのことを引き合いに出して貶すような引用リツイートも見られました。 退職時、進太郎さんに1 on 1の時間もらって最後の挨拶したときに貰った「まあ株式会社インターネットみたいなものだから」という言葉を忘れない。2年半前のことなので、今に始まったポーズじゃなくて昔からのスタンス。 Culture Doc | 採用情報 株式会社メルカリ https://t.co/1kTYHh0wVN pic.twitter.com/d3qJwUExcB — きょすーけ | D
Ubie Discoveryに入社して感じた「これまでとの違い」 - maru source
@h13i32maru Ubie Discoveryに入社して半年がたった。半年働いてみて、これまで働いてきた会社と比べて違うなと感じたことが結構ある。それらを忘れないように残しておこうと思う。ちなみに個人的に感じたことや解釈なので、ズレていることがあるかもしれないのであくまでも主観ということで。 人ではなく仕組みやコトを管理 組織運営に組み込まれた権限委譲 徹底した目標設定と運用 人事評価をしない意思決定 人ではなく仕組みやコトを管理 Ubie Discoveryではマネージャーと呼ばれる人はいないし部長などの役職もない。じゃあどうやって組織を運営しているかというと、そもそも「人や人の行動を管理（マネージ）する」という管理スタイルではない。Ubie Discoveryで管理しているものは「目標・目標達成の方法・様々な型（プロセスやフレームワークのこと）」などの仕組みやコトである。 そして
Team Topologies in Souzoh | メルカリエンジニアリング
こんにちは。ソウゾウの Software Engineer / Engineering Manager の@motokieeです。連載：「メルカリShops」プレオープンまでの開発の裏側の4日目を担当します。 4日目は、ソウゾウがどのような体制でメルカリShopsを開発しているかについて、Team Topologiesの解説を交えてお送りします。 はじめに チームの在り方には様々な形がありたくさんの議論が交わされていると思います。自分自身も以前いた会社はもちろん、メルカリに入ってからも旧ソウゾウ、JP(日本事業)、メルペイとの関わり合いなど様々なチーム構成を見てきました。 タイトルにあるTeam Topologiesですが、https://teamtopologies.com/ では以下のように定義されています。 Team Topologies is the leading appro
うちのチームのデイリースクラム 2021年夏編 - 半空洞男女関係
「自分ができるタスクもうないので次のスプリントのPBIに着手します」問題をなるべくわかりやすく説明したい。良い例え話あるかな。— ama-ch (@ama_ch) August 6, 2021 を見ていて、うちのチームのデイリースクラムを紹介したくなったのでかいてみます。こういうのを書くのははじめてかもしれない。 全体デイリースクラム まず、決まった時間になったら一つの部屋に集まって、全体のデイリースクラムをする。今は3チームくらいあるので、全体でやりとりしたいことも多い。 全体のゴールとかあるわけでもないので、ただの朝会って感じ。(「朝会」でいいのかも) チャットで報告でおしまいでもいいのだが、「知らなかったー」とかはあるので、共有したい勤怠の連絡事項とか、今日はリリースがありますねーとか、この前の障害についてですがー、などなど、全体で知っておきたい情報はここで共有する。 現状、品証チー
新参者だけどバーンアウトしかけているチームを立て直す
ジョインしたばかりの組織に違和感を感じたとき、新鮮な目線で改善すると良いよという発表をしました。
なぜスクラムチームをスケールしたくなるのか - だいくしー(@daiksy)のはてなブログ
Nexus, Scrum@Scale, LeSS, SAFeなど、スクラムチームをスケーリングする手法はたくさん存在する。 しかし、アジャイルコーチなどに、「スクラムをスケールするにはどうすればいいですか？」と聞くと「そもそもスケールをするな」と言われることもある。ぼくも基本的にはこれに同意する。 コンパクトな職能横断型のチームで、短いサイクルで高速に、安定したペースで開発をする。これをずっと続けることができるのならばそれが一番良い。 なのになぜ、人々はスクラムチームをスケールしたくなるのか。なぜこんなにたくさんのスケーリング手法が存在するのだろうか？ そういうことを考えてみた。 最初から人がたくさん必要な場合 そもそも最初からスケールされたチームでやりたいパターンがある。大規模な開発などはそうだろう。 小さくローンチして、インクリメンタルにユーザーフィードバックを受けながら開発できれば理
スプリント1を始める前にどんな準備をするか
みなさんこんにちは。@ryuzeeです。 スクラムでスプリント1を開始する前にどんな準備をしておくと良いかについては、Regional Scrum Gathering Tokyo 2018で話をしたのですが、改めて文章化してみました。 なお、かなり長いので関係なさそうなところは適宜読み飛ばしてください。 1. はじめに1.1 この記事の目的スクラムでは、プロダクトバックログが用意されていて、それを元にスクラムチームでスプリントプランニングを実施し、スプリント期間中毎日デイリースクラムを行い、最後にスプリントレビューとレトロスペクティブを実施することになっています。 つまりプロダクトバックとスクラムチームが存在するところがスタート地点になっています。言い換えるとそれらがないとスプリントが開始できません。 本稿では、実際にスクラムでスプリントを開始する前にどんな準備を行うと良いのかを考察してい
チーム開発で活躍するために、自分の庭を作れると良い - hitode909の日記
チームでどうやって活躍するか、まだイメージがついてない、振られた仕事をやっているだけで、仕事をしている間は忙しいけど、確認待ちになるとすぐ暇になってしまう、というメンバーの悩みを聞いていた。 巨大なチーム、巨大なプロダクトだと、すぐに全容を把握するのは難しい。その中で、この範囲なら触れています、任せてください、という庭を作るとよいのでは、という話をした。 思いつきで話したわりには意外といいことを言ってるなと思ったので掘り下げて書いてみます。 庭とは 現代では、庭のある家に住んでる人は少ないかもしれない。うちは実家が田舎だったので庭があって、ボールを蹴って回ったり、石をめくってアリを観察したり、隣の家の庭との境界もゆるくて、冒険と言って隣の家の庭で遊んだりしていた。 大人になってからの庭というと、池袋で遊んでた人が「池袋は俺の庭」と言ったり、JR新宿駅の東口を出たら椎名林檎の庭があることが知
［報告］ヤッホーの井手社長に聞くティール組織の作り方
ヤッホーブルーイング井手直行社長（以下、井手氏）：まず、ヤッホーブルーイングの骨格をお話ししていきます。看板製品は「よなよなエール」。1997年に我々が最初につくったビールの1つで、今年で23年目です。家庭で飲める手ごろな本格エールビールというのがコンセプトです。ブランドキャラクターは「知的な変わり者」で、このキャラクターが会社の組織文化にもなっています。 ティール組織というところでは、私たちは経営理念というのをとても大事にしてきました。経営理念の一番の上位概念は会社のミッションです。私が2008年に社長になる少し前ごろにつくり、社長になって本格的に浸透させようと思いました。ミッションというのは使命であり、会社の存在する意義や目的です。また長期的な将来像の目標を立てないといけないので、ある程度指標となる目安の最終像としてビジョンという言い方をするものも持っています。 ミッションは「ビールに
CTOの頭の中：技術を財務で表現する｜Shin Takeuchi｜note
会社の体制が大きく変わり、カオスの中に少しの静寂（暇）ができました。特に日々執行に勤しんでいる方々は皆そうだと思いますが、色んなこと考えているのにそのプロセスをアウトプットする機会があまりなく、結果や結論、最終的な決断のみが共有されるため、サクセッションプランに対する有効な情報を残すことも出来ていないことと思います。僕もその一人。 この時間を有効に活用するため、頭の中にあるイメージと考え方をここに、時間の許す限り吐き出していこうと思います。時折、言葉が足りないところも前提条件やバイアスの記述が足りないところもあるかと思いますが、混沌とした頭の中を曝け出すプロセスにはつきものですので、大目に見ながら読んでいただけると幸いです。 財務諸表と同じように見える化する会社は財務諸表によって経営されるものなので、経営者たるもの財務諸表を見ながら戦略を立てるべきであると僕は考えています。数字以外信じない
青学･原監督｢強いチームは指示待ちしない｣
96回目を迎えたお正月恒例の箱根駅伝。青山学院大学陸上競技部（以下、青学陸上競技部）が2年ぶり5度目の総合優勝に輝きました。 昨年こそ東海大学に敗れ5連覇を逃したものの、王座に返り咲き。青山学院大学の強さがいまだ健在であることを示しました。かつては箱根駅伝の予選会さえ通過できない弱小チームをここまでに強くし、さらに勝ち続ける集団へと育ててきたのが、原晋監督です。著書『フツーの会社員だった僕が、青山学院大学を箱根駅伝優勝に導いた47の言葉』にも記されている常勝チームのつくり方を明かします。 選手を成長させていくことが役割 2年ぶりに箱根駅伝の優勝を果たすことができました。青山学院大学陸上競技部（以下、青学陸上競技部）が、大学駅伝の歴史にまたひとつ大きな足跡を残せたのではないかと思っています。 しかし、私が青学陸上競技部の監督に就任した2004年当時は、箱根駅伝の予選会さえ通過できない弱いチー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
チームトポロジーによるエンジニアリングチーム構造の負債解消 -日本語版-
Tuckmanは間違っている！Doc Norton氏のリチーミングモデル
チームで働くための礼節と心理的安全性 / Civility and psychological safety for working in a team
