タグ

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

  • 物理サーバを選定する際のポイント – Eureka Engineering – Medium

    Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.

    物理サーバを選定する際のポイント – Eureka Engineering – Medium
  • リードエンジニアを3ヶ月やって得た開発マネジメントに関する教訓 - seri::diary

    ここ3ヶ月ぐらい同じRails案件でリードエンジニアとして仕事をしています。 何気にマネジメント的なことをやるのが初めてだったので色々と戸惑うことがありましたが、だいぶ慣れてきて知見が溜まってきたので、自分のしごとの振り返りも兼ねてまとめておきます。 リードエンジニアのお仕事とは 会社やチームによって全くと言っていいぐらい異なると思いますが、私の場合は以下の様なことをしてきました。 開発スタート時 要件確認 仕様書を読んで全体像やどこから着手するかなどを考える Railsアプリのベース部分の実装 rails new DB周りの設定 初期モデルクラスをDB定義に基づいて作成 factoryも使いそうなものについてのみ作成 rspec、rails_config等諸々の設定 ローカル環境動作用のseedsを整備 使いたいGemを追加 共通で使うCoffeeScriptのライブラリを思いつく限り実

    リードエンジニアを3ヶ月やって得た開発マネジメントに関する教訓 - seri::diary
  • プロダクトマネージャのロールモデル、あるいは、ひとりのプログラマから見たプロダクトマネージャ - 29%の純情な感情

    これは Product Manager Advent Calendar 2015 の参加エントリです。12月12日(土)を担当します。 最初に、ほんの少しだけ自己紹介させてもらいます。ぼくは職能としては「プログラマ (ソフトウェア・エンジニア)」といったところで、ふだんの業務でもプログラミングをして過ごす時間が一定以上あります。とはいえ、創業期の会社に身を置いている期間も長かったので、そういった状況では、コードを書く作業に入る以前の「プロダクトの方針をどうするか?」「ビジネスとしてどうするか?」といった会話も身近なものです。そういった背景もあって、今年はちょうど「プロダクトマネージャ」「プロダクトマネージメント」に興味があって、この Advent Calendar にも参加させてもらっています。 今回は「プロダクトマネージャのロールモデル」、あるいは、ひとりのプログラマである自分から見た「

    プロダクトマネージャのロールモデル、あるいは、ひとりのプログラマから見たプロダクトマネージャ - 29%の純情な感情
  • プロダクトマネージャーを2ヶ月やって思ったこと - Qiita

    自己紹介 こんにちは。田村壽英(タムラ トシヒデ)です。 freee株式会社でプロダクトマネージャーをやり始めて早くも2ヶ月が経ちました。この2ヶ月間、どのようにPMとして動けば顧客にちゃんと価値を届けられるか、そのためにどうしたらfreeeの社員が熱狂をもって働けるかを悩みながら活動してきました。この記事では現時点での悩んだ結果を共有したいと思います。 背景 PMになるつい最近まではエンジニアとしてあるプロダクトのリーダーをしていました。そのときの悩みはだいたいこんなものでした。 今やっている開発が手一杯で次何するかをちゃんと考えられない サービス利用者の当の課題は何なのか十分に検討できないまま開発に入ってしまい、当にこの機能でよいのか実装中にも迷いが生じた せっかく開発した新機能の魅力を営業チーム等の他のチームにちゃんと伝えられてない このような悩みがあると「このプロダクトはどこに

    プロダクトマネージャーを2ヶ月やって思ったこと - Qiita
  • 超優秀なプレイヤーは出世させてはいけない

    Recent Commentsクラウドソーシングでパキスタン人にアニメーションを作らせてみた | innova on アニメをアウトソースする#031 金持ち父さん貧乏父さん 実践その1:まず5つの障害を乗り越えよう (#3 怠け心) | あすなろ(earth76)式 on プレゼンの冒頭で伝えなければいけないWIIFMとは?何故日人はブレストを嫌うのか | Masafumi Otsuka's Blog on 根回しが何故日人に必要なのか、ちゃんと説明しよう外国人上司に「私に活躍させたかったらやり方をこう変えて欲しい」と言葉にして伝えよ う! | Masafumi Otsuka's Blog on 根回しが何故日人に必要なのか、ちゃんと説明しよう外国人上司に「私に活躍させたかったらやり方をこう変えて欲しい」と言葉にして伝えよ う! | Masafumi Otsuka's Blog o

    超優秀なプレイヤーは出世させてはいけない
  • サイボウズの給料は「あなたが転職したらいくら?」で決めています | サイボウズ式

    「市場価格は適当に決まるから、給与は最終的には適当に決める」「でも、そのプロセスの説明責任はしっかり果たす」 こう話すのは サイボウズ副社長 兼 サイボウズUS社長の山田理。創業以来、人事評価制度を決めては変え、変えては決め、紆余曲折をたどってきました。 そして今、サイボウズの給与は「市場価値」から決めています。それは社外/社内的価値の2軸から定められるものです。給与が決定した後は徹底的に「説明責任」を果たします。「市場評価は適当」と話す裏側にある、サイボウズの人事制度の変遷を追いかけてみます。 2015年10月28日開催、「Gartner Symposium2015」の講演を再構成したものです。後編「社内評価だけで給料を決めるのをやめたら、多様な働き方が実現できた」に続きます サイボウズの山田です。最近注目を集めているサイボウズの働き方や人事制度の中で、今回は「市場価値」について話してみ

    サイボウズの給料は「あなたが転職したらいくら?」で決めています | サイボウズ式
  • 毎日の開発ふりかえりを支援する furik のご紹介 - Pepabo Tech Portal

    チーフエンジニアの @hsbt です。 今日はペパボでの日報と日報支援ツール furik について紹介します。 日報とは 日報とは、企業をはじめとする組織で様々な用途に使用されます。日々の作業の結果や記録として使われたり、チームのメンバーが考えていることや、その日その日の気分を知ることでコミュニケーションを取るための材料として使われたりします。 上記に述べた日報の使われ方は、主に自分以外の他者が参照するための用途ですが、@hsbt は日報を書きながら、何が原因で質の低い仕事をしたのか、明日良い結果を出すにはどうすればいいのか、というその日の仕事の質のふりかえりを行っています。 GitHub と日報 ペパボでは、GitHubGitHub Enterprise を使用しています。開発者は pull request によるコードのアウトプットだけではなく、issue を用いた設計の議論、p

    毎日の開発ふりかえりを支援する furik のご紹介 - Pepabo Tech Portal
  • 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についてのお知らせ
  • 【資料公開】強いチームの作り方 | Ryuzee.com

    2015年11月10日に某社の社内勉強会で、「強いチームの作り方」というテーマで話をしたのでその際の資料を公開しておきます。 内容自体は、WEB+DB PRESS 83号に書いた内容なので興味があればそちらを参照ください。 最近DevOpsの文脈ですぐに「インフラ自動化しないといけない」とか「ツール使って効率化」みたいな話を頻繁に聞きます。 が、端的にいえば、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」というデマルコの一節の通りであり、 DevOpsの質もツールではなく、CLAMS(Culture、Lean、Automation、Measurement、Sharing)であって、土台となるのはやはり組織やチームの文化になります。 一度自分たちのチームや組織について考えてみるとよいと思います。

    【資料公開】強いチームの作り方 | Ryuzee.com
  • 失敗しない情報共有ツール導入 21のtips - Qiita Blog

    この記事は、第1回情報共有ツールお悩みNightのグループワークを元に作成しています。 新しい情報共有ツールを試すぞ!と思っても、一人では使えるものではないし、やめるかもしれないものに仕事の実情報を載せてガンガン使っていくというわけにもいかなかったりして、どうやって試すのかなやみどころ。 「30日間お試しで、ある情報共有ツールが使えるようになった。どうやって楽しく使ってもらうようにするか。」 こんなお題でアイデア出しをした結果をまとめました。 こちらの記事はイベントのまとめサイト、「JohoKaigi 情報会議」内に移動しました。 お手数ですが以下のページをご覧くださいm(_ _)m http://johokaigi.org/articles/2015/11/09/johokaigi-1.html

    失敗しない情報共有ツール導入 21のtips - Qiita Blog
  • 伊藤直也氏がプロダクトマネジャーの役割を学んだ良書5選と、適材を見極めるポイント - エンジニアtype | 転職type

    2015.10.29 ITニュース Kaizen Platform, Inc.など複数の企業で技術顧問を務めている伊藤直也氏。同氏が自身のブログ『naoyaのはてなダイアリー』をほぼ1年ぶりに更新したのが、界隈で話題となっている。 伊藤直也氏(From GitHub_naoya/myprofile) そのエントリテーマは「プロダクトマネジャー」について。Twitterでつぶやいていた内容をまとめられたことをきっかけに、筆を取ったという。 >> プロダクトマネージャーについて – naoyaのはてなダイアリー ここ最近、伊藤氏の下には、顧問契約を結ぶ企業以外にも相次いで相談が寄せられていた。その大半が、「良いプロダクトを作るために、開発体制を整えたい」という内容だ。 こういった問い合わせに対して伊藤氏は、「良い開発体制を作れば、それだけで良いプロダクトができるわけではない」と話し続けてきたと

    伊藤直也氏がプロダクトマネジャーの役割を学んだ良書5選と、適材を見極めるポイント - エンジニアtype | 転職type
  • プロダクトマネージャーについて - naoyaのはてなダイアリー

    Twitter でプロダクトマネージャーについてぶつぶつ呟いていたら、まとめられていました。ありがとうございます。 プロダクトマネージャー制度を導入するにはどうすれば良いのか プロダクトマネージャーについてあれこれ考えていることを、ここらで一旦整理する良い機会かなとも思いましたので、ちょっと文章をこさえてみることにしました。一年ぶりにブログでも書いてみようと思います。 プロダクトマネージャーはユニコーンなのか。なぜそれが必要なのか。プロダクトマネージャーを見つける / 組織で制度化するとはどういうことなのか。それについて自分の考えを述べていこうと思います。 プロダクトマネージャーは新しいユニコーンか? 昨今よくプロダクトマネージャーが話題になっていますが、人によっては「プロダクトマネージャー」 が今自分たちができないことを象徴している/それが登場すれば全てが解決する銀の弾丸的なもの・・・い

    プロダクトマネージャーについて - naoyaのはてなダイアリー
  • プロダクトマネージャー制度を導入するにはどうすれば良いのか - 小さなごちそう

    KAIZEN platform Inc. 技術顧問 伊藤直也さんの、プロダクトマネージャーに関するツイートがとても示唆に富んでいるのでまとめさせていただく。 ソフトウェアエンジニアのひとがなにかと口うるさいの、組織的な怠慢のツケをはらう羽目になるのがだいたい自分たちだから、というのはあるだろうね。ごまかしがきかない仕事だし — Naoya Ito (@naoya_ito) 2015, 10月 21 良く見る典型例は、企画とか品質を保証する仕事までエンジニアに丸投げして、エンジニア側にはその期待値がなくてお互いの思惑がずれる、みたいなケースだな。この場合にエンジニアがしょぼいものを作るから、と指を指されてるけど、問題は製品企画開発の責務を組織の中で曖昧にしてるところにある — Naoya Ito (@naoya_ito) 2015, 10月 21 たまたまエンジニアの中にそこまで含めて上手な

    プロダクトマネージャー制度を導入するにはどうすれば良いのか - 小さなごちそう
  • 帰宅前の溢れるやる気を持続させる - Konifar's WIP

    他の人はどうかわからないですが、自分は 会社から帰宅する前にやる気が異常に高まることがあります。 仕事でも個人の活動でも「今日は家帰ったら朝までやってやるぜ」みたいな感じで、何でもできそうな気がするくらいやる気に満ちあふれるんですよね。完全にやる気MAX状態なんですが、そのほとばしるやる気のままに行動するかというと、まぁ実際はうまくいかないことが多いです。 参考までに、自分のダメパターンを書き出してみます。 まず家帰って飯って、ちょっとゆっくりしたら 「あれ?俺のやる気どこ行っちゃったの?」ってなり始めます。 23時くらいに 「よっしゃ23時半からやるぞ!」と思ってアニメ見てたら23時34分くらいになります。 「キリが悪いから0時からオールで頑張るぞ!」とか思ってたらいつの間にか1時になってて、 「まぁ6時まで5時間もある!俺たちの夜はここからだ!」とか考えつつTwitter見てたら2時

    帰宅前の溢れるやる気を持続させる - Konifar's WIP
  • 部署の課題を継続的に改善する取り組み - クックパッド開発者ブログ

    はじめに こんにちは、投稿推進部の勝間です。 約1年前、「サービス開発エンジニアからマネージャになった話」というエントリを投稿しましたが、現在も試行錯誤しながらマネジメントに取り組みつづけています。 「組織は生きもの」とも言いますが、私の部署もまた生きもののように、日々いろいろな課題が生まれ、それに取り組んでいます。今回は、そのような部署で私が感じた課題と、それに対する具体的な取り組みについて、いくつか事例とあわせてご紹介します。 1. 業務外の問題に目を向ける 私の部署では、毎日約5分間の朝会を開いています。 1人30秒くらいで、「今日取り掛かること」「参加するミーティング」「その他勤怠など含めて共有すべきこと」を共有します。 朝会を行うことでそれぞれの業務的な進捗を確認でき、また、内容について疑問に思ったこともすぐに確認、理解できる状態を作ることができていました。 一方で、業務と直接関

    部署の課題を継続的に改善する取り組み - クックパッド開発者ブログ
  • 書籍『Webプロジェクトマネジメント標準』を全文PDF無償公開 | News&Column | 株式会社ロフトワーク

    書籍『Webプロジェクトマネジメント標準』を全文PDF無償公開 ロフトワークは、書籍『Webプロジェクトマネジメント標準』全文をPDFデータで無償公開します。 ロフトワークは、2002年という早い段階からWebとクリエイティブの領域に世界標準のプロジェクトマネジメントの知識体系「PMBOK(ピンボック)」を導入し、Webプロジェクトのフレームワーク確立やリスクの軽減などに努めてきました。その過程で得た知識や経験を体系化、Webの制作現場につながるように編綴し、2008年に技術評論社より書籍『Webプロジェクトマネジメント標準』(共著=林千晶・ロフトワーク代表取締役、高橋宏祐・富士通グループWebサイト統括(*1))を出版しました。 『Webプロジェクトマネジメント標準』は、プロジェクトの課題が個人の能力・努力の問題であると苦しんでいる方々にこそ読んでいただき、制作側・クライアント側の双方が

    書籍『Webプロジェクトマネジメント標準』を全文PDF無償公開 | News&Column | 株式会社ロフトワーク
  • 「だから言ったのに」と言う人の言葉を無視してはいけない | サイボウズ式

    マネジメント 新しいチームのあり方を探求 就活 就活生必見!サイボウズの疑問 ティール組織 会社の「あたりまえ」が変わる 多様性 100人100通りの個性 ワークスタイル 働き方、生き方、もっと自由に 青野慶久 サイボウズ社長の想いと覚悟 キャリア 人生の「積み上げ方」を見直す 複業 複数の「業」をもつ働き方 人事制度 多様な働き方を支える仕組み マンガ サクッと手軽に読める! サイボウズ式編集部より:著名ブロガーをサイボウズ外部から招いて、チームワークに関するコラムを執筆いただく「ブロガーズ・コラム」。はせおやさいさんが考える「チーム運営で意見を1つの視点ととらえることの大切さ」。 こんにちは。はせおやさいです。 「失敗は成功の母」と言いますが、失敗から学ぶことは思った以上に多いものですね。「失敗しないこと」よりも「失敗したとしてもそこから有益な知見を得られた」というほうに注目していく

    「だから言ったのに」と言う人の言葉を無視してはいけない | サイボウズ式
  • 弟子の育て方(OJTにおいて『教える側』として気をつけたこと) - ゆとりずむ

    こんにちは、らくからちゃです。 先日、はてなブログ界隈をうろついていたら、中々面白げな記事を発見いたしました。 ■「メモを取れ」ほど非効率なものはない よくOJTで「メモを取れ」という人がいる。私はいつもこれが理解できない。メモを取るほど重要なことならば、なんで教える側の人間が要点をまとめたメモを事前に作っておかないのか?自分の怠惰を押し付けているだけではないのか?メモをとることで意識が手先に移り、重要点を聞き逃す可能性は考えないのか。 そもそも、その仕事を教えられるほど熟知している人間と、何もわからない新人のどちらが重要なポイントを把握できるだろうか。初めて聞いた仕事内容で瞬時に重要なポイントを書き出せるスーパーマンはそんなに居ないと思う。 最初に言っておきますが、どんな仕事においても『ちゃんとメモをとること』は大切な技術です。お客様からの電話を受けるとき、打ち合わせで議事録を取るとき、

    弟子の育て方(OJTにおいて『教える側』として気をつけたこと) - ゆとりずむ
  • プロダクトマネージャーにたちはだかる壁を、どう乗り越えるか

    スタートアップやプロダクトの成功に必要な「アイデア×プロダクト×実行×チーム×運」の 5 つの項目について解説した概要のスライドです。急成長するプロダクトの初期に役立てていただければと思います。 プロダクトマネージャーやスタートアップの CEO の方向けにどうぞ。 ※ Japan Product Manager Conference 2016 の登壇資料です

    プロダクトマネージャーにたちはだかる壁を、どう乗り越えるか
  • その目標、チームでやる意味ありますか

    まだ無意味なチームで消耗してるの? チームで足を引っ張るタイプの人っていますよね。 一匹狼タイプはいいんですよ。個人で仕事が完成されているならば。悪いのは「チームで取り組むほうが無条件でいいと思っていて、でもチームのメリットを活かせない人」ですね。 チームだからベテラン新人が混成のこともありますけど、仕事を覚えていない若手が悪いって話しでもないんですよ。始末が悪いのは、間違った努力・考えで足を引っ張る人です。ベテランでも「チーム」に対する考察が甘ければあっという間に地雷を踏むでしょうね。自戒を込めて。 チーム活動に投下しているリソースチームをつくる、動かすには結構なリソース投下が必要です。まずはリソースに思いを馳せてほしいですね。 ではチームを動かすために投下するリソースとはなんでしょうか。調達と製造の人の思惑がぶつかることがあったりしますので、それを調整するためのコミュニケーションコスト

    その目標、チームでやる意味ありますか