蛯谷敏 日経ビジネス記者 日経コミュニケーション編集を経て、2006年から日経ビジネス記者。2012年9月から2014年3月まで日経ビジネスDigital編集長。2014年4月よりロンドン支局長。 この著者の記事を見る
“雰囲気最悪”な職場の共通項：日経ビジネスオンライン
蛯谷敏 日経ビジネス記者 日経コミュニケーション編集を経て、2006年から日経ビジネス記者。2012年9月から2014年3月まで日経ビジネスDigital編集長。2014年4月よりロンドン支局長。 この著者の記事を見る
【島国大和】ゲームはこうしてダメになる。横ヤリ刺さって死屍累々。
【島国大和】ゲームはこうしてダメになる。横ヤリ刺さって死屍累々。 ライター：島国大和 島国大和 / 不景気の波にもがく，正体はそっとしておいて欲しいゲーム開発者 島国大和のド畜生 出張所ブログ：http://dochikushow.blog3.fc2.com/ どうも，島国大和です。 デスマーチ，してますか？ 前回，「ゲームを作る立場で，どうやって落とし穴を回避するかを考えるよ。」と題して，ゲームを開発していくうえでハマりやすい罠を，どうやって回避するのかといったことを書きました。 今回はその続き，というか，そこで書き切れなかったことをまとめてみたいと思います。テーマは，「なぜ横ヤリは入るのか」ということ。 ゲームが大失敗する理由の中で，かなり大きいのが，偉い人からの横ヤリです。完成品を見て「ここちょっと，こうすべきじゃない？」みたいな。 ここではなぜ横ヤリが入るのか，それがどうしてダメー
組織パターンを実践する - Kentaro Kuribayashi's blog
先日(10/30)「ジム・コプリエン (James O. Coplien) : Advanced Scrum - 組織パターンでScrumを微調整する "Scrum Fine-Tuning using Organizational Patterns」という研修 + ワークショップに参加しました。先日刊行された『組織パターン (Object Oriented SELECTION)』に基づき、著者のコープ氏自らによる解説を聞ける貴重な機会でした。 研修について コープさんについては、『組織パターン (Object Oriented SELECTION)』その他の本などの活動により、非常な敬意を抱いているのですが、今回、これまた尊敬する角谷さんに機会を与えていただき参加することができて、とてもよかったです。コープ氏、角谷さんをはじめとするコーチ陣のみなさま、ありがとうございました。 研修の内容は
DevOpsなんてくそくらえ - razokulover publog
先日こんなことを言われた。 「テストを書いた成果を見せよ」 と。 ショッキングだった。 経緯 わたしはいまレガシーなコードに囲まれている。 もちろんテストもほとんどないピカピカのレガシーちゃんである。 レガシーちゃんは「Ctrl+F5 & tail -f 駆動開発」により開発が進められており、日々進化している。 このまま進化をつづけるといつかモンスターになり(もう軽く怪獣っぽいが)、開発スピードがどんどん遅くなり、メンテナンスやバグつぶしでエンハンスとなるような開発ができなくなる。このままじゃマズい...。 こういった事態を一新すべく、手探りながら私含め数人の先輩たちで「DevOps」に取りかかることになった。 バズワードにもなっているが「DevOps」とは、 従来型のシステム管理や調達（ITILを含む）といった、保守的でプロセスを中心に据えた運用からよ>り戦略的でアジャイルな、そして自動
Blog : 賢く振舞おうとするから大企業病になる。
2013年10月10日21:39 カテゴリキャリア系独り言 賢く振舞おうとするから大企業病になる。 書くとマヌケな話だが、実際には難しい話。例えば、ある失敗が発生するとする。二度と同じく失敗を繰り返さないために、失敗回避プロセスを導入する。そう考えることが、当たり前であり、賢い振る舞い。 でも積み重なって行くと、失敗回避プロセスばかりで、成果に向かうための時間シェアが下がって行く。クリティカルな失敗や頻度が高い失敗には効果的だが、進化すると、発生してから対処してもカバーできることまで失敗回避プロセスが導入される。 事前調整も同じ。賢く効率的に議論するために、事前調整をするのだが、やればやる程、本丸の成果のためのシェアが下がって行く。マネジメントは、成果に対して最大効率化をするために、メンバーに成果に対して最大にパワーを割けるようにするために存在するはずなのに、失敗回避や事前調整のためマネジ
「とにかく頑張れ」「名刺100枚もらってこい」なんて精神論、有害無益でしょう――ライフネット生命 出口治明さんに聞く、最強チームの作り方【前編】 | サイボウズチームワーク総研
TOP ブログ 「とにかく頑張れ」「名刺100枚もらってこい」なんて精神論、有害無益でしょう――ライフネット生命 出口治明さんに聞く、最強チームの作り方【前編】 2013.09.11 「とにかく頑張れ」「名刺100枚もらってこい」なんて精神論、有害無益でしょう――ライフネット生命 出口治明さんに聞く、最強チームの作り方【前編】 ベストチーム・オブ・ザ・イヤー ※ベストチーム・オブ・ザ・イヤーのサイトから移設しました 新しい価値を生み出すチームとはどのようなものか？ 特集「最強チームの作り方」では、新しい価値を生み出すチームの"リーダーシップ"や"コミュニケーション"の考え方に迫ります。大企業から新進気鋭のベンチャー企業まで、大小さまざまな規模でチームを作ってきたライフネット生命保険株式会社、創業者の出口治明さんに、普遍的なチームの作り方を聞きました。 （出口さんへのインタビューは、「面従腹
人事評価とはどういう仕事か－－『C:A:Pモデル』による分析の試み | タイム・コンサルタントの日誌から
中間管理職になってからそれなりの時間がたつが、人の評価というのはいまだに不得手である。毎年回ってくる、人事評定と呼ばれる仕事のことだ。部下を面接し、その目標や達成度や希望やら不満やらを聞いて、それからおもむろに机に向かって、その人の評点をつける。面接自体はそれほど苦にならないが、評価がいつも難しい。その昔、面接で自分が上司に訴えるだけですんだ頃に比べると、とても気の重い仕事である。自分の評価した結果が、直接、その人のボーナス査定や昇進につながるからだ。 まあ、わたしの職場の場合、自分の決めた評点が最終値となるわけではなく、さらに上司やもっと上での調整・決定が行われるので、少しは責任が軽いと言えるかもしれない。ただ、査定が決まった後、今度は管理職は部下にそれを伝えなければならない。当然、（なぜ自分の努力はこれしか報われないのですか？）と、全員の目が訴えてくる。自分だってそうだったのだから、も
ディレクターがプログラマーとうまくやる方法を全部教えます : LINE Corporation ディレクターブログ
こんにちは、櫛井です。 プロジェクトマネージャーやディレクターの仕事というのは多岐に渡りますが、特にプログラマーと上手にコミュニケーションを取り一定の目的を果たすというのはわりと大変なことだったりするらしいです。私は比較的プログラマーとうまくやれているタイプのようなのであまり苦労した覚えが無いのですが、過去10数年で培ったプログラマーと上手くやる方法を紹介していきたいと思います。おまけで「プログラマーに嫌われる６つのこと」も紹介します。 ※うまくやれてるイメージ図 プログラマーと上手くやる方法をざっくり言うと 役割分担として求められていることをやる お互いのTODOを把握し区切りをつける スケジュール管理をしっかりする といったカンジです。ではそれぞれ説明していきます。 役割分担として求められていることをやる そもそもディレクターが求められる役割とはなんでしょうか。Web開発案件におけるデ
部下がホウレンソウをしない理由 - teruyastarはかく語りき
多分、報・連・相の意味は間違って伝えられてるよ | 日系パワハラ http://nikkeiph.com/spinaches/ 私は、会社の"ほうれんそう"が立派に育っているかどうかの一つの目安はイヤな情報、喜ばしくないデータなどが何の粉飾もされずに正しく上に伝えられることだと思っている。 〜中略〜 上の人間が聞いて不快になりそうな情報は、なるべく伝えないようにしようという土壌がいつのまにかできているとしたら、この土壌には"ほうれんそう"は育たない。 そして山崎氏曰く、若い人からの率直な意見は吸い上げ、問題点があるならば改善するなど積極的な反応が大事だといっています。そればかりか、ほうれんそうを腐らせているのは管理職であるとも遠回しに言及しておられます。 この記事に共感したので、 上司と部下の視点で思うところを書いてみます。 ちなみに報連相の定義は、 ホウレンソウとは 〜 exBuzzwo
ITエンジニアの『生産性』と、データ・サイエンスの微妙な関係 | タイム・コンサルタントの日誌から
ある、社外の人との集まりに顔を出した時のこと。IT分野の経験を積んだ人が多く、みな一家言持っておられる。わたしは昨年後半から、久しぶりに社内のIT関連業務を見るセクションに移ったばかりなので、最近の事情に疎い。なるべく拝聴する側に回ることにした。話は業界の技術トレンドから、クラウドやビッグデータといった最新のバズワードに向かい、日本のIT業界の現状をなげく論調にうつった。日本を代表する大手SIerたちの低空飛行ぶり、技術的イノベーションの不足、そして多重下請に象徴される業界の構造的問題。追い打ちをかけるように、オフショアとの競合による単価の下落。なんだか、あんまりエンカレッジされるような話題が出てこない。 －－だとすると、日本のSI業界というのは将来性があるのでしょうか？ わたしは思い切って、直球ど真ん中の質問をなげてみた。しかし返ってきたのは、苦笑いするように首を横に振る姿ばかり。 「情
ソーシャルゲーム開発の実体験記 #1 ポチポチゲー開発実体験談 : 驚異の趣味人
6/21追記 ほ、ホッテントリ入りしてしまった…！？ ちょっと補足なども書いてみました→ソーシャルゲーム開発体験談のホッテントリ入りを受けて はじめに ソーシャルゲーム開発会社で仕事していた時のアレコレ話 裏側って程でもないけど、まぁこんな感じだよってな具合で ソーシャルゲーム開発の実体験記 #1 ポチポチゲー開発実体験談 ソーシャルゲーム開発の実体験記 #2 全く売れない こんなオシゴトがあった。 ちょうど1年くらい前だが、ソーシャルゲーム開発現場に業務委託として関わっていたので その時あった事でも書き連ねて見ようと思った。 2年くらい前からソーシャルゲー開発には関わっており、現場もいくつか経験してはいるのだけど 所謂「ポチポチゲー」に初めて関わったのがこの時なので、色々と新しく得るものが多かったかな？ 良くも悪くも（苦笑） 開発会社・そのメンバー ちなみにこの時居たのは、業務システムや
「報・連・相（ほうれんそう）」でいい思いをした人などいない：日経ビジネスオンライン
今回のコラムでは「部下に仕事を任せる」技術を７つのエッセンスに整理してお伝えてしいる。 エッセンスその1：「任せるしかない」と腹をくくろう。 エッセンスその2：「振る」と「任せる」の違いを知ろう エッセンスその3：まずは信頼関係の構築から始めよう エッセンスその4：「失敗は部下の権利である」と知ろう エッセンスその5：「コピー」作りはやめよう ここでお伝えしているメッセージは「上司の仕事は経営そのもの」ということである。そして経営とは矛盾を解消しつつ、矛盾を意図的に創造することではないだろうか。本連載で取り上げる「部下への任せ方」もそれに類する。今回は、エッセンスの最後。部下に任せつつも適切に導くための「定例ミーティング」を紹介する。 前回の記事で、私は「口出しはやめよう」と提案した。また「部下にあえて失敗させよう」とも提案した。だが、そればかりではうまくいかない。適切な方法で部下の仕事の
開発時間短縮のためのプラクティス10選 - give IT a try
このエントリを書いた背景 先日会社で「開発時間を短縮するためのアイデアやノウハウをみんなでシェアしよう」という課題が出されました。 「カウボーイコーディングとコピペプログラミングで技術的負債たっぷりのシステムを作りましょう。そうすれば開発時間はぐっと短くなりますよ」なんてことは口が裂けても言えないので、真面目に考えてみました。 色々あるとは思うのですが、その中でも特に重要だったり、言語や技術を問わずに使えそうなものを10個選んでみました。 どれもまあ、基本中の基本だったり、アジャイル開発だと常識的に行われているようなことばっかりかもしれません。 とはいえ、おいらの会社に限定されるような話は載っていないので、ここにもその時に書いた内容をそのまんま載せておきます。 ただし、あなたの仕事とおいらの仕事は少し違うと思うので、読む前に以下の前提条件を確認しておいてください*1。 このエントリを読む前
チケット駆動開発で作業管理はしないほうがいい - arclamp
先日、2013/3/23（土）に弊社でチケット駆動と開発環境に関するイベントを開催しました。リンク先には資料も上がっていますので参照ください（※アトラシアン製品関連のイベントです）。 基調講演にはチケット駆動開発を推進されている関西XPUGのあきぴーさんをお招きして「チケット駆動開発をパターン言語で読み解く」という話をしていただき、最終枠ではパネルディスカッションをしました。 チケット駆動開発とウォーターフォール パネルディスカッションでは、僕が「チケット駆動開発を作業計画に使うのは難しく、WBSとの併用が現実的」と話し、あきぴーさんが「作業計画をチケット駆動開発で回していくには」というノウハウを紹介されていました。 この違いは僕がウォーターフォール的な新規案件を、あきぴーさんがアジャイル的な開発/保守運用案件を前提にしているためです。 僕自身はBTS（Bug Tracking Syste
どうすれば小さなチームでも大きな成果を出せるのか 〜 少人数のチーム、低コストで開発を続けていくためのプロセスを学ぶ | Social Change!
先日3月21日に、スクー（ http://schoo.jp/ ）という、ウェブ上で様々な授業が受けられるサービスにて、ひとつ講義を受け持って授業をしてきました。 「どうすれば小さなチームでも大きな成果を出せるのか 〜 少人数のチーム、低コストで開発を続けていくためのプロセスを学ぶ」というテーマで授業をしてきました。 オンラインで生放送の授業をするという初めての経験で緊張しましたが、質疑応答で沢山質問も頂けたので、とても良かったです。オンラインの方が、質疑応答で質問が出やすいような気がしますね。 この記事では、その授業での内容や、スライドと質疑応答について書きました。 授業内容の紹介 大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。 ウェブサービスを
勝ち抜きたければ「迷わない人」と組んではいけない。：日経ビジネスオンライン
原作は『ライアーズ・ポーカー』『世紀の空売り』のマイケル・ルイスが書いたノンフィクション。作品の舞台となっている球団、「オークランド・アスレチックス」は、弱小チームで予算が少ないのによく勝っている。その裏にいた男とは…というお話です。 押井：プロスポーツを舞台に、スポーツクラブのマネージメント映画を作るというのはアメリカではひとつのジャンルになってるんです。日本にはなぜかほとんどないんだけど。常々いつか自分でも撮りたいと思ってるんだけどさ。 押井さんが撮りたいのはどういう内容の企画なんですか？ 押井：熱海グランスパってJFLで低迷しているサッカーチームがJリーグに昇格するという話。だいたい構想もできてるんだけど、たぶん誰も撮らせてくれないかな（笑）。それこそ日経ビジネスオンラインはこんなに読まれているし、いろんなビジネス本が売れてるし、企業小説も流行ったじゃん。なんでこの国ではプロスポーツ
ダメなシステムが無くならない理由はエンジニアを正しく活用できないから - GoTheDistance
Twitterで流れてきたのでつい見てしまいましたが、この方の連載は全体的にやっつけ感が否めないですね。 なぜ“ダメなシステム”は無くならないのか？ - なぜ“ダメなシステム”は無くならないのか？：ITpro この"ダメだしとっつあん"があの手この手で言わんとしてることは｢上流工程と下流工程の分断は悪であり、ダメなシステムはそこから生まれている｣ということですので、この記事を読んだ人は連載読まなくて大丈夫です。僕が書いたこのエントリ読んでください。もっと突っ込んで書いてあります。 ｢SIerでのキャリアパスを考える｣というイベントに登壇しました - GoTheDistance もうそろそろぶっちゃけてもいいでしょ。ダメなシステムができる理由は簡単だってことに。ウオーターフォールが逆流できないせいだ/丸投げするからダメ/リスクをとらないからダメ/技術力のないやつが舵を取るからダメ・・・ってさ
天才でもカリスマでもない、普通の人のためのリーダーシップ：日経ビジネスオンライン
蛯谷敏 日経ビジネス記者 日経コミュニケーション編集を経て、2006年から日経ビジネス記者。2012年9月から2014年3月まで日経ビジネスDigital編集長。2014年4月よりロンドン支局長。 この著者の記事を見る
「仕組み化」では勝てなくなってきている時代に正社員はどうなるか : けんすう日記
仕組み化力 仕組み化というのは、ビジネスについて非常に重要と言われています。成功する会社とそうでない会社の違いを述べる時に、「属人的ではなくて、仕組みに出来たところが強い」という話はよく出てきます。 たとえば、楽天などは「仮説→実行→検証→仕組み化」を5つある成功のコンセプトの１つにあげていました。 これは超同意で、仕組み化をいかに作るのか、属人的ではなくて組織力、そして組織が持っている知見でどう戦うのか、という点について、nanapi社でも意識をしていました。 しかし、最近それだけでは全然勝てない時代かもしれない・・・とも思い始めています。 仕組みをすぐに変える必要がある というのも、仕組みを作ってそれで何年もやっていけた時代と違って、今の時代、特にインターネット業界では、動きが早すぎるのですね。 特定のルールの元で「仮説→実行→検証→仕組み化」をしても、ルール自体が変わるのです。つまり
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
なぜサイボウズは、働く「時間」と「場所」の制約をなくせたのか？（前編） | サイボウズ式
