無法地帯のプロジェクトチームを立て直すために準備をしておくことリスト

タカシ君はとあるプロジェクトのリーダの交代要員として来月から参画することになりました。着任前でしたが挨拶がてらプロジェクトルームを覗いて見たら一部の人だけが忙しくしてました。話を聞くと進捗は遅れ月末のリリースも大変のようです。来月までに何を準備しておくか答えなさい。

— ふみさん (@finayama) 2018年3月12日

いつもタカシ君は大変な役割を負わされていて不憫だなと思いますw。そろそろ、自分で最初から立ち上げるプロジェクトに参画させてあげたいものです。

準備することリスト

参画したら、以下のリストの順にプロジェクトチームに対して情報提供を求めます。

とても重要なことなので仕掛かり中の作業を止めてでも情報把握と出来る手を打つために。

スコープを確認する

引き継ぐリーダと（営業がいれば）営業それぞれと契約で法的な責任を負う成果物を確認しましょう。

スコープを確認するのはプロジェクトのゴールを設定するためです。

スケジュールを確認する

 直近のマイルストーン、リリース計画を確認しましょう。

大変そうなプロジェクトのようですが、そうはいってもプロジェクトは動いているので締め切りにどんなものがあるかを確認してプロジェクトのToDoリストを作りましょう。

メンバのリソースを確認する

 社員、パートナーに限らずプロジェクト参加の工数とフルでなければ来れない日や時間帯を確認します。

キーパーソンが不在が多ければ段取りをしておかないと滞留するタスクが出てしまうので。

チーム内SOWを確認する

チーム内のSOW、つまり役割分担を確認しましょう。SOWを確認することで作業の平準化の材料にします。メンバの工数によってはSOWを変更することを頭の隅に入れておきます。

メンバのスキルを確認する

 メンバ一人ひとりが持っているスキルとスキルレベルを確認しましょう。

SOWでのSPOFの有無を確認するために確認しておきましょう。ひいては平準化に寄与します。

リポジトリを確認する

 プロジェクトのリポジトリを確認しましょう。センター管理できていなければ、分散している成果を一元管理しましょう。

作業プロセスを確認する

プロジェクトチームで採用している作業プロセスを確認しましょう。

トラブってたら作業プロセスはまず存在しませんが。

新しいルールを作る

 あってないような現行のルールは破棄して、新しいルールを作ります。

ルールといっても、作業プロセスと完了条件を守らないとリーダはメンバを守らないと宣言することです。

物理カンバンを使う

 プロジェクトルームにいる限り、いやでも目に入るように物理カンバンを作れる準備をします。

コミュニケーションルールを決める

必ず、自分からメンバに関わり期待する回答を得るまで責任を負うルールにします。投げっぱなし、待ちっぱなしはギルティです。カバーし合うチームに変えます。

掃除する

プロジェクトルームから不要なものを一掃します。見た目からも情報へアクセスしやすいことのメリットがあることを体感させます。

まんがでわかる トヨタの片づけ

当たり前のことですって。当たり前ができないからタカシ君は立て直しに行くんです。残念ながら。

ほとんど躾レベルから手を入れて、まずチームとして自立させます。自律を目指しますけど。

うちのプロマネにコードを書ける必要なんてない。むしろ書かせるな

びっくりしましたね。プロマネってコード書けないと出来ないんだ。知らなかったー。

「コードを書けない奴にプロマネなんて出来る訳が無い」
「そうなんだー（な訳ないだろう）」 

そうそう、以前はコード書いていたけど20年くらいコードを書いていないプロマネはプロマネって呼べない方ですかね。それとも呼んでいいんですかね。

ご自分の主義主張はご自分の経験や信念からの発言だと思いますので、ご自身の周りでされる分には特に申し上げることはございませんし、そういった考え方もあるんですね。何分、まだ素人なので大変勉強になります。

という心持ちで流しますが、コードを書かないプロジェクトマネージャだっていますし、コンサルなんてコード書かないでしょうと思ったりしますが些細なことなのでこの辺で。

多分コーディング知識を持っていないとPMが出来ないと言いたいのでは

 と思ったのですが。

それはなんでも出来た方が良いに決まっていますから。でも、必ず必要な資質とあったらいいねは別です。

プロマネなんですから、必要なのはプロジェクトを遂行するために必要なスキルが必須であって、そうでないスキルまでを求めるのは無い物ねだりするようなものです。

作業プロセスが作れればいいだけ

 プロマネにコードを書くスキルが必要だという論拠を想像するに、プロマネの仕事として工程の計画、工程内の作業プロセスのデザインが必要になります。

