管理職になりたてのとき、結構どうしていいかわからなかったりしました。
できる人は悩まないのでしょうが、意思決定はなかなかにストレスのかかる作業です。この決定が複数の人たちやPJを左右するからです。リーダーシップ研修などでは「これをすることがリーダーシップだ！」という感じでぐいぐい引っ張っていくことを無条件に要求しますが、では何が正しいのか？どう判断したら正解なのか誰も教えてくれません。「かっこいいのはズバリ判断することだ」といわれても困ります。
そんなに経験があるわけでもないのに、重要な判断について、「どうしたらいいか？」「どうするのか」「方針は？」など始終あらゆる人から詰められてしまいます。
私が実践してきた方法を紹介します。
① 意思決定ができないことで悩んでないか
② 腹をくくれ
③ 自分で手におえないと判断したら
これは頑固であれという意味ではありません。強い意志とはやりきる意思といってもいいかもしれません。
途中で投げ出さない、へこたれないということです
一度決めたら曲げないということもありますが、曲げないのは基本方針「やりきる」というところにすべきで、方法に関しては、「やりきるために」柔軟に変えながら進めていくべきです。(「改善)、「イノベーション)ともいう)
実行レベルに近い決定事項を守り、状況を無視してかたくなにやり続けると、組織がおかしくなってしまうこともままありますので、「やりきる」ことを重視し、「そのためには何でもする」という強い意志が必要です。
プロジェクトには絶対に何らかのトラブルが発生します。発生しない物はありません。キーマンの病気や事故といったどうにもならないと思えるような外的要因が発生するかもしれません。突然の無理な仕様変更要求が来るかもしれません。虚偽報告によるサービスイン前の受入試験での実はプログラムが何もできていない事件が発生するかもしれません。
その時にくじけることなくやりきる能力が一番最初に、絶対に必要なのです。
自分自身のパーソナルスキルの側面と管理技術的な面があります。両方重要で、特にパーソナルスキルの部分は、下手をすると、ひたすらコンピューターに向かってプログラミングしてきた我々にとっては苦手とする部分かも知れません。わかっていることと実践できることは違いますが、それが顕著に出る部分でもあります。とにかく勇気を持って頑張る必要があります。
一方管理技術はというと、管理されることはあっても管理側としての意図意味が分かっていないため、相当に意識しながら勉強する必要があるかもしれません。
今までの経験があるから何とかなるだろうという甘い考えではだめです。
間違いなくこれらの技術の勉強は必要です。ここではどんなものであるかの紹介をします。
とはいえ具体的な方法論もNaOHKI説での展開を時間があるときに追加で述べさせていただきたいと思います。
他のものの本にあるパーソナルスキルという用語とは少し違う解釈になっていることはご容赦いただきたいのですが「(イ)強い意志」から「(キ)意思決定」までがパーソナルスキルでそれ以降が勉強と経験で身につく管理スキルです。
(イ)強い意志
(ウ)原則論(決められたプロセスを実施する)
(エ)コミュニケーション能力
(オ)交渉力
(カ)方針決定
(キ)意思決定
～ここで別れる～
(ク)リスク管理
(ケ)品質管理
(コ)要員育成
(サ)課題・問題管理
(シ)レビュー
(ス)必要な知識
こうしてみるとわかるように精神論的なものが最初に多いように感じるかも知れませんが、これが意外に重要です。
これらのパーソナルスキルがないと知識だけあっても人を率いていけませんし、圧力に負けて心が折れてしまうことも多いです。
まずは一般的な話から。
ここでいう「いろいろ」はいろいろな管理手法のことではなく、いろんな役割を持つＰＭがいることを話します。
これらのマネージャは組織やどんなプロジェクトであるかによってあったりなかったりします。どれが偉いとかというものはありません。規模に応じて組織や役割を分割統合して責任を果たせるようにするものです。つまり広くすべてを行うか分割して少しづつ担当するかの違いになります。
① 与えられたプロジェクトの遂行のみをするマネージャ
案件が持ち上がったらその都度ごとにプロジェクトマネージャを選定しそのプロジェクト全体を遂行してもらうタイプのマネージャです。大抵の場合、営業部門か上司が仕事をとってきて、それを人に割り当てていく感じで進めていくタイプです。
ある意味イベントドリブンで、PJの遂行に責任を持ち、与えられた範囲内で成功させていきます。
ソリューションベースの特定のノウハウや技術を元にそれに関するプロジェクトを遂行していくマネージャにこのタイプが多いですね。
ここでイメージしているタイプは１PJ１マネージャ程度の規模のものを想定しています。技術者上がりのマネージャはこのようなタイプの仕事が向いているかもしれませんね。
② パークを与えられ、営業戦略を含め策定していくマネージャ
特定のお客様や業界を自分のパークとしてその中での様々なお客様の課題を解決していくタイプのマネージャです。あるパーク（市場）を担当として与えられていますから、その行う範囲は各PJの成功のみならず、そのパークでの事業の拡大が入ります。大抵の場合範囲を与えられると一PJではありえませんから、複数のPJを並行してみていくことになります。
そうなってくると部門の管理的なもので、複数のリーダを使って複数のプロジェクトを管理することになります。規模によって、マネージャと呼ぶのか部門規模であれば部門責任者ということになるのでしょう。
複数プロジェクトを並行して管理していく技術が必要になります。組織作りの技術が強く要求される立ち位置ですね。
ここではパーク(市場)を範囲として与えられるものとして書きましたが、ソリューション(技術・製品)という範囲もあり得ます。同じように、そのソリューションを利用する複数のお客様のPJを管理する必要がある場合もあります。あたえられている「範囲」の概念が違うだけで同じ話です。
③ 巨大プロジェクトの一部を担い責任を果たしていくマネージャ
大きなプロジェクトとなると一人では管理しきれなくなることがあります。その場合、複数のマネージャに役割を分割して管理させることがあります。
開発と基盤と運用とQCD管理に分けて、それぞれマネージャが付き、その上にさらにプロジェクト統括責任者(これは部長だったり・マネージャだったり)が付くことが多いです。
それぞれマネージャはメンバーを持って行動しますが、実態はプロジェクトマネージメントチームとして行動することになることが多いです。
サブシステム事態が巨大である場合、サブシステムを管理職が管理することもあります。この場合は、そのサブシステムの専門家であると同時に、サブシステムをPJと同じにとらえ、その中のQCDをはじめとして、人材育成・人事管理等も範疇として行っていく場合もあります。
あなたはどれになりたいですか？
ほかにもPJタイプでの分類もあります。
用語説明：パークとソリューション
・サブシステムを任される
システムにはサイクルがあって、定期的にリプレースが必要になります。(HWやソフトウエアの保守期間が切れたり、業務が時代に合わせて高度化するから)
そんなリプレースのときに一つのサブシステムを任されてサブシステムリーダになりました。
この時はメンバーを３人にして私入れて４人でチームを作りました。運の良いことに優秀なプログラマが一人入っていたのであとの２人は２年目程度の人でもなんとかなるだろうとふんでいました。そのサブシステムはメンテナンスをしてきたところであったので、中の構造はすべて把握しています。最初に作られていたのがぐちゃぐちゃだったので、リファクタリングしたのです。
ほとんどの設計は私がすべて実行し、共通部分、難しい部分のコーディングを優秀なプログラマ(設計とかのドキュメンテーションは不得意)にひたすら作らせます。
その作られたフレームワーク上で２年目たちに機能を作りこませたのです。概要設計までは私で行い詳細設計以降を任せる感じです。
後から聞いたところでは、初回とは比べ物にならない生産性だったそうです。
今から思うと普通の開発ではできない手法でした。(一般化できないという意味)
・管理をサポートする
そのかいもあって管理サポートをするようになり、管理チームに参加する様になります。見積もりの精査や品質管理、課題管理などの技術面を中心にサポートをしたのです。見積もり精査は、見積もりに対して、勘違いしているところはないか見落としているところはないか、妥当性を欠くところはないかを見ました。品質管理はバグが入り込む原因を分析して対策したり、直らないバグに対して助言を与えたりしました。課題管理は、課題に対して複数の解決方法がある中で最適なものを提案したり選択したり技術面の裏付けをとったりしました。
・専門家として参画する
別の案件では技術の専門家としてPMをサポートする立場(ITアーキテクト)で、システムの全体設計を行いました。基本設計までは私が行い、みんなに伝えて、サブシステムごとに概要設計から実施していただくという方法をとりました。
マネージメントをするマネージャーがいたので、その部分は任せて、システムアーキテクチャの策定、技術問題の解決に専念できたのでした。
・PMとして参加する
その後のプロジェクトではマネージャとなってシステム全体の開発構築を行いました。
何となくきれいな段階を追ってPMになっていったように見えますね。当然細かいところは省いていますから、真実ここまできれいではありませんが大きな流れとして、参考にしていただけたらと思います。
実際にはいろいろ紆余曲折はあるものの美しく並べるならば以下の通りです
・サポート要員としてまずはPJに
サービスインしたプロジェクトの残件対応としてこの業界に入りました。サービスインしたといっても問題は多く、バグも大量に残っていましたのでそれらを何とかするのが役割でした。
・いくつかの問題を解決
当時は派遣社員でしたから１月以内に成果を上げないと切られてしまいます。
最初の２週間は仕様書設計をひたすら読みました、早く何らかの成果を出さなければならないのに１０００P以上あるあるサブシステムの設計書を渡されたのです。読み終わったことを報告して、障害一覧の中からプライオリティーの高いものから支持を受けて修正しました。
何とか１月以内に１つの修正物件をリリースすることができました。そこからは片端から修正です。
・他のサブシステムの問題を解決
サービスインしていますから使っているときのバグは重大障害として問題になります。大きなものになると担当者全員を集めて緊急対応することになるのです。
そんなことで客先に集められたのですが、たまたま私のいた作業場が近くであったため、先について、その時の責任者から簡単なサブシステムの説明を受けた後、障害調査をしたのですが、運よくすぐに原因が分かったのです。その時はまだ担当者が来ていなかったため、修正内容の案とその影響調査しながら待っていたのです。運が良かっただけなのですが結果的には担当者より早く対応したという結果だけが残りお客様の印象に残る実績となったのです。
・改修案件をやる
システムが安定してくると、今度はシステム変更案件なども入ってくるようになります。変更ですから、見積もり(どれだけ時間がかかるかを言うだけ)をして、受注できたら、それを実行する。というものです。
・大きな改修案件をやる
それらの改修案件をこなしていると、大きな改修が入ってくることもあります。そうなってくると一人ではできませんから、人を入れてやることになります。自分だったら何時間かかるというものはありましたが、ほかの人がそれだけの実力があるのかわかりません。同じくらいだろうと見積もって、ちょっと安全をみてまったくみんなが使えず自分が一人でやっても何とかなる期間と人数を報告してやりました。
当時は資格試験の受験生でしたのでパートタイマーのチームリーダーだったのです。２人いれて３人でやったのですが、私よりは経験が長い人たちでしたが生産性は半分程度であったと記憶しています。困ったら相談してくれと言ってあったのに一つのバグで丸一日悩んでいて、声を掛けたら相談してくれたのですが、単純な話であったためにすぐに直ったのです。悩まずに相談してくれたら１日（８時間）は無駄にせずに済んだはずです。といようなことがあるということを学びました。
ここまではシステム保守段階の話です。
ここからリプレース開発の受注後の開発を担当する話になります。
虚偽報告をされてしまったら「運が悪かった！」のでしょうか？
違います。これも発見できます。
昔の話で今ほど業界は経験を積んでいなかった時代であり、報告内容などが性善説に立ったものだったのです。まず、進捗が可もなく不可もなく理想通りに進んでいる段階で怪しいです。人が動いて作っているものですからそんな馬鹿なはずがないのです。必ず苦労したり失敗したり、残業がかさんだり進んだり遅れたりするのです。
今であればこれらのことをすることでこのような事態は避けられます。
このような詳細な報告を受けている場合で虚偽報告をしようとした場合、かなり大変です、必ずぼろが出ます。
ぼろを発見する
課題がないということはありません。課題があるということはそれについて人が動いているはずでそのモジュールなり機能のところで、進捗が動くはずです。当然品質にも影響があるはずでそれらの関連性が合理的でないのであれば虚偽報告である可能性があります。早急に現物確認をします。
現物確認は疑っているからするのではなく、PMの責任として、成果物を自分のものとして内容等を把握するために絶対に必要ですから、怪しくなくても時々行うべきです。
進捗報告の粒度もある程度負担にならない程度に詳細にもらうべきです。自動的に集計が取れるものでも良いかもしれません。
テスト要員と開発要員を分けることも肝要です。
五感を駆使して、異常を発見して早めに手を打てるようにしましょう。
大昔の話。
毎週進捗会議をして、各サブシステムから進捗をヒアリングします。シンプルな書式で、工程ごとに進捗率の目標と実績を報告してもらうものです。
各サブシステムごとに進んでいたり、遅れていたりするのですが、おおむねスケジュール通りに進んでいました。遅れているサブシステムは監視対象になって細かく進捗を見られます。それこそねほりはほり。
そんなこんなでサービスインを控え、ユーザ総合試験をすることになりプログラムを動かしてみようということになったのですが、あるサブシステムだけが何やら見てもらいたくなさそうです。説得して見せてもらったのですが、プログラムが動きません。それどころか、プログラムが完成していません。進捗上は内部の総合試験をほぼ終わっていて、動きそうです。どうしたことでしょう・・・実は報告者が、実態を見ておらず、期日に合わせて数字だけ更新した資料を毎週提出していたのでした。
虚偽報告です。ＰＭとしてはこれをされてしまうと手の打ちようがありません、さすがに嘘をつかれた場合には・・・
「運が悪かった！」のでしょうか？
解：発見できるか？
例によって、気ままに書きますので順番の前後等あります、気長にお待ちください。
あるPJでバグは日々たくさん出るが直る数も多く、頑張ればバグはなくなるように見えました。
ここでほんの少しSINを遅らせるだけで収束するように見えます。
「あと二週間徹夜すれば！！」本当にそうか？
このときの収束曲線
開発を経験しているのであれば、バグが日々出ていることに着目して、「この時期にこんなにバグって出るもんだっけ？」と疑います。さらにバグの中身を見ます。単純な表示上の問題や計算の問題に見えるものが多いです。数十の画面で表示されるべきものが表示されなかったり、別のものが表示されたり。ここで「あれ？」と感じる人も多いでしょう。「バグの数が多すぎます。別のものが表示とは？表示されなかったり？数からいう１画面あたり１回以上？」どういう作りをするとそんなことに？
実態は、あまりにもバラバラに正規化されたテーブルを集めてデータにするところを一か所に集めてルーチン化したのですが、パターンが増えるごとにそこに手を加えていって、ものすごい巨大な関数がいつの間にか出来上がっていたのでした。なので問題があると、そこだけ直せば直るのですが、影響調査がしきれず、ほかのところに影響が出て、新たなバグになり・・・・バグの収束の速さとバグが出る量が多いことはそこが原因でした。「典型的スパゲッティー・・・」
それをほぐすには！とすぐに期間の見積もりを指示しますが、１月２月ではとてもやりきれないほどめちゃめちゃに・・・仕様の整理も十分にされていないようです。たとえバグをつぶしていって機能要件を満たしたとしても、性能要件での問題が起きそうです。
これは死亡プロジェクトの例です。行きつく先は契約解除と損害賠償です。(実例かどうかはノーコメント)
仕様がはっきりしない段階から開発をはじめ、仕様が明確になるにしたがって、機能を追加していった結果のコードでした。(最初に単機能のものを作り、あとから追加された機能をその機能に追加しました。あとから予想もしない機能がどんどん言われて、それも追加していくうちに、後戻りできず、現場はさらに追加し続けてしまった)現場のプログラマに開発を任せ、ウオーターフォールを無視して、設計レビューをせずにものの完成のみを追っていったために起きたのでした。アプリケーションアーキテクチャを機能全体を見て設計していたら避けられた事態です。
サービスイン直前まで数字のみを追って、現場の報告をうのみにしてきたためにそうなってしまったのです。開発経験をしたことがある人は何となくわかると思いますが、中身を見るPMであればもっと前から問題点に気が付いたであろう、予兆が見えたと思います。
上記例では技術上がりの管理者としては火を噴いた後から「たーすーけーてー」という声を受けて支援に入ったところで事態がわかるということになるかと思います。もっと早くから事態がわかっていれば打てた対策もあるかもしれません。
本来の収束曲線
プログラマー経験があるとわかりますが、プログラミングってズバリセンスですよね。
センスが良ければ時間をかけずにそこそこのコードが書けるようになります。経験を積むと、人に迷惑をかけないソースが書けるようになって、さらに経験を積むと人のソースをみて、相手の考えていることがわかるようになりますよね。
PMも同じです。かなりセンスが要求されます。同じように経験を積むことでいろいろな管理方法論が確立されていって、怪しいところが犬のように臭いでわかるようになります。
いろんなPJをいろんな立場で経験していると、「その時どう考えていたかな？」「こういうことはありがちだな」などと思ったところは必ず記憶しておいて役に立てます。PG経験があるとPGの気持ちや落とし穴をよく知っていますから、管理するときでも「実はこういうことなのではないか？」という話ができてPJの真のもん亜ぢ店を明らかにして対策を打ったり、課題管理においても「この問題の解決策としてはこんなことがある」あるいは「この観点で調べるといいかも」などとアドバイスができたりします。(問題解決自体はマネージメントの仕事ではないのですが・・・)
たたき上げの嗅覚で対策した例を示します。
良い例かどうかはあれなんですが・・・
①必死のバグつぶし、バグは直っていくが・・・
②データの受け渡しの無駄
③バグを隠しているのではないか
これらについて述べていきます。
例によって、気ままに書きますので順番の前後等あります、気長にお待ちください。
