ローストビーフを作ります
材料
牛肉塊(モモ・ロースなど) １Ｋ位
塩コショウ 少々
ねぎの青いところ １つ
赤ワイン 少々
ポン酢 少々
適当に牛肉を買ってきます。この時周りに筋がついていた場合きれいに取ります。(筋を引きます)
常温にした後、塩コショウをします。
この時塩コショウのほかに適当なスパイスもかけます
油は牛脂を使います鍋が温まったら
周りに焦げ目をつけます。
焼き目をつけるだけでＯＫ
焼き目が付いたらねぎの頭と一緒にアルミホイルに包みます。
この時アルミホイルはお皿のようにして、流れ出てくるであろう肉汁をこぼさないように包みます。
余熱をしたオーブンで１６０度２０分
温めます。
その後、開けずにタオルで包んで発砲スチロールに入れ
余熱で１時間ほど余熱調理します。
肉汁がこぼれないようにそーっと開けます。
肉汁は鍋に入れてソースを作ります。ソースは私は赤ワイン少々とポン酢を混ぜてあっさり風に作ります。
薄切りにしてきれいに並べて完成です。
切るときは繊維を切る形で切ります。
SEの気分のまま、経験だけでそのままPMにあろうとすると、いわゆる顧客のためにシステムインテクレーションを行うプロジェクトで、管理を徹底することを要求される場合は通用しないことがあります。
どのようなスキルが必要で、自分が開発するのとはどう違うのか簡単に触れる
実際のPM技術に関しては、それ専用のものの本（PMBOKとか）を参照してください。
――(ア)身に付けるべき基本的なスキル
――(イ)強い意志
――(ウ)原則論(決められたプロセスを実施する)
――(エ)コミュニケーション能力
――(オ)交渉力
――(カ)方針決定
――(キ)意思決定
――(ク)リスク管理
――(ケ)品質管理
――(コ)要員育成
――(サ)課題・問題管理
――(シ)レビュー
――(ス)必要な知識
について書きます
例によって時間があるときに書きますのでのんびりお待ちください
塩バターパンを作りました
てごねです、この時はボードを持っていなかったので、まな板の上でこねます。
一次発酵をさせて
巻きます。写真はウインナーをまいてますが
通常はバターだけを巻きます
二次発酵をします
溶けてしまいました・・・・中のバターがしみだしています。
気にせず塩をまぶして焼く！！
ダレっとしています
なかなかにおいしかったですが、カロリーはめちゃくちゃ高そうです・・・自己嫌悪・・・
業態やその組織の性質によってパークベースなのかソリューションベースなのか違うと思います。
ソリューションベース
特定のよく使われる技術があってどこでも同じような業務がある場合、ソリューションベースで事業を展開していくことが多いように感じます。この場合でも使われる技術によっては業界が限定されることもしばしばであろうかと思います。
「人事給与ソリューション部」「財務・経理ソリューション部」「BWHソリューション部」「防災ソリューション部」等のような名前になることが多いと思います。
パークベース
官公庁系ではどこもオリジナルの業務を行っており、ソリューションとしての使いまわしができないことが多いです。縦割り行政の影響でしょうか、似たようなシステムであっても中身は大きく違っていることがほとんどです。
その場合はどうしても特定のお客様につくパークベースの仕事の進め方になります。お客様の指定する進め方や、納品物などに対応することが重要だからです。
「○○社担当部」「○○省事業部」「○○県庁営業部」等特定のお客様のお仕事であればとりあえず引き受けるタイプです。
どっちを採用するか
民需の作業では業務遂行ができてプログラムが動けば納品物はあまり言われないのかもしれませんが、官公庁の場合、前例踏襲主義や会計検査院の検査対応、無謬性の証明の証拠、各種ガイドライン等へのプロジェクト遂行の順守の必要から、プログラム以外の納品物が大変多いです。
そのために、慣れないと失敗することが多く、パークごとに担当者がつくパークベースのプロジェクトが多いように感じます。
どちらが良いというものではありません。適切な切り口でプロジェクト遂行をするのが良いと考えます。
どちらかを選ば根ければならないということもないでしょう。縦糸と横糸の関係ですから、立野役割をもつ縦糸と横糸の役割を持つ組織が両方あっても構いません。
うまく連携できるような仕組みつくりは必須ですが、共存可能です。事業幹部はじっくりとよく考えて組織を構成してみましょう。
混ぜる必要がある場合も
構造としては営業部門などの顧客と密接なところはパークベース、開発部門などは技術で分けるソリューションベースがよいように感じます。とはいえ、営業ではない技術者も顧客の業務に詳しい必要があり、中間的な立場としての組織として両方の仲立ちをしつつパークを見る技術者も必要になって、きれいにすっきりした組織にできないことがあります。(技術者なのにパーク付き・・・)
皆さんの組織はどうですか？
パーク：対象とする市場、顧客
ソリューション：対象とする要素技術、システム製品、業務分類
GWいかがお過ごしでしたでしょうか？
私はかなりのんびりさせていただきました。
ところで、書き溜めたものも減ってきたのでペース落とします。
お許しを・・・
ここでいう「いろいろ」はいろいろな管理手法のことではなく、いろんな役割を持つＰＭがいることを話します。
これらのマネージャは組織やどんなプロジェクトであるかによってあったりなかったりします。どれが偉いとかというものはありません。規模に応じて組織や役割を分割統合して責任を果たせるようにするものです。つまり広くすべてを行うか分割して少しづつ担当するかの違いになります。
① 与えられたプロジェクトの遂行のみをするマネージャ
案件が持ち上がったらその都度ごとにプロジェクトマネージャを選定しそのプロジェクト全体を遂行してもらうタイプのマネージャです。大抵の場合、営業部門か上司が仕事をとってきて、それを人に割り当てていく感じで進めていくタイプです。
ある意味イベントドリブンで、PJの遂行に責任を持ち、与えられた範囲内で成功させていきます。
ソリューションベースの特定のノウハウや技術を元にそれに関するプロジェクトを遂行していくマネージャにこのタイプが多いですね。
ここでイメージしているタイプは１PJ１マネージャ程度の規模のものを想定しています。技術者上がりのマネージャはこのようなタイプの仕事が向いているかもしれませんね。
② パークを与えられ、営業戦略を含め策定していくマネージャ
特定のお客様や業界を自分のパークとしてその中での様々なお客様の課題を解決していくタイプのマネージャです。あるパーク（市場）を担当として与えられていますから、その行う範囲は各PJの成功のみならず、そのパークでの事業の拡大が入ります。大抵の場合範囲を与えられると一PJではありえませんから、複数のPJを並行してみていくことになります。
そうなってくると部門の管理的なもので、複数のリーダを使って複数のプロジェクトを管理することになります。規模によって、マネージャと呼ぶのか部門規模であれば部門責任者ということになるのでしょう。
複数プロジェクトを並行して管理していく技術が必要になります。組織作りの技術が強く要求される立ち位置ですね。
ここではパーク(市場)を範囲として与えられるものとして書きましたが、ソリューション(技術・製品)という範囲もあり得ます。同じように、そのソリューションを利用する複数のお客様のPJを管理する必要がある場合もあります。あたえられている「範囲」の概念が違うだけで同じ話です。
③ 巨大プロジェクトの一部を担い責任を果たしていくマネージャ
大きなプロジェクトとなると一人では管理しきれなくなることがあります。その場合、複数のマネージャに役割を分割して管理させることがあります。
開発と基盤と運用とQCD管理に分けて、それぞれマネージャが付き、その上にさらにプロジェクト統括責任者(これは部長だったり・マネージャだったり)が付くことが多いです。
それぞれマネージャはメンバーを持って行動しますが、実態はプロジェクトマネージメントチームとして行動することになることが多いです。
サブシステム事態が巨大である場合、サブシステムを管理職が管理することもあります。この場合は、そのサブシステムの専門家であると同時に、サブシステムをPJと同じにとらえ、その中のQCDをはじめとして、人材育成・人事管理等も範疇として行っていく場合もあります。
あなたはどれになりたいですか？
ほかにもPJタイプでの分類もあります。
用語説明：パークとソリューション
・サブシステムを任される
システムにはサイクルがあって、定期的にリプレースが必要になります。(HWやソフトウエアの保守期間が切れたり、業務が時代に合わせて高度化するから)
そんなリプレースのときに一つのサブシステムを任されてサブシステムリーダになりました。
この時はメンバーを３人にして私入れて４人でチームを作りました。運の良いことに優秀なプログラマが一人入っていたのであとの２人は２年目程度の人でもなんとかなるだろうとふんでいました。そのサブシステムはメンテナンスをしてきたところであったので、中の構造はすべて把握しています。最初に作られていたのがぐちゃぐちゃだったので、リファクタリングしたのです。
ほとんどの設計は私がすべて実行し、共通部分、難しい部分のコーディングを優秀なプログラマ(設計とかのドキュメンテーションは不得意)にひたすら作らせます。
その作られたフレームワーク上で２年目たちに機能を作りこませたのです。概要設計までは私で行い詳細設計以降を任せる感じです。
後から聞いたところでは、初回とは比べ物にならない生産性だったそうです。
今から思うと普通の開発ではできない手法でした。(一般化できないという意味)
・管理をサポートする
そのかいもあって管理サポートをするようになり、管理チームに参加する様になります。見積もりの精査や品質管理、課題管理などの技術面を中心にサポートをしたのです。見積もり精査は、見積もりに対して、勘違いしているところはないか見落としているところはないか、妥当性を欠くところはないかを見ました。品質管理はバグが入り込む原因を分析して対策したり、直らないバグに対して助言を与えたりしました。課題管理は、課題に対して複数の解決方法がある中で最適なものを提案したり選択したり技術面の裏付けをとったりしました。
・専門家として参画する
別の案件では技術の専門家としてPMをサポートする立場(ITアーキテクト)で、システムの全体設計を行いました。基本設計までは私が行い、みんなに伝えて、サブシステムごとに概要設計から実施していただくという方法をとりました。
マネージメントをするマネージャーがいたので、その部分は任せて、システムアーキテクチャの策定、技術問題の解決に専念できたのでした。
・PMとして参加する
その後のプロジェクトではマネージャとなってシステム全体の開発構築を行いました。
何となくきれいな段階を追ってPMになっていったように見えますね。当然細かいところは省いていますから、真実ここまできれいではありませんが大きな流れとして、参考にしていただけたらと思います。
実際にはいろいろ紆余曲折はあるものの美しく並べるならば以下の通りです
・サポート要員としてまずはPJに
サービスインしたプロジェクトの残件対応としてこの業界に入りました。サービスインしたといっても問題は多く、バグも大量に残っていましたのでそれらを何とかするのが役割でした。
・いくつかの問題を解決
当時は派遣社員でしたから１月以内に成果を上げないと切られてしまいます。
最初の２週間は仕様書設計をひたすら読みました、早く何らかの成果を出さなければならないのに１０００P以上あるあるサブシステムの設計書を渡されたのです。読み終わったことを報告して、障害一覧の中からプライオリティーの高いものから支持を受けて修正しました。
何とか１月以内に１つの修正物件をリリースすることができました。そこからは片端から修正です。
・他のサブシステムの問題を解決
サービスインしていますから使っているときのバグは重大障害として問題になります。大きなものになると担当者全員を集めて緊急対応することになるのです。
そんなことで客先に集められたのですが、たまたま私のいた作業場が近くであったため、先について、その時の責任者から簡単なサブシステムの説明を受けた後、障害調査をしたのですが、運よくすぐに原因が分かったのです。その時はまだ担当者が来ていなかったため、修正内容の案とその影響調査しながら待っていたのです。運が良かっただけなのですが結果的には担当者より早く対応したという結果だけが残りお客様の印象に残る実績となったのです。
・改修案件をやる
システムが安定してくると、今度はシステム変更案件なども入ってくるようになります。変更ですから、見積もり(どれだけ時間がかかるかを言うだけ)をして、受注できたら、それを実行する。というものです。
・大きな改修案件をやる
それらの改修案件をこなしていると、大きな改修が入ってくることもあります。そうなってくると一人ではできませんから、人を入れてやることになります。自分だったら何時間かかるというものはありましたが、ほかの人がそれだけの実力があるのかわかりません。同じくらいだろうと見積もって、ちょっと安全をみてまったくみんなが使えず自分が一人でやっても何とかなる期間と人数を報告してやりました。
当時は資格試験の受験生でしたのでパートタイマーのチームリーダーだったのです。２人いれて３人でやったのですが、私よりは経験が長い人たちでしたが生産性は半分程度であったと記憶しています。困ったら相談してくれと言ってあったのに一つのバグで丸一日悩んでいて、声を掛けたら相談してくれたのですが、単純な話であったためにすぐに直ったのです。悩まずに相談してくれたら１日（８時間）は無駄にせずに済んだはずです。といようなことがあるということを学びました。
ここまではシステム保守段階の話です。
ここからリプレース開発の受注後の開発を担当する話になります。
虚偽報告をされてしまったら「運が悪かった！」のでしょうか？
違います。これも発見できます。
昔の話で今ほど業界は経験を積んでいなかった時代であり、報告内容などが性善説に立ったものだったのです。まず、進捗が可もなく不可もなく理想通りに進んでいる段階で怪しいです。人が動いて作っているものですからそんな馬鹿なはずがないのです。必ず苦労したり失敗したり、残業がかさんだり進んだり遅れたりするのです。
今であればこれらのことをすることでこのような事態は避けられます。
このような詳細な報告を受けている場合で虚偽報告をしようとした場合、かなり大変です、必ずぼろが出ます。
ぼろを発見する
課題がないということはありません。課題があるということはそれについて人が動いているはずでそのモジュールなり機能のところで、進捗が動くはずです。当然品質にも影響があるはずでそれらの関連性が合理的でないのであれば虚偽報告である可能性があります。早急に現物確認をします。
現物確認は疑っているからするのではなく、PMの責任として、成果物を自分のものとして内容等を把握するために絶対に必要ですから、怪しくなくても時々行うべきです。
進捗報告の粒度もある程度負担にならない程度に詳細にもらうべきです。自動的に集計が取れるものでも良いかもしれません。
テスト要員と開発要員を分けることも肝要です。
五感を駆使して、異常を発見して早めに手を打てるようにしましょう。
大昔の話。
毎週進捗会議をして、各サブシステムから進捗をヒアリングします。シンプルな書式で、工程ごとに進捗率の目標と実績を報告してもらうものです。
各サブシステムごとに進んでいたり、遅れていたりするのですが、おおむねスケジュール通りに進んでいました。遅れているサブシステムは監視対象になって細かく進捗を見られます。それこそねほりはほり。
そんなこんなでサービスインを控え、ユーザ総合試験をすることになりプログラムを動かしてみようということになったのですが、あるサブシステムだけが何やら見てもらいたくなさそうです。説得して見せてもらったのですが、プログラムが動きません。それどころか、プログラムが完成していません。進捗上は内部の総合試験をほぼ終わっていて、動きそうです。どうしたことでしょう・・・実は報告者が、実態を見ておらず、期日に合わせて数字だけ更新した資料を毎週提出していたのでした。
虚偽報告です。ＰＭとしてはこれをされてしまうと手の打ちようがありません、さすがに嘘をつかれた場合には・・・
「運が悪かった！」のでしょうか？
解：発見できるか？
例によって、気ままに書きますので順番の前後等あります、気長にお待ちください。