昨日のエントリで、プロジェクトマネジメント ・アクティビティガイドラインとして示してありますが、プロジェクトの成果物を実現するためにプロジェクトマネジメント 、その上で行うシステム開発の手法、開発手法を効率的、生産性を確保するために機械化する開発ツールの導入などあります。

この開発ツールの導入や使い方ばかりがエンジニアの関心を引くのでそれってどうかなーその前の大事なこと忘れないでねーと思いつつも、作業プロセスの一部もしくは全部を機械化することがプロジェクトの制約を実現するために必要なことだと理解した上でツール類が楽しーとやって欲しいところです。はい。

置き換えが適切かどうかの判断が出来るか

コードを書く作業は、開発工程の中の一部です。極端な例を持ち出せば、プロジェクト全体から見ればほんの10％あるかどうかというケースだってあります（あくまでも極端な事例）。

大事なことは、手作業を機械化に置き換えて生産性を確保する際の判断を適切に判断できる知識を持っていなければ間違えて判断してそれが結果的に作業プロセスのデザインに影響するだろう、それは結果的にプロジェクトマネジメント の遂行で大きな障害になるんだよ、と言いたのだろうと想像します。

コーディング知識を持った専門家を調達すればいい

以上。プロマネが専門家である以上、コードを書くエンジニアも専門家を調達せよ、です。その辺に歩いているエンジニアを捕まえて頭数を揃えてチームだと称してプロジェクトをやろうとしているんじゃないんですかね。

プロジェクトチームとして、チームに必要なスキルセットを調達するのがプロマネの仕事です。そっちをちゃんとやればいいんですよ。

下手にコードを書く知識を持っていて、それも古かったり、プロジェクトの言語に合わなかったりしてるのにあれこれ口出されたいの、と小1時間くらい問い詰めたいですよ。

アジャイルエンタープライズ

プロジェクトマネジメント・アクティビティガイドライン

読む前に

1. 以下に記載する事項はプロジェクトで必要なアクティビティのテーマとして捉える。実務のプロセスで必要になるルール、フォーム、ツールはプロジェクトの特性で別途用意すること
2. 記載した事項は全て行うのでなく、プロジェクトの特性でテーラリングすること
3. テーラリングは、プロジェクトマネジャーもしくはプロダクトオーナーの好き嫌いではなくプロジェクト、プロダクトの価値を基準とすること
4. 採用するチームマネジメント方針を明確にチームに伝えること
5. 社内でのプロダクト開発の場合は、契約を事業企画に置き換える。その場合は、プロダクトライフサイクルの章立てを追加する
6. スコープ管理はバックログ調整と読み替える
7. 会議体設計は、SOWが生じる組織、団体を全て列挙する。社外については契約単位とすること（再委託は契約関係がないことから委託元を対象とする）
8. 制約条件は委託元（含む法令、省庁・業界ガイドライン、顧客標準、社内規程）からの要求事項を含める
9. 前提条件はプロジェクトマネジャーまたはプロダクトオーナーが想定している必要条件を全て文章化する
10. プロジェクト期間中にプロジェクト監査を受ける場合、プロジェクト計画で計画しコストを織り込むこと

契約

1. 見積もり成果物仕様またはアウトプット仕様
2. システム方式
3. 仕様概要と界面
4. 体制
5. SOW
6. 体制
7. 金額
8. 検収条件
9. 前提条件
10. 制約条件

プロジェクト計画

1. 目的
2. 要求事項
3. 目標
4. スコープ定義（成果物またはアウトプット仕様）
5. プロジェクトマネジメント方針
6. 開発・試験方針
7. 会議体計画
8. リソース・教育計画
9. セキュリティ計画
10. 調達計画
11. コスト計画
12. 監査対応
13. 前提条件
14. 制約条件

プロジェクトマネジメント 

1. プロジェクトマネジメント標準プロセス

システム開発手法

1. ウォーターフォール開発
2. アジャイル開発（スクラム、カンバン）

作業プロセスデザイン

1. 工程（局面）設計
2. 工程内作業設計
3. 作業標準設計
4. 実施要領・内規
5. 標準様式

生産性向上ツール

1. プロジェクト標準端末
2. プロジェクト標準ソフトウェア（OA、コミュニケーション）
3. 設計支援ツール
4. 開発支援ツール
5. 試験支援ツール
6. 開発環境
7. プロジェクトマネジメント支援ツール

WBS

1. 作業プロセスデザインに基づく成果物またはアウトプットの作業分解
2. アクティビティ依存関係設定
3. 作業見積もり

