これは頑固であれという意味ではありません。強い意志とはやりきる意思といってもいいかもしれません。
途中で投げ出さない、へこたれないということです
一度決めたら曲げないということもありますが、曲げないのは基本方針「やりきる」というところにすべきで、方法に関しては、「やりきるために」柔軟に変えながら進めていくべきです。(「改善)、「イノベーション)ともいう)
実行レベルに近い決定事項を守り、状況を無視してかたくなにやり続けると、組織がおかしくなってしまうこともままありますので、「やりきる」ことを重視し、「そのためには何でもする」という強い意志が必要です。
プロジェクトには絶対に何らかのトラブルが発生します。発生しない物はありません。キーマンの病気や事故といったどうにもならないと思えるような外的要因が発生するかもしれません。突然の無理な仕様変更要求が来るかもしれません。虚偽報告によるサービスイン前の受入試験での実はプログラムが何もできていない事件が発生するかもしれません。
その時にくじけることなくやりきる能力が一番最初に、絶対に必要なのです。
蕗を収穫しました
はさみで刈り取ります
これがなかなか腰が痛くなります。
この時期でも虫に刺されます。
材料
蕗 ２K位
醤油 ５０CC
みりん ５０CC
料理用酒 ５０CC
砂糖 ２５CC
山椒 ２００G位
茎だけにして、塩ずりします。
太さに応じて分けます。
なぜかというとゆでる時間が太さによって変わるからです。
太いところは３分くらい
細いところは２分くらいゆでます。
ゆでたら、皮を取ります。これが大仕事です・・・
爪がないとつらいです。
適当な大きさに切って材料を入れて煮ます。
煮詰まって汁がなくなってきたら完成です。
自分自身のパーソナルスキルの側面と管理技術的な面があります。両方重要で、特にパーソナルスキルの部分は、下手をすると、ひたすらコンピューターに向かってプログラミングしてきた我々にとっては苦手とする部分かも知れません。わかっていることと実践できることは違いますが、それが顕著に出る部分でもあります。とにかく勇気を持って頑張る必要があります。
一方管理技術はというと、管理されることはあっても管理側としての意図意味が分かっていないため、相当に意識しながら勉強する必要があるかもしれません。
今までの経験があるから何とかなるだろうという甘い考えではだめです。
間違いなくこれらの技術の勉強は必要です。ここではどんなものであるかの紹介をします。
とはいえ具体的な方法論もNaOHKI説での展開を時間があるときに追加で述べさせていただきたいと思います。
他のものの本にあるパーソナルスキルという用語とは少し違う解釈になっていることはご容赦いただきたいのですが「(イ)強い意志」から「(キ)意思決定」までがパーソナルスキルでそれ以降が勉強と経験で身につく管理スキルです。
(イ)強い意志
(ウ)原則論(決められたプロセスを実施する)
(エ)コミュニケーション能力
(オ)交渉力
(カ)方針決定
(キ)意思決定
～ここで別れる～
(ク)リスク管理
(ケ)品質管理
(コ)要員育成
(サ)課題・問題管理
(シ)レビュー
(ス)必要な知識
こうしてみるとわかるように精神論的なものが最初に多いように感じるかも知れませんが、これが意外に重要です。
これらのパーソナルスキルがないと知識だけあっても人を率いていけませんし、圧力に負けて心が折れてしまうことも多いです。
まずは一般的な話から。
食パンを作ろうと、レシピ通りに作ってみたものの
型がない！！
仕方がないので取っ手がとれる鍋に入れて作ってみました。
結果は・・・・
怪しいパンになりました・・・でも食パンです
よく、ホームベーカリーで焼くと、周りの耳が圧くて固いパンが出来上がります。
香りも膨らみも「まー家庭で作るとこんなものか・・・」というレベルのものしかできませんでした。
膨らみは粉とてごねで納得いくまでこねるという手ごねで解決しました。
周りの耳が固くなる原因は！テフロンの厚い鍋だったようです。
久しぶりにあの食感を味わいました。
食パン型、買っちゃいました
確かにあの食感は改善されました！
ローストビーフを作ります
材料
牛肉塊(モモ・ロースなど) １Ｋ位
塩コショウ 少々
ねぎの青いところ １つ
赤ワイン 少々
ポン酢 少々
適当に牛肉を買ってきます。この時周りに筋がついていた場合きれいに取ります。(筋を引きます)
常温にした後、塩コショウをします。
この時塩コショウのほかに適当なスパイスもかけます
油は牛脂を使います鍋が温まったら
周りに焦げ目をつけます。
焼き目をつけるだけでＯＫ
焼き目が付いたらねぎの頭と一緒にアルミホイルに包みます。
この時アルミホイルはお皿のようにして、流れ出てくるであろう肉汁をこぼさないように包みます。
余熱をしたオーブンで１６０度２０分
温めます。
その後、開けずにタオルで包んで発砲スチロールに入れ
余熱で１時間ほど余熱調理します。
肉汁がこぼれないようにそーっと開けます。
肉汁は鍋に入れてソースを作ります。ソースは私は赤ワイン少々とポン酢を混ぜてあっさり風に作ります。
薄切りにしてきれいに並べて完成です。
切るときは繊維を切る形で切ります。
SEの気分のまま、経験だけでそのままPMにあろうとすると、いわゆる顧客のためにシステムインテクレーションを行うプロジェクトで、管理を徹底することを要求される場合は通用しないことがあります。
どのようなスキルが必要で、自分が開発するのとはどう違うのか簡単に触れる
実際のPM技術に関しては、それ専用のものの本（PMBOKとか）を参照してください。
――(ア)身に付けるべき基本的なスキル
――(イ)強い意志
――(ウ)原則論(決められたプロセスを実施する)
――(エ)コミュニケーション能力
――(オ)交渉力
――(カ)方針決定
――(キ)意思決定
――(ク)リスク管理
――(ケ)品質管理
――(コ)要員育成
――(サ)課題・問題管理
――(シ)レビュー
――(ス)必要な知識
について書きます
例によって時間があるときに書きますのでのんびりお待ちください
塩バターパンを作りました
てごねです、この時はボードを持っていなかったので、まな板の上でこねます。
一次発酵をさせて
巻きます。写真はウインナーをまいてますが
通常はバターだけを巻きます
二次発酵をします
溶けてしまいました・・・・中のバターがしみだしています。
気にせず塩をまぶして焼く！！
ダレっとしています
なかなかにおいしかったですが、カロリーはめちゃくちゃ高そうです・・・自己嫌悪・・・
業態やその組織の性質によってパークベースなのかソリューションベースなのか違うと思います。
ソリューションベース
特定のよく使われる技術があってどこでも同じような業務がある場合、ソリューションベースで事業を展開していくことが多いように感じます。この場合でも使われる技術によっては業界が限定されることもしばしばであろうかと思います。
「人事給与ソリューション部」「財務・経理ソリューション部」「BWHソリューション部」「防災ソリューション部」等のような名前になることが多いと思います。
パークベース
官公庁系ではどこもオリジナルの業務を行っており、ソリューションとしての使いまわしができないことが多いです。縦割り行政の影響でしょうか、似たようなシステムであっても中身は大きく違っていることがほとんどです。
その場合はどうしても特定のお客様につくパークベースの仕事の進め方になります。お客様の指定する進め方や、納品物などに対応することが重要だからです。
「○○社担当部」「○○省事業部」「○○県庁営業部」等特定のお客様のお仕事であればとりあえず引き受けるタイプです。
どっちを採用するか
民需の作業では業務遂行ができてプログラムが動けば納品物はあまり言われないのかもしれませんが、官公庁の場合、前例踏襲主義や会計検査院の検査対応、無謬性の証明の証拠、各種ガイドライン等へのプロジェクト遂行の順守の必要から、プログラム以外の納品物が大変多いです。
そのために、慣れないと失敗することが多く、パークごとに担当者がつくパークベースのプロジェクトが多いように感じます。
どちらが良いというものではありません。適切な切り口でプロジェクト遂行をするのが良いと考えます。
どちらかを選ば根ければならないということもないでしょう。縦糸と横糸の関係ですから、立野役割をもつ縦糸と横糸の役割を持つ組織が両方あっても構いません。
うまく連携できるような仕組みつくりは必須ですが、共存可能です。事業幹部はじっくりとよく考えて組織を構成してみましょう。
混ぜる必要がある場合も
構造としては営業部門などの顧客と密接なところはパークベース、開発部門などは技術で分けるソリューションベースがよいように感じます。とはいえ、営業ではない技術者も顧客の業務に詳しい必要があり、中間的な立場としての組織として両方の仲立ちをしつつパークを見る技術者も必要になって、きれいにすっきりした組織にできないことがあります。(技術者なのにパーク付き・・・)
皆さんの組織はどうですか？
パーク：対象とする市場、顧客
ソリューション：対象とする要素技術、システム製品、業務分類
GWいかがお過ごしでしたでしょうか？
私はかなりのんびりさせていただきました。
ところで、書き溜めたものも減ってきたのでペース落とします。
お許しを・・・
ここでいう「いろいろ」はいろいろな管理手法のことではなく、いろんな役割を持つＰＭがいることを話します。
これらのマネージャは組織やどんなプロジェクトであるかによってあったりなかったりします。どれが偉いとかというものはありません。規模に応じて組織や役割を分割統合して責任を果たせるようにするものです。つまり広くすべてを行うか分割して少しづつ担当するかの違いになります。
① 与えられたプロジェクトの遂行のみをするマネージャ
案件が持ち上がったらその都度ごとにプロジェクトマネージャを選定しそのプロジェクト全体を遂行してもらうタイプのマネージャです。大抵の場合、営業部門か上司が仕事をとってきて、それを人に割り当てていく感じで進めていくタイプです。
ある意味イベントドリブンで、PJの遂行に責任を持ち、与えられた範囲内で成功させていきます。
ソリューションベースの特定のノウハウや技術を元にそれに関するプロジェクトを遂行していくマネージャにこのタイプが多いですね。
ここでイメージしているタイプは１PJ１マネージャ程度の規模のものを想定しています。技術者上がりのマネージャはこのようなタイプの仕事が向いているかもしれませんね。
② パークを与えられ、営業戦略を含め策定していくマネージャ
特定のお客様や業界を自分のパークとしてその中での様々なお客様の課題を解決していくタイプのマネージャです。あるパーク（市場）を担当として与えられていますから、その行う範囲は各PJの成功のみならず、そのパークでの事業の拡大が入ります。大抵の場合範囲を与えられると一PJではありえませんから、複数のPJを並行してみていくことになります。
そうなってくると部門の管理的なもので、複数のリーダを使って複数のプロジェクトを管理することになります。規模によって、マネージャと呼ぶのか部門規模であれば部門責任者ということになるのでしょう。
複数プロジェクトを並行して管理していく技術が必要になります。組織作りの技術が強く要求される立ち位置ですね。
ここではパーク(市場)を範囲として与えられるものとして書きましたが、ソリューション(技術・製品)という範囲もあり得ます。同じように、そのソリューションを利用する複数のお客様のPJを管理する必要がある場合もあります。あたえられている「範囲」の概念が違うだけで同じ話です。
③ 巨大プロジェクトの一部を担い責任を果たしていくマネージャ
大きなプロジェクトとなると一人では管理しきれなくなることがあります。その場合、複数のマネージャに役割を分割して管理させることがあります。
開発と基盤と運用とQCD管理に分けて、それぞれマネージャが付き、その上にさらにプロジェクト統括責任者(これは部長だったり・マネージャだったり)が付くことが多いです。
それぞれマネージャはメンバーを持って行動しますが、実態はプロジェクトマネージメントチームとして行動することになることが多いです。
サブシステム事態が巨大である場合、サブシステムを管理職が管理することもあります。この場合は、そのサブシステムの専門家であると同時に、サブシステムをPJと同じにとらえ、その中のQCDをはじめとして、人材育成・人事管理等も範疇として行っていく場合もあります。
あなたはどれになりたいですか？
ほかにもPJタイプでの分類もあります。
用語説明：パークとソリューション
