Google に限らず、多くの組織では、仕事のかなりの部分をチームによる共同作業で進めています。チームは真の成果を生み出す最小の単位で、画期的なアイデアが生み出され評価される場です。従業員はほとんどの仕事をチームの一員として行います。しかし、チームの対人関係に問題が生じたり、メンバーのスキルが適切でなかったり、あるいはチームとしての目標が明確でなかったりすると、生産性の低下やメンバー間の摩擦が生まれるといった問題が生じかねません。 Google のピープル アナリティクス チームは、「Project Oxygen」というリサーチ プロジェクトによって、「優れた上司の条件」を突き止めることに成功しました。このプロジェクトの成功を受けて、Google の研究者はその後、Google 社内で効果的なチームの特徴を明らかにするため、同じ手法を用いて新たなリサーチを実施しました。アリストテレスの言葉
日本XPユーザグループ（XPJUG）が主催になり、毎年秋に開催されている「XP祭り」。ここでナビプラス株式会社の水越氏が登壇。まずは水越氏がこれまで関わってきたプロジェクトを振り返りつつ、PdMの役割などについて話します。 水越氏の自己紹介水越明哉氏：よろしくお願いします。「エンジニアからPdMになって苦労している話」というタイトルです。水越明哉と申します。Twitterアカウントは「@akiyah」です。 では進めていきます。自己紹介です。今、ナビプラス株式会社というところに2年半ぐらいいて、レコメンドサービスという「あなたへのおすすめアイテム」みたいなものを出すサービスをしています。タイトルにあるように、エンジニアをやっていて、2022年3月からPdMをやっています。 あと、アジャイルプロセス協議会という会をやっています。その中にアジャイルマインド勉強会があって、読書会をやっています。
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ほとんどの人はだれかと恊働しています。マネージャーやリーダーであるなら、この割合はより大きくなります。 筆者は、仕事の重要な要素のひとつを「進捗を出すこと」と定義しています。そして進捗を出すには、進捗をただしく把握することも重要になってきます。 しかし「進捗を把握する」と言っても、想像以上に難しいと感じる場面が多々ありました。たとえば、 進捗はどうですか？ → 進行中です／〜をやっています なにか問題はありますか？ → とくにないです 〜までに終わりそうですか？ → たぶん大丈夫だと思います というようなやりとりは一般的なコミュニケーシ
プロダクトマネージャーの育成や、役割などの悩みに対する取り組み方法を記載しています。 1. Product Managerの役割や立ち位置は？ 2. Product Managerをどう育成している？ 3. Product Managerってどう評価したら良い？
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集していま
はじめに 何かはじめてのことをする場合、人はとても「不安」を感じます。人は未来を考えることができる生き物です。その特異な能力ゆえに、未来に起こるかもしれないよくないことを考えると「不安」を感じてしまうのです。 仕事のプロジェクトなどは、「間に合わなかったらどうしよう」とか「この仕事はちゃんと終えられるのだろうか。」など、未来のことを考えてしまうので「不安」に満ちたものになりがちです。 また、不安なものに取り組むというのは大きなエネルギーが必要です。試験勉強をしている時などに、部屋の掃除をしたくなってしまって、気が付いたら時間がなくなっていたという経験を多くの人が体験したことがあるのではないでしょうか。人は、不安なものを直視することを無意識に避けてしまうクセがあるのです。 本稿では、プロジェクトにおける不安とはなんだろうか？を考え、できる限り不安を最小化させるということを主眼に置いたスケジュ
たとえば、詳細設計から結合試験までを行う場合なら、 13sp + 13sp + 13sp + 19.5sp = 58.5sp と計算します。 スクラムでやるなら1スクラムあたり何sp消化できるか、ウォーターフォールなど日数を見積もりたい場合は、そこから1spが何人日かを予め定義しておいて、実際の工数を割り出します。 (1スプリントで10sp消化できるとした場合は6スプリントかかる計算になるし、1sp=0.5人日とした場合は、29.5人日≒1.5人月となります) なお、この比率は求められる品質レベルから算出します。 たとえばドキュメントをかっちり書く必要があるのなら設計の比率を上げる必要がありますし、メモレベルでよかったり、GitのPullRequestなどに記載する程度でいい場合は比率は下がるでしょう。テストの工数も同様です。なお、上記のは「ある程度かっちりやる」場合の比率です。 比率を算
少し前、こんなツイートを見た。 以前も言いましたが「出過ぎた杭は打たれない」と考えるより 『誰も打ちたがらない杭になる』のが一番良いと思います 例えば会社で利己的な欲求を排除し「会社への貢献」を念頭に行動している人は周りが応援するしその人を打とうとする人のことも制する 目指すなら『誰も打ちたがらない杭』一択です — マルコ👔 (@marco_biz_man) August 17, 2019 「利己的な欲求を排除し、会社への貢献を念頭に行動する」は、経営者や管理職がいかにも好みそうな話だし、なんとなく「いい話」っぽいのだが、実務的には、私は少し異なった考え方を持っている。 ＊ 私が駆け出しのコンサルタントだった頃。 ようやく現場のプロジェクトを仕切らせてもらうほどの経験を積んだときのことだ。 そのプロジェクトは、業務プロセスに関するもので、業務フローの作成が必要だったので、私はクライアント
この「極言暴論」の記事はIT業界や技術者の間でちょくちょく物議を醸す。「暴論」とうたっているわけだし、人月商売のIT業界の悪弊やユーザー企業のIT部門の駄目さ加減などを徹底的にこきおろしているから、当たり前といえば当たり前だ。 記事や私に対する大概の批判は感情的なものなので、「おいおい、もっと冷静になって現状をよく見たほうがいいぞ」と思いつつ、スルーすることにしている。ただ、あるテーマに関しては理性的な批判も多く、「この違いは何なのか」とずっと考えていた。 そのテーマとは「プロジェクトマネジャーは誰が担うのか」である。私の答えは随分前から決まっている。「プロマネは技術者の仕事ではない」。そう言い切っていた。技術者が担っても構わないが、SEやプログラマーといった技術者カテゴリーの仕事とは全くの別物なのだ。 だってそうだろう。プロマネはマネジメントが仕事なのだから当たり前である。技術者だけでな
鳥のさえずり声を聞いて、私は悪態を吐いた。今日の早朝に予定されていたミーティングのことをすっかり忘れていたのだ。 まったく、最悪の朝だ。着替えている間に、電話も鳴った。「高い金を払ってコンサルタントを雇った極めて重要なミーティングだ」と念を押されていたというのに。 それもこれも昨日のバグのせいだ。睡眠時間も、開発スキルも、人員も、私の現場には何もかもが足りていない。 それにも関らず、理解の足りない上司は「テスト工程を削ってでも早く納品しろ」とプレッシャーを与えてくる。 あの馬鹿どもめ。一体何を考えているんだ？ スーツに着替え終わった私は、冷蔵庫の缶コーヒーで空腹を誤魔化すと、バイクに跨った。通勤時間が5分なのが、せめてもの救いだ。 「遅れてすまない」 そう言って会議室に入ると、奇妙なことに気がついた。教室のように整然と並んでいたはずの机が、即席の半円形に並べ替えられていた。 何より、ホワイ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 前置き 私のキャリアは少し変わっています。 この業界に新卒で入ってから十数年は、大手ゼネコン的SIerにて、ほぼ一貫してプロジェクトマネジメントをやってきました。最終的には100人月程度の案件を回していたので、中堅クラスではあったと思います。それなりに経験も積んだとは思いますが、あれ、そもそも私って人の管理をやるためにIT業界に入ったんだっけ。。というレーゾンテートル的な理由で、プログラマーに転身しました。 そんなわけで、おそらく日本のIT業界におけるプログラマーから管理職に至るという一般的なキャリアパスを逆行している形になります。 そ
今まで数々のプロジェクトマネージャーとそのプロジェクトマネージメント手法に翻弄されてきたが、現在の勤め先であるベルリンのITスタートアップで取り入れている手法が歴代の中でも一番マシ。まず工数見積がとても洗練されている。エンジニアが無理やりに「今週中に完成させます！」と言わされて、結局はその約束が守りきれずに翻弄される、というような弊害が最小化できているな、という話。 プロジェクトマネージメントチームのメンバー達はその見積方法を「フィボナッチ」と表現している。 だいたい工数見積なんてものが正確にできる人に出会ったことが無い。複雑なITプロジェクトの全体像を把握して「これをうちのチームで完了するためには＊＊日を要する」なんてピタッと当てたためしがない。絶対にズレる。 エンジニアに向かって「お前さー『今週中に完成させます』って言ったよな？誰だっけ、それ言ったの？オレじゃねーよ。お前だよ。おめーの
プロジェクトが発展する際は、単純に新しいコードが古いコードの上に追加されているのでしょうか。もしくは、時間をかけて徐々に古いコードが新しいコードに置き換えられているのでしょうか。これを解明するために、手ごわい GitPython プロジェクトの助けを借りて、Gitプロジェクトを分析する 簡単なプログラム を構築してみました。履歴を年ごとに振り返り、 git blame を実行してみようと思ったのです（この処理を多少でも速くすることは簡単ではないと分かりました。しかし、ファイルのキャッシングを便宜的に含ませることや、変更された点を履歴から見つけること、 git diff を使って変更したファイルを無効にすることなどの詳細を、いつかお伝えします）。 頭がさえている時に、 テセウスの船 をダサくもじって、 “テセウスのGit” と名付けました。私は父親になって、ひどいダジャレを作れるようになった
Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ！』 こんにちは、谷口です。 某Mずほ銀行の案件のニュースが出たとき、弊社でも結構話題になりました。 あんなに巨大なプロジェクトをしずめるのは、もう本当に不可能なんじゃないかと思いますが、どんなに大きな炎上も、恐らくは小さな火種が集まって、やがて大きな炎となってしまった結果だと思いますし、最初の小さな火種の段階からぷちぷち消していけたらこんな結果にはならなかったはず……。 という話をしていたときに、paizaのエンジニアが「かつて炎上しているプロジェクトに自ら突入していくのが趣味だった」などと言い出しました。「そういう性癖なのかな」と思ったんですが、聞いてみると 「炎上しているプロジェクトに行くと『優秀な人たちはどんな振る舞いや働きをして炎上をしずめているのか』『何が原因で炎上したのか、どの時点で何をし
この連載では、先が見えないプロジェクトを「暗闇プロジェクト」を担当するマネジャーにとって参考になりそうなヒントやノウハウを紹介している。 前回（部下はマネジャーのようには決して考えない、期待しても無意味）から、「暗闇」でのメンバーマネジメントを取り上げている。今回も、二つのセオリーを紹介したい。 セオリー1 時には指示をあいまいにするのも手 マネジャーのD氏はイラついていた。中途で入社したU氏に対してである。 U氏の学歴や職歴は申し分ない。発言や質問の内容から、地頭の良さがうかがえる。問題は、言われた仕事しかしないことだ。 「次の打ち合わせのための資料を作成してくれないか」などと明確に指示を出すと、U氏は確かに言われたことはする。ただ、それだけである。「これはどうなった？」と付随する作業について尋ねると、まず間違いなく「指示になかったので、やっていません」と答える。 「お前はロボットか？」
エンジニアの常識はマネジャーには「非常識」、意識を変えないと地雷踏む エンジニア出身マネジャーの注意点（上） ITに関わるプロジェクトは多様化する一方だ。新規事業やサービスの開発、業務改革などと密に絡み、あらかじめゴールを設定できない状況で開始せざるを得ないケースも少なくない。 この連載では、そうした先が見えないプロジェクトを「暗闇プロジェクト」と呼び、この種のプロジェクトを担当するマネジャーにとって参考になりそうなヒントやノウハウを紹介している。 プロジェクトには様々なステークホルダー（利害関係者）が関わる。実は顧客以上に厄介で面倒なのは、社内関係者のコントロールだ。今回からしばらく、暗闇プロジェクトを進める際にマネジャーが知っておくべき社内コントロールの心得を紹介する。 今回と次回は主に、エンジニア出身の新任マネジャーが陥りやすい注意点を中心に見ていく。 セオリー1 マネジャーは自信満
今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス
Android Studioでプロジェクトを新規で作る時、テンプレートは何を選択していますか？ テンプレートには自動でNavigation Drawerを生成してくれるものや、最近だと広告をつけてくれるものなど色々ありますが、実際のところ、Add No Activityを選択するか、Blank Activityを選択する人が多いのではないのでしょうか。 テンプレートはプロジェクト作る時に必ず通るのですが、正直あまりイケてると思えないので、今回もうちょっとましなテンプレートを作ってみました。 Android Studioの標準テンプレートの問題点 Android Studioの標準テンプレートの問題点としては、以下があると思います。 余計なリソースファイルやコードが自動で生成されてしまう →例えば、Blank Activityだと、activityごとのmenu(menuリソース + onC
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