プロジェクトスケジュール

1. プロジェクト採用カレンダ
2. WBSの日程設定
3. マイルストン設定
4. 日程の確定

プロジェクト立ち上げ

1. リソース調達
2. ステコミ
3. 会議体招集案内
4. 概要日程案内
5. プロジェクト計画書レビュー

プロジェクトキックオフミーティング

1. プロジェクト計画説明
2. プロジェクトルール説明（遵守事項、収集メトリクス）
3. 直近工程の作業アサイメント
4. セキュリティ教育

進捗会議

1. ディリースタンドアップミーティング
2. 公式進捗会議
3. 課題管理
4. 工程終了会議
5. プロジェクト完了会議

品質管理

1. 仕様検証
2. 機能検証
3. 障害管理
4. リリース判定

変更管理

1. 要望受付
2. 影響調査
3. 作業見積もり
4. スケジュール検討
5. 採否判断
6. 契約変更（追加）
7. マスタースケジュール変更承認

ステアリングコミッティ

1. 報告事項
2. 協議事項

ちょいと欲しい belkin Qi対応 7.5w

belkin Qi対応 7.5wワイヤレス充電パッド iPhoneX/8/8Plus用 ワイヤレス充電器[国内正規品]BOOST UP F7U027dqWHT-A F7U027DQWHT-A

ADPS & EPUBがやってくる　InDesignで作る電子書籍

頑張るエンジニアにはアンドンの紐を引けない

どこの組織でもプロジェクトの月次報告はあるようです。その月次報告で何をするか、つまりその会議で何をするかは報告事項か承認事項のどちらかです。報告事項はやっている工程は問題ありませんとか工程の品質はそこそこです、とかそんなことを話していると思います。審議内容が承認、つまり決議をするのであれば工程終了と次工程突入の承認をもらうとかリリース判定を審議してもらうとか。

プロジェクトの報告内容がグダグダ過ぎると、開発責任者とか全社のプロジェクト監査員的な人たちから書き方やら報告内容の構成やらと会議の狙いとは違うお作法的なところで躓いて、良くても数ページにわたる条件付き、最悪はリジェクトされてしまうのです。あーめん。

リスクを識別していれば

月次報告会が機能しているかどうかは、会議での発言がプロジェクトチームの活動の報告内容が定性的すぎるとか、報告書より口頭説明での言い訳が多いとかやっている作業の内容が第三者として理解できないなどの綻びからプロジェクトの将来が見通せるか、出来ていると言っている成果物が確認できるか、機能検証がプロジェクトの要件でテーラリングされて設計されているか、セキュリティ要件が識者により検証されているかなどなどのツッコミがあるかどうかで判別できます。

こうした場で実際やることをやっていれば報告するプロジェクトマネージャやスクラムマスタは言い切れるし、裏付けを持って言い切られることで隠蔽しているかどうかをレビューアは敏感に察してリスクがそのプロジェクトにあるかを識別することができます。

でも、その月次報告会が昨日していれば。

エンジニアの方がリスクに鈍感

 そう言った月次報告会に出てくるようなマネージャやPMO的なおじさんたちより現場に一番近いエンジニアの方がプロジェクトの作業に携わっているのだから、今プロジェクトで起きかかっていることがプロジェクトのリスクの芽となるかどうかはわかりそうなものですが、なぜか周りのおじさんたちの方がリスクを見つけるのがお上手です。

エンジニアの方が一つひとつの作業に直接携わり、進捗上の障害となる作業の当事者なのに。

違和感を感じたらアンドンの紐を引く

やはり、作業に没頭してというよりプロジェクトの進捗を脅かすリスクが発現しそうな事象は、プロジェクトのメンバとして日々、時間で追われていると手が届く範囲しか関心をが及ばず、例えば、試験方針がなく、思いつきでエンジニアが試験仕様をソースコードに合わせて作っているのではないかとか、セキュリティの観点で全く対策をしていないとか、と起きていても気づくことができないのではないかと思ったりもします。

プロジェクトのリスクはプロジェクトマネージャがやればいいと思うかもしれないですし、実際そういう役割の方がいいのはそのとおりです。

でも、やはりプロジェクトのファーストラインに陣取るエンジニアは「これでいいんだっけ」という違和感を感じているかどうかだけでもプロジェクトマネージャに感じたタイミングでリアルタイムでつぶやいてくれればものすごく助かるのです。リスク識別の観点で。

生産ラインであればアンドンの紐を引いてラインを止めるんですよね。じゃあ、ITのプロジェクトではどうするか。

