"プロジェクトマネジメント"投稿一覧

Shinichi Kogiso

デザイナー

Figma上のアニメーション表現も最近充実していますが、より実際の動きを見せる必要がある際はコードを直接書いて見せています。以下のようなサイトでコードを簡単に書いて、実際に動作している様子を見せるとかですね。
https://c...

大橋桃太郎

プロジェクトマネジメント

（過去も今もたくさんありますしこれからもありそうです..）特に、設計した通りの使われ方をしていただけなかった事が多いです。

毎回気づくことは、
・正しい分析を行なって狙いを出さめること
・自分たちの狙いがいま設計しているもので起こせるのか？と強く問い続ける高い意識を保つ必要性
・第三者、願わくば想定されるユーザーからのFBを細かく得続けること（そ... 続きを見る

和田健太郎

エンジニア

ヘルスケアについては、帰ってもらう・寝てもらう・くらいしか思いつきません。
先々を考えてどんなに忙しくても休んでもらうタイミングは作っています。

メンタルケアについては、意外と負荷のポイントが遅延や作業量以上に「裁量権」「意思決定の風通し」などが関わってくるので、そこを非常に重要視しています。

・高頻度でコミュニケーションの場（２日に１回ランチ... 続きを見る

和田健太郎

エンジニア

正解がない前提で回答します。

ズレが発生した時（特に遅れが発生した時）の動きとしては、スコープ範囲を絞る、変更する、がおそらく一番最初に出てくる選択肢です。「全てリリースできません」はビジネスインパクトが大きすぎたり、「全員残業です」というのはチームのマネジメント的に後々かなり苦しくなるのが見えているため、どちらも視野に入れつつも「まずはここまででリリースできないか検討しまし... 続きを見る

北野勝久

エンジニア

複数製品を一つのチームで管理していて優先順位付けをするのは至難の業な気がしていて（優先順位付けの観点が発散しやすそう）、情報収集を追えた後の意思決定は信念でやるしかないかもしれませんね。
・業績へのインパクト
・製品同士の連携有無
・将来達成したいビジョンからの逆算
・お客さんの状態
製品レベルでの開発投資をアロケーションする意思決定をするのであれ... 続きを見る

北野勝久

エンジニア

プロジェクトマネージャーという文脈に限らないかもしれませんが、スコープをうまく調整できる人ですかね。
ソフトウェア開発において、デスマーチで品質の低いコードをスケジュール通りに仮に出せたとしても、中長期での開発スピードが担保されているかは疑問だと思います。（もちろん、一度つくりきって運用をまったく考慮しないケースなんてものが仮に存在するなら話は別ですが・・・）
なので、プロジェ... 続きを見る

Nobufumi Fukumoto

プロジェクトマネジメント

PMPをとってください。そうすれば、何が必要なのかが体系的に理解できます。
IPA資格は無駄です。日本で通用するかもしれませんが、グローバルで無理ですしPMのレベルも低いです。

Waterfallが完全にできないのであれば、アジャイルだろうがスクラムだろうができません。
理由は、アジャイルもスクラムもWaterfallから早くサイクルを回すために簡略化した... 続きを見る

kentaro haneda（jumbo）

エンジニア

無くていいと思います。
ただ無いことを自覚・理解してチームやプロジェクトとして技術的な課題や進行を誰とどうするめるかをちゃんと言語化・明文化するのが大事だと思います。
ケースによって職責や作業の線引きが難しくなるので、どこまで誰が何をするか、指示なのか・要求なのかなど曖昧な部分をとにかく無くしたり、技術面以外でどうすれば工期を短縮したり・リスクと向き合えるかなどを考えてみると良... 続きを見る

石垣雅人

プロジェクトマネジメント

スクラムというのは型なので、ただ型を入れているだけだとそれに従って動いているロボットみたいになってしまいます。
基本的に型を入れたときに、ちゃんとそのチームに合ってるいかどうか、差分を見つけ出すのが大事です。

例えば、前のチームだと「スプリントレビューっていらないよね」という話だったり、そもそも常にコミュニケーションを取ったり、POがちゃんとスプリントのレビューに入... 続きを見る

石垣雅人

プロジェクトマネジメント

工数で話すというのはあると思いますが、注意は必要です。

最近あったのが「友達紹介キャンペーンをやりたいです」と言われたのですが、その要求が3行しか書いておらず、それでこっちが超概算見積もりで10人月で出した後に、予実を確認をしてみたら20人月かかったという例です。それに対して、何かすごい文句を言われるとかもあるのですが、基本的に「もうちょっと要求をちゃんとしてくれ」という話を... 続きを見る

