「きちんと管理すれば企業は成長する」の迷信が企業を衰退させる〜ToMo指数の研究〜｜Yasuhiro Yoshizawa
事業が軌道に乗り、ここ２１ヶ月連続で、毎月売上記録を更新してきたベンチャーA社は、ついに念願の上場を迎えた。 ところがその直後、毎月の売上が急激に鈍化。役員たちは、上場初年度の売上予測の下方修正といった事態をなんとしても避けたいため、事業を担うマーケティング部長、営業部長たちに、こう檄を飛ばす。 「もっとしっかりと分析を行って、何を改善すべきかレポートにまとめてくれ。そして、速やかに改善計画を立て、実行してほしい」 今振り返れば、このときまでが、A社の繁栄のピーク。 この号令を境に、事業を担うメンバーたちは、「今月は、お客さんへのリーチを２０％回復させるためになんとかしなければ」「来訪したユーザが、うちのサイトで購入してくれる率を５％改善しよう」など、計画に基づいて打ち手を探るが、なぜか以前のようなインスピレーションも沸かなければ、ありきたりなアイデアばかりの繰り返しとなる。 一向に成長の
非エンジニア副社長がゼロから歩む テクノロジー企業経営への道 - Qiita
はじめに この記事は CrowdWorks Advent Calendar 2016 25日目の記事です。 クラウドワークス副社長をやっております、成田と申します。アドベントカレンダーのトリということでプレッシャーがすごいです。 私の役割ですが、創業当初はサービスUX改善やWebマーケティング・ビズデブ全体の責任者をやっていて、その後法人セールス部門の立ち上げをやり、現在は副社長 兼 プロダクトマネージャー（PM） 兼 プラットフォーム事業部の事業部長という立ち位置です。PMの周りに4人の優秀なプロダクトオーナー（うち3人がエンジニアバックグラウンド）がいます。 当社は「働くを通して人々に笑顔を」というミッションに基づき、素晴らしいサービスを生み出し、冒頭の写真のようにユーザーの皆さんに笑顔を届けることを追求していますが、その素晴らしいサービスを生み出す企業文化として「日本を代表するテクノ
RACIマトリクスを使ってスクラムでの責任分担を見える化する
こんにちは。@ryuzeeです。 開発プロジェクトを進めるときには、ご存知の通り多くの人が関わります。一方で以前から何度か書いているようにいきなり人が集まっただけの段階だと、まだ組織やチームとしてはうまく機能せずさまざまな混乱が起こることになります。 たとえばスクラムを採用した場合で、かつスクラムに関する経験があまりない状況の場合、それぞれが持つロールを十分に果たせなかったり、そもそもどんな責任を持つべきなのかも分からずに声の大きい人の言いなりになったり、上司や外部からのコントロールを受けすぎてしまったりといった混乱も起こります。 そこで、初期の形成期や混乱期を早めに終わらせるために、それぞれの役割が持つ責任を見える化するのをお勧めします。（混乱した現場でこれをやると、想像以上に全員の認識が違うことがよく分かります） 以下の表はRACI（レイシー）マトリクスと呼ばれるものです。縦軸にタスク
アカウンタビリティとは「命令責任」である | タイム・コンサルタントの日誌から
「RACIチャート」というものをはじめて知ったのは、90年代半ばのことだ。当時使っていたアメリカのERPコンサルタント会社が、要件定義段階での役割分担をRACIチャートの形にまとめてきて、なるほど、こういう整理の仕方があるのかと知った次第だ。ついでにいうと、「サプライチェーン」という言葉も、同じ時にはじめてきいたのだった。まだ日本ではほとんど知る人のいない概念だった。 RACIチャートとは、業務の上での役割分担と責任範囲（Role and Responsibility）を、分かりやすく整理するための表である。ふつう横軸の欄には、関係者や部門の名前が並び、縦の行には業務を構成するアクティビティが続く。そして、どのアクティビティは誰がどのような役割で関わり、責任はどこが持つかを書く。このとき、
「限界をつくるな」を精神論で終えないために僕らは何ができるのか
201801_29_DevLove関西 登壇資料 「限界をつくるな。」や「できるかできないかじゃなくて、やるかやらないかだ。」「言い訳するまえに行動してみろ。」 高い目標に向かう中で立ち止まった時や、先輩から悩める後輩へのアドバイスでこんな事を聞いたことや、言った事はありませんか。 でも、こう言われた時に何をどうすればいいのでしょうか。こう言ったあとに何ができるのでしょうか。 がむしゃらにがんばれば目標が達成できますか？精神論だと吐き捨てて新天地を目指すことで成長できますか？ 精神論で終えず、論理的に「できないこと」を「やれること」にするための戦略・戦術を見つけるにはどうすればいいのでしょうか。 僕自信が現場のメンバーとして、ITベンチャーの中間管理職として、プロダクトマネージャーとして歩んできた経験から今考えているような内容を共有させてもらいます。
プロダクト開発チームで今年やってみてよかったこと10選 - Qiita
この記事はCrowdWorks Advent Calendar 2017の最終日の記事です。 メリークリスマス！ 去年のアドベントカレンダーで、非エンジニア副社長がゼロから歩む テクノロジー企業経営への道という記事を書かせてもらいました。 「もうそれから1年かー！」という感じですが、今年は、この1年でうちがやってみたことで、効果があって組織が成長したなーと自分が感じたことを10個紹介してみたいと思います。 ①考えると人と作る人を分けずにフラットな組織にした やったこと： プロダクトオーナー制度を取り、プロダクトオーナーとエンジニアとデザイナーがOne Teamになり、開発を行う そのチームで日次週次でプランニングと振り返り(KPT)を行い、日々改善する そのチーム内の関係性を「フラット」にする マネジメント(評価とか)はチーム開発とは基本的に分ける よかったこと： 「は？いつまでにやるって
非エンジニアのマネージャがエンジニアチームと上手くやる方法 - Qiita
近頃の世の中の流れは恐ろしい。全業種ソフトウェア企業にならないと競争力が維持できない。 “寝たときは製造業、朝起きたらソフトウェア企業” by Werner Vogels（CTO, Amazon.com）at AWS re:Invent 2017 Key Note という恐ろしい話は管理職に落ちてくるので、「寝たときは製造業のマネージャ、朝起きたらソフトウェア企業のマネージャ」になれるのか？を考え始めるべきです。 元銀行員で非エンジニアで、いつのまにか開発ツールベンダーにどっぷりの私の経験からのTips を共有します。 エンジニアの方は、非エンジニアのマネージャにしれっとリンクを送ってあげてください（笑） 結論： 目標もバスの走らせ方もバスに乗せた優秀な人たちに任せて、バスの整備をする人になる。 マネージャが「何をつくるか？」の決定権を持てるのは彼/彼女が優秀なエンジニアの場合だけです。非
わたしはなぜ、「プロジェクト管理」という言葉を使わないのか | タイム・コンサルタントの日誌から
旅先ではいつも、その土地のものを食べるのが習慣だ。だが、ときおり、外国で日本料理屋に入ることもある。そして、たまに面食らうような体験もする。いつだったか、アメリカの日本料理屋で食事を頼んだら、まっさきに味噌汁だけが出てきた。ふつうの街にある店で、来客はアメリカ人が多い。どうやら彼らの概念では、味噌汁はスープだから（Miso soupとよばれる）、真っ先に出すのが当然だということらしい。味噌汁を飲み終えたら、メインのおかずとご飯が出てきて、妙な気分だった。 汁物をsoupと訳するのは、もちろん正しい訳だ。だが日本語で言う汁物と、英語のスープは微妙に違う。たとえば英語では、スープは食べる（eat）という。日本人で、「味噌汁を食べる」という人は滅多にいるまい。ふつうは飲む、を使う。そして、当たり前だが、ご飯と一緒にいただくものだ。
おじさん Product Manager サバイバル戦記 2017 (ShanonAdventCalendar2017・15日目)
皆様こんにちは。シャノンでプロダクトマネージャーを担当している gacky です。 おじさんプロダクトマネージャーの皆さん、今年も無事生き残れてますか？ この記事は、Shanon Advent Calendar 2017 の15日目と Product Manager Advent Calendar 2017 の15日目を兼ねた投稿です。 昨年は「おじさん Product Manager サバイバルガイド」と題して、アラフォー世代のおじさんプロダクトマネージャーの戦い方について考えてみました。 今年はケーススタディとして、実際の製品開発におけるおじさんプロダクトマネージャーの奮闘ぶりを検証していきたいと思います。果たして、プロダクト開発の現場において、おじさんの貫禄を見せることができたのでしょうか？ なお、一部「それってプロダクトマネージャーの仕事じゃなくね？」とツッコミが入りそうな内容も含
エンタープライズアジャイル勉強会の資料 - @m_seki の
エンタープライズアジャイル勉強会という勉強会に呼んでいただけたので資料公開しますね。広島の旅費が苦しいのでこういうのうれしい！ Gumroadからの課金勢のみなさんへ 恒例！スライドに名前を入れる券 2017-2018 反復開発を中心に お話したこと 反復開発は全工程やって1ターンだよっていうみんなが知ってる（けど、ある方面のScrumではやられていないことが多いらしい）ことを45分間ずっと説明しました。 その結果チームの境界（サブシステムとか工程別チームとか）がどうでもよくなると思う（実感してる）んだけど、Scurm Incの説明だと階層がたくさんある例を示していたし、永田さんはQA部門にこだわりがあるのがおもしろいなー。自分も含めて、みんな自分の状況が好きなんだな。いいことだ。 再演バイト待ってます。 （再演したいんじゃなくて、RubyKaigiの旅費かせぎたいので！） speaker
Microsoft PowerPoint - ProjectFacilitation20070314.ppt[読み取り専用]
1 Copyright © 2005-2007 Kenji HIRANABE, Some rights reserved 現場力を高める 現場力を高める見える化 見える化手法 手法 プロジェクトファシリテーション プロジェクトファシリテーション ～ ～モチベーションアップの モチベーションアップの ツールと場づくり ツールと場づくり～ ～ 株式会社永和システムマネジメント 株式会社チェンジビジョン 平鍋 健児 http://www.ObjectClub.jp 2 Copyright © 2005-2007 Kenji HIRANABE, Some rights reserved 本日のお話 本日のお話 z 自己紹介（簡単に） z プロジェクトの見える化を実践例で z プロジェクトファシリテーション（PF）とは？ z PFの価値 z PFの原則 z PFの実践 プロジェクトファシリテーション
「それ、アジャイルできてへんのちゃいますか？」チェックリストの公開 - メソッド屋のブログ
DevOps を導入して、リードタイムの短縮などの効果を出したい時に、前提条件となっている「アジャイル」がまだ導入できていないケースが多い。そういったケースでは、まずアジャイル導入のご支援をすることもよくある。 そういった支援に入ると、「アジャイル導入前提」で構成されたはずのプロジェクトであっても、全然「アジャイル」のポイントを外しているというケースは珍しくない。更に問題なことに、「アジャイルをできます！」と言っているベンダーさんを連れてきても、全然ポイントを外しているというケースすら珍しくない。今回のブログではそういったケースでも、簡単に確認できる、「アジャイルになっていないかもしれない簡単なチェックポイント」を対策付きでいくつかご紹介しよう。 スプリントの中で、ウォータフォールを実施するのではない。それはミニウォータフォールというバッドプラクティスだ。 1. 進化型設計ができていない
【資料公開】強いチームの作り方 | Ryuzee.com
2015年11月10日に某社の社内勉強会で、「強いチームの作り方」というテーマで話をしたのでその際の資料を公開しておきます。 内容自体は、WEB+DB PRESS 83号に書いた内容なので興味があればそちらを参照ください。 最近DevOpsの文脈ですぐに「インフラ自動化しないといけない」とか「ツール使って効率化」みたいな話を頻繁に聞きます。 が、端的にいえば、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」というデマルコの一節の通りであり、 DevOpsの本質もツールではなく、CLAMS(Culture、Lean、Automation、Measurement、Sharing)であって、土台となるのはやはり組織やチームの文化になります。 一度自分たちのチームや組織について考えてみるとよいと思います。
テストについて考える #devlove
DOWNLOAD THIS BOOKS INTO AVAILABLE FORMAT (Unlimited) ......................................................................................................................... ......................................................................................................................... Download Full PDF EBOOK here { https://tinyurl.com/y6a5rkg5 } ........................................
nabokov7; rehash : 【忘年会シーズン向け】飲み会の幹事は新入りじゃなくてマネージャーの仕事ですよ
December 18, 201113:30 カテゴリ組織とyou番組の途中ですがマジレスです 【忘年会シーズン向け】飲み会の幹事は新入りじゃなくてマネージャーの仕事ですよ 「マネージャー」っていう職種は会社によって定義のブレが大きいようだ。年功序列で給料を上げるための言い訳に利用される側面があったり、きちんとした job description が用意されていないことも珍しくなく、結果なんとなく「古参で偉い人」みたいな雰囲気マネージャーが量産されてる職場も少なくないんじゃないだろうか。 僕も前職の後半はプログラマとマネージャを兼任してたんだけど (というかマネージャ=リードプログラマ、みたいな位置づけになってたと思う) 「マネージメント」っていう仕事の定義が曖昧でどうしても掴みづらかった。結局「マネージャ = チームの雑用係」と脳内変換することでようやく何をすべきなのかが分かってきた気が
アジャイル開発のボトルネック | Social Change!
「お金なら出しますから、４ヶ月のところを２ヶ月で作ってくれませんか？」 システム開発で、顧客からこう言われた時、どうするか？ SIerの経営者や管理職であれば、飛びついてしまうんじゃないだろうか。私だって飛びつきたい。確かにエンジニアがいるなら、もしくは、集める目処が立つなら、ありがたい話かもしれない。XPでも、「リソース・スコープ・品質・時間」のパラメータで、品質以外は変動可能としている。 ということは、リソースがなんとかなれば、時間を短くする、もしくは、時間を変えずにスコープを増やすことができるのだろうか。人月という単位で考えれば、計算上は出来るかもしれないが、実際には難しいと言わざるを得ない。それはなぜか。ボトルネックは、プログラムを作る速度か、それとも、仕様を決めて受け入れる速度か。 冒頭の台詞は、開発側にこそボトルネックがあり、コストさえかければスピードアップできると考えているか
どうしても、もやもやして一歩が踏み出せない君へ - やまもといちろうBLOG（ブログ）
子会社や、幹部との人事面談が相次いでおり、どうしても東京をバタバタと出たり入ったりしている毎日でありますが、成果の出る人出ない人、同じ仕事でも悲喜こもごもであります。 前にも書いたんですが、私や私の影響力の及ぶグループでは、あまり成果目標というものを社員に与えることはありません。成果主義ではない、というのが正しい言い方になりますか。ただ、相応の能力は持ちながらも、なかなか活躍ができない、一歩、頭を出せないという経営者や社員がいて、そういう人には一定の期間を与えてある種のアドバイスをすることがあります。 というのも、私自身も、投資業務はともかく実業の面ではあまりマネージメントがうまくなく、ずいぶん遠回りをしてきたように自己反省するところもあり、自分なりに悩んでこんにちあるのは間違いありませんので、似たような立ち止まり方をしている人であれば悩みを共有できるのかなと思うわけです。 ● ”もやもや
最終講 イノベーション力の再生に欠かせない「身体性の復権」：日経ビジネスオンライン
暗黙知と形式知の相互作用による知の創造プロセスをモデル化し、ナレッジマネジメント（知識経営）の世界的第一人者として知られる野中郁次郎・一橋大学名誉教授──。 その野中氏が、本来持っていたイノベーションのDNAを失い、国際的な競争力を低下させ続けている日本企業の現状を憂慮。イノベーションの創出力を取り戻すための方策を緊急に説く。 野中氏による緊急特別講義を、同氏とともにイノベーションの事例研究に取り組み、『イノベーションの知恵』（日経BP社）などの共著を世に送り出してきたジャーナリストの勝見明氏が書き下ろしでお届けする。 最終講となる今回は、日本発のイノベーションモデルを取り戻すカギを握る「身体性の復権」とその方法について、企業の実践例を交えながら明らかにする。 企業活動における大きな流れとして、「身体性の復権」が始まろうとしている。身体と身体で触れ合い、向き合うことの大切さを再認識する傾向
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Theory Of Constraints: Productivity Metrics in Software Development · Los Techies
技術的負債、マネージャの視点