月次報告会でレビューアが外から眺めてアンドンの紐を引くようではそれこそ1ヶ月遅れになることだってあるし、遠い距離からリスクを識別しているのでエンジニアの後ろに隠れてしまえば見つけられません。

結局、ITプロジェクトでのアンドンの紐を引くのはエンジニアです。結果的に生産ラインの工員と同じファーストラインの役割の人が一番早いタイミングでラインを止められるし、違和感を感じやすいのです。

それでもエンジニアはアンドンの紐を引けない

 なぜなら、リスクを指摘されるとリカバリをする際に投下するリソースがほぼ人的リソースで、生産設備や原料の調達、引き当て、生産計画を立てるというような外部リソースを使う必要なく、（残業で）頑張るという精神論を振り回すことで対処することを刷り込まれているからです。

これって、人的リソースが無限であると勘違いしているんですよ。人のリソースって使い切っちゃダメなんですよ。スマホのバッテリじゃ無いんですから。

PMの哲学

形なしエンジニア

他人様の会社のエンジニアだし、他人様の会社だし、まあ、自分の会社のエンジニアのエントリだったりしても、「そうか。頑張ってね（ニッコリ」とその意気込みや前向きな意思はいいものだね、と思います。とは言え距離を置いて。

tech.plaid.co.jp

怖いところ

「常にゼロベースで考えて進む」プレイドの文化において、型を守ることから始めないソフトウェア開発は進めやすい、というか自然とそう考えさせられる力学が働いている。

 多分、内製化しているでしょうからそういうこともないでしょうけど、これが発注元でやられるとそれがアジャイル開発だとしてもスプリント内で後出しで色々出て来そうで怖いです。

そんなことはしないよ、と言われるかもしれませんが。

とは言え、ウォーターフォールだっとしてもプロマネの経験知により（良い意味で）テーラリングされているプロセスで開発することになるので、プロマネ次第なんですけどね。

良いところ突いてる

「型を守る」＝「理論についてあれこれ考えずに、その作法に集中する。」で本当にいいんでしょうか。その理論は自分たちが抱えている問題に対して本当に正しく、適切なものなのでしょうか。

この文節は良いですね。ここに気づいて言語化して問いを投げるエンジニアさんは若い方ではあまり見られないので良いところを突いているなー、鋭いなーと思います。

今問題になっているのは形自体を作れないエンジニアが多いということです。ツールの使い方をチュートリアルで覚えてツール使えますっていうようなレベルです。

課題があってそれの解決の要件を満たすものがそのツールで、それを選べたり、課題を解決する方法を組み立てたりできるスキルを持っているエンジニアが必要なのですが、その領域まで足を踏み込めるエンジニアはとても少ないので何とかして欲しいとよく泣きつかれます。

こうした消費型エンジニア（今作った）はツールばかりではなくプロセスデザイン、プロジェクトの作業標準のデザインでも同じことが起きています。

その点での問題提起として捉えたのでとても良いなーと思ったのです。

形なし

 形なしとは、守破離の守で基礎を身につけないままに自己流で始めてしまう状態を言います。

ポイントなのは基礎が身についているか、です。基礎は基礎が身についているからこそアレンジできるし、どれを変えたら如何なるかが見極められるんですよ。

まあ、形なしで自己流派を作られても良いでしょうけど。

適用する理論が適切かどうか

 良い気づきと2つ前に取り上げましたが、適切か如何かを判断する基準が基礎だったりします。基礎が意思決定の判断基準になるわけです。それがないと基準づくりから始めることになります。

ものすごく大変です。基準づくりは。

なぜなら、意思決定の判断基準は組織の文化としてインストールされるから。通常の意思決定は組織構成上の責務の重いロールから分掌されて個人までデレゲートされるものですが、組織文化はそうしたロールの重いところからチームや個人に影響するものです。

それを前提とすると自己流でやろうぜと言える環境なのは組織の文化なんだなと看做しても間違いなさそうですね。

なんだかんだ言って、数年もすればそちらでも開発標準的な考え方が形としてできると思いますけど。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

やる気のないエンジニアの指導で消耗しないために

目標管理の制度が導入されているので業務目標でどういった貢献をするのか具体的に、定量的に達成する期限を設けて目標をせってしてもらっています。

立ててもらう目標（こちらからこれをやっては基本的には言わないです）が今のスキルやロールの経験を鑑みるとだいぶ背伸びをしているなというケースがままあるのです。

この背伸びをした目標を持つこと、達成したいと考えたことはこちらとしてはとても嬉しいことなので基本的にはそのまま設定していいよと進めることになります。

