橋本将功のレビュー一覧
-
Posted by ブクログ
ブラックなプロジェクトや職場を経験したことがある人なら、ヘドバンさながらに大きくうなずきながら読んでしまう一冊ではないでしょうか。
長時間労働、マイクロマネジメント、無理なスケジュール、形だけの会議、部門間の対立、情報セキュリティの軽視など、本書で紹介されている事例は「どこかで見たことがある」と感じる内容ばかりでした。
私自身も読みながら、長時間働くことを美徳と考えていた上司や、細部まで口を出すリーダー、バッファを認めないプロデューサーなど、過去に関わった人たちの顔が次々と思い浮かびました。特にソフトウェア開発やプロジェクト運営に携わった経験がある方なら、共感できる場面が少なくないのではないでしょうか。
本書は単なる失敗事例に留まらず、問題が起きる原因と「正しいマネジメントの手法」も示されています。もっとも、紹介されている改善策の多くは現場だけで実現できるものではなく、上司や経営層の理解と協力があって初めて機能するものも多くあります。その意味では、組織を良くしたいと考える管理職や経営層にこそ読んでほしい一冊だと感じました。
もし本書で指摘される問題が日常的に起きていて、改善の意思も見られないのであれば、その環境で働くことそのものを見直すことも選択肢の一つかもしれません。 -
-
Posted by ブクログ
人に勧められて。
なんか見たことある著者だと思ったら人が壊れる方も書いていたのか
「プロジェクトの9割は炎上している」と言われるくらいだから、ここに書いてあることが全てできるというのは本当の理想なのだろうか
とにかく認識の違いをなくしましょう、抜け漏れをなくしましょうと繰り返されていたが、ユーザー側から見たプロジェクトはどんな感じなのか気になった
同じこと考えているのなら両者あまりに不憫
メンバーのやる気うんぬんって隠されたらどうしようもないんじゃないか？目に見える態度や成果で判断するのか？
メンバーってどうやって選ばれるんだ？
やる気のある若手潰そうとする人間がいるらしいが、どう考えても仕事に責任感持っている人間がプロジェクトにいた方が使いやすくないか…？
-
Posted by ブクログ
仕事をして、上司からは耳障りの良い評価をもらっているのに、今の会社では「仕事」を出来ていないと焦燥感が消えないもは何故だろう。
この会社に居ても、いずれ「何も出来なくなる」と会社への強い恨みにも似た、不満を持つのは何だろうか？
本人が望むかどうかは別だが、後輩にして上げられるマネジメントは何だろうか？と思っていた時に、ネットニュースでおすすめされていたこの本を思い出した。
内容は
タスク編/プロジェクト編/コミュニケーション編/キャリア編/組織・環境編と5つの分野があり、どういう状況で壊れてしまうのか、それに対する対処法をまとめたもの。
読みやすく理解しやすい。
特にキャリア編と組織・環境編が私には目新しく映りった。
この本を読んで分析出来た事は、
私が抱く、会社への強い不満は、キャリア形成の「プロフェッショナルスキルの成長停滞」で壊れている状況。
さらに、椅子が古く不快な音がする「不十分な設備」や、向かいの先輩の雑談が多く、「騒音」化と、冬は屋外かと思う程寒すぎる「劣悪なオフィス環境」のせいなんだと言語化してくれた本。
「職場の嫌いな人の取り扱い方法」と同じくらいバイブルになりそう。 -
-
-
-
-
-
Posted by ブクログ
プロジェクトマネージャーだけに限らず、
システムに関わる人(ベンダー、ユーザー側共に)全員に読んでほしい一冊。
本書を読めば、ベンダー側にとってはプロジェクトのどの部分に気をつければ良いかを理解することができ、逆にユーザー側にとってはシステム開発の各工程にどういう意味があるのかを理解することができます。
本の構成としては商談開始、要件定義〜リリース、運用保守までの各工程で章立てされています。
それぞれで何をやればいいか、やらなかったらどうなるか、具体的なエピソードで書かれているため、理解しやすくてよかったです。
また、見積もり手法やビジネスモデルの類型などそれぞれ種類が示され、解説されていたのも良いポイントでした。
読んだ中で印象に残った点は下記の通りです。(備忘も兼ねてますので冗長になってます。興味ある部分のみ読んでください)
※以下ネタバレ注意
①スケジュール管理について
ガントチャート法だと管理が面倒
クリティカルパス法で管理すると良い
→進捗管理工数の削減は悩みの種の一つだったので、ぜひ試してみたいです。
② ベンダー選定の観点
その企業ならではの提案があるか
(言われたことだけをやる企業ではないか
判断するため)
見積もりが安すぎないか
(スキルや見積もりの精度が低い可能性があり、プロジェクト進行上のリスクとなるため)
→見積もりが安すぎないかという観点はなるほどと思いました。IT業界では特に安かろう悪かろうなんだとしみじみ感じました。
③アジャイル開発を採用できる条件について
下記条件を満たさない場合、ウォーターフォールよりも上手くいかない可能性あり
条件1.素早い意思決定
意思決定が開発プロセスに含まれているため
意思決定が止まると開発全体が止まる
条件2.プロジェクトメンバーの要求レベルが高い
スクラム開発は短期間で適切な要件や設計を行う必要があるため、基本的なスキルや経験が必要になる
また、品質を管理するレビュアーが重要となるが、各領域の知見を持っている必要があるため調達が難しい
上記メンバーを揃えるためには一人当たりの単価は高くなることが想定される
条件3.外部システム連携がない
設計や実装、テストフェーズを足並み揃える必要があるので、スクラム開発を使用するとかえって非効率になる可能性もある
条件4.プロジェクト全体の予算スケジュールを調整できる
スクラム開発では動くものをつくり、フィードバックをしていくという流れになる
スクラム開発の中で要件や仕様が変更されていくため、一定の継続的投資があることが前提となる。
→日本の大企業では意思決定に時間がかかる、一度決まった予算に弾力性がない、システムが大きいため外部システム連携もある、というようにアジャイルに向かない理由があることを再確認できました。
世間では一概にアジャイルがいいという流れになっていますが、顧客に合った開発スタイルを志向していくべきだと思いました。
④ 準委任契約と請負契約
IT業界では契約自体では完成物が決まっておらず、正確な発注内容を資料化することが難しい。そのため、請負契約では不公平な契約になりやすく失敗の原因になるため、基本的に順委任契約を目指す
ブレが大きい要件定義や設計段階を準委任、それ以降を請負とする手もある。
どうしても請負でと迫ってくる客には準委任契約と請負契約でバッファの割合を変えて顧客に提示する手もある。
→契約の交渉は難しいことが多いが、上記のような手もあるのだなと思いました。
⑤ビジネス要件の調査方法について
1〜12の順で調査
1.市場調査
どのような競合他社があるのか確認
調査報告書や新聞、書籍、雑誌などがあるが
簡易に実践する場合はウェブ検索でも可
2.競合調査
競合となる企業の売り上げやポジションを探るまた、プロダクトを実際に使用し、機能や見せ方、売り方を見る
社内システムの検討の際も、世の中のシステムにどのようなものがあるか調査すると有意義
3.ビジネスモデル
市場調査や競合調査を参考に自社でどのようなビジネスモデルを構築する必要があるか検討する
ビジネスモデルの検討手法としては下記の通り
Ⅰ.ビジネスモデルキャンバス
Ⅱ.リーンキャンバス
Ⅲ.4p分析→商材、価格、流通、販促の4つの要素を一つにまとめたフレームワーク
Ⅳ.4c分析
顧客にとっての価値、顧客が費やすお金、
顧客とのコミュニケーション、顧客にとっての利便性
4.KPIツリー
収益構造に無理がないか調べる
見た目が分かりやすいため、意識合わせやディスカッションに最適
5.ペルソナ設計
プロダクトを利用するユーザーがどのような人物なのか決めていく手法
6.ユーザーヒアリング
ペルソナに該当するユーザーにヒアリングし、
対象となるテーマにどのようなペインがあるか
プロダクトにニーズがあるか確認する手法
7.カスタマージャーニーマップ
ペルソナで設計したカスタマーが日々どのような生活を送っているのか、どのようなペインを解決するのか確認する手法
プロダクトにどのような機能が必要か客観的に俯瞰することができるようになる
8.ユーザーストーリーマッピング
ペルソナで設計したユーザーがペインを解決するためにプロダクトをどのように利用するか確認する手法
機能の優先度をチェックする
9.ユースケース
ユーザーが目的を達成するための
ユーザーとプロダクトのやり取りを明確に示したもの
※要件の抜け漏れを防ぐため全ての画面において行う
10.業務フロー
業務の流れや判断の分岐をフロー図で表す手法
業務システムの開発など、toBのプロダクトでは必須と言える手法
11.グロース設計
プロダクトが成長していく際、何が必要で
誰が何をやるのか明確にする
12.UI.UX
画面や使い心地などのデザインを検討するプロセス
→SEとして顧客の業務を理解し、提案していく必要がある。業務調査の手法については気になっていたので一連のフローを知れて良かった。
⑥要件定義にて合意した資料のポイント
1.できるだけ図で表現する
ホワイトボードやミロなどのオンラインツールで描くようにする
業務に関してフローチャートにして合意を取ると良い
2.スライド作成ツールで作成しない
要件定義資料はパワポは避ける
要件定義資料は多くの前提条件や検討の経緯を踏まえて決められるものなので、結論だけでなく、検討の経緯や他の資料との関連は記載しておく必要があるので紙面の限りがあるものは避ける
visioやdraw、lucidchart.miroなど概念図を整理できるツールを見つけておくとよい
3.正しい書き方よりも伝わる資料
正しい書き方よりも伝わる資料を作ることが大切
4.ASIS TOBEを作成する
今どうなっているかを漏らさないように気をつける
→具体的なツール名が記載されてたのが良かった。
⑦ソフトウェアの7原則について
1.テストは欠陥があることしか示せない
→テストはソフトウェアが完全なことを示すものではなく、欠陥を早期に発見するためにあるもの
2.全数テストは不可能
→テストは指数関数的に増えていくため、
限られた予算の中で効率的に欠陥を発見するための方法を検討する必要がある
3.早期テストで時間とコストを節約
→フェーズが進めば進むほど影響調査の範囲は拡大していくため、早期フェーズで実施することが大切
4.欠陥の偏在
パレートの法則にある通り、8割のバグは2割の場所で発生する
複雑な部分が偏在することが原因
5.殺虫剤のパラドックスにご用心
同じシナリオ、同じデータで新規のバグは発見できないのでそのテストで何を発見するかを明確にしておく
6.テストは状況次第
Wi-Fiが届いている環境でのテストで問題なかったとしても一般的な動作環境ではうまく動作しないなど状況により異なる場合がある
7.バグゼロの落とし穴
欠陥をなくすことで処理が遅くなったり、機能が一部制限されるなど利便性が悪くなる場合もある
バグがクリティカルか、トレードオフとして失われる機能がないか確認すること
→限られた工数の中でテストを検討することが当たり前なんだなと思いました。4のパレートの法則についても今のプロジェクを見回してみてなるほどと納得。
⑧リリース時期について
検討事項
・関わるメンバーや連携するシステムの担当者の稼働が確保できる日にする
・体調不良等も見越して誰が誰をカバーするか決めておく
・トラブルに即応するための監視体制も整えておく
避けるべきこと
・長期休暇前にリリースを設定すること
長期休暇前は他の業務も立て込み、作業が想定通り進捗せず生煮えの状態でリリースに取り掛かる可能性が高まるため。
また、トラブルが発生した場合担当者の休日が潰れ、不満、離任につながる
→長期休暇前にリリース設定日は避けるという頭はなかったので今後意識しておこうと思いました。
以上、冗長になりましたが感想です。 -
-
Posted by ブクログ
・関係者（発注者/ベンダー/メンバー/関連企業）が対等に話し合える関係性を築く
・プロジェクトマネージャーが多忙もしくは能力不足で全体観を失わないようにする
マネジメントは管理だけではない
管理：状況確認（計画との差分）、作業アサイン
→計画に固執する
マネジメント：管理＋目的達成に必要な判断、全体像の把握、事前調整
→リスク把握し、アクティブな調整を行い、計画にフィードバックさせる
■交渉
・説明資料と議事録は文書化
・フォーメーションを組む：重要度、費用と進捗課題は人を分けるなど
■タスクマネジメント
・タスクを洗い出す→優先順位つける→メンバアサイン→振り返りＫＰＴ
★タスク名は「○○を○○する」で記載
いつまでに、は期限ではなく工数で記載
・ガントチャートの欠点
タスクの抜け漏れ、
納期に合わせたスケジュールになりやすい（逆線表）
追加、変更管理が煩雑
メンバが「学生症候群＝ぎりぎりにやる」になりやすい
・メンバアサイン
背景、目的も伝える
完了条件を認識合わせる（優先度、期限とともに）
★定期的な振り返り
■プロジェクト計画
・目的、前提条件
座組（体制図）、意思決定者、利害関係者、予算、日程、要求
を確認する
（目的、前提条件を優先的に確認。後から変更難しい）
・開発体制
スクラム（≒アジャイル）開発はメンバスキル必要、予算＆日程が流動的
→納期・予算厳守の開発には向かない
■見積
・工数見積もり→費用と日程を組み立てるが鉄則
・ざっくり見積もり：What（何を実現するか）
通常の見積もり：How（どうやって）、Who（誰が）で見積もる
・プロジェクトバッファ 1.2～1.5の係数をかける
リスク低い＝やること明確 1.2倍
■契約
請負契約 チェックポイント
・成果物の完成義務：成果物の定義
★検収の定義
・契約不適合への対応
・損害賠償事項：上限額の設定
追完請求（補修）、代金減額請求
準委任契約 チェックポイント
・作成資料、具体的作業、報告の共有
・善管注意義務：通常期待される注意義務
（PMとして期待されることをやっているか）
■要件定義
・「要求＝やりたい」と「要件＝すること」を切り分ける
・ビジネス要件（Why）を固める
・実現することの軸足と概要を描く
システムアーキテクチャ、機能要件一覧、非機能要件一覧
画面遷移図、シーケンス、ER図（データ構造）、API一覧
・資料化
できるだけ図で表現：draw.io
正しさより伝わる資料
BA（Asis/Tobe)を作る：現状把握を怠らない
・要件変更/追加要件は期限を切って対応
■デザイン
・ユーザーインタビュー
既存のプロダクトの客観的評価に向く
新規プロダクトには向かないことが多い
・ロゴ、フォント、トーン＆マナー、顔を決める
★全体像をデザイン
類似プロダクトUI/UXを学習する
ユーザーにとってのメイン画面、機能を検討する
→基本的パーツを作る
検討内容をUIに落とし込む
デザインを育てる：プロトタイピング
■設計
・技術スタックの決定
言語、OS、ミドルウェア、フレームワーク、ライブラリ、インフラスペック
・開発作法の整える
ソースコード管理、コード規約、開発環境
デプロイ方法、コンテナ採用判断、仕様ツール
・設計書記載精度を決める
・技術的負債を見極める
■テスト
・ソフトウェアテストの7原則
★各テストの定義を確認する
リグレッションテスト、受入(検収)テスト、負荷テスト
・テスト計画、マネジメント
テスト全体管理者を置く
責任の追及ではなく対策を追求する
チケット（タスク）で管理する
定期報告を行う
■リリース
トラブル発生時の対応を検討する
■保守改善
PJ目的は事業としての成功を実現する。QCD達成が目的ではない
プロダクト改善費用
保守運用のみ、保守運用＋改善、保守運用＋大型改善
それぞれの対応工数を見積もる
ファネルモデルを作る -
-
-
Posted by ブクログ
PMじゃないが、仕事を進める上でのエッセンスがあるかと思い読んだ。自分用メモ
・事前の計画も大事だが、不確定要素を踏まえた余白を持たせることが大事（PMでは、複数人を動かすためほぼ巻き返しができない）
・適宜ロードマップの提示とあるべき姿の提示は必須（分業型で個々が作業するため、組み合わせた際に成り立たないことがある）
・個別意見を取り入れる際も一回は全体最適かを確かめる必要がある
・全体を俯瞰し常に優先順位を示すことが仕事
・あるべき姿に沿って進めていく。顧客の要望でも、良い悪いは的確に判断しダメなら伝えて整理していくことが大事
・プロジェクトマネジメントにおけるタスク依頼はサッカーのパスと同じ。適当に出すのではなく相手の状況も把握して、連携を進める必要がある
・丸投げしてもタスクの品質が下がるため、常に状況を察知してすぐに手を打つようにする
・先にロードマップを書いて、ステークホルダーにいつどこで何を依頼するか共有しておく
・工数を洗い出し、スケジュールに可視化する
→普段の月の業務も整理してやるといいかも！ -
-
-
-
Posted by ブクログ
プロジェクトマネジメントの流れを全部説明する本
流れとしてわかりやすく書いてあってまとまってる
プロジェクト：スタートとゴール、不確定要素、複数人
交渉：ヒアリング、同期非同期、ツール、議事録、共有、体制
タスクマネジメント：ジョブ型、能力見積り、①洗出し②優先順位③依頼④振返り、パスチャート
プロジェクト計画：①ヒアリング：目的前提座組期間②契約③マイルストーン
見積り：概算、詳細：積み上げ、バッファ
契約：請負、成果物・研修、準委任
要件定義：要求要件、ビジネス要件、
デザイン：ペルソナ、全体像
設計：コード規約、設計書、
テスト：テストとはなにか、テスト定義、計画、マネジメント
リリース：日程体制、リリース計画、リハーサル、関係者説明
保守改善：損益分岐点、固定費 -
Posted by ブクログ
ネタバレ無理なスケジュール、、、上からの短期実現を固定で、それを実現させるためには、何をして何を諦めなければいけないかでアプローチしていたので、かなりプロジェクトとして無理があることが少なくないなと感じた。反省。
自分が管理している課やプロジェクトでどこが問題になっているか見直すのに便利な1冊。
自分が大事に思っている事は当たり前のようにできていて、一方で、頭ではわかっていても、そこまで重要視していない事がパターンの1つとして上がっていると、心にグサっとくる。全てが全てできるわけではないけど、プロジェクトの達成やチームメンバーの成長につながるような全体マネジメントをしていかないといけない。やはり日本の企業はマネジメントのスキルを育てることに重要視しておらず、どうしてもプレイヤーが年功序列で部長になったりするシーンをよく見る。プレイヤーとマネージャーのスキルは全く別物で、プレイヤーはプレイヤーとして極めるのもそれはそれで良いし、マネージャー路線で行くならば、マネージャーのスキルをきちんと育てる会社の制度が必要だと感じた。
以下読書メモ↓
指示する時は6w2h(what何の作業 why何のために who誰が whom誰に whereどこで whenいつまでに howどのように how muchどれだけ)