組織が死にいたる病
今日、会社の事業部長と話していて、どうしても目の前の案件や問題解決を優先してしまって、気づいたら未来への打ち手が全く打てずに早半年・・・みたいな状況になりやすいよねー・・・！！という話をしていたので、自戒200%ぐらいで、組織が未来への… — 今日、会社の事業部長と話していて、どうしても目の前の案件や問題解決を優先してしまって、気づいたら未来への打ち手が全く打てずに早半年・・・みたいな状況になりやすいよねー・・・！！という話をしていたので、自戒200%ぐらいで、組織が未来への布石が打てなくなるフラグを考えてみた。 熱さと議論が煮詰まり死に至ったsaileチームの皆さんリーダーが忙しすぎる最も多くの情報を持ち、ビジョンを示す役割のリーダーが目の前のタスクに追われてしまい、「未来を考え、メンバーに示す」という本来の役割を全うできていないケース。忙しすぎる＝戦いを略せていない＝戦略がない＝頭を使
採用とか退職とか評価に関するよもやま話
こんにちは。@ryuzeeです。 以前に、採用プロセスを真剣に考えろという話を書きましたが、ちょっと関連する話を書こうと思います。 採用に関するメトリクスを取ろう採用プロセスに真面目に取り組んでいる会社ならやっていると思われますが、採用活動をするにあたってはメトリクスを取ることが望ましいです。特に成長中の組織でたくさんの人を採用したい場合や、ある一定規模の組織でそれは顕著です。取るべきメトリクスには以下のようなものがあるはずです。 総応募者数採用媒体別応募者数エージェント別紹介者数社員の紹介によって応募が来た数自社の採用サイトから応募が来た数各属性で書類選考を通った数各属性で一次面接を通った数各属性で二次面接を通った数 (ここは各社によって何回面接があるか違いますが…)各属性で最終面接を通った数 (同上)プロセスの途中で辞退した数オファーを出した数オファーを受けた数オファーを辞退した数各採
ふりかえりに入る前にする2つの質問 | GuildWorks Blog
現場コーチをやっていると、ふりかえり(例えばKPT)で、いきなり「続けたいこと(Keep)」を出し始めるような場を見かけることがあります。このような場合、往々にしてどこかフワッとしたふりかえりになりがちです。 私は、よく現場コーチでふりかえりをする際に、以下の2つの質問をするようにしています。 1：「前回から今回の間でなにがありましたか？」 2：「前回から今回の活動はうまくできましたか？」 この2つの質問を答えも含めて5分程度でサッとやってからふりかえりに入っていきます。 ＃こういうのも含めて「ふりかえり」と呼ぶ方もいると思います。 1：「前回から今回の間でなにがありましたか？」 前回から今回の間であったことをそれぞれ思い出してもらい、その思い出したもので印象に残っていることを1人1つずつ話してもらいます。例えば「クライアントに動くものを見てもらった」「◯◯機能をリリースした」「残業しなか
「ふりかえり」を効果的にするための実践的なトライの出しかた 〜 TRYを掛け声で終わらせない | Social Change!
メンバーの一人一人が自ら考えて行動し、それでいて仲間と協調し合うような自律的なチームを目指して、日々様々な取り組みをしています。その中でも、セルフマネジメントできる人材を育てるのに効果的だと考えているのが「ふりかえり」です。 そして、私たちは上手に「ふりかえり」ができるようにするために、メンターがついて、そのレビューを行っています。先日も私が「ふりかえり」のレビューをしたのですが、今回はその際に話した効果的なトライの出しかたについて書きました。 「KPT」を使った「ふりかえり」を「レビュー」している そもそも「ふりかえり」とは何か、その手法である「KPT」とは何かについて、以前に記事を書いています。 自律的に現場を改善できるチームをつくるための「ふりかえり」の進め方 〜 KPTと進め方のノウハウ KPTは、Keep/Problem/Tryの略で、「Keep＝よかったこと」「Problem＝
【資料公開】強いチームの作り方 | Ryuzee.com
2015年11月10日に某社の社内勉強会で、「強いチームの作り方」というテーマで話をしたのでその際の資料を公開しておきます。 内容自体は、WEB+DB PRESS 83号に書いた内容なので興味があればそちらを参照ください。 最近DevOpsの文脈ですぐに「インフラ自動化しないといけない」とか「ツール使って効率化」みたいな話を頻繁に聞きます。 が、端的にいえば、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」というデマルコの一節の通りであり、 DevOpsの本質もツールではなく、CLAMS(Culture、Lean、Automation、Measurement、Sharing)であって、土台となるのはやはり組織やチームの文化になります。 一度自分たちのチームや組織について考えてみるとよいと思います。 アジャイルコーチングやトレーニングを提供しています株
僕がお話しているプロジェクト管理とチームの作り方などについて | 株式会社ヌーラボ(Nulab inc.)
2015年3月25日に、株式会社ロフトワークさま主催の『ビジネスを躍進させる創造的チームの作り方』にて、千葉県の柏にある柏の葉オープンイノベーションラボ（KOIL）にて、「小さなままで世界を相手に冒険できる自己組織化したチーム」というタイトルでお話をさせていただきました。また、最近ではないですが、2012年9月には、Movida School にて「スタートアップは自己組織型であるべき」といったタイトルでスタートアップの起業家に向けてお話させていただきました。 いづれも、「チームの作り方」に触れるような内容でした。 また、同様の内容で、台湾のお客様の社内セミナーや、その他多くの場所でお話させて頂いてます。 自分自身もまだまだ勉強中だということもありますが、このような題材は、「こうすることが正解」というケースは無いと思います。なので、いずれも「会社の文化や、背景、業務内容などにあわせて、良さ
【後編】大先輩のフリークアウトCTOが語ってくれた、マネジメントの深くてイイ話
＜前編のあらすじと後編のお話＞ 本企画のホストである伊藤直也（以下「naoya」）と、『フリークアウト』執行役員であり『ヤフー』のフェロー／名誉黒帯でもある明石信之（以下「明石」）。意外にも初顔合わせとなる二人だったが、Web業界を長年リードし続けてきたという共通項もあり、酒肴を愉しみながらのマネジメント談義は大いに盛り上がりを見せた。明石氏が『フリークアウト』に参画後、色を組織名にするなど、破天荒とも思える組織マネジメントの実例も披露され、その深い洞察にもとづく一手に、naoya氏は大いに感銘を受けるのだった――。 ⇒【前編】の記事はこちら 【後編】となる今回は、明石氏の『フリークアウト』における取り組みを掘り下げていくことで、そのマネジメント論の神髄に迫っていきます。大の魚好きという点でも一致する二人の会話は、酒の力もあってますますヒートアップしていきます。 — naoya：チーム名の
開発組織のマネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
組織能力を圧倒的に成長させること - Kentaro Kuribayashi's blog
この記事は、Pepabo Advent Calendar 2014の12日目の記事です。前日は、hisaichi5518さんの「Web APIを作るときに考えること。 - パルカワ2」でした。 ここ半年ほど考えていることを、以下に述べる。 技術とは何か？ 「技術とは何か？」という問いに対しては様々な回答があり得るが、ひとまず「企業にとっての技術」という観点からいえば、経営学による以下の記述にその定義を求めてもよいだろう*1。 すべての企業が、自分が必要なインプットを市場から買ってきて、それに自分が得意とする「技術的変換」を加えて、その結果として生まれてくる製品やサービスを市場で売っている。 (中略) 誰にでも容易に手に入る財やサービスであれば、とくに企業が存在してその提供を業とする必要はない。その提供プロセスが難しいからこそ、その困難さを解決する努力が企業の「技術的変換」になるのである。
組織も人も最適化の果てにあるのは緩やかな死
なんか会社のチャットネタが続きますが、先月、会社のチャットでマクドナルドの衰退と吉野家のリンクから最適化の話しになり、「もしトレタが最適化しすぎると、どういう風に発展の妨げになるんでしょう」って話しが出てちょっと面白かったのでブログにまとめて見ることにしました。 私がアプリ開発で一番怖いと思うのは、既存ユーザへの最適化です。 既存ユーザはある程度使いこなした上で「あの機能が欲しい」と要望を出してきます。確かにその機能があると便利ですし、他のユーザでも喜ぶ人が大勢います。 実際、その機能実装すると多くのユーザが便利になり満足度があがります。画面にボタンは増えましたが使わないユーザが不便に思うほどではありません。 誰も困らないし、この機能追加はとても正しいことに見えます。 でもその機能があることで、初めて触るユーザはどう感じるでしょうか？画面にボタンが多いほど、マニュアルが厚いほど初めてのユー
現場の経験知をパターン言語にするコツが分かった #agileto2014 - プログラマの思索
AgileTourOsaka2014に参加してきた。 テーマは「パタン特集」。 パターン言語とは何か、現場の経験知をパターン言語にするコツが分かった。 とても有意義な勉強会だった。 ラフなメモ書き。 【元ネタ】 10月11日 AgileTourOsaka2014 Agile Tour Osaka 2014でパタン・ランゲージのワークショップを担当しました AgileTourOsaka2014 #agileto2014 のまとめ - Togetterまとめ KenColle/AutomationPatternLanguage パターンを使うもう一つの動機～パターン言語の構築よりも設計・実装・運用のノウハウをカタログ化する: プログラマの思索 パターン言語の構造と事例集: プログラマの思索 「アジャイルに効く アイデアを組織に広めるための48のパターン」の感想～エバンジェリストが自分のアイデア
「組織パターン」で未来をあぶり出す！
ある日突然、業務知識もない、人脈もない、基礎的な素養もない部署に異動することになったら、あなたならどうしますか？そして、その事業が15年連続右肩下がり業界としたら、あなたは何から手を付けますか？そんなピンチな私の杖になってくれたのは、アジャイルの鉄人たちの教えでした。 業務改善をしたいけれど、どこから手を付けていいかわからないと思っている方に、未来会議というフレームワークとそのダンドリを「XP祭り2014」でお話させていただきました。何かの参考になれば幸いです！
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
