あまいものが大好きです。
ソフトクリーム、チョコレートパフェ、ケーキ、和菓子、etc。
その中でも一番はチョコレートパフェ。
チョコレートパフェ食べながら、生ビールを飲んだこともあります。
死期が近づいたら、毎日チョコレートパフェまみれになります。絶対に。
新任部長研修
昨日、今日と新任部長研修でした。
今まで受けてきた研修は、講師が講義をして課題を出して、グループに分かれてディスカッションして、内容を発表して、また講師が講義をして・・・といったことを繰り返す方式でした。
今回も似たような感じだと思っていたら、講師がものすごい早口で他社事例や経営の知識をしゃべりまくって、（しゃべり疲れたころ？）グループに分かれて４、５０分フリートーク（雑談）をして、また講師がしゃべりまくって・・・の繰り返し。
こういう形式の研修ははじめてで、感想が言えないほど消化不良の状態。
私はあなたたちが自分で考えて行動するために役立ちそうな知識を教えます、ただそれだけです、と講師が言っていました。
つまり部長になったら全部自分で考えて行動するんですよ、とそれを叩き込まれた研修だったのかもしれません。
めちゃくちゃ・・・
今月からIT責任者になって、激務が続いています。
今まで自分のチーム外の同僚の仕事ぶりを知らなかったのですが、めちゃくちゃな人が多く、前任の上司が怒鳴りまくっていた理由が分かりました。
今日の「めちゃくちゃ」は、当社が使うシステムを当社がお金を払って作ってもらうという普通のシステム開発なのに、なぜかベンダーとSaaSの利用契約をするスキームにしちゃってました。
どうも会計の資産計上と著作権を混同してしまっていたようで、ベンダーは著作権を移転したくないと言っているだけなのに、うちが資産計上するのが困ると言われたと誤解をし、じゃあSaaSとして提供してくれ、という話になっていったようです・・・。
うちの担当者もベンダーも「めちゃくちゃ」で、涙が出ました。
きっとこれは、私が前世で何か悪いことをしたことの報いなんだと思い、心を鎮めています。
私がとらわれていた「しなきゃ」
最高のチームにしなきゃ。
35,6 歳のとき、会社でもっとも花形のシステムのリーダーになりました。業界の中でも進んでいるシステムとして話題になっていて、同業他社はこのシステムを利用したいために、進んで傘下に入ってくるようなシステムでした。
メンバーは 20 名。日本で最高のシステムを担当するのだから、チームも最高のものにしなければと張り切っていました。
そのとき私の考えていた「最高のチーム」とは「仕事のできるチーム」。
私の満足するレベルに達しなければ、決してレビューで OK を出さず、本番さえも延期させていました。
当然、メンバーは疲弊し、私だけが全力疾走をして、振り返ると誰も後ろにいない状態。品質は良かったけど、メンバーからは笑顔が消えました。
あのときのやり方が全て間違っていたとは思いません。周囲の期待がものすごく大きく、あのときのやり方でなかったら品質を保つことができませんでした。
重大なトラブルを起こすと、システムに詳しくない人たちから様々な不毛な要求を突きつけられ、メンバーは疲弊します。そんなチームを数多く見てきました。
あのときの私を縛っていたものは何だったのでしょうか。一生懸命仕事をすれば報われる、という思いだったのかもしれません。
今日から上司が執行役員
今日から新年度。部長に昇格して、上司が執行役員になりました。
席が隣なのは嫌だけれど、年収４０００万円の人の仕事ぶりを間近で見れるので、これからが楽しみです。
プロジェクト計画書の書き方：プロジェクト体制と役割分担
プロジェクト計画書の書き方の説明です。
第五回は、プロジェクト体制と役割分担の説明です。
１．プロジェクト体制
プロジェクト体制図を記載する目的はいろいろありますが、プロジェクト計画書のプロジェクト体制で一番重要なことは、ベンダーにとってのカウンターパートを明確にすることです。
ベンダーにも PM やリーダーの立場の人たちがいて、彼らが仕事を進める上で発注者のカウンターパートが明確になっていると、ストレスなく仕事を進められます。問題が生じた時に誰に相談すればいいのか、適切な相手が分からないと、プロジェクトとして問題への対処が遅れます。
例えば上記図で専任のアプリ全体 PL がいない場合、機能 A の PL と兼任でも構いません。アプリ全体 PL というロールを置くことで、アプリで問題が発生した場合の発注者側の意思決定のルートが明確になり、ベンダーが誰に相談すればいいのかが分かります。
さらに業務部門の体制もきちんと記載した方が、ベンダーからもプロジェクト全体が分かるので、要件定義や受入テスト、教育等で話が通じやすくなります。
また体制図とセットで、それぞれの箱の役割を記載します。
ただこれは、名称から想像できるレベルのことしか書かないことが多く、重要なのは役割分担なので、私はよほど大きなプロジェクトでない限りは、この役割定義は省略してしまいます。
２．役割分担
役割分担は、大きくは発注者とベンダーの役割分担、発注者の IT 部門とユーザー部門の役割分担の２つを明確にすることが重要です。
また体制図の一つ一つの箱と役割分担の単位を合わせると、エスカレーションルートとセットになるので、役割と責任範囲が明確になります。
例えば、上図のような体制図と役割分断だと
・監査や品質管理のプロジェクト内での立場が分からない
・発注者の全体 PL と機能ごとの PL の役割分担が分からない
・共通基盤の役割が分からない
といった問題があります。
これを下図のようにすると、体制図と役割分担が一致するので、それぞれの役割とプロジェクト内での立場が明確になります。
【振り返り】
今回はプロジェクト計画書に記載するプロジェクト体制と役割分担の説明でした。次回は工程管理基準と会議体計画の説明です。
①プロジェクト概要（目的、背景、範囲、特徴、前提・制約事項等）
②開発方針（開発手法、技術、テスト環境、パッケージのカスタマイズ方針等）
③マスタースケジュールと工程定義
④プロジェクト体制と役割分担
⑤工程管理基準と会議体計画
⑥プロジェクト管理ルール
今週のお題「行きたい国・行った国」
はじめて行った国はブラジルでした。
今だったら絶対にそんな選択はしませんが、若気の至りでツアーにも申し込まず、友人と飛行機のチケットだけ買ってブラジルへ。
目的はリオのカーニバル。
「地球の歩き方」等によると、その時期は旅行者が襲われることが多いらしく、ニューヨークのハーレムの１０倍危険で、ブラジルでの命の値段は５００円・・・。
二人とも初めての海外旅行だったので、チケットを買った後で不安になり、毎週末、友人の家でポルトガル語の勉強。と称して、だらだら酒を飲んでは、中森明菜のミ・アモーレを熱唱してました。
現地での滞在は７日間で、サンパウロとリオでカーニバルを堪能。怖さと楽しさとがハイペースで交互に現れ、２０代後半の体力も底をつき、帰国してしばらくは廃人になってました。
