『童話でわかるプロジェクトマネジメント』ソリューション力をチームで成長させる
プロジェクトマネジメントの学習は問題解決や要求の達成を掲げるソリューション業務の遂行をチームで行うに際し、身につけるべきことのほぼ全てが凝集されています。ところがこの”プロジェクトマネジメント”20年ほど前に流行り始めましたが、最近では定着したのか、言葉に新鮮味が無くなったからなのか、新たに本を出しても売れないためか、めっきり入門書の類が減りました。自分はこれまでの経験から、どの年代に対してもプロジェクトマネジメントは有効だと考えています。マネジメントは個人のために作用する方法論ではなく、チームの総力を発揮し、将来に繋がる方法論だと考えています。その為、良い入門書をたたき台にして、チームメンバー全員で現在までの業務を振り返り、ありたい姿を描き、明日の糧にしたいと思い、入門書を探しました。自分の体験談ベースの教育本を社内向けに作る方法もあったのですが、どうしても主観が入り偏向的になる可能性があることと、近しい距離感にいる説明者の実体験談だと、受講者が自分自身に置き換えて考える際、妨げになると考えた為、敢えてニュートラルな外部の本(入門書)を探すことにしました。現在の自分のチーム自分が纏めるチームは男女混合で22歳~48歳までおり、中には外国人(日本語が喋れます)もいます。非常に個性あふれ、かつ優秀ですが、場当たり的で苦労貧乏な側面も多く見られ、このままではちょっとずるい人からいいように利用され、正しく評価されず、苦労の連続になってしまい、いざイノベーションに取り組む際、自由闊達に羽ばたく能力を身につけられないと思います。「場当たり的」という表現を使いましたが、これには”どのような課題であっても、知らんぷりや他人事にせず、真正面から取り組んで何とかする”という意味です。手前味噌ですが、素晴らしく責任感のあるメンバが揃っています。ただ、近年は労働問題(時間の問題)が厳しいため、いつでも、なにがなんでも全てをやりきるということを個人のゴールにはできません。よって、より一層、上手なチームワークを行わないと、引継ぎだらけで自分の責任の所在や達成感、得られた知識などが偏ってしまい、労働時間は少なくて済んだものの、個人が能力を身につけられなくなってしまい、それでは元も子も無いです。教材(本)の選定本の選定に際し、デマルコやワインバーグ、ゼックミスタなどの著名人が書いた本でも良かったのですが、新卒者と中堅を同じ場で教育し、議論したかったので、もっともっと取っつきやすい本を探しました。・・・探し回った挙句、やっと良さそうな本を見つけました。『童話でわかるプロジェクトマネジメント』一冊買って読んでみたところ、まずまず良かったので、若手の分だけを自腹で6冊ほど買って配布し、読んでもらいました。しかし、この本、なかなかのネーミングです。色づかいといい、表紙の絵といい、取っつきやすそうです。これなら新入社員でもokayです。中堅どころも笑って取り組んでくれるでしょう。取り纏めるチームの担当業務申し遅れましたが、自分は国内外のソフトウェア開発を20年以上やってきました。ここ15年くらいはソリューションという枠組みで全国各地やアジア圏に様々なターゲットがありますが、常に現場の開発技術チームを受け持っているので、浮世離れした開発企画などでは無く、作成したソフトウェアは必ず1~2年以内に現地投入し、国内外で稼動させています。投入対象はインフラなので365日無停止稼動をし続け、トランザクションについても日単位で億以上のオーダに上ります。インフラは高い公共性がある為、利便性の向上を日々要求され、これに伴いシステムサイズは肥大化の一方であり、結果としてSIerやソリューションから下流工程のソフトウェア設計開発、実装、検証、までを一貫して行うチームになっています。・・・悩みの尽きない職務です。常に人がある程度入れ替わる中、組織(チームワーク)をどうすると最適な開発が行えるのか、考えています。教育プランの立案今回の教育は、前述しましたが、若手から中堅社員までを一堂に集め、改めて仕事をやり抜く力であるソリューション力に焦点を当て、切磋琢磨しよう!と集合教育形式(スクール)でやることにしました。事前に本を配布し、読了状態で集合教育を行いますが、教育者は中堅社員とし、受講者は若手としました。普段のOJTでは見られない、集大成的な話を中堅社員に説明するようにお願いしました。ファシリテータは自分が行いますが、必ず参加者が一回以上発言するタイミングとネタを与え、議論した結果を思い思いにメモって持ち帰って貰う形式にしました。そういった点では、宿題や課題が残ったままになるケースも多かったです。これは、後々にグループ内で継続検討課題として取り組めたので、良い傾向にあったと言えます。ここで、本当は悲しいのですが、いつも自分がその仲間の輪に入ってばかりいないようにしました。せっかく、中堅と若手の間に共通認識が芽生えつつあり、会話が盛り上がるタイミングです。ここは敢えて、思い切り身を引くことにしました(T_T)近年の若手エンジニア像これまで自分が手掛けてきたプロジェクトは、下地がある程度出来上がっている社員を引き抜き、期間限定で難易度の高いソリューションをやることが多かったのですが、近年の若手エンジニアは価値観や目標が以前よりバラバラで、だんだん纏めるのに苦労を伴うようになってきました。その為、こういったプロマネ教育を通じて本質的なソリューション力を養いつつ、そもそも現在の中堅と若手はどういった価値観で会話し、どういった心構えでソフトウェアエンジニアとしてやっていくのが良いか、探ろうというテーマも同時進行しています。(参加者の硬直化を避けたい為、現時点では非公開テーマです)また、年々若手は受け身になっていく傾向があります。中堅エンジニアと若手エンジニアのギャップここ10年余り、ソフトウェア開発はコモディティ化が進み、急速に単価が下がる縮小均衡傾向となり、ひと昔前まで引く手数多であった旧来のエンジニアには大変難しい冬の時代でした。にもかかわらず、ソフトウェア品質問題は後を絶たず、新聞にも何度となく掲載され、日経コンピュータ(昔、取材を受けたことがあります)などでも年中取り沙汰され、社会に与える影響は絶大です。レガシーで複雑化した既存インフラと大規模災害を呼べる大きな影響力を持ち、これに付き合わなくてはなりません。大変なプレッシャーです。こういった逆境を生き抜いたエンジニアには、変な自負が生まれ、あたかも自分が生き残ったのは、「全方位の能力を持った」からだと気負ってしまいがちです。事実、こういうエンジニアは気概以外に資質も含め、十分な能力者が多いのですが、チームワークが不得意でなりません。その彼らの気概のベースには”徹夜してでもスキルを身につけるタイミングは逃すな”とか”苦労は金を出してでも買え”といったものがあります。これらはひとつの事実であるため、間違いでは無いように見えますが、時代背景が異なる若手に対し、独善的にぶつけても理解や成果は上がらないので、結果的に間違いとなってしまいます。これが、若手との距離を一層、広げているように見えます。その結果、若手から中堅に対し、”~さんには追い付けませんよ””~さんと会話して決めたんでOKです”のような発言が年中聞こえてくるようになりました。強い他人依存と、既知解探しの思考プロセスが生み出す典型的な発言に聞こえます。謙虚なのか、上昇志向が無いのか、それとも他の何かなのか、正直分からないことも多く、その発言をストレートに咎めてみると、ほとんどの場合、肩透かしのような回答が返ってくるだけです。(「普通、みんなこんなもんですよ?」とか・・)しかし、ここで停滞しては互いに時間の無駄です。少なくとも、その状態ではスキルアップできるとは思えません。伝え方を選び、通るべき道を順序立ててセッティングすれば、過去の自分よりもっと効率的に同じ以上のスキルを取得する可能性を持っているのが若手のはずです。よって、中堅にはPJの進め方をおさらいの意味で本ベースに説明をしてもらい、若手はそれを傾聴し、考え、自分らが拙くもやってきた業務との照合を行い、その真価を問います。こうして外部の本をベースに互いの距離感を埋め、中堅と若手が本質的に会話できるようになることが、いま最も必要なことだと考えます。※もちろん、この議論には「中堅世代が苦労して遠回りしたことに真の価値があるんだ」という節から目を背けていることは認め、中堅にもその旨を伝えてから勉強会を開催しています。本来、苦労は乗り越えた個人にとって、何より尊ぶべき貴重な体験であることは、実体験を通じ嫌というほど知っていますが、今はそれを前面に推し出して若手と対峙する方法以外で伝えないとならない、と捉えています。何故なら、10人中8人はその苦労を乗り越えられなくなっている事実がある為です。言い方を変えますと、そういった苦労を越えなくても良いのではないかという考え方も認められているということで、時代の変遷による価値の変化だと思います。その代償として、もしかすると、個々人のパフォーマンスは昔より下がっているのかもしれません。しかし、この議論のベースにある「昔」は、超超過労働をしていたため、それを普通とみなすのは前提が間違っていると考えるべきであると自分は思います。社会での(ソフトウェア)ソリューション前述しましたが、レガシーによりユーザ要求咀嚼が複雑になったことで、単一機能の提供ではなく、ソリューション指向が高まり、ソフトウェアテクノロジーは単なる解決の一手段に成り下がりました。元々、一手段なのは不変の事実ですが、そのテクノロジー保有者にはスキルと共に創造力もありました。→ もっと砕けた表現にしますと、奢侈財のような面白味や興味を掻き立てる商売が主体となったことで”企画”とソリューションが混濁し、文系の仕事にスライドしていったと捉えています。これは主に北米から始まったシンドロームです。いつの間にか難解なテクノロジーが汎用化(難しさはあまり変わらない)し、エンジニアが増えると、ソフトウェア品質は90点取れれば、あとは企画のインパクトで商売は成立する、という方向性です。いつしか、 ソリューション > テクノロジー という構図が出来上がり、給与体系、出世の階段も差が付けられることになりました。なにやら悔しいです。ソリューションの三大要求について自分の受け持つチームの本業はソフトウェア開発ですが、ここで取り上げるのは開発理論やマネジメント観点(規模見積もりや工程/課題管理うんぬん)ではありません。エンジニアがソフトウェア開発スキルを行使しながら、業務としてアウトプットを出すために必要な本質に重きを置いた教育です。そもそも商用利用のソフトウェア開発(に依らずですが)に於いて、設定すべきゴールはa)ユーザ要求b)社会要求c)自社要求をバランスよく満たすことが最初の定義です。まずプロジェクトリーダは、ユーザ要求を”絶対”にしないことが肝要です。その理由は、ユーザも知らない要求が潜在しているからです。それを見抜き、仮説にもとづいた提案をしながら、完璧を目指すのがプロフェッショナルだと考えます。---[例]-----------------------------------------------------「走行安定性を考え、4WDの自動車が欲しい」という新卒社会人の購買意欲があったとします。これを聞いたカーディーラー販売員は別ビューからの提案(要求に対する追補)をします。 → 燃費が悪いですよ → 維持費が高いですよ。などです。これらは4WDの自動車から言える端的な特徴です。維持費と言う成分も細かく分解すれば、税金やオイル代、はたまた任意保険など数限りないですが、可能な限りリアリティのある根拠情報を定量的に提示します。(オイルの交換スパンや価格など)この際、絶対に揺るがない軸は「時間軸」なので定量化と合わせて時間の経過にもとづく仮説を提示します。任意保険は加齢とともに経年で安くなる可能性が高いですが、オイル代は物価変動と共に高くなる可能性があります。こういった”自動車を購入した人間が向き合う一般的な課題”を多面的に考え、ユーザ要求に追補をし、ユーザの主張がそれでも揺るがないのか総合的な判断を仰ぎます。優先順位は「安全性、利便性、初期費、維持費」でしょうか。ユーザの要求だけでは無く、社会通念と照合して合理性があるかチェックしてあげる必要もあります。もし、ここで互いが納得いかなければ、今一度、背景や要求の真意を探りに行き、納得が取り付けるまで続けます(価値の共有)また、現在の自動車に関しては、初期費と維持費は比例関係(共変)にあると考えます。このように、ユーザは一番気になることにしか目が行かないことが多いため、販売員は長期にわたる満足を供与するために、それ以外の要素である「利便性、初期費、維持費」についても知見をもとに説明をすることで、よりユーザに役立つ要求の明確化が行えます。-------------------------------------------------------------------社会要求についても同様です。(低炭素化の要求などなど)しかし、自社要求は毛色が違います。多くのサラリーマン・エンジニアを悩ませるのが、この社内からの(時に理不尽な)要求です。論拠は技術要件でもユーザ要件でもなんでもなく、単なる在庫整理かも知れませんし、利己的でかつ断る余地のない不自由な選択肢の提示かも知れません。もちろん、法的に排除されるようなことは普通、無いでしょうが、自分の正義やプライドを持ってして勘案した挙句の提案が通用しないケースです。多くの場合はコスト要求だと思われます。しかしながら、自社要求もソフトウェア開発の大きな要素です。よって、戦略的な妥協(compromise)をしながら、前進するしかないです。今回、ここでご紹介するのは、こういったソリューションをソフトウェア設計開発に携わりながら行う人物向けのスタディです。「こうすればベストソリューションが・・」とか「あなたの会社の労働効率を30%アップ」的なことをのたまう訳ではなく、実体験の生情報を記載します。エンジニアがソリューションを行う時にソフトウェアエンジニアは、とんでもなくくだらないミスをします。コンピュータ側の考え方や都合に慣れ過ぎてオーバービューが見えなくなってしまった結果だと思います。人間ならやらないミスを、人間が作ったコンピュータは平然としてしまいます。こういった事故はソフトウェアエンジニアに対し、意義を理解させることの重要性を示唆していると思います。計算機は複雑な算数の問題でを瞬時に解くことができますが、計算問題そのものを作りだすことはできません。算数の問題を解くという方法論は、例えば24個のリンゴを10人のクラスメイトに配るには?などに使われます。余った4個のリンゴを隣のクラスにあげるか、じゃんけんの勝者に配るか、そもそもリンゴの調達を20個にするか、答えは捉え方一つで計算機向けの問題になったり、そうじゃなくなったりします。テストの問題として提起されている訳では無いので、前提条件は合理的であれば変えることは全然問題ないのが社会で発生する問題です。(ここでの合理性は、論理的な意味に加え関係者のコンセンサスも含めます)こうした問題を「ソフトウェアエンジニア」だけのキャリアで、ソリューションするには不足があります。本題のプロジェクトマネジメントここで登場するのが、所謂、プロジェクトマネジメントです。マネジメントというと、リーダとメンバーに分けがちですが、実際は違います。もちろん、適切に振る舞う為に役割や権限の明確化は必要なので、役割としてのリーダは必要です。リーダにはリーダの目的があり、メンバにはメンバの目的があります。リーダの目的は案件の最終成果を(いくつか)出すことです。その目的のために全メンバの目的(リーダから見ると目標)を束ねるという方法論でチームとしての成果を導きます。とうぜんメンバにも目的があり、方法論があります。決してリーダが具体の指示をすることで引き出されるものが成果では無いです。という事は、リーダ、メンバ問わずに自律的且つ主体的な人格を持つ集団であることが肝要です。ここでの議論の焦点です。しかし、非常にあいまいでグレートな響きを持つ「自律性」「主体性」は、当てはめるケースによって、たいへん都合よく使われることも多いです。特にコンサルタントを生業にする人間にはこういった事をそれっぽく、すぐ口にします。(それっぽい現状分析の後に)その場合、自分はいつもそういうコンサルに依頼するのですが、『それならば、私に代わって本案件のプロジェクトリーダをやってください。仰るセオリーに従うと私以上にできそうですか?スキームを見せてください』です。とっても嫌味に聞こえますが、決して嫌味では無いです。これは主に中東や南アジア系の駐在員から言われるセリフに似ています。”そんなに言うならお前がこっちに来てやれ”・・・とても良く聞くセリフです。これを言われると仕方がないので、現地へ赴いて一緒に泥水を飲みながら応対するのですが、絶対、現地に赴かないと理解できない発見だらけです。本気でやろうとするから出てくる発言ですし、本気で対峙するなら応答すべきです。もちろん職務分掌から見ても権限を持てないコンサルに本当にやらせる訳では無いのですが、それくらいの心意気でスキームを持って来れますか、と言う点を初めに伺っておき、今後への期待度に結び付けています。今のところ、けっこうな大手コンサルが数千万円の契約金で取り組もうとしましたが、全社挫折していきました。こういったこともあって国内のコンサルはあまり能力的に信用できません。また、同じようにベンチャーキャピタル(VC)についても、近年は積極的に運営にかかわるところが増えつつあると言いますが、実際は”チャンスを与えるところまで”の支援にとどまり、結果的にお金だけ投資するってところが多いように見えます。こうなってくると先駆者である欧米式の外部トリガーで自律性・主体性を養うのは難しいです。誰がプロジェクトを運営するのかやはり、自分たちでやるのがベストではないでしょうか。結局、複数の人間が集まって上手いこと仕事の成果を出すためには個々人が『目的の理解をすること』に尽きます。これが出来ていれば、主体的に判断していきますし、客観的な事実から良否の判定もできます。課題があれば立ち止まるでしょうし、必要な知識が自分に持ち合わせなければ、有識者の参集もするはずです。しかし、目的を理解している事=目的の意味を理解している事、では思った以上に自律的な行動をする人は現れません。意味と意義、その理解と行動その原因は「意味の理解」と「意義の理解」の差によるものだと考えています。喫煙は将来、病気のリスクを上げることは統計的にも医学的にも証明されていますが、それでは2,000本で癌になるのか、250本で癌になるのかは解明できていません。もちろん非喫煙者でも癌になります。(第三変数問題)この場合、「喫煙の害について意味を理解している」が「喫煙は継続する」という一見矛盾ともいえることが起きます。ここでの喫煙者心理は”分かっちゃいるけど止められない”です。でも、本当はおかしくて、本当に分かっていたら絶対に止めるはずです。例えば、250本吸った瞬間に肺が爆発することが100%決まっていることなら、誰も250本喫煙しないはずです。それどころか、そんな危険なものには手も出さないはずです。この”危険なので手を出さない”というのは「意義が理解できた状態」です。目的を理解するときは、意義を理解することが最重要です。意義を理解したうえであれば、行動は目的に向かって合理的に進み、誤りがあっても気付けます。これらを複数のメンバで行う事で多眼的な行動の立案(複数の行動選択)が発生し、それら議論はいわゆるコラボレーションとして融合し、創造的な立案が行えることもあります。その際、簡素化や効率化を狙って単なるルールを決めることは大変危険で、進化を止める方法です。一緒に働くメンバが、レビューなどの時に「~のルールに従って・・」と言い始めたら、一度はその目的を聞き出すことが必要です。根拠の正当性証明を避ける呪文化している可能性があります。 また、もちろんメンバの達成感や実際に達成した成功体験は他に変えられない資産となります。スクールの開始以下は実際に当該の本をベースに自分がリーダをして、スクールをおこなったときの資料です。メンバ分の本を購入し、事前に配布し読んでもらい、一週間ほど時間を空けて、開校しました。スクール形式のため先生役は必ず必要です。フリーディスカッションも重要ですが、基礎教育であるため、いったん『既知解はある』として進めます。先生役は自分をはじめとして中堅クラスで分担し、童話ごとに先生を決めて隔週でスクールを開催しました。販売されている本の内容に一部、触れるので多くは書けませんが、参考に以下を少しご紹介します。※あくまで自分の判断、やり方です。--------------------------------------------------------------【狙い】・読本で標準的な知識を得る・これまでの業務を振り返り、この新知識が 利活用できるか? 脳内シミュレーションを行う【進め方】・同じ本を読んだ先輩から要点の指導を受ける・自分の振り返り内容と比べながら ディスカッションを行う・互いに何が不足しているのか見え、より実践的な 計画が立てられるようになる----------------------------------------------------------------------------------------------------------------------------【第一章 三匹の子ブタ 要点】・お母さんブタは気づいた 「今のままだと未来がヤバイ、なんとかしよう」 (ref.p19) ↓【振り返り・気づき】□自分の業務で何がヤバイか気付けますか?□何が、どれくらいヤバイか把握できますか?□どうすればいいのか対処できそうですか?----------------------------------------------------------------------------------------------------------------------------【第一章 三匹の子ブタ 要点】・プロジェクトは日常業務とは違う 今までやったことがない特別な仕事(ref.p20)・設計に於いてはどんな仕事も“非日常”である・毎案件がプロジェクト的要素を持っている・しっかり考察し、計画すれば、学びが大きい! ↓ 【振り返り・気づき】□現在の業務の目的、特徴は何ですか?□計画は作りましたか?----------------------------------------------------------------------------------------------------------------------------【第一章 三匹の子ブタ 要点】・一致団結してやろうとメンバー全員に 考えてもらう(ref.p38)・何のためにやるのかをハッキリさせる (ref.p42) ↓□目的を可視化し、共同作業者(チームメンバー) に説明し、納得させていますか?□納得は、相手からの応答を見て判断していますか?----------------------------------------------------------------------------------------------------------------------------【第一章 三匹の子ブタ 要点】・やるべきことを具体的に洗い出す(ref.p46)・役割分担をし、成果物・責任を決める(ref.p52)・必要な時間を予測する(ref.p59) ↓□不明点を相談し、納得しましたか?□各タスクの成果物は明確ですか?□工程表として可視化し、共同作業者(チームメンバー) に説明し、納得させていますか?----------------------------------------------------------------------------------------------------------------------------【第一章 三匹の子ブタ 要点】・絶対に遅れてはいけない作業(critical-path)を 把握する(ref.p68) なるべくクリティカルなタスクを作らないように! ↓□クリティカル・パスの成果物をベースに 実担当者とシミュレーションし、 安全な工程になりましたか?□前後工程の担当者含めて、クリティカルである 認識を共有しましたか?----------------------------------------------------------------------------------------------------------------------------【第一章 三匹の子ブタ 要点】・助けあることでプロジェクトは失敗を 減らせる(ref.p94) ↓□独りぼっちでやろうとしていないか?□課題が可視化できる仕組みは作ったか?--------------------------------------------------------------僅か60分程度のスクールですが、事前の準備と気持ちの準備をして参加してくれたので、とても分かりやすく、今後の実践に活かせる内容となりました。マネジメントには人間力が問われます。(いかなる場合でも同じですが)参加者はこのスクールを通じて、その人間力を鍛える第一歩を踏み出せました。エンジニアには必要以上に華美であったり、粉飾的な鼓舞、独善的で一過的な支援は意味を為しません。そのため、今後一年間は折あるごとに今回の学習を思い出してもらえるように声かけを行っていこうと思います。実践では訓練されたパートナー以外も大勢設計に参加するため、イレギュラーやイリーガルな事件も起きえます。そういう計画外に直面したとき、妥当な判断、チームの意思決定を行う事が大切です。これらはPMBOKを学んだだけでは、全く実践行使できません。リーダとしてメンバから認知され、ステークホルダーからも一様に認められるようになる必要があります。自分の経験上、正直者であることが最初にして最大の資格であると考えています。今現在、読本とスクールをベースとした勉強会を半年行って、先日全章分のスクールが完了しました。4月から新しい期が始まったばかりなので、ここでの学習効果がどのように表れてくるのか分かりませんが、これをきっかけにして一段高い視座で頑張れるチームになると信じています。同じような悩みを持つエンジニアやPLの方も多いと思います。何か新しい気づきがあれば、教えていただきたい次第です。人対人の伝達なので、やり方や伝え方は、常に日々改善や工夫をする必要があると考えています。この本ですが表紙や中表紙に書かれているマネジメントのスペルが”MANEGEMENT”となっており、間違っています。執筆者の方にeメールで連絡をしたところ、チェック漏れだったようです。次回の改版で直ると思いますが、本文は良い内容でした。PMBOK対応 童話でわかるプロジェクトマネジメント [ 飯田剛弘 ]会議室のあるホテルで宿泊研修というのもたまには良いです。自分は年に2回ほど開催していますが、どこかノスタルジーな熱海が一番好きです。熱海温泉 熱海ニューフジヤホテル昨年の冬は、暖かいという理由もあって那覇でやりました。東京からですと、ちょっと旅費がマズイです・・。ダブルツリーbyヒルトン那覇↓”会議室”で検索すると、たくさん見つかり過ぎるので”会議室 熱海”とかにすると良いです。