タグ

経営に関するkanu-orzのブックマーク (59)

  • セガは早すぎたから失敗したのではない。

    セガの話の前にこちら。 技術と時機 | Preferred Research (1)時機を見極めるのは専門家でも難しい。しかし勝負をしないと舞台に上がることすらできない。 (2)成功してからの後追いは自分でゲームを変えられるぐらいでないと難しい。しかも成功している方は100倍ぐらいの差はあっという間につけることはできる (3)成功する時機のスイートスポットは半年〜1年である。それより前より後でも成功することは難しい (4)一方で準備は数年前からはじめていなければならない 新技術とその投入タイミングはこんなにも難しいという話です。時機を見極めるのは当の専門家でも難しいのに、やらないと舞台に上がれないけど、そのタイミングが早すぎても遅すぎてもダメで、でも準備は数年前からやらないといけない、、、あまりに矛盾が大きすぎます。 技術会社であるPFIの中の人らしい話ですが、僕は「技術」と「時機」は必要

    セガは早すぎたから失敗したのではない。
  • 組織能力を圧倒的に成長させること - Kentaro Kuribayashi's blog

    この記事は、Pepabo Advent Calendar 2014の12日目の記事です。前日は、hisaichi5518さんの「Web APIを作るときに考えること。 - パルカワ2」でした。 ここ半年ほど考えていることを、以下に述べる。 技術とは何か? 「技術とは何か?」という問いに対しては様々な回答があり得るが、ひとまず「企業にとっての技術」という観点からいえば、経営学による以下の記述にその定義を求めてもよいだろう*1。 すべての企業が、自分が必要なインプットを市場から買ってきて、それに自分が得意とする「技術的変換」を加えて、その結果として生まれてくる製品やサービスを市場で売っている。 (中略) 誰にでも容易に手に入る財やサービスであれば、とくに企業が存在してその提供を業とする必要はない。その提供プロセスが難しいからこそ、その困難さを解決する努力が企業の「技術的変換」になるのである。

    組織能力を圧倒的に成長させること - Kentaro Kuribayashi's blog
  • 不稼働損という名のダウン・スパイラル - 原価を下げると赤字が拡がる謎 | タイム・コンサルタントの日誌から

    ビジネスの世界では、ときどき常識では理解しがたいことが起きる。前に書いた『黒字倒産』という事象もその一つだが、もう一つ訳が分からないのは、原価を下げて黒字受注を続けたのに、会社が赤字に陥るケースである。しかも、“これはマズイ”と思ってさらに原価を下げる努力をすると、もっと赤字幅が増えてしまう。もちろん売値は下げていないのに、である。それは『不稼働損』という名のダウン・スパイラルだ。いくつもの日企業(それも立派な大企業)が、この病に陥っているように見受けられる。いや、米国でもかつて多くの製造業がこれを経験し、その結果衰退した会社も少なくなかったと想像される。今回は、これについて書いてみたい。 単純化した例で説明しよう。今、ある企業の主力製品Aは、定価が25万円で原価が20万円だ、というケースを考える。原価のうち、製品1個あたりの標準の材料費が10万円、労務費が3万円、製造経費が3万円で、つ

    不稼働損という名のダウン・スパイラル - 原価を下げると赤字が拡がる謎 | タイム・コンサルタントの日誌から
    kanu-orz
    kanu-orz 2012/10/15
    "マンパワーの稼働率から人月単価を計算している。不稼働だと原価が上がる。そこで営業マンは、単価の安い開発外注やハードの外部仕入れを推し進めるようになる。社内に人が余っているのにもかかわらず、である"
  • Geekなぺーじ : 優秀な社員を辞めさせない方法

    「16 Ways to Keep Your Best Employees -- Without Breaking the Bank」という記事がありました。 ITworld.comの記事です。 原文には、「多くの社長はビジネスのルールが変わったことに気がついていない。昔はお客様が神様だったが、最近は従業員を満足させる事で従業員がより良いサービスを提供して顧客を満足させるということが求められる。従業員がより芝が青い土地に移動すれば顧客もその従業員についていくだろう。」というような事が書いてありました。 新天地を探すというのは、既に辞める気持ちが発生しているということなので、そもそも従業員が「より青い芝」を探し始める時点で手遅れだそうです。 原文には、自分の土地をより青く保つための「種」を16個紹介しています。 以下、それらの要約です。 誤訳などがあるかも知れないので、詳細は原文をご覧下さい。

    kanu-orz
    kanu-orz 2011/08/09
    ウチの社長に読ませたい
  • 日経BP

    株式会社 日経BP 〒105-8308 東京都港区虎ノ門4丁目3番12号 →GoogleMapでみる <最寄り駅> 東京メトロ日比谷線「神谷町駅」4b出口より徒歩5分 東京メトロ南北線 「六木一丁目駅」泉ガーデン出口より徒歩7分

    日経BP
  • 社員の副業はどんどん認めたほうがいい - モジログ

    ドキュメントツールSphinxの普及活動などで知られる渋川よしきさんが、ホンダからDeNAに転職したとのこと。 渋日記@shibu.jp - ホンダを辞めて、DeNAに転職しました http://blog.shibu.jp/article/43616649.html <昨年の12月末で技術研究所を退職し、1月付けでDeNAに転職しました。ホンダが嫌いでやめたわけではなく、自分のキャリアプランや夢と合わなかったのと、DeNAであれば自分の力をもっと生かせるんじゃないか、と思ったからです。。> ITエンジニア転職なんて日常茶飯事だし、特に渋川さんのように優秀であれば引く手あまただろうから、転職自体は特に驚くべきことではない。 どちらかといえば、渋川さんがいままでずっとホンダにいつづけたことのほうが、私にはむしろ驚きだ。このエントリを読むと、それだけホンダという会社を愛していたことがわかる

  • 新しい契約形態での受託開発サービス | 永和システムマネジメント

    近年、大変注目を集めているソフトウェア開発手法に「アジャイル」があります。 アジャイルはお客さまの組織やビジネスの変化に素早く対応することが可能な開発手法です。 しかし、ソフトウェア業界での受託型の請負契約は要件定義が完了してから開発見積り・契約するというやり方が当たり前となっており、お客様にアジャイルのメリットを実感頂くのが難しいという課題がありました。 これまでの受託開発における一括請負型の契約では納品時に費用を全額お支払いいただくというビジネスモデルをとってきました。 このサービスではこのビジネスモデルから脱却し、開発したシステムを初期費用0円で提供します。その後、お客さまにはサービス利用料という形で月々お支払いいただきます。 サービスがお客さまに価値を提供するのは納品した瞬間ではなく、お客さまがサービスを利用しているあいだ継続的にです。 このことから、お客さまがサービスを利用してい

    kanu-orz
    kanu-orz 2010/11/11
    全然違うけどギョイゾーを思い出した。ギョイゾーは数頭しか売れなかったらしいけど... どちらにしても知名度や体力、既存顧客への展開が鍵になりそうなビジネスモデルだと思う。これからの展開注目。ギョイギョイ。
  • 営業活動という名前のプロジェクト - そのリスクとリターンを考える | タイム・コンサルタントの日誌から

    プロジェクト型の事業はふつう、初期には費用を使って、成功するとリターンを得るというキャッシュフロー構造をしている。言いかえれば、最初に投資が必要で、完了時に回収する仕組みである。受注型プロジェクトでも、最初は人件費や外部コストがかかり、成功裏の完了すると支払を得るわけだから、時間的な構造は同じである(会計的には「投資」扱いにならないとか、一部の「前払金」があり得るなど、細かな差違はある)。 いうまでもなく、多くのプロジェクトは失敗のリスクをともなっている。すなわち、初期の投資を回収できずに終わる可能性が(大小はともあれ)存在する。いま、プロジェクトの初期投資額をC、成功時の収入をSとし、かつ途中で中断失敗するリスク確率をrとすると、プロジェクトの生み出す価値の期待値は、非常に単純化して言うならば (1 - r)S - C       (1) で表されることになる。これがプラスでなければ、そ

    営業活動という名前のプロジェクト - そのリスクとリターンを考える | タイム・コンサルタントの日誌から
  • レーベル運営の悲喜交々:HMV渋谷閉店にまつわる僕の見解

    HMV渋谷閉店にまつわる僕の見解 連日、大きく報道されていたのでご案内だとは思いますが、先日、HMV渋谷店が閉店しました。 CDが売れない時代になった。 配信に小売店が押されはじめた。 アマゾンが販売をほぼ独占し始めた。 そして、ユーザーの音楽への接し方が変わってきた。 そんな事が、今回の閉店の理由として、説明するメディアが多かった。 いや、ほぼすべてが、それらを理由としていただろう。 ご存知、HMV渋谷は、90年代のある一時期には文化発信基地としての役割を担い、そこからは渋谷系と呼ばれる音楽を世に広めたりした功績を残した。ブームの中心にいつもいるお店だった事は、確かだ。 僕も、この店には通い詰めた。80年代中盤はタワーレコード渋谷店と、LOFTの一階にあったWAVE渋谷店が輸入盤という存在を一般的にした。そこは、外国の香りでいっぱいだった。 80年代後半は、六木WAVEが知られざる世界

  • 第9回 「我が社の社員に経営者感覚がない」のは当然だ:日経ビジネスオンライン

    気になる記事をスクラップできます。保存した記事は、マイページでスマホ、タブレットからでもご確認頂けます。※会員限定 無料会員登録 詳細 | ログイン 「社員には知らしむべからず」の会社が多い現状 仕事で経営者に会うと、「うちの社員には経営者感覚がない」「会社の状況が分かっていない」というため息を聞くことが少なくない。そんな時、私は「社員の皆さんが経営情報に触れられる機会はどれくらいあるのですか」と質問を返す。 世の中にはまだまだ「社員は由(よ)らしむべし、知らしむべからず」という会社が多いと感じる。説明するまでもないかもしれないが、これは中国の論語にある孔子の言葉を引用したもので、もともとの意味は『大辞泉』(小学館)によると、「為政者は人民を施政に従わせればよいのであり、その道理を人民に分からせる必要はない」というものだ。 「経営者感覚を持て」とは、社員一人ひとりも会社の経営を担う一員であ

    第9回 「我が社の社員に経営者感覚がない」のは当然だ:日経ビジネスオンライン
    kanu-orz
    kanu-orz 2010/08/23
    「お前は知らないから、そんなことが言えるんだ!」「ならばその情報を教えてください!」「それは経営の話だから言えない!」と言う間抜けな会話を思い出す。
  • あなたの会社にスクラムマスターが必要な8つの理由

    みなさんこんにちは。@ryuzeeです。 このタイトルで記事を書く約束を@katzchangと約束したので、書いてみたいと思います。 前提として、スクラムマスターはいないが管理職がたくさんいて、日々現場のメンバーが悩まされているようなシチュエーションを想像しています。 (かなり)現実の管理職を悪くステレオタイプ化していますが、スクラムマスターとの対比のためにあえてそうしています。 うちの管理職はもっとまともだ!とか言わないようにしてください。 管理職は部下を育てる責任、もしくは勝手に育つような環境を用意する責任がありますが、もう1つの大きな責任である「数字(※1)をあげる」というテーマが優先されてしまう。 (※1:ムリと分かっていても勝手に経営が決めて部門目標とかいう名の元に押し付けてきた売り上げと利益目標のこと)。→スクラムマスターはコーチ・ファシリテーター・メンターとして、チームの成長

    あなたの会社にスクラムマスターが必要な8つの理由
    kanu-orz
    kanu-orz 2010/05/18
    素晴らしいまとめ!
  • 翻訳 - 次のアジャイルソフトウェアプロジェクトに使える10の契約

    以下の文章は、Peter Stevensによる「10 Contracts for your next Agile Software Project」の日語訳である。 Creative Commons ― 表示-非営利 3.0 Unportedの条件下で、ここに掲載する。 次のアジャイルソフトウェアプロジェクトに使える10の契約 2009/4/29 by peterstev ソフトウェアサービスの顧客であれサプライヤであれ、ソフトウェア開発プロジェクトの最初の頃というのは、口約束だけでいろんな仕事をやらなくちゃいけない。 契約書というのは、言ってしまえば、競技のルールがだらだらと書かれてあるものに過ぎない。 ルールが正しければ、顧客にとってもサプライヤにとっても、成功する確率が高まる。 ルールが間違っていれば、お互いに協力することも難しいし、進捗だって妨げてしまう。 それでは、アジャイル

  • アジャイルって受託開発との相性が最悪な気がする - GoTheDistance

    全くもって、その通りだなぁと思った。 初期段階ですべての意志決定をしても、問題はコードを書き始めてから表れるのです。そして終わりに近い時点で判断する方が、より正しい判断ができるはずです。ですから、できるだけ意志決定は先延ばしにして、正しい意志決定をしようとするのがアジャイルのやり方です。 「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え - Publickey 「ウオーターフォールとは」のラベル貼りの議論になるとめんどくさいから、とりあえず「初期段階ですべての意志決定をしようとするシステム開発の進め方」という定義で話を進めたいと思います。 滝 「要件定義」→「設計」→「実装」→「テスト」という一連の流れがあって、ウオーターフォールなるものは前工程が100になるまでひたすらそこでPDCAを回します。100になると言う意味は、ソフ

    アジャイルって受託開発との相性が最悪な気がする - GoTheDistance
    kanu-orz
    kanu-orz 2010/02/12
    準委任にすりゃよろしと言ってしまえば終わりだけど、それが難しい受託開発の罠
  • ThoughtWorks社マネージングディレクターXiao Guo氏インタビュー―アジャイル開発を行うために組織文化をどう変えるか | gihyo.jp

    ThoughtWorks社マネージングディレクターXiao Guo氏インタビュー―アジャイル開発を行うために組織文化をどう変えるか 2009年12月8日に開催されたAgile Conference Tokyo 2009で、基調講演のために来日したThoghtWorks社のXiao Guo氏にインタビューを行いました。ここにその模様をお伝えいたします。 Agile Conference Tokyo 2009のレポートはこちらです。 図1 Xiao Guo氏 アジャイル開発に組織を適合させるための3つの課題 Q:日は基調講演をどうもありがとうございました。その中でも、組織文化についてのお話しを興味深く伺いました。日でもエンジニアを中心にアジャイルプラクティスが知られるようになってきていますが、組織そのものをアジャイル化していくことはまだこれからなのが現状です。アジャイル開発は日で一般的な

    ThoughtWorks社マネージングディレクターXiao Guo氏インタビュー―アジャイル開発を行うために組織文化をどう変えるか | gihyo.jp
  • 「動かないコンピュータ」とコンサルタントの関係

    今回の主題は,「動かないコンピュータの影にコンサルタントあり」というものである。動かないコンピュータとは,情報システム構築プロジェクトの失敗など,当初計画の通り,動かなかったコンピュータを指す。筆者は5~6年前から,講演などでは「コンサルティングと詐欺は紙一重」などと滅茶苦茶なことを話していた。だが,原稿にするのは難しく,きちんと書いてはいなかった。 なぜ書くのが難しいかというと,確たる裏付けがない話だからである。筆者は,「動かないコンピュータ」の取材をライフワークにしているので,日ごろから情報システムのプロジェクトについて情報を収集している。うまくいかないプロジェクトの原因を調べていくと,コンサルタントに突き当たることが多い。これは5~6年前からの傾向のように思う。 「日プロジェクトをお前は全部取材しているのか。数件そうした事例があったからといって,コンサルタント全部がダメといわんば

    「動かないコンピュータ」とコンサルタントの関係
    kanu-orz
    kanu-orz 2010/02/04
    みんなプログラム書くのを止めてコンサル目指すんだ!おいしいぞ! orz
  • 受託開発と自社製品開発では結構メンバーの志向が違うという話&受託開発のアピール:プログラマー社長のブログ:オルタナティブ・ブログ

    今日は当社IT事業部のWEB-DBチームのサブリーダーと客先訪問に行ってきました。IT事業部は現在2チーム体制で、私がいつもブログに書いている話題は、不正接続検知/排除システム「IntraGuardian2」をはじめとした製品開発や、ネットワーク関連を得意としている「ネットワークチーム」の話題が多く、実際私もそっちに関わっていることが多いのですが、今日は「WEB-DBチーム」の紹介を書いてみましょう。 詳細はこちらのページに出ているので、私が中途半端に紹介するより、そっちを見ていただければいいので、公式ページに書かないような話題など、裏話を中心に・・・。 まず、2チーム体制になった経緯なのですが、当社のソフトウェア開発関連事業は、元々はプリント基板設計用CADシステムの開発・販売事業を行うPLASMA事業部(PLASMAというのはCADシステムの名前)というのを私が入社3年目に立ち上げたの

    受託開発と自社製品開発では結構メンバーの志向が違うという話&受託開発のアピール:プログラマー社長のブログ:オルタナティブ・ブログ
  • 2009年、SIerの現状を俯瞰する - @IT自分戦略研究所

    あなたも@ITでコラムを書いてみないか 自分のスキル・キャリアの棚卸し、勉強会のレポート、 プロとしてのアドバイス……書くことは無限にある! コードもコラムも書けるエンジニアになりたい挑戦者からの応募、絶賛受付中 米国のサブプライムローン問題やリーマン・ショックに端を発した金融危機は、世界的な不況をもたらした。IT業界も例外ではなく、多くのITエンジニアが不況の影響を痛感した1年だった。 今年後半は特にシステムインテグレータ(SIer)のエンジニアを中心に、「案件が減った」「待機が増えた」という声を多く聞いた。こうした傾向がいつまで続くのか、不安に思っている読者は少なくないだろう。 「景気が回復すれば元通り」――そう楽観視するのもいいだろう。だが、当にそうだろうか。今年から来年にかけて、SIerの事業は大きな転換期に差し掛かっているのではないだろうか。 特集では、日の情報サービス産業

  • アジャイル開発のボトルネック | Social Change!

    お金なら出しますから、4ヶ月のところを2ヶ月で作ってくれませんか?」 システム開発で、顧客からこう言われた時、どうするか? SIerの経営者や管理職であれば、飛びついてしまうんじゃないだろうか。私だって飛びつきたい。確かにエンジニアがいるなら、もしくは、集める目処が立つなら、ありがたい話かもしれない。XPでも、「リソース・スコープ・品質・時間」のパラメータで、品質以外は変動可能としている。 ということは、リソースがなんとかなれば、時間を短くする、もしくは、時間を変えずにスコープを増やすことができるのだろうか。人月という単位で考えれば、計算上は出来るかもしれないが、実際には難しいと言わざるを得ない。それはなぜか。ボトルネックは、プログラムを作る速度か、それとも、仕様を決めて受け入れる速度か。 冒頭の台詞は、開発側にこそボトルネックがあり、コストさえかければスピードアップできると考えているか

    アジャイル開発のボトルネック | Social Change!
  • https://www-607.ibm.com/support/partners/jp/webcast/play/play.wss?&keyword=&usergroup=null&mode=&uid=null&contentid=910&appid=null&checksum=941819ca

    kanu-orz
    kanu-orz 2009/10/19
    1:02:20から某氏名指しの後、事例として紹介される。 1:10:40再び名指しですくすくスクラムを紹介される。
  • kuranukiの日記 - ディフェンシブな開発 〜 SIビジネスの致命的欠陥

    Rubyをはじめとするスクリプト言語ではなく、なぜJavaを選ぶのか。 そして、XPをはじめとするアジャイル開発ではなく、なぜウォーターフォールを選ぶのか。 そこには、言語の良し悪しや、開発プロセスの考え方などが理由の中心にあるわけではなくて、SIerというビジネスの仕事の仕方(ビジネスモデル)に起因している。 RubyやXPは、考え方や技術としてはとても良くて、生産性もあがるし、何よりもソフトウェアをクリエイティブに作り上げることができ、利用者にとっても使い勝手がよく、スポンサー(経営者)にとっても経営戦略に沿ったものが手に入り、開発者にとっては何よりも仕事に対してやりがいを感じることができる。すばらしい!・・・・が。。。 しかし、だからといって、誰でもRubyやXPを使って開発をするべきか、というとそうではない。もし、質を理解しない誰かが、「やってみたいのだが・・・」と相談に来たら、

    kuranukiの日記 - ディフェンシブな開発 〜 SIビジネスの致命的欠陥