ssmonline #43 での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
![運用改善、不都合な真実 / 20240722-ssmjp-kaizen](https://cdn-ak-scissors.b.st-hatena.com/image/square/9a7f6b2914dd7eb0fdc2ccc7d9aac21f63654d3a/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Feb49e29723a54931b1e3a7ca75225a38%2Fslide_0.jpg%3F31067052)
ssmonline #43 での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
プロジェクトマネジメント未経験の方も今日から参考にできるTipsをシェア。 ゼロから始めるプロジェクトマネジメントシリーズ第十二回です。 プロジェクトで新規要件が発生した際には瞬間的に考えた見積を3倍して、その要件を請けるかどうか判断しましょう。 情報システム室の進地@日比谷です。 プロジェクト進行中に新しい要求、要件が発生する。よくあることです。そして、それほど重い要求、要件ではないと感じた貴方は直感で導いた工数で対応の可否を判断しようとする。これもよくあることです。 しかし、これはとてもx2危険なことです。 新規要件を即答して請けてはいけない理由 新規要件を即答して請けてはいけない理由はいくつかあります。 新規要件を出す側の心理的ハードルが下がり、新規要件が噴出しやすくなるから 直感で出した工数の確かさはかなり疑わしいから あなたは大きなステップを見落としているから、確実に すぐに出来
皆さん、こんにちは。虎の穴ラボの大場です。 本記事は2024 夏のブログ連載企画の4日目の記事になります。 前回はH.Hさんによる「Backlogをスクラム開発のタスク管理に最適化するためにした事」が投稿されています。 次回はH.Kさんによる「気づいた人がやるタスク」をなんとかするためにマネージャーが実施した3つの施策 が投稿される予定です。 今回の記事では、リモートワークでチーム生産性を上げるため工夫していることを3つを紹介します。 忙しい人は、まとめの方を 1. 自分の返信がボトルネックにならないようにする タスクを進めているうちに、ふと別のメンバーに判断を仰ぎたいシーンがあるとします。 私自身がそういった類のメッセージを受け取った時は、メンバーの作業が止まることを避けたいので、できる限り早めに返答を心がけています。 (ミーティング中は難しい場合がありますが...) Slackには絵文
こんにちは。KDDIアジャイル開発センターのサービスデザイナー よねみちです。 生成AIを用いたto Bプロダクトのスクラム開発や、お客様のDX・新規事業創出のきっかけとなるデザインスプリント支援などを行っています。 はじめに レビューや会議で誰かが「詰められてる」様子、心にきますよね。自分がやられるのはもってのほかですが、周囲で発生するだけでも心がすり減ります。。 特に、何か問題が発生したときや、参加者間の誤解が解消できないときに「詰め」が生じがちです。 質問する側の、焦りや不安から「なぜ?」「どうして?」「つまり?」と質問マシーンになってしまう気持ちも理解できるのですが。 問い詰めてしまい心理的に不安全な状況に陥ると「ミスを隠そう、自分が責められないようにしよう」と回避する力が働きはじめ、結果として「正確な状況がわからない」「適切なアクションが取れない」といったチームとして重大なリスク
本記事の要約 ドキュメントを書かない事は、企業やチームの「負債」になる ドキュメントを書かない事は、自身の学びや振り返りの「機会損失」になる そういう文化が根付く前に、負の連鎖を断ち切ろう! はじめに 世の中のプロジェクトには、ドキュメントが足りていない、と感じています。 でも残念な事に、ドキュメントをどうしても書きたい人は「ほとんどいない」と思います。 その一方で「ドキュメントを書いた方が良い」という事は、 何となく分かっている人も多いと思います。 やりたくない事をやらなければならないのは、嫌ですよね。 そんな気持ちは分かりますが、これを機に一度改めてみませんか。 何故なら、ドキュメントを書かない事はチームに「負債」を生むからです。 勤め人ならば少なからず一度でも、体験した事があると思います。 「どうして必要な過去の資料が無いんだ」って。 あるはずの歴史の一端がソースコードからしか分から
エンジニアのみなさま、日々の学習本当にお疲れ様です! また本記事まで足を運んでいただき本当に感謝です。 約3分程度で読めるので最後まで読んでもらえると幸いです。 はじめに 工数管理はプロジェクトの成功に欠かせない要素です。工数を正確に見積もり、管理することで、プロジェクトの遅延を防ぎ、クライアントやプロジェクトメンバーの信頼を得ることができます。 本記事では、工数見積もりの重要性とその手法、そして失敗しないためのポイントについて書きたいと思います。 「もっとこうした方が良いよ!」 や 「うちの会社ではこの様な考えで取り組んでます!」 があればぜひコメント欄で教えていただけますと幸いです。 工数とは? プロジェクトや業務を完了するために必要な作業時間のことを指します。 「人日」 や 「人月」 と呼ばれており、1人日は8時間、1人月は160時間(1日8時間、平日20日稼働)で表現するケースが多
モダンPM技法の三本柱の一つである、EVMS(Earned Value Management System)について、しばらく解説してきた。EVMSでは、横軸にプロジェクト開始からの日付、縦軸に金額をとったグラフをよく用いる(理屈の上では、別に金額に限る訳ではなく、成果物の数量を表す単位、たとえば床面積m2とか設計図面数でもいいのだが、現実には金額を使うことが多い)。そしてこのグラフの上に、計画線PV・実績線AC・出来高EVの3本の線を描いていく。 EVMSでは、スケジュール差異SV(=EV-PC)と、コスト差異CV(=EV-AC)を主要なKPIとして見ていく。両方とも、プラスならば良好、マイナスならば問題を表す。つまり、グラフで言えば出来高EVのカーブが、計画線PVや実績線ACのカーブよりも上に来ているかを、まず注目する訳だ。 そして一般に、プロジェクトという活動は、最初はゆっくり立ち上
最初に プロジェクト管理ツール うまく使いこなせてますか? システムの保守・維持管理業務でプレーイングマネージャをやっている皆さんこんにちは。 システムの保守・維持管理のプロジェクト管理用にRedmineやJira等のプロジェクト管理ツールを導入し、 ITILとかPMBOKを参考しながら運用ルールを作って、チケットを使ってタスクや課題、工数の管理をやり始めてみたけど、 なんかうまくいかないみたいな経験ありませんか。 例えば ・Excelやメモ帳での管理を脱却してredmine、Jiraに移行してみたけど、結局Excelの方が楽で管理もうまくいってた ・チケットは作成しているけど、忙しくて中身を確認しきれず、結果 長期間放置されている謎の塩漬けチケットが大量 ・チケットの種類の決め方、項目の書き方が人それぞれ入力内容や形式がバラバラで、結果どこに何が書いてあるのかわからない。 などなど・・・
ソフトウェア開発プロジェクトは、「兼務」を用いるチーム編成が多用されやすい対象ではないでしょうか。エンジニアであれば誰もが経験したことがあるでしょう。1人で複数のプロジェクトやチームを掛け持ちするあれです。マネージャーであれば、組織の人的リソース配置を考える時の手段の1つとして用いたことが何度かあるはずです。 しかし、兼務が引き起こす様々な弊害や問題については、あまり意識されないまま多用されているように感じます。 たとえば、兼務者本人にとってプロジェクトの掛け持ちは、仕事のマルチタスク化やミーティングの増加に苦しむ原因になります。組織の観点からも、兼務への依存は、知識の偏りや負荷の偏りという弊害をもたらすことに繋がりかねません。プロジェクトの観点から見ると、兼務という形での「人的リソースの共有」は、プロジェクト間での「リソースの競合」を引き起こしやすく、それが市場投入までの時間を長くする要
あいまい・多義性症候群 症状成功の定義が決まってない オーナーの意図・指示があいまい。テーマだけを現場に適当に投げている 意思決定・判断基準がない。指標と測定方法が未定 色んな人の意見ややりたいことを盛り込みすぎている どこまで展望しているかかわからない(範囲が決まってない) アウトカム、アウトプットの因果関係がよくわからない 症状の概要と症状が招く結果あいまいさは成功の定義や判断基準、視程・範囲(どこまで展望しどこまでやるか?)が明確に規定できていない状況を意味します。多義性は一つのものごとに対
こんにちは。スクラムマスターの@sakebookです。 今回は「象・死んだ魚・嘔吐」をチームでやってみたのでその振り返りをします。 「象・死んだ魚・嘔吐」とは 振り返り手法の一つです。Airbnb Story 大胆なアイデアを生み、困難を乗り越え、超人気サービスをつくる方法(原題: The Airbnb Story)の中で紹介されていたようです。 翻訳されてなかなかキャッチーなネーミングになっています。 それぞれ次のようなことを意味します。 象 凄く大きい、見えているけど、みんな見ないふりをしている課題・問題。表層化しているけど大きすぎてみようとしていない。これが何かをみんなで話していく。 死んだ魚 放っておくと腐っていく。そういう問題。放置しておくとまずいことになる問題ってなんだろう?ということを話し合う。 嘔吐 自分の胸の中に隠していて、吐き出せなかったこと。これをこの場で嘔吐する。
個人の生産性に関する名著、スティーブン・コヴィーの“The 7 Habits of HighlyEffective People”(和書『7 つの習慣』)では、縦軸を重要度、横軸を緊急度としてアクティビティを分類しています。これには4 つの組み合わせがあります。 重要でかつ緊急であること:ヴェロキラプトル†の襲撃。 重要だが緊急ではないこと:今後の製品戦略の準備、製品上問題のある部分の改良。 重要ではないが緊急であること:砂糖を借りようと電話をかけてくるお隣さん。 重要でも緊急でもないこと:YouTube、Web サーフィン。 それでは最大限に効率を上げる方法について調べていきましょう。 最初に、重要でも緊急でもないタスク(4)(「サボること」に分類しても構いません)について考えましょう。これらのアクティビティのほとんどは、単純に落としてしまって構いません。その名の通り、重要ではなく(なぜ
この投稿は毎年恒例、pyspa Advent Calendar 2020の1日目の投稿になります。 どうもご無沙汰しております、akisuteです。すっかり年に1回アドベントカレンダーのときにだけ顔を見せる人になっておりますが、おかげさまで無事平穏に過ごしております。 さて突然ですが私はプログラマーを引退しました。 なぜなら今年で36歳だからです。プログラマーは35歳になったら定年ですね。 実際のところ、このぐらいの年になると、よほど何らかの意志が働かない限り、技術に対する情熱みたいなものが失われてくると思います。もちろん本当に技術とプログラミングが好きな人は間違いなく35歳なんかで情熱を失ったりはしないと断言しますが、残念ながら私はそうではなく、もはやiPhoneには大した興味が湧いておりませんし、最近はJavaだのGoだのTypescriptだのVue.jsだのといったものを必要に応じ
どうも、外資系うさぎのちょこさんです。 気がつけばもう2023年が始まってしまってますね。 一年の計は元旦にあり、ということで正月早々とても有益なnoteを書いて徳を積むところから今年をスタートすることにしましょう。 年末年始に限らず、それなりにまとまった時間を使えるタイミングってインプットにもアウトプットにもとても良いですからね。 せっかくなのでフォロワッサン各位も何かアウトプットしてみるとよいんじゃないでしょうか。 というわけで、新年早々のアウトプットにおすすめな、土地勘の無い業界/テーマのプロジェクトにアサインされた場合の最低限の情報収集を手早くこなすにはどうするのがよいかってnoteをお届けします。 これは再現性のあるやり方なので、このnoteを見ながら同じような流れで情報収集して自分なりの見解なんかをまとめてみたりすると良いセルフトレーニングになるはずです。 これは有益な情報なの
いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。 こんにちは、フリッツ です。今回はプロダクトマネージャーの日課とも言える「仕様書」について。自分にとっては PM 業の施策実行フェーズにおいて最も重要な仕事のひとつであり、最も心躍り、最も興奮する瞬間です。 PM になってかなりの時間が経ちましたが、「仕様書」への力の入れようは減るどころか、「もっと気合を入れなければ。」と感じる一方。在宅勤務が(たぶん) IT 業界のニュースタンダードとなっていくいま、なおさら「仕様書」の重要性を訴えたい今日この頃です。 ということで、今回は ・ 良い仕様書がもたらす 5 つの効果 ・ 仕様書の重要性が増していく 2 つの理由 ・ 仕様書に含めたい 14 の項目・実戦編 ・ 仕様書作成時に心に留めたい 3 つのこと ・ 具体的な仕様書サンプル(
・・・ ・不確実性パフォーマンス・ドメインについて加筆しました ・テーラリングについて加筆しました ・適応課題について補足を追加しました。 はじめにPMBOKといえば、PMIが世界中のプロマネの実務家から意見を集めてプロジェクトマネジメントについて知識体系化している分厚い本、というイメージです。 いや、でした。。。以前の第6版までは(7版からはすごく薄い)。 2021年8月に第7版が発表されると(ただし、日本語版はもっと先)公式からアナウンスがありましたが、本家サイトに行ってみると英語版は既に購入できる状態でしたので早速電子版を購入し読みましたので解説したいと思います。 一応前置きしておきますと、僕はPMPホルダーではありません。外資系にいるときにPMBOKをベースとしたプロジェクトマネジメントを実施したり、国内企業ではCMMI レベル5(最高レベル)を運用したりバージョンアップ対応を経験
ジョージ・スミス・パットン将軍の「どんな戦術も眼前の敵には無力だ」という言葉が好きなプロジェクト・マネジャーがいます。彼らはこの言葉を、計画するのは時間のムダだという言い訳にしています。これにはほとんど根拠がありません。こうした姿勢は数多くのプロジェクトを失敗へと追いやってきました。計画することよりも行動を支持するマネジャーは必ずいるものです。行動することは魅力的で、計画することは退屈だからです。 確かに計画することは退屈かもしれませんが、一連のドキュメントを作ることだけが目的ではありません。アイゼンハワー大統領は、計画するという訓練はプロジェクトについて考えるきっかけになると考えていました。計画セッションはプロジェクトに対する深い理解をもたらします。ここでは、仕事、予算、リソース、リスク、スケジュールなどを考慮します。計画することにより、成功するために何が必要とされているのか、もっとうま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く