タグ

Managementに関するWatsonのブックマーク (367)

  • 403 Forbidden

    \閉鎖予定のサイトも売れるかも?/ アクセスがないサイトもコンテンツ価値で売れる場合も… ドメインの有効期限を更新してサイト売却にトライしてみましょう

    403 Forbidden
  • プロジェクト管理のエモいはなし - Qiita

    前置き 私のキャリアは少し変わっています。 この業界に新卒で入ってから十数年は、大手ゼネコン的SIerにて、ほぼ一貫してプロジェクトマネジメントをやってきました。最終的には100人月程度の案件を回していたので、中堅クラスではあったと思います。それなりに経験も積んだとは思いますが、あれ、そもそも私って人の管理をやるためにIT業界に入ったんだっけ。。というレーゾンテートル的な理由で、プログラマーに転身しました。 そんなわけで、おそらく日IT業界におけるプログラマーから管理職に至るという一般的なキャリアパスを逆行している形になります。 そういった事情もあり、プロジェクト管理からは距離を置くようにしていたのですが、最近またプロジェクトマネジメントについて考える機会が多くなったので、この辺で昔話をしてみようと思います。 他山の石としてワカモノの役に立てば。 前提として ガチガチのウォーターフォー

    プロジェクト管理のエモいはなし - Qiita
  • 技術なきマネジメントの衰退とその対策 - メソッド屋のブログ

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

    技術なきマネジメントの衰退とその対策 - メソッド屋のブログ
  • グーグル会長が語った「価値を生み企業を成長させる人材のたった2つの資質」とは

    「『潤滑油』を雇いすぎるな」とアルファベットのエリック・シュミット会長は語る。(ラスベガスで開催された2017年SALT会議にて) Richard Brian/Reuters エリック・シュミット氏が2001年にグーグルの会長兼CEOに就任した当時、従業員はほんの数百人しかいなかった。しかし10年後、同氏が会長職に専念する為にCEOを退任する頃には、従業員数は3万2000人にまで膨れ上がっていた。 シュミット氏は今や、グーグルの親会社であり、世界最大級の影響力を持つ会社、アルファベットの会長を務めている。現時点で、アルファベットの従業員数は6万人以上、時価総額は約6630億ドル(約72兆9000億円)。 「私自身のみならず、グーグル全体のマネジメント哲学の基礎は、急成長していたグーグル黎明期に築かれた」 LinkedIn共同創業者兼会長リード・ホフマン(Reid Hoffman)氏が有名創

    グーグル会長が語った「価値を生み企業を成長させる人材のたった2つの資質」とは
  • フィボナッチ工数見積は「完成させます!(徹夜で)」という無理ゲーによる弊害を最小化するプロジェクトマネージメント手法 - ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記

    今まで数々のプロジェクトマネージャーとそのプロジェクトマネージメント手法に翻弄されてきたが、現在の勤め先であるベルリンのITスタートアップで取り入れている手法が歴代の中でも一番マシ。まず工数見積がとても洗練されている。エンジニアが無理やりに「今週中に完成させます!」と言わされて、結局はその約束が守りきれずに翻弄される、というような弊害が最小化できているな、という話。 プロジェクトマネージメントチームのメンバー達はその見積方法を「フィボナッチ」と表現している。 だいたい工数見積なんてものが正確にできる人に出会ったことが無い。複雑なITプロジェクトの全体像を把握して「これをうちのチームで完了するためには**日を要する」なんてピタッと当てたためしがない。絶対にズレる。 エンジニアに向かって「お前さー『今週中に完成させます』って言ったよな?誰だっけ、それ言ったの?オレじゃねーよ。お前だよ。おめーの

    フィボナッチ工数見積は「完成させます!(徹夜で)」という無理ゲーによる弊害を最小化するプロジェクトマネージメント手法 - ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記
  • ヤフーの1on1 - @kyanny's blog

    Engineering Managerになって三ヶ月経ち、ぽつぽつと1on1をやりはじめたが、合ってるのかよくわからないのでを買って答え合わせすることにした。結局、を読んでも自分の振る舞いに対するフィードバックは得られないので、答え合わせにはならなかったかもしれない。 アクティブリスニングはできてると思う。昔から、人に興味ない割に、一対一で話すときは不思議と会話にのめり込みながら聞く癖がある レコグニションは大事そうだと理解してたけど、実践はまだまだのような気がした ティーチングとコーチングの切り替え・使い分けをもっと強く意識すべきだと思った。コーチングの割合を増やした方が良い 相手のための時間であるということも、もっと強く意識すべきだと思った。つい自分が話しすぎてしまう コーチングに通ずるテクニック全般に言えることだが、綺麗事にみえて実際は「相手に悟らせず自分の意のままに操る、人を動

    ヤフーの1on1 - @kyanny's blog
  • 技術的負債と向き合う

    オープンセミナー2017@岡山での発表スライドです

    技術的負債と向き合う
  • CodeIQについてのお知らせ

    2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod

    CodeIQについてのお知らせ
  • フリーランスに向いている人はどんな人か(結城浩「ワークスタイル・ライフスタイル」) | mine

    ●自分が自分の上司になれる人「自分が自分の上司になれる人」というのは抽象的な表現ですね。以下のようにパラフレーズしてみましょう。 ・混沌とした状況を整理して、人に振り分けられる形の「仕事」に分割することができる人。 ・分割された「仕事」の内容や難易度を見極めることができる人。 ・メンバーの中でその「仕事」に適している人材として「自分自身」にその仕事を割り当てることができる人。このような人をイメージしました。 フリーランスであろうがそうでなかろうが、「仕事」は無から自動的に生まれてくるものではありません。必ず誰かが混沌とした状況から「仕事」を切り出してくるものです。 はい、この「仕事」は、 この資料をもとにしてこういう文章を書くもの。 何月何日までに書いてくださいね。こういうのが「仕事」の指示ですよね。こういわれてきちんと期日までに仕上げるのは「仕事をちゃんとやる」ということです。 でも、よ

    フリーランスに向いている人はどんな人か(結城浩「ワークスタイル・ライフスタイル」) | mine
  • エンジニアを指導する立場の人こそ読んでほしい、新卒エンジニアが1年間で上司に感じた5つのこと - Qiita

    (追記 2017/5/10) だいぶ放置していた形になってしまい申し訳御座いません。 僕自身ここまでの反響が(炎上が?笑)起こったことに驚いております。 賛同してくださった方・批判してくださった方、どちらも最後まで記事を読んでいただき、コメントまでしていただいたことに感謝でいっぱいです! 自身の考え方としても勉強になりますし、何よりみなさんがこれだけ真剣になっていることが僕自身はとても嬉しい限りです。当にありがとうございます。 前書き エンジニアとして1年経ち、振り返ってみると、業務中にわからないことがあるたびに調べ、 Qiita (記事投稿者の皆様方) には大変お世話になりました。ありがとうございます。(今頃になって自分は登録しましたが笑) 社会人1年目って人生1回きりしかありません。自分も2年目となり指導する側になる身として、 1年目で抱いていた心をいつまでも忘れないために、これを残

    エンジニアを指導する立場の人こそ読んでほしい、新卒エンジニアが1年間で上司に感じた5つのこと - Qiita
  • 村上春樹のうなぎ説を応用して、Misocaうなぎ説でチームづくりに取り組む - 弥生開発者ブログ

    ユーザー、プロダクト、チーム こんにちは、こくぼ @yusuke_kokubo です。 プロダクトをつくることと、つくりかたをデザインすることが好きです。 早速ですが、プロダクトをつくる流れをごくごく簡単にまとめてみました。 細かいことを言うと、他にもプロダクトのリリースに至るまでのプロジェクトについての話があったり、リリース後のユーザーサポートやメトリクスの話があったりしますが割愛します。 今日はチームづくりの話をします よいプロダクトはよいチームによってつくられます。 よいチームをつくるためにはよいマネジメントが必要です。 ボトムアップの行動と文化は勝手には育ちません。 会社としてトップダウンで環境をつくり、指針をつくることで文化が育まれる、というのがぼくの考えです。 今日はぼくがMisocaで行っているチームづくりについてお話しします。 チーム内のコミュニケーションを活性化するために

    村上春樹のうなぎ説を応用して、Misocaうなぎ説でチームづくりに取り組む - 弥生開発者ブログ
  • タスクをどんどん遅延させてしまう人に、何故遅延させてしまうのかヒアリングした時の話

    何度か書いていますが、しんざきはシステム関係の仕事をしており、今はそんな大きくないチームの責任者です。自分でも色々作業しますが、一応マネジメントもする立場です。 今とはまた違うチームにいた頃、チームの統合・再編成が行われたことが何回かありました。 チームメンバーは増えたり減ったりしますが、大体毎度、新しいメンバーを何人かは見ることになります。 当たり前のことですが、知らないメンバーと一緒にやっていく際には、まずその人にどんなタスクを振るか、どうタスクを振るかを考えないといけません。 何か新しい技術に触れていくならどのようにスキルのキャッチアップをしてもらうか考えないといけませんし、引き継ぎがあるなら引き継ぎの計画を立てなくてはいけません。 だからチームの再編成の時には、格的に仕事を始める前に、それぞれのメンバー、及びそれぞれのメンバーの以前の上司に必ず面談とヒアリングをします。いや、別に

    タスクをどんどん遅延させてしまう人に、何故遅延させてしまうのかヒアリングした時の話
  • 「エンジニアのための制度」は作りたくない クックパッド技術部長が人事を兼任してまずやったこと

    2017年2月17日、人事とITをキーワードに、エンジニアリングやテクノロジーに関する理解を深めるためのイベント「人事 to IT カイギ」が行われました。第1回目のテーマは「エンジニアのキャリアパスとしての人事」。パートでは、クックパッド技術部長の庄司氏が人事部長を兼務することになった経緯について紹介しました。 クックパッド技術部長と人事部長を兼任 庄司嘉織氏(以下、庄司):藤(真樹)さんのありがたいお話のあとで恐縮ですが、自己紹介から。庄司嘉織といいます。だいたいGitHubTwitterやFacebookで「yoshiori」で検索すると出てくるので、よろしくお願いします。 技術部長と人事部長を兼任しています。今日は人事部長の立場として来ました。藤さんがやらなかったのでこれをやるのは恐縮なんですけれども。(挙手をしながら)クックパッドを知っている人? (会場挙手) 良かった

    「エンジニアのための制度」は作りたくない クックパッド技術部長が人事を兼任してまずやったこと
  • 新任の管理職に知っておいてほしいこと。

    4月である。今日から新任の管理職となった方もいるだろう。 ただ、管理職という肩書を得ても、その人に部下が付き従うかどうかは別の問題である。国も、企業も、自治体も、町内会も、部活や子どもたちのコミュニティですら例外ではない。 実際、管理職たちは下から厳しい目で見られる。 彼らが「他者から決定を委ねられている」ということは、それだけ彼らの統治能力が高くなければならぬ、ということでもあるのだ。 だが、組織における管理職の統治能力とは一体なにを指すのだろう。 この質問をすると、 ある経営者は 「ビジョンを示すことだろう」 と答え、またとあるマネジャーは、 「人格である」 と答える。 確かに、管理職研修のテキストを読めば、そう書いてあるし、実際に大事だ。 しかし、それらはあくまでも「きれいごと」に過ぎない。我が身を振り返って見てほしい。現実的に、上司にそれほどビジョンや人格を求めたことがあるだろうか

    新任の管理職に知っておいてほしいこと。
  • プロダクトマネージャーに訊く #9:Increments及川さん - 小さなごちそう

    — 今回はIncrementsでQiitaのプロダクトマネージャーを担当されている及川さんにお話を伺います。早速ですがQiitaの概要やサービスコンセプトについて教えてください。 Qiitaはエンジニアのための情報共有コミュニティサイトで、様々なユーザーが技術の習得やトラブルシューティングに役立つ情報を発信しています。Qiitaはエンジニアのためのナレッジベースになっており、多くのトラフィックがGoogleなどのWeb検索から流入します。エラーメッセージをキーワードに検索し、Qiita上のページにたどり着いて問題を解決する、といった使われ方ですね。 Increments株式会社は「ソフトウェア開発をよくすることで世界の進化を加速させる」を企業ミッションとしています。その企業ミッションのもと、ソフトウェア開発を支える技術者のための知の共有プラットフォームとしてQiitaを提供しています。 人

    プロダクトマネージャーに訊く #9:Increments及川さん - 小さなごちそう
  • なぜ優秀なエンジニアを低待遇で採用してはいけないか

    この記事は技術そのものやエンジニア採用のことがよく分からない経営者へ向けて書いています。エンジニアが読めば当たり前のことが書いてあります。また優秀なエンジニアならこう考えるのではないかというところは、私見によるものなので当にそうかどうかは分かりません。 募集要項を書く募集要項で最も重要なのは待遇に関するところだと私は思います。具体的に言えば、だいたいの年収です。もちろん業務内容や組織の雰囲気なども重要ですが、業務内容や組織の雰囲気が良ければ年収が低くても働こうと思ってくれるのではないかと考えるのは経営者の奢りであって、そんなエンジニアはほとんどいません。優秀なエンジニアにとってはそのどちらも満たす求人が他にたくさんあるために候補にすらなりません。 逆に業務内容に魅力がなくても年収さえ高ければ良いという優秀なエンジニアも一定数いるはずです。待遇を具体的に書くことはそういった層に響くのではな

    なぜ優秀なエンジニアを低待遇で採用してはいけないか
  • どのようにエンジニアの目標設定を行うか - $shibayu36->blog;

    以前 ゴールを決め目標を決める・解決案ではなく質問する - コーチングの学習で学んだこと - $shibayu36->blog; で、「ゴールを決め、現在位置とのギャップを考え、目標を決める」と良いということをまとめた。イメージとしては以下の図の通り。 しかし、前回の記事だと具体的にどのようにエンジニアの目標設定を行うかイメージが湧かない。そこで、もう少し具体的に最近どのようにやっていたかを書いてみたいと思う。 僕がメンティーと目標設定を行うときは、以下のフローを辿っている。 なんでも良いのでゴールのイメージを明確にする 現在の自分とゴールのイメージのギャップを考える ギャップを埋める目標を考え、アクションを定める ちなみに今回は、チームの成果達成のために個人の目標を決めるのではなく、エンジニアのスキル向上の目標を立てるという前提で書いていく。 なんでも良いのでゴールのイメージを明確にする

    どのようにエンジニアの目標設定を行うか - $shibayu36->blog;
  • ADHDで管理職をやっている者なんだが

    週末の借金玉氏(id:syakkin_dama)のエントリやそれを受けて書かれたわかり手氏(id:ganbarezinrui)のエントリ、http://anond.hatelabo.jp/20170227005158 あたりのブコメとか読んでいて、随分と世知辛いねえ、と思ったのだけれど、良い場所が無いので増田にこれを書いている。たぶん超長い。 俺はタイトルに書いてあるようにADHD(診断済み)だ。典型的な注意欠陥・多動性が認められ、一方でASDの症状はゼロという純正ADHDマンである。なので先のお二方のエントリは全力で泣きながら、共感しすぎてヘドバン状態で読んだ。でもわからない人には何が「なので」なのか気でわからないんだと思うし、それで正常なんだろうということも理解している。 んで、一般的なIT関連の企業で管理職をやっている。それなりに多様な部下もいる。業界的にブラックな香りがするWeb

    ADHDで管理職をやっている者なんだが
  • CTOがチームマネージメントじゃない方向に向かう時に何をするべきなのか - トレタにおけるmasuidriveの役割 2017年版 - トレタ開発者ブログ

    トレタ CTOの増井です。 トレタは創業して3年半、エンジニアも2名から13名に増え、私の役割も変わってきました。 当初は一人目のエンジニアとしてアプリの設計やサーバサイドのコードを書いたり運用全般を行っていました。 人数も増え、2年を過ぎたあたりからエンジニアリングの中で私が率先してやる必要のあることがほぼなくなってきました。むしろ海外展開で出張が増え、連続した時間がとれずに進捗を遅らせる原因になってしまうこともありました。 最近の論調では、メンバーが増えるとCTOはマネージメントや組織作りに移行して行くみたいですが、私はそっちに興味が全然なく、向いているとも思えませんでした。そもそも私は上司を持ったこともないし、決められた環境の中で働くのがとても苦手なので。 私が「組織を作って管理して行く」のは無理というのはトレタ設立当初から分かっていたことなので、メンバーを増やす時は「自分で目標を作

    CTOがチームマネージメントじゃない方向に向かう時に何をするべきなのか - トレタにおけるmasuidriveの役割 2017年版 - トレタ開発者ブログ
  • Google:マネージャはやはり重要な存在である

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    Google:マネージャはやはり重要な存在である