調達 ネルネル 21回用 (口閉じテープ) 噂に聞いたので
試してみよう
顎固定サポーター いびき睡眠グッズ 無臭 通気性良い 肌に優しい 顎用 美顔 寝室の寝音防止 静音おやすみマスク 開口睡眠マスク 男女兼用
- 出版社/メーカー: GLAMSVILLE
- メディア: ホーム&キッチン
- この商品を含むブログを見る
％の進捗報告は何かを隠している
プロジェクトの進捗報告で％を使っているプロマネを見るとき、
「このプロジェクトマネージャは何が問題を抱えているのかもしれない」
と思うのです。ではどのような問題を抱えていると思っているかというと、
- 進捗を％で把握しても意味がないことを知らない
- ％で報告することで進捗を誤魔化したい
の2つ。
進捗は％で把握しても意味がない
進捗は ％で把握しても意味がありません。例えば、2つのWBSがあって、1つが期限３日前に完了していて、2つ目が３日遅れているとトータルではプラスマイナス０でオンスケになってしまうんです。正しい進捗は、３日遅れですよね。
WBS１
|計画|□□□□□|
|実績|■★□□□|
WBS２
|計画|□□□□□|
|実績|■■■■■|■■■
進捗管理で進捗を正しく把握するには
「完了の個数/完了予定の個数」
で把握しないと意味がありません。
そこでどうしようかと悩みやすいことは「完了」の扱いです。自信のないプロマネは報告時に完了していないと困ると思って完了までの中間値を考えようとします。ここまでできていたら進捗５０％とか、このくらいまで進んだと言っているのだから進捗８０％だから、と。
でも、これに悩んで意味はありませんし、「このくらい進んだから」とやっている時点でダメ進捗管理の典型的な見本です。
作業の詳細な進捗のモニタリングが必要なのであれば、作業プロセスに対して％の重み付けをしなければ意味がありません。
例えば、
未着手 ０％
詳細設計書執筆 ２０％
内部レビュー ５０％
外部レビュー ８０％
指摘反映・提出 １００％
上記の例を見て、アレと思ったら良い感覚を持っています。そうです、作業をバラして1つのWBSのステップごとに重み付けをしても、今度は、ステップごとの進捗を詳細に把握しなければならなくなります。
これがマネジメントへの報告のスパンであればこれを対応するコストを積んでおかなければなりません。それをやりますか、ってことです。そこまでのコストも積めないし、シビアな進捗管理のニーズがなければWBS単位での進捗管理は、未着手０/完了１００で十分です。
％で報告することで進捗を誤魔化したい
進捗を誤魔化したいプロジェクトマネージャも中にはいます。例えば、
- ある特定のWBSの進捗が芳しくなくて、対策中で先が見えている
- 進捗は把握できているので報告はいい感じに楽をしておきたい
こんな感じ。こういうことを判断できるプロマネはベテランでできるプロジェクトマネージャが多いです。やらなくちゃいけないのはわかっているけれど、そこまで仔細に報告するのは面倒だから、言われるまでは手を抜いておこう、という感じ。
もう1つのパターンがあって、こっちはダメPMの場合。
- ある特定のWBSの進捗が芳しくなくて追求されたくない
- 進捗は把握できていないので報告で指摘されたくない
やらないといけないことをやっておらず、個数で報告すると進捗遅れを指摘され、対策を聞かれると困るから誤魔化そうというパターン。
こんなPMのプロジェクトは見る方もアレですが、メンバで入るのもゴメンという感じです。
プロジェクトの特性で進捗の粒度を決める
プロジェクトマネージャは進捗管理に対しては、０/１００でやれば十分です。１００をWBSのどの作業の粒度にするかはマネジメントのモニタリングのニーズに合わせれば十分ですが、マネジメントのニーズよりプロジェクトの特性で考えればプロジェクトの進捗管理の粒度は小さくなるはずです。小さな粒度で管理されているから大括りの報告ができるのであって、その逆はできませんから。
システムエンジニアの扱いに公平性は必要か
持論からいえば、システムエンジニアは期待に応えてくれる社員に対しての扱いは優遇します。期待どおりの貢献ならそれに見合うとこちらが考える対応をします。全く期待に応えてくれない社員に対してはそれなりの扱いです。
先に注意点を。扱いと評価は別です。もちろん、日常の対応が期待に応えている社員とそうでない社員と変えることはありません。ここで取り上げている扱いとは「機会」といったら良いかもしれません。
評価については、過去のエントリに書いてきたと思いますが改めてが考え方を書くとするならば、次の３点で評価をします。
- 評価の基準は統一したものを目標設定時に用意しておく。
- 評価基準は公開しない。
- 評価基準は基本的に定量的とし、一部定性的な点を含める。
もちろん、各人の目標はロールや専門性に応じた設定をします。つまり、誰一人同じ目標はありません。その時点から各人の扱いは違うのです。それを踏まえても、評価を同じ基準にするのは、 評価をする側としての軸を持って評価しないと評価後に説明が必要となったときに根拠が説明できないためです。
これは対外的な説明のためが主眼ではなく、あくまでも評価は基準で行うことを方針としています。この方針は、組織の成熟度の進度や事業内容のピボットがあったとしても軸としてぶれないという利点があります。
日常的な扱いも社員に対して同じように振る舞うのは同じ職場で働いているメンバに期待するものとして当然のことです。そこで温度差が出てしまうと目に見える依怙贔屓にと感じ取られても仕方がないですし、評価側が取るに望ましい振る舞いではありません。
では、どの扱いで公平性を変えるのか。それは、機会です。機会は人により魅力的に捉えられたり、反対に負担に感じるものがあります。機会を与えられる社員は期待に応えているから常に新しく挑戦的な機会が与えられるもので、機会を与えられない社員に対しては魅力的に見えるものです。一方、常に機会を与えられる社員にとっては忙しい最中に「また面倒ごとを持ってこられた」と思えば負担に感じられるかもしれません。
では、なぜ期待に応える社員だけに（他の人から見たら）魅力的な機会が与えられ続けるかといえば、期待に応えていない社員はその魅力的に思える機会をやり遂げるに必要なスキルを持っていないからです。その魅力的に見える機会に挑戦する前に身につけなければならないスキルを身につけて、期待に応えて欲しいのです。
そうした身につけて欲しいスキルはロールごとにあり、それが評価基準にも反映されています。
個々のメンバの経験は違います。スタート時点で違いが生じている状態に公平性を求めること自体が無理がありますし、個々人が持っている特性を客観的に評価すれば、適応性の観点からも差異が生じますから公平性を持ち出すこと自体に意味がありません。適応性も特性もない人に公平性を持ち出し、機会を与えて無理をさせることは誰も幸せにしません。
そうした公平性が適切でないところは個々にテーマを持てば良い話です。公平性を持ち出すなら、評価基準です。それは個々人の成果をロールに応じて評価基準に従い絶対評価をすれば良いのです。それ以外は相対的に物事を進めるだけなのです。
アクアリウムの水草がぼうぼうに伸びてきたのでお手入れに
もともと沢山植えていたのでB伸びすぎてきたら抜いていたけど、ちょっとトリミングして梳いてみようっと。
Govine® 水草トリミング 5点 セット ハサミ ピンセット (ストレート・カーブ) サンドフラッター 水槽管理 ステンレススチール製
- 出版社/メーカー: Beiqiペット用品
- メディア: その他
- この商品を含むブログを見る
プロジェクトマネージャ初心者だったときに意識して気にしていたこと
初めてプロジェクトマネージャをしたとき、それはもう、ドキドキでした。初めてだから、「失敗したくない」「成功させるためにはどうしたらいい」という感じで。
まあ、今ならそんな心配しても、なるようにしかならないんだけどさあ、みたいなことしか思いませんけど。嫌ですねぇ、オジサンになるとわかったようなこと言うようになって。
幸いにも自分がプロジェクトマネージャをやっていたプロジェクトでは失敗がなくて、それもこれもチームのメンバや周りに助けられて、いや、お互いに助け合ってやれたからなんでしょうね。今こうやって振り返ってみても、チームで困ったことはなかったからねぇ。
それで、初めてプロジェクトマネージャをする方にワタシが初めてプロジェクトマネージャをしたときに気をつけていたことを共有しますね。何かの足しになれば。
計画を作る
計画とはプロジェクト計画書ではなく、WBSです。とにかく、WBSを最初に作る。WBSを作って、考えるんです。このプロジェクトをどうキャリーしていこうか、と。
最初からプロジェクト期間の分だけ日程を取ってしまいます。短いプロジェクトもあれば1年以上のプロジェクトもあるでしょう。その期間を入れてしまいます。期間を入れたら、まじまじと何月から始まって、何年の何月までかかるのかとか思いながらみるとこれからやることがその期間でできるのだろうか、とか思ったりします。
そう思ったら、今度は工程やサブプロジェクトなどの大項目の単位で行を埋めていきます。大項目を入れながらその上に、マイルストーンをわかっている範囲で入れていきます。
WBSの工程に戻って、大項目を入れ、中項目に展開し始めるとそのレベルで依存関係に気づくことがあります。またそれをマイルストーンに繋げてみたりします。
WBSはプロジェクトの期間にもよりますが、直近のWBSは具体的に詳細化する必要がありますし、ずっと先なら中項目レベルで一旦は置いておくくらいにしておきます。
アウトプットを紐付ける
さて、直近のWBSを考えるわけですが、一緒にしておかないといけないものがあります。それがアウトプットです。アウトプットをつくるためにプロジェクトが存在するのですから。
なのでWBSにアウトプットを紐付けます。この作業が完了すれば何のアウトプットができるのかを紐づけておきます。これを契約書に書かれたアウトプット全て行います。
なぜこれをこの段階でしておくかといえば、プロジェクトマネージャ自身が忘れてしまわないためです。契約でお仕事をしているのですから、契約に書かれたアウトプットが揃っていなければ、対価は支払われません。
契約書にはアウトプットの提出時期や工程まで書かれている場合があります。そこまで仔細に決めるのかと思うかもしれませんが、中間での費用請求ではよくあることです。なんとなく、時期を指定されると狭苦しく感じるかもしれませんが、これは逆に捉えらたほうがいいです。どういうことかと言うと、提出する期限がなくても、どっちにしても工程ごとにアウトプットを作らないといけないことは変わりません。期限が最終提出で良い場合は、そのあたりのスケジュールを全部自分で立てなければなりません。これは顧客も同じで最後に全部揃って入ればいいよ、と言いますが、これが危ない。この言葉に合わせていると工程の一杯まで検討をするようになってギリギリでしか仕様が確定しません。
なので、契約書で期限がった方が工程は何時何時だから検収を考えると２週間前にはレビューがほぼ終わっている必要があるとか、１週間前には提出するから見れくれとかリクエストするんです。
そうした段取りを含めて考えないと後続工程の準備なんてやっている時間がないことがWBSを詳細化してアウトプットを紐づけていくことで次第に分かってきます。
毎日更新する
もうですね、WBSを毎日見ないと。前日の進捗を確認して、今日の予定を確認して、会議の準備の段取りをして、と。プロジェクトマネージャのプロジェクトが完了するのはすべてのWBSを終わらしても続きます。契約の手続きのための最終のアウトプットを揃えたり、挨拶したり、報告したり。そこまでやっって初めて終わりです。
そういった付帯作業まで含めてプロジェクトです。
まとめ
最初から必要な項目をWBSになんて書くことはできません。できたら神様級です。でも、普通はできないものです。だから、毎日見て、毎日更新して、先々を考えるんです。つまり、WBSこそプロジェクトマネージャがプロジェクトをどうやってキャリーしていこうかと考えの詰まったアクティビティの塊なんです。
と言うことで、WBSを書くことが初めてプロジェクトをやることになった方のお仕事なんです。
１日チームのアウトプットがなければ人数＊人日のコストが無駄になるという考え方を持っているかがプロジェクトの成功の鍵になる
昨日のエントリで、記者の眼 - みずほ銀行のシステム統合、いつの間にか消えた“本当の”期限：ITproを取り上げましたが、その中の一つのことが気になったので今日はそれを取り上げます。
Costについて下世話な話をすれば、期間を１日でも延長すると判断すれば、システムエンジニアが1000人いれば1000人日ですから、たった１日で人月換算して50人月の追加コストが余計に掛かるわけです。 ＃1000人は便宜上の数値です。
まだ終わっていないけど、みずほ銀行のシステム統合プロジェクトはどこに原因があるのだろうか - 室長のひとりごち
facebookである方はシステムエンジニアが8000人いた場合の試算をしていたのですが、さすがにそれはありえない数字だと思ったのですが、この辺りの数字ってどこかにあるのでしたっけ。
それにしても１日アウトプットがないと50人月をドブに捨てるようなものです。プロジェクトマネージャやコスト管理を担当しているPMOは胃が痛くなるでしょうね。役員からはコストに見合うアウトプットが出ているのかと聞かれますから。でも、そういったコストに対するアウトプット、それもプロジェクトの最優先項目の品質を伴ったものがWBSの完了ごとに確保されているかと問われているようなものですから。
このプロジェクトは、システムエンジニアが1000人でも既に超大規模プロジェクトですし、そんなプロジェクトのプロマネなんてやりたくないですねぇ。お鉢が回ってきて退路がないならどう首脳クラスを調達するかにかかっていると思うので、それは相当の社内政治力が必要でしょうし、どの役員に腹を詰めてもらうかまで考えて受けないとあぶない危ない。
妄想は棚に上げて、エントリのタイトルには入りますが、まあ、そのまんまなんですよ。
１日チームのアウトプットがなければ人数＊人日のコストが無駄になる
プロジェクトのトップからリーダまでは少なくとも、この思想を持っていないとプロジェクトは進捗しないんですね。いや、メンバまでが持っていないといけないですけど…。
ただ、注意して欲しいのは、だったら「何でもいいから作っておけ」みたいなことを考えてはダメなんですよ。あくまでも、プロジェクトの目的を達成するためのアウトプットがタイトルのアウトプットですから。何でもいいから作っておけという考え方自体が思考停止している証拠ですけれど。自分で必要かどうかを見極められないんですから。下手にそんなことをされてアウトプットに紐付かない何か怪しいものが作られてしまうと今度はそれを維持しなければならなくなって余計にコストがかさむという負のループ。
そういうことで、プロジェクトのアウトプットと紐づいてアウトプットに至る中間生産物もプロジェクトの目的達成のために必要なアウトプットのサブセットになります。ここでゴミを増やさないように、作らないようにしなければならないのです。
仕様書の様式の帳票設計をするときに、人手が必要な項目はその工程で処理されているかとか後工程で使われるかを精査しないといけないんですよねぇ。あったほうがいいからとついつい足しがちですが。とはいえ、後からは超大規模プロジェクトだと帳票の差し替えなんてとんでもないので、こうした標準化は優秀な人をアサインしないといけないんですよ。
結局、プロジェクトの目的はシステム開発なので動くプログラムで構成されたシステムです。そのシステムには、業務要件が実装されているわけです。
プロジェクトを進捗させるとは、契約書に書かれたアウトプットや記載されていないけれど中間生産物を日々作ることです。だって、いきなりプロジェクトの目的であるシステムを作る手段や手法を私たちは持っていないのですから。
だからこそ、１日の作業でアウトプットがないなんてありえないんです。たとえ、処理の実装を考える日であっても、どこまで考えるかを決めて、手書きでもいいのでノートに描き出さないとアウトプットしたことにならないんですよ。
頭の中で悶々としているのは何もしていないのと一緒です。
まだ終わっていないけど、みずほ銀行のシステム統合プロジェクトはどこに原因があるのだろうか
プロジェクトとは、有期限性の業務的な活動です。限られた期間の中で達成したい業務目的を達成するために必要となるリソースを確保して遂行します。リソースには、人・物・金と限定した時間が含まれます。
ところで、みずほ銀行のシステム統合プロジェクトはこれまでのプロジェクトのスケジュールをさらに伸ばすことにしたようです。
プロジェクトの目的はより具体的で定量的なQulity/Cost/deliveryに設定されます。このQCDは三角形で表現され三角形の頂点にQCDを配置し、この３点のうちどれを最優先事項とするのかを決めておくことで、プロジェクト全体として判断をしなければならない事態になったときにそれに従い意思決定します。
みずほ銀行のシステム統合の場合、公表されている事項から
Quality > Delivery > Cost
の優先順位がつけられていると想定できます。それは度重なるリリース時期の延期を品質の確保として公表していることからも推測できます。
1度目の延期では、開発完了を2016年3月から同年12月と、延長後の期限を示した。
DeliveryとCostですが、Deliveryである納期はリリース時期を延伸しているので優先順位が低いことがわかります。
一方、Costについて下世話な話をすれば、期間を１日でも延長すると判断すれば、システムエンジニアが1000人いれば1000人日ですから、たった１日で人月換算して50人月の追加コストが余計に掛かるわけです。
＃1000人は便宜上の数値です。
それを１回目のリリース時期の延伸を決めた時点で9ヶ月伸ばしたわけですから、１回目のリスケで450人月を追加コストをみずほ銀行のプロジェクトオーナーは承認していることになります。このリリースの延期これだけで5億以上は人件費だけで投入していることになります。
楽しい邪推はここまでにして、みずほ銀行はこのプロジェクトを実施することを公表しなければならなかったのでしょうか。
はてブのコメントで書いたとおり、行内システムの再構築として淡々とやっていればここまで騒がれなかったのではないか、と思うのです。もちろん、行内の資金を投資してプロジェクトを行うのですから、株式公開企業としては株主には説明をする必要があります。でも、それはIRの範疇でやっておけばいいわけです。預金者の立場ならATMの端末が入れ替えになればTATが早くなるとか、スマホでサービスを受けられるとかそう言ったことしか気にならないし、そう言ったことはリリース後に初めて使うときに「何か変わった」と感じるくらいでしかありません。
みずほ銀行や他のメガバンクに限らず、監督省庁には事前にご説明はして余計なお小言や横槍が入らないような対策は必要としても。
このシステム統合プロジェクトは、ウォーターフォール以外は考えにくいのは、銀行業務で新規業務のシステム化ではないからです。つまり、最初からスコープがはっきりしているプロジェクトであるということです。
であれば、システム開発手法ウォーターフォールを採用することに問題はないように思えます。それでは他にリリース時期が延伸している原因があるのでしょうか。
プロジェクトが目的を達成するためには、プロジェクトに必要なリソースが必要でそれの１つが欠ければ、他のリソースを増やすことが必要になったり、バランスが崩れれば新たなプロジェクトのリスクが増えるだけです。
とてもベーシックなことですが、プロジェクトは目的を達成するためのチームとしてのスキルセットが必要で、それが足らなければ目的を設定したタイミングでのリソースでは実現できません。他のリソースも必要になりますがリリース時期を延伸していることから時間のリソースに制限はそれほど強くないし、資金的なリソースも品質に比べ強くはないと言えるでしょう。
チームに必要なスキルを持ったメンバ、特にキーパーソンになるポジションの人材を、ーこれにはみずほ銀行側も含まれますがー、が集められなかったことが原因でしょう。
では、なぜ集められなかったのか。銀行業務はみずほ側が知っているとしても、銀行業務を知っているシステムエンジニアはどうだったのでしょうか。３行をまとめられるPMOの体制は作れたのでしょうか。システムエンジニアにどのようはスキルとスキルレベルを持った人材がどこに必要かを誰かが見極められたのでしょうか。
リリース時期を延伸できるくらいですから資金的には問題はないのでしょうし、納期は延伸しているのですから、問題はそれを実現する人的リソースのスキルセットではないかと思うのです。
みずほ銀行のいち利用者としてはプロジェクトの立て直しを願うばかりですが。
