記事一覧
Backlogで挑む、透明化と越境 抽象編
私の携わっている25ヵ月にわたる基幹システム刷新プロジェクトにおいて22ヵ月が経過しました。当記事はその中で得た知見とプロジェクトの進め方についてまとめています。
下記「具体編」の続きです。抽象編と題し、プロジェクト管理にBacklogを導入することで起きた変化を踏まえ、プロジェクト及びチームの目指すべき姿について抽象度を上げた内容としております。
Backlogとはnulab社の提供するSa
YAPC::Hiroshima 2024で気づいた子どもに戻れる場所の大切さ
いてもたってもいられず、片道3時間のバスに揺られてYAPC::Hiroshima(以降ヤプシー)に参加してきた。
とても多くの気づきがあったので書き留めることにする。
ヤプシーって大人が子どものままでいていい場所なんだなぁこの感覚を思い出せたのが一番の収穫だ。
じきに3歳を迎えるうちの子どもたち(双子)はブロック遊びが大好きだ。自由に大胆に創造し、家だか車だかよくわからないカラフルな塊を自慢
生成系AIで作ってきたなんとも言えない画像たちを放流する
ドーモ。株式会社ヌーラボでプロジェクトマネージャをしているナカミチです。ヌーラボブログリレー2023 for Techの貴重な一枠を消費して、大してTechでもなく誰の役にも立たないかもしれない情報を発信する。羊羹でも食べながら見ていただければ嬉しい。
私の趣味のひとつがITエンジニアの勉強会で話をすることだ。なので頻繁に発表資料を作る。
資料作りにおいて何が困るかというと、スライドに添えるいい
プロジェクトマネージャーのすべき決断の種類について
PjMの仕事は決断だ。とにかく決断することでプロジェクトを前に進めなければいけない。
決めるべきことをうやむやにして皆を困らせていませんか？って話をする。
決断のパターンは3種類だと考えている。
方針選択
権限移譲
決断条件の策定
何かしらの出典があるわけではないので経験と勘によるものだけど、僕はいつもこのうちのどれかを選択している。
プロジェクトを進める中で湧き起こるあらゆる事象におい
あなたのチームメンバーは他のメンバーのことをちゃんと知ってる？パーソナルマップ編
チームメンバーがお互いのことを知るのはとても重要だ。
以前の記事では1on1を通してメンバー同士のことを知る方法についてまとめた。
今回はパーソナルマップを作成して相互理解を深める方法について書く。
僕たちはフルリモートで働いている。
毎日雑談の時間は設けられているが、やはりそばにいないと互いのことを知る機会は減ってしまう。
僕が入社してほどなく、チームメンバー全員でオフィスに集合する機会が
プロジェクトマネージャしかできない仕事って、交渉だと思う。
この仕事だけはPjMがやらないといけないってのを一つあげるとしたら「交渉」だと考えている。他にもあげるなら、決断、政治、土下座かしら。
大抵の仕事は他のポジションの人がやっても問題ない。しかし、決算発表の会見を社長がするように、プロジェクトにおける交渉はPjMがしなければいけない。
交渉といっても多岐にわたる。納期、成果物、メンバーのアサイン、社内の予算、キリがない。ここでは顧客と社内上層部につ
議事録作成は新人教育のためのコンテンツじゃねーぞ！
プロジェクトを進めるにあたって議事録は非常に大切だ。だからこそ真剣に議事録作成業務について取り組んで欲しいって気持ちを文章にする。
新入社員はとりあえず打ち合わせに連れて行かれ、議事録作成を命じられる。録音した音声を何度も聞き返し、打ち合わせ時間の何倍もかけて作り上げる。新入社員のやるべきことだからとか、議事録作成を通して業務理解を深めるとか、まあそんな理由で依頼される。大抵の場合、参加者から大
物事を依頼するときは最終的なアクションを明確に書いてくれ！
PjMは依頼することが仕事のひとつだ。
社内のエンジニアであったり、お客さんであったり、ひたすら「これお願いします」を日々やっている。
プロジェクトが大きくなると「この依頼事項は終わってるんだっけ？」とわからなくなることが多々ある。いや、多々あってはいけないんだけどさ。
以前、課題には「なぜ」を書いてくれと記事にしたが、今回は依頼時には明確な完了条件を書いてくれという話をする。
そのタスクは
報告資料なんかいらない
何が嫌かって進捗報告やちょっとした説明のための資料作成である。
お客さんへのプレゼンテーションや何かしらの発表の場でもない限り、社内での報告のためにいちいち資料なんて作りたくない。いや、作らなくてよい。
上司が詳細な報告を求めてきたら「このドキュメント読んでください」とか「この課題でやりとりしています」と言ってURLをペタッと送ればいい。無礼でもなんでもなく、効率的で漏れのないやり方だ。
すで
正しく見積もるたったひとつの方法
プロジェクトマネジメントの肝は見積にある。
最も重要な要素だと断言する。
まあ難しい。はっきり言って未来予知の領域だ。見積もりに自信があるって人がいたら紹介してほしい。僕にはできる気がしない。
しかし、かなり正確に見積もる方法が一つある。それは再現だ。
要するに同じことをもう一度やるってことだ。システム開発においては、最強の見積方法は一度作ってみることだ。
寝ぼけてんじゃねーぞ！できるならや
Backlogの課題には「なぜ」を書きなさい！マジで！絶対書きなさい！【仕事の依頼のお作法について】
システム改修において何が困るかっていうと、該当の処理を修正していいのか判断がつかないことである。これは実に困る。
処理の内容はコードを読めばわかる。単純なバグなら修正してそれで終わりだ。しかし、実装された経緯のわからない正常に動いているプログラムほど厄介なものはない。
その処理がどんな経緯で追加されたのか不明
誰の要望によって追加されたのか不明
なぜその処理方法や技術が選択されたのか不明
皆に嫌われることがプロジェクトマネージャーの仕事な気がする
最近こんなことを思う。関係者たちから等しく嫌われるってことはものすごく重要なんじゃないかと。
PjMの仕事は決断することだ。
プロジェクトの規模や複雑性が大きくなるほど関係者は増え、ひとつ決断する度に誰かしらは嫌な顔をするもんだ。
誰も嫌な思いをしないプロジェクトがあるとしたら、それはそもそもやる価値のない仕事だろう。一見社会に与える影響がとても素晴らしいような仕事でも、受注した側の経営者だ