石垣雅人

プロジェクトマネジメント

どうして「ずれ」が発生するのかをまず考えることが重要です。
ブリリアントジャーク的な人がいるのか、そういう心情的な問題なのか、それともスキルがあまりにも違いすぎるとかですと、それをアサインする責任のところの問題にもなってくると思うので、こういった箇所はもうちょっと深掘りしないと原因がわからないと思いつつ、とはいえスクラムは仲良くなるイベントがたくさんあると思います。
続きを見る

石垣雅人

プロジェクトマネジメント

ストーリーポイントも概念的な話なので、これはチームによるかもしれないですが、まず時間見積もりから逆に始めてみるというのも一回手かなと思っています。

ストーリーポインターだとフィボナッチ数列になり、やっぱり掴みづらくなるとは思うので、一回フィボナッチ数列「1、2、3、5、8」とかを時間として置き換えてしまって、「だいたいこの「5」というのは3日ぐらいだよね」とか「「8」というの... 続きを見る

石垣雅人

プロジェクトマネジメント

やっぱり失うものに関しては時間とその時間にかけた労力・メンタルです。
これは、もういろんな現場で見ていてやっぱり長いというのが一番のストレスだったりとかしていますし、結局予実を管理していなかったりすると思うので、失うものは時間というところが大きいかなと思っています。

メリットのところは、意思決定の材料として使えるものが獲得できるというのがあります。
続きを見る

石垣雅人

プロジェクトマネジメント

基本的に経営陣に対しては金額で出しています。

「この機能をつくるためには、5500万ぐらいかかります」みたいな形で、一応工数みたいなのを書きはしますが、だいたい人月と工数で変換して出すようにしています。

例を挙げると、「友達紹介キャンペーンをやりたいです」みたいなのがビジネスサイドに来たときに、まず企画を通すためにやっぱり工数点が必要だと思っていまして、... 続きを見る

石垣雅人

プロジェクトマネジメント

チーム再編が起きたら、基本的やり直しになると思います。
タックマンモデルでいうと、最初のほうの形成期に戻ってしまうことになります。よくある話としてはやっぱりチームの過半数が変わってしまった場合、文化もガラッと変わると思うので、1個の目安としては「半分以上変わる」かなと思っています。

例えば、今あるチームに新卒が1人来てとか、そういったことであれば全然問題ないのですが... 続きを見る

ぽむ

エンジニア

コミュニケーション能力だと思います。
チームメンバーやお客様の立場に合わせて、適切なコミュニケーションを取れる能力が必要です。
相手の要求をくみ取って仕事を振ったり提案したりする力を身に着けたいと私も頑張っています。

Takuo Doi

エンジニア

ちょっと語弊のある言い方かもしれませんが、管理する、予測することに価値を置いている開発においては、No Estimateは適さないのではないかと思います。

ストーリーポイントを見積ることにより、スプリントゴールの設定に根拠を持つことができます。
ストーリーポイントを見積り、ベロシティを計測することで、リリースの目安を算出することができるようになります。
<... 続きを見る

Nobufumi Fukumoto

プロジェクトマネジメント

PMは、事業ドメインと言うか会計が解らないと駄目。要は、ビジネスが理解できないと、各々の影響金額がどれくらいなのかとか関連法規がわかってないと犯罪の片棒を担ぐことになる。「事業ドメインを理解して」が該当する。
ビジネスの内容やビジネスプロセスを分析して、利用者の意見を尊重しつつも駄目なものは駄目と言うこと「ユーザーの意見を尊重し」が該当する。
必要な言語やテクニカルスキル、最近... 続きを見る

大橋桃太郎

プロジェクトマネジメント

一般的（かつ簡易的）な整理かもしれませんが、プロダクトマネージャーはアウトカム(成果)に責任をもち、プロジェクトマネージャーはアウトプットに責任をもつ認識です。アウトカムには、アウトプットの推進が含まれるため、プロジェクトマネジメントの役割を担うこともあると理解しています。プロダクトマネージャーが成果に責任を負うとする以上、その役割は上下左右様々になりがちですが、イシューに集中して取り組むために組... 続きを見る

Haruka Ishii

プロジェクトマネジメント

前提として、私はプロダクトマネジメントとプロジェクトマネジメントは双方、各専門職の方々とやお客さまとの間に立ち、プロダクト or プロジェクトを「なんとかする」調整職だと認識しています。

その中で、それぞれの職務の違いを有無大きな要因は、マネジメントをする対象が「完成という概念のないプロダクト」なのか「完了という概念があるプロジェクト」なのかだと思います。
続きを見る