タグ

マネジメントに関するpapiroのブックマーク (11)

  • 「元グーグル」という肩書はいつか外したい――及川卓也さんが考える、日本の「残念なIT」からの脱出法 | HRナビ by リクルート

    DEC(デジタル・イクイップメント・コーポレーション)・マイクロソフト・グーグルと、時代を築いた外資系IT企業を渡り歩いた及川卓也さん。マイクロソフトではWindows NT、グーグル時代にはGoogle日本語入力Chrome OSなどのプロダクトに、エンジニアリングマネージャーとして携わっている。 今年5月にプログラマー向けの技術情報共有サービス「Qiita(キータ)」を運営するインクリメンツを経て、今年6月に独立。現在は、国内人材紹介大手のクライス&カンパニーの顧問に就任し、CTO・IT技術人材の採用支援や組織変革活動に力を入れている。そんな及川さんに、「日ITをどう見ているのか」という観点から話をお聞きした。 日IT産業はどこが残念なのか? ――組織変革やIT活用という面で、しばしば「残念」と評価されてしまうこともある日IT産業ですが、いわゆる外資大手IT企業での経験を

    「元グーグル」という肩書はいつか外したい――及川卓也さんが考える、日本の「残念なIT」からの脱出法 | HRナビ by リクルート
    papiro
    papiro 2017/11/25
    自分は今後何をして行けばいいのだろう・・・
  • 技術なきマネジメントの衰退とその対策 - メソッド屋のブログ

    今回は、マイクロソフトにいて自分が感じているIT業界の大きなスタイルの変化の兆候とその対策について書いてみた。今回もいつも通り、単に自分の意見をシェアしているだけであって、他の人にどうこうしろと言いたいわけではない。ただ、日IT業界が米国に追いつき、追い越すための議論のきっかけになるといいなと思っている。自分も楽しみながらも、もがいていることと、そこで見えた光について書いてみたい。 世界は「技術力」の重視に向かっている 私のキャリアは、某大手SIerを12年勤めた後、ITコンサルティング企業に3年在籍して、主に超上流を実践した。その後独立し、ビジネスモデリングから、アジャイルや、DevOpsの導入支援、マネジメント、開発などを実施していた。 私がマイクロソフトを受けてみようと思ったのは、友人からの推薦の要素が大きかったのだが、その背景では、海外で勤務したいという希望があったのと、「技術

    技術なきマネジメントの衰退とその対策 - メソッド屋のブログ
    papiro
    papiro 2017/06/20
    全てが3流とまでいかなくても2流なオイラの未来わ
  • 見えない非効率 ー 今、動いているんだからいいじゃないか | タイム・コンサルタントの日誌から

    新任の取締役が、あるとき担当する事業部の支社を見に行った。一通り見学し、支社長らと懇談した後、かえろうとしたら、ある部署だけ灯りがついているのを見つけた。現場仕事はもう終業しているのに、管理部門の1セクションだけ、忙しそうに机にむかって仕事している。 「何をしているの?」と彼がたずねたところ、「社に送る書類を作成しているんですよ。毎月、数字をまとめて送らなけりゃいけないんで、残業になるんです。」との答えだ。資料を見て、さらにたずねる。「社は、この統計資料を見てどう役立てるんだろう?」「・・存じません。社にたずねてください。」 その取締役は社に戻ると、早速、送付先の企画部門にいって、その書類のことをきいてみる。すると、「ああ、その書類ですか。工場が毎月送ってくるんでね、ファイルして保管しているだけです」という。「でも、なんで工場はその書類を送ってくるのかな?」「さあ・・。」 いろいろ

    見えない非効率 ー 今、動いているんだからいいじゃないか | タイム・コンサルタントの日誌から
    papiro
    papiro 2016/11/15
    気づいてないことがたくさんありそうだし、自分がリスクを負って変えていくと思えてない。
  • 新規事業と「ざっくり力」 - UNIX的なアレ

    新規事業ってあまりにも変数が多すぎて考えないといけないことだらけです。来であれば一定以上はやってみないとわからないものだらけなのですが、どうしても細かいリスクに目が行きがちで議論が深まってしまいます。 来であれば、とにかく意思決定は早くしプロジェクトをどんどんと前にすすめるほうが見えることも多いです。 しかしなかなかそうはいかないこともあるのが現状。そのときに使えるスキル「ざっくり力」というものに会話をしていて気づきました。 立ち上げ時のワナ まずありがちなのが、細かなリスクやこういうときにこうだったらというとにかく多くのケースの想定です。 当然、出来る限りリスクを想定しておくことは大事なのですがこのリスクを潰そうとすることをやりすぎてしまうとプロジェクトがなかなか前に進みません。とくに「予算が多い」「関わる人間が多い」となるとそうなりがちかなと思います。 確かにそれは間違ってはいない

    新規事業と「ざっくり力」 - UNIX的なアレ
    papiro
    papiro 2016/10/18
    丁寧にやることと割り切るところのバランス
  • long_time_work_cannot_finish_tasks

    先日、会社のチームリーダーと面談を行った。 リーダーから「この会社で働いていて楽しい? 困ったことはない?」と尋ねられ、 僕は即座に「すごく楽しいですよ。日で働いていた会社とは大違いです」と答えた。 「日では毎日2時間から3時間残業するのが当たり前でした。 ときには週末を潰したり、徹夜でバグ修正を行ったりすることもありました。 それに比べてこの会社では残業が全然ないし、毎日適度な作業量を与えられて集中して仕事ができるから最高ですよ」 彼女はこれを聞いて、驚いたような呆れたような表情を見せこう語った。 「その日の会社、マネジメントがひどい。 いくら長時間仕事をしたところで仕事が終わるなんてありえないのに」 いくら働いても問題は無くならない 「それは生産性が落ちるからってことですか?」と尋ねる僕に、彼女はこう続けた。 「例えば、いま未解決のバグが10個ある。 すべて直すのに80時間かかる

    long_time_work_cannot_finish_tasks
    papiro
    papiro 2016/08/16
    知的労働は完全に終わることはない・・・そうか
  • 「指示待ちの部下」の原因は「無能の上司」だ。

    ある会社で、マネジメントについて議論をしていた時の話だ。 「もっと自由にやらせろ、って言う人は見込があるんだけどね。」 と、その会社の役員は言った。 「当に問題なのは、「もっと細かく仕事の指示をだしてください。」って言って、当に言ったことしかしない人。こういう人は問題だね。」 彼は心底困っているようだ。 この手の話はよく耳にする。 「そうなんですね。でも少なくとも「言ったこと」はやるんですよね。やらないよりマシじゃないですか?」 「まあ、そういう考え方もあるけど、当にこっちが「言ったこと」しかしないって、問題じゃない?」 「ふーむ。」 「例えば、こっちがデータの入力を頼んだとするじゃない。で、そういう人たちにはまずマニュアルがないとダメなんだよ。」 「マニュアルですか。」 「そう、結構細かく書いてあげないと、「できない」って言うし。で、たまにマニュアルに書いてないこともあるわけだ。そ

    「指示待ちの部下」の原因は「無能の上司」だ。
    papiro
    papiro 2016/07/05
    組織の運営が回るか回らないかは、本来上司の仕事であり責任だよね。なんのための上司?結局部下は上司を見ているということを忘れているかもしれん自戒を込めて(部下いないけど)
  • マネジメントサイクルは「PDCA」ではなく「STPD」で回す - プログラマの思索

    「マネジメントサイクルは「PDCA」ではなく「STPD」で回す」記事をメモ。 以下は理解できたことをラフなメモ書き。 【参考】 ITエンジニアのための押さえておきたいビジネス知識 - 第5回:マネジメントサイクルは「PDCA」ではなく「STPD」で回す:ITpro リスクマネジメント(安全管理) 楽しいアウトドア活動は安全から STPDサイクルでリスクマネジメント メルマガ詳細 【近況】Plan-Do-Check-ActionとSee-Think-Plan-Do: クイズの引力実験室 PDJロゴス・ブログ: 今を生きる 「目標を考える(2)」 脅威と正面から向き合えるか ~富士フイルムとコダックの明暗を分けた脅威~:仕事を楽しく未来を明るく:ITmedia オルタナティブ・ブログ マネジメントでよく出てくるPDCAサイクルの弱点は、Planの意味が大きすぎること。 計画を作るだけでパワーを

    マネジメントサイクルは「PDCA」ではなく「STPD」で回す - プログラマの思索
  • ソフトウェアエンジニアがたどる成長過程と失敗の行きつく先 | POSTD

    これからご紹介する私の試みはなかなか難しい側面があり、物議をかもすかもしれません。また、お見せするのは初めてなので完璧とは言えないかもしれません。私はソフトウェアエンジニアのスキルとその影響力を評価するシステムを開発しようとしています。少なくとも、プログラマが成長していく理想的な成長過程を大まかに描いてみようと思います。評価スコアは0.0から3.0まであり、それぞれの数字は専門能力を開発していく際の出発点を表しています。 このシステムは主にビジネスの観点から見た、ソフトウェア業界が求めるものに基づく 実務的な スケールです。数学的な才能や高速アルゴリズムを書く能力、Linuxカーネルの内部構造に関するプログラマの理解の深さなどを評価するスケールではありません。もちろんこうした能力は重要ですし、通常、エンジニアのスキルとともに伸びていく能力ですが、私のシステムが焦点を当てたいのはそこではあり

    ソフトウェアエンジニアがたどる成長過程と失敗の行きつく先 | POSTD
  • 炎上プロジェクトの責任はプロマネが9割 - プロマネブログ

    サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ 前回からの続きです。 以下、3部作の3目となります。 ウォーターフォール開発とアジャイル質 - プロマネブログ サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ 炎上プロジェクトの責任はプロマネが9割 - プロマネブログ 追記)ブコメで誤字の指摘がありましたので、訂正します。。。お恥ずかしい NetPenguinさん、ご指摘ありがとうございます 改めて考えたいプロマネの仕事 プロマネの仕事とは、PMBOKのプロジェクト管理に関する観点をマネジメントする、と言えます。 統合   ・・・ チーム内の意思統一 スコープ ・・・ 目標、成果決定 タイム  ・・・ 期限、スケジュール管理 コスト  ・・・ 予算、費用管

    炎上プロジェクトの責任はプロマネが9割 - プロマネブログ
  • セルフマネジメントのレベルと欠かせないスキル 〜 自己組織化されたチームを作るためには | Social Change!

    私はよく講演などで「弊社はマネジメントしない会社です」と言ってます。ソニックガーデンでは、指示や命令などすることなくて、スタッフは各々で状況判断しながら仕事に取り組み、働くことを監視されたりすることはありません。 マネジメントしない、というのは、あえて気を引く言葉を使っているだけで、当は、各自が自分で自分のマネジメントができるから、なんです。つまり、全員がセルフマネジメント出来れば、マネジメントは不要になります。そうすると自己組織化されたチームが出来上がります。 とはいえ、セルフマネジメントにもいくつか段階があると最近感じるようになりました。最初から高いレベルのセルフマネジメントができる人は稀です。順番に身につけていくような気がしています。この記事では、そんなセルフマネジメントのレベルについて考えてみました。 Jogging on a bright November morning /

    セルフマネジメントのレベルと欠かせないスキル 〜 自己組織化されたチームを作るためには | Social Change!
    papiro
    papiro 2013/04/22
    僕は全然ダメだということね・・
  • エンジニアのジレンマ ~悩む立ち位置と仲間の境界~ 記事一覧 | gihyo.jp

    運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します⁠。個別にライセンスが設定されている記事等はそのライセンスに従います。

    エンジニアのジレンマ ~悩む立ち位置と仲間の境界~ 記事一覧 | gihyo.jp
  • 1