人格劣る稼ぎ頭は、出世させるべきか －サイバーエージェント社長兼CEO 藤田晋氏
私がインターネットサービスを主な事業とするサイバーエージェントを立ち上げたのは、1998年のことである。現在はアメーバピグを中心としたAmeba事業が好調で収益の柱に成長しており、お陰様で「2011年 働きがいのある会社」の第6位にもランクインしている（グレート プレース トゥー ワーク調べ。前年は第7位）。 しかし、サイバーエージェントの歩みは決して平坦ではなかった。00年に東証マザーズに上場した直後にネットバブルが崩壊。先行投資がかさみ04年までは赤字の連続。業績の悪化に連れて社内の人間関係も悪化し、離職率が異様に高い状態が続いた。 このままではまずい。会社を根本的に変えなければ……。危機に際して私が参考にしたのは、日本的経営だった。即戦力を必要とするベンチャー企業は中途採用に頼りがちだが、日本の場合、優秀な人材のほとんどが新卒で就職を決めてしまう。一方で、中途の人材マーケットはそもそ
管理職はなぜ書き込みをしないのか? - teruyastarはかく語りき
社内コミュニケーションとしてTwitterなどの ソーシャル系サービスを使うのがとても有効だ という記事をよく見かけます。 昨日見たホットエントリーでも、 脱電子メールの4年間：IBM社員のワークスタイル « WIRED.jp 世界最強の「テクノ」ジャーナリズム IBM社で「電子メールを廃止」した者はスアレズ氏だけではない。 同氏はほかに数十人を知っているという。 例えば最高情報責任者オフィスのプロジェクト・マネージャーである ジュリアナ・レオンは、スアレズ氏ほど徹底してはいないが、 同僚からメッセージが来た時にはConnectionsで答えるようにしている。 そうすると、質問してきた人物は他の人から回答を得られる場合も多いし、 その回答は公開されているので、他の人も読むことができるからだ。 (略) 「メッセージ製品について調査していたときに、 人々がメールの件名をどう使うかも調べた。 件
ハッカーマインドでいこう！後編--求められる企業文化の変化
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 前回、楽天 開発部アーキテクトグループの技術理事であり、12年の歴史を持つOSS勉強会「カーネル読書会」を主宰する吉岡弘隆氏にオープンソースとしてのLinuxが果たした役割について語ってもらった。 後編でさらに吉岡氏は「それを実現したのはハッカーマインドであり、今の日本企業が持つべきもっとも重要な要素だ」という。 震災が掘り起こした日本のハッカー精神 Linuxのオープンソースとしての始まりは、20年前、フィンランドの大学生だったリーナス・トーバルズ氏が、インターネットに公開したOSのソースコードを、たまたま他の誰かが改良したのがきっかけでした。ですから、最初から精密な設計のもとにプロジェクトが始まったわけではなく、当時21歳の若者だっ
SIがアジャイルやってよくならない点 - @ledsun blog
SIでアジャイルをやるとハイブリッドアジャイルやWater Scrum Fallになります。しかし以下の4点は解決はしません。SIのビジネスモデルでアジャイルが無理なのではなく、「期間と機能を固定して受注する」と変えられない点です。 営業中は、システム担当者は動くシステムを見れない*1。営業マンは見たことないシステムを想像しながら見積もるという高度なヒアリング技術が必要なまま。 開発会社とシステム担当者間で落とす機能を合意しても、「偉い」ユーザーの一声で落とした機能が復活する。多層構造*2による意思決定の遅さは残ったまま。 予算の見積もりは超過方向にしかブレない*3。（予算）見積もりのバッファ問題は残ったまま。 チームメンバによってベロシティ（開発速度）が２〜３倍は変わる。しかし単価はそれほど（４０万〜８０万）変わらない。 アジャイルといっても現時点でのSIのビジネス面へのインパクトは「少
PR：変わるSI構造の中で「価値あるプログラマ」として生きる
SI企業のビジネス構造に疑問を抱き、独立した倉貫義人氏。倉貫氏が描くビジネスモデルと、「これから求められる、価値あるプログラマ」とはどんな人材なのか。マイナビエージェントのキャリアコンサルタントとの対談。 2011年にソニックガーデンを立ち上げた倉貫義人さんは、もともとTISで働いていたプログラマである。そんな倉貫さんが独立を考えたきっかけとなった、「SI企業におけるビジネス構造の問題」とは？ そして、同氏が考える「一生プログラマとして活躍できる」人に求められるものとは？ マイナビグループの人材紹介会社 マイナビエージェントのキャリアコンサルタント 折尾大介さんを交えて、これからのIT業界、そしてエンジニアのキャリアをテーマに語ってもらった。
世界は分断されている - Chikirinの日記
最近、世の中って分断されてるよねーと思うことが多い。 (1)平日の昼間に美術の企画展などに行くと「高齢者＆女性」しかいない。びっくりするほど「働き盛りの男性」がいない。今までいた場所の“裏面”を見てる気がする。 (2)渋谷に行くと「この国はめっちゃ若いな」と思い、ニコタマ（二子玉川）に行くと「世の中の女性はみんな専業主婦なの？」と思い、郊外の住宅地に行くとあまりの高齢者比率の高さに「どう考えても移民が必要でしょ？」って思う。 (3)大手町や丸ノ内に行くと、男の人がみんなダークスーツ着てて驚く。青山や表参道辺りに行くと「ビジネススーツって禁止なの？」って思う。 (4)去年の末まで（働いている間は）、毎日何十本も英語のメールを読んだり書いたりしてたのに、今年一年で、ちきりんが書いた英語のメールは多分3本。 以前は当然のように毎日英語で話してたけど、この一年で英語で話したのは海外旅行をのぞくと
品質に厳しい組織で、なぜ品質が劣化するのか？ - 現場のためのソフトウェア開発プロセス - たかのり日記
このエントリーは「Software Test ＆ Quality Advent Calendar 2011」における12/18分として書いています。 12/17は @NoriyukiMizuno さんによる 「ソフトウェアテストの勉強会。1年目。」 というエントリでした。 今回は、以前から感じている矛盾について、私なりの考えをまとめたものです。 特に、マネージャーや経営層と呼ばれる人に読んでもらいたいと思っているのですが、このブログの読者層を、考えると、あまり多くはなさそうなので、以下に示す問題について、悩んでいる／苦しんでいるような人から、うまく伝われば良いと思っています。 矛盾する問題 私は、SEPG（Software Engineering Process Group）という役割上、いろいろなソフトウェア開発のプロジェクトや組織に関わってきました。 絶対数で言えば、そんなに多くはない
“課題の共有”から”共通価値の創造”がはじまる―「What’s CSV? カンファレンス」企業（コーポレート）セッション [イベントレポート]
“課題の共有”から”共通価値の創造”がはじまる―「What’s CSV? カンファレンス」企業（コーポレート）セッション [イベントレポート] 2011.12.16 石村 研二 石村 研二 『What’s CSV? カンファレンス』は、世界中の若手起業家が交流する1週間Global Entrepreneur Weekの一環として、ブリティッシュ・カウンシル主催、グリーンズ企画、本田財団後援で開催したイベントです。 「CSV」は耳慣れない言葉かもしれませんが、経営学者のマイケル・ポーターがCSRの次の概念として提唱している「Creating Shared Value」＝共有価値の創造を意味します。 今回は、「CSVとはいったい何だろう？」ということを、「企業（コーポレート）」と「起業（アントレプレナー）」の2つのセッションそれぞれで議論し、その結果をシェアするという形式で考えて見ました。 こ
![“課題の共有”から”共通価値の創造”がはじまる―「What’s CSV? カンファレンス」企業（コーポレート）セッション [イベントレポート]](https://cdn-ak-scissors.b.st-hatena.com/image/square/f1219825bf3da83c71cb0ff8150379b0a325134e/height=288;version=1;width=512/https%3A%2F%2Fgreenz.jp%2Fmain%2Fwp-content%2Fuploads%2F2011%2F12%2Fcsv_top.jpg)
要求仕様書の品質特性を満たすには、図より自然文？ - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） 要求仕様書の品質特性として、ＩＥＥＥ８３０では、以下のように定めているようだ。（リンク先のＰＤＦから引用） ・妥当性 ・非曖昧性 ・完全性 ・無矛盾性 ・重要度と安定性のランク付け ・検証可能性 ・変更可能性 ・追跡可能性 で、これを満たそうと考えたとき、図で書くより、文章で書いたほうが、いいんでないかい？ というのは、図で書いてしまったり、形式仕様で書いてしまうと、確かにあいまいではなくなるかもしれない。しかし、全てのことをあらわせる図っていうのは、普通書けない（巨大な図になる）。形式仕様でも全てあらわせるわけではない。 だからそれらを組み合わせる。。。とデータ間で、無矛盾にするのが大変になる。 そもそも、組み合わせたからといって、すべて完全に記入できるとは限らない。 自然言語
『サービス構築の実行コストは構築側より提案側のほうが上回ってるんじゃないかって話』
一昔前ならシステム構築の手間って膨大な時間と労力をつぎ込んで作るものってイメージがありました。 例えちょっとした機能変更でさえも、開発側の担当者は「それは多くの機能に影響を与えるからかなり時間がかかる」とか何かと理由を付けて拒む姿勢もよく見かけました。 まぁ、これは担当者が面倒くさがっていたり、品質や納期の観点からこの時期にその要求を受け入れるリスクを嫌っていってたのかもしれません。 しかし、今ではその労力というのはだいぶ軽減されてきています。 もちろん要件の規模によりますけど、その一部の機能を構築するのにも昔に比べたらはるかに楽になっているでしょう。 技術の標準化や多様なライブラリ、ネット上に発信される多くのノウハウ、IDEなど開発環境の進化などその理由は多々ありますが、そういった開発コストの低下の中で思うのは、システムを構築する手間っていうのはもはや構築をする側より仕様を決める側の方が
受託開発業界に本当の競争がないだけだ - Sean_SF’s blog
このブログ記事「人月は悪どころか、ものすごい善かもしれない」を読んでとても違和感があった。 筆者は、スマフォアプリは安いからヒットしても500万円程度で、かかる手間に対してリターンが少なすぎる、人月商売でかかった時間に対してお金をもらえる仕組みの方がもしかしたら善なのではないかと言っている。 それは違うと思う。価格はコストや競争で決まる。 コスト（原価）が100円だから利益を50円のせて150円にしようとか。ライバル会社が150円で販売しているからうちは140円で販売しようとか。 価格を決める根拠が人月であるか他のものであるかはどうでもいい。そこに競争があれば、自然と価格は決まっていく。あるいはその価格で作れないメーカーは勝てないだけだ。 日本のSI業界、受託業界で人月計算がまかり通っているのは本当の競争がないからだ。一方、スマフォアプリは世界中のデベロッパーを相手に、オープンなプラットフ
人月商売が悪だと思っている、イノセントなあなたへ - GoTheDistance
色んな意味で示唆的なエントリ。山本さん、どうしちゃったんですか。飲みにでも行きますか。 人月は悪どころか、ものすごい善かもしれない - 山本大＠クロノスの日記 140文字ぐらいでまとめちゃうと、人月ではなくソフトウエアの持つ価値だけでお金を取ろうとすると、例えばスマホアプリの場合は非常に単価が安いのでペイする算段が立たないこともある。それを鑑みると、エンジニアの稼働ベースで請求できる人月ってなんだかんだでイイとこあるよ、って話です。 人月について語られる記事はエンジニアよりの観点で議論されることが多いんですが、そうなると「人月はエンジニアにとって善か悪か」という方向に話が飛んでしまい、ゼネコンは死ねば良いし多重請負は終わってるし日本のIT競争力はなんだかんだっていう感じで一定の結論が出しにくい。なので、もっとビジネスよりの観点で整理してみたい。 人月のメリットは成果物ではなく作業内容に対し
ITなひとだけ笑えるネタ。 - すべての夢のたび。
笑えないかも。 わたしの近所のプロジェクトで採用されている、斬新なプログラム開発手法についてご報告いたします。「IST」といいます。ISTとは「いきなりシステムテスト」の略です。どんな感じに進むかと申しますと、 システムテスト行程開始！ 試験担当者がバグ報告票を書きます。 「バグ：アプリケーションのアイコンがありません」 開発担当者が対応します。 「理由：アプリケーションのアイコンを作っていませんでした」 「対処：アプリケーションのアイコンを作りました」 試験担当者がバグ報告票を書きます。 「バグ：アプリケーションのアイコンをクリックしても、なにも起きません」 開発担当者が対応します。 「理由：メイン処理がありませんでした」 「対処：メイン処理をコーディングしました」 試験担当者がバグ報告票を書きます。 「バグ：（再）アプリケーションのアイコンをクリックしても、なにも起きません」 開発担当
転職して感じたウォーターフォール文化とアジャイル文化の違いについて - 達人プログラマーを目指して
今月から新しい会社に転職して、あっという間に半月が過ぎてしまいました。いろいろな会社の規則や、開発環境、フレームワーク、仕事の進め方など、とにかくたくさんのことを短期間で詰め込む必要があり、もともと想定していたことではありますが自分としてはかなりたいへんでした。 やはり、自分としては、外資系の会社で英語でのコミュニケーションが必要となるということが、最も気がかりなことでした。実際、初日の歓迎ランチはいきなり名前もわからない多くの外国人に囲まれる状況でしたし、電話会議を使って中国やアメリカのチームと一緒に行う日々の進捗ミーティングも英語で行われています。自分としては、特に、リスニングが苦手ということもあり、いまだに完全に会話についていくのが困難なところはありますが、同僚やマネージャーもみんなすごく親切に教えてくれるので安心しました。私は新しい環境に慣れるのに結構時間がかかる方なので、まだまだ
チェックリスト信仰 - rabbit2goのブログ
開発現場で問題の再発防止策を検討すると、その結論として出てくるものの一つにチェックリストが有る。曰く、このチェックリストに従って確認を行えば、同じような問題の発生を防ぐことができるし、誰でも同じレベルで作業を行うことが出来る。チェックリストは素晴らしい、是非ともチェックリストを作るべきだ、チェックリストに従わないのはけしからん等々。 確かにその指摘は正しくで、実施すべき有力な対策の一つではある。優秀な開発者が自分の作業を終えて、万が一のミスが無いか確認する程度の使い方なら充分に有効だと思う。しかし、チェックリストの有効性を信じて疑わない人の姿を見ると、ちょっと待って欲しいと言いたくなってしまう。現場の人なら既に知っているように、チェックリストは同時に問題も多い存在だ。例えば、開発現場でこんな状態を見かけることは少なくないだろう。 確認作業の形骸化 「チェックリストで確認する目的は？」と聞か
日本人プログラマーについての記事が Hacker News で話題になった
東京住まいの外国人プログラマーが日本人のプログラミング世界について記事を書いて (Jawaad Mahmood 氏のブログ記事)、その記事が Hacker News で取り上げられて、話題になった。 "My hypothesis is that a lot of Japanese companies produce little new because they have people solving solved problems over and over again." 以下、拙訳。(*) がついているところは訳していて意味がくみ取れなかった部分なのでコメント頂ければ幸い。誰か Hacker News へのコメントも要約してくれると助かる。 昨日、コーヒーを飲みながらアール氏とアキバに関する話題やらボードゲームやビジネスについて話していた。まじめな話題としてはプログラミングについて、
プログラマ35歳定年説、定年後の未来 - GoTheDistance
株式会社クラステクノロジー代表の四倉氏の連載コラム「第151回」が、とても興味深いのでご紹介します。 【第151回】35歳定年説の真実-株式会社クラステクノロジー 詳しい内容は上記コラムをご覧頂きたく。 プログラマ35歳定年説とは 上記の四倉氏によれば、プログラマ35歳定年説とは｢1Step,1Stepの生産性に比例するので、長い間労働すれば高いアウトプットが出せ収入が増える。体力が下り坂になってきて徹夜や残業ができなくなるのが、大体35歳前後。体力低下と共に収入も下り坂。それに限界を感じてIT業界去ってしまう｣ということのようです。これをプログラマと呼ぶのかとか、ステップ数(笑)という憤りもあるでしょうが、｢ステップ数と売上が比例するため、いっぱいコードを書けば収入が増える｣という理屈は腑に落ちました。是非の問題ではなく、確かにその理屈なら体力勝負という表現も理解できる。 そして、この理
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Loading...
自分のことは一番分かりません
TechCrunch | Startup and Technology News