そうした自分のキャリアに対して考えたエンジニアに対しては、じゃあ、それをやれる様になるために必要な準備をどうするかを尋ねることになります。立てた目標を達成するために、裸で武器を持たずにモンスターを仮に行っても負傷で済めばいい方です。最悪立ち直れないほどのダメージを負いかねませんから。

そうすると、じゃあどんな準備をすればいいのかを考えてもらいます。今の現況のスキルの把握、背伸びしている目標を達成するために必要だと思うスキルとレベルの仮説。そのギャップを埋めるためのアイテムとアイテムの手に入れるタイミング。

こうした段取りでやっていければ多分意識的に動けるのでそうそうのこと（デスマに巻き込まれるとか）がなければそれなりに結果は付いてくるものです。

ただ、目標自体を立てられないエンジニアが相応の割合で存在します。これまで何度かあちらこちらのエントリで述べてきましたが、そんなものです。

ちょっと脱線をするとパレートの法則というのがあります。これがエンジニアにも当てはまります。冒頭の目標管理の設定が自分で出来るのは20％程度です。残りの80％はマネジメントサイドで期待する目標とズレていたり、設定するレベルの認識がこちらが期待するまでではなかったりすることがとても多いです。

目標管理に関わらず、やって欲しい要件を持っている立場の人とそれを解釈して実行する人という様に分けると思いが透過的に伝わらないことばかりです。それを認識して、丁寧に、繰り返し説明をしても期待する範囲の目標に着地するのは20％でしかありません。

それを毎年実感する度に思うことは「そんなものだ」という達観した領域へ意識が飛ぶというか、賢者モードに入るというか。

プロジェクトをキャリーしているときに新しい工程に突入する際には必ずその工程の作業プロセスを決め、日々繰り返し守る様に伝えますがそれを破るエンジニアが出てきます。それでも繰り返し伝え、実行させることがプロマネの仕事なので感情は棚にあげて遵守することがエンジニアを守ってあげられる最低条件であることを伝え続けるのですが。

そう言った経験も売るほど持っているので今更なんですよね。80％のエンジニアにより程度の差はあるとしても伝わっている程度の差があることを。

こうした目標管理の設定に紐づくのが技術習得です。それもOFF-JT、つまり、業務で必要に迫られ覚えないければならないツールの利用技術などではない、立てた目標を達成するためにOJTでは埋めることができない知識や技術の習得をその目標を立てたエンジニアが目標を達成する為に、エンジニアの価値を高めるための。

業務に今必要としない、将来のエンジニア自身のために必要なことを（側から見ていると）仕事だけに流されてやらないエンジニアが多い。

こうしたエンジニアにどれだけ口すっぱく言ったとしても先のパレートの法則にある通り、自分の体験に基づく経験知も合わせて思うとやっても結果は見切れています。

さて、エンジニアは中堅やシニアのエンジニアになると後進育成をそうしたエンジニアに期待したり、スールにしたり、メンター制度で紐づけたり、遠回し直接的に目標を設定させるケースがあります。

マネジメントから期待されるので当人は当人なりに頑張ってくれますが、80％のエンジニアに当たるとどうしようもありません。テコでも動かないエンジニアもいるしのらりくらりして1年を過ごすエンジニアもいるわけです。

後進育成の命を受けているエンジニアは挫折するんですよね。もしくは諦めてしまう。

これは決して後進育成する側のエンジニアに対して無駄な時間を使わせることにはならないと思っています。2つのことが実戦で学べるからです。

いわゆる、対象となるエンジニアとの距離感を掴む訓練になります。エンジニアも様々なタイプがいます。無理にタイプに分ける必要はありませんが個々のエンジニアの性質を把握して、どう付き合うのが目標を達成できる距離感かを試行錯誤する機会だと思ってください。

もう一つは、パレートの法則のどちらかにいることを知り、リソースの配分の仕方を学んでください。誰でもリソースは1です。それをどれだけ割くかはリソースを持っているエンジニアが決めればいいのです。ただ、やらなければならないことは全てやっておきましょう。80％のエンジニアの中でも超絶受け身のエンジニアも中には存在してあとで文句を言うのはそうしたエンジニアですから。エビデンスを残しておきましょう。やらなかったのはキミだろう、と。

ゆるキャン△　６巻【Amazon.co.jp限定描き下ろし特典付】 (まんがタイムKRコミックス)

AIのある家族計画

まあ、エンジニアの成長に責任を負っているは80％のエンジニア自身ですけれど。