終わらないエンジニアの考えるスケジュール

エンジニアに限らず、他の部門でも成人済みの社会人のかなりの割合の人が納期に間に合わないような仕事をしています。

「ほんと？」と思うでしょ。ほんとです。20％くらいの割合でいますね。去年度の体感ではそのくらいの人が締め切り直前のリマンダーをみて慌てて対応していましたから。忙しいだろうと余裕をもたせたスケジュールが災いしたのかもしれませんが締め切りを厳しくすると納期に間に合わせてくれる大多数の方がしんどくなるのでねぇ。

アラートがないと始めないなら間に合うわけがない

作業を終わらない人のスケジュール感ってはたから見ているとこんな感じです。進捗を黙って見ていると、途中まで何をやっているのかさっぱりわかりません。

だって、アウトプットがないのです。作業期間の途中になってそろそろ期限が近いと警告を受けてやっと動き出す。もともと作業プロセスが決まっているなら、全てのステップは通過しなければならない（からチームとして標準プロセスを決めているわけです）のですから、慌てて初めても間に合わないのは確定事項です。

ではどうしたら納期に間に合わせることができるでしょうか。

何をしなければならないのかを知る

必ず納期に間に合わせるためには、まず、納期までに経なければならないレギュレーションや標準プロセスを押さえておく必要があります。

例えば、資料作成や設計書の執筆、コーディングでプログラムを書くというような作業のいずれも共通項としての項目は下図のようなプロセスを経るものです。

作業の中で行う小さなボックスは図では一列に並んでいますが作業プロセスとして定義する業務やプロジェクトで決める作業プロセスでは繰り返す場合もあります。そのようなケースでは、ループが前提で基準を満たすとブレークするプロセスの設計になっています。

作業を見切る

決められている作業プロセスが明確であればそれをベースに、その作業を自分のスキルでやったらそれぞれ何時間かかるか「時間単位」で作業の工数を腹づもりする必要があります。

上記の図の5つの小さな作業が今の自分のスキルレベルなら1つずつ何時間あればできるかを見積もるのです。

ただ、作業を見切るためにはもう一つ情報が必要です。

ゴールを設定する

作業はチームやプロジェクトとしての1つの作業を切り出しているのであって、自分が勝手にやっていいものではありません。

つまり、自分でやった作業の完了形を次の人に渡さなければならないということです。その人が（例え後続を自分でやることになっていても）受け入れられる水準があるのです。それを満たさなければ後続の（自分かもしれない）方に前行程の不十分な作業のツケを回すことになります。

今日終わらせると決めたことを終わらせる

納期に間に合わせるためには、今日終わらせると予定したことを終わらせることです。これ、当たり前ですが、計画した通りに進まない（のは周りと一緒に働いているからと自分のスキルレベルと見積もりの甘さなどの原因があるので）のです。

でも他責にしては何も産みませんし、進捗が進むわけでもないので、いかに進められるかを考え行動する必要があるのです。

仕事でメールを使わない方に持っていく

今の中堅くらいまでのエンジニアには信じられないかもしれませんが、ワタシが社会人になったときに仕事には電子メールは存在しませんでした。

厳密に言えば、UNIXホストコンピュータではどうやら使えたようですがそれを仕事で使っている職場のエンジニアはおらず、興味で電子メールっていうものがあるよ、と教えてくれた先輩がいたくらいで、基本的な仕事での伝達手段はミーティングか直接伝える手段のみでした。

メールの洪水は自分の首を絞めている

プロジェクトがデスマスになると増えるのが電子メールです。それも大規模プロジェクトでデスマになると昼夜を問わずメールが飛んでくるようになります。深夜終電前に帰ったはずなのに、翌朝メーラーを立ち上げると100通もの未読があると他社のエンジニアであってもお疲れ様という感想を持たざるを得ない心境になったものです。

こうしたプロジェクトでやっていけないのは全部のメールにいちいち返信をすることです。極力減らす活動を、仕事の仕方をしなければ肝心の作業に時間を割けず、アウトプットされない事態に自らを追い込んでしまいます。

メールが情報共有に向かない理由

先のプロジェクトのような場合、すでにチームの中の情報伝達がメール中心になっていることが多いものです。それは外部に巻き込まれて同じようにようにチームの中でもメールで情報伝達をしているからです。

メールは添付もできるし、一度に多くの関係者に情報共有をできるので一見便利ですが、過去に情報を遡ることはそのメールの受け取っていた関係者に限られるので情報を遡求して調査する必要がある場合のリポジトリには向きません。

途中の参加者が入ってきた場合、過去メールを共有するのは至難の技です。なので、メールを情報共有ツールだと思っていたら実は間違いだ、と思い直した方が良いです。

メールのダメなところ

メールの一番のダメなところは、メールを作ったり、返信したりすること時間を割いていると仕事をした気分になることです。

気分になるのがダメということは、実質は何もしていないのと同じです。貴重な自分のリソースを使っていても実は担当する作業が１ミリも進捗していなかったなら、全くもって時間の無駄なのです。

あと、セキュリティ上も安易にメールで情報共有をするのは誤送信を防止する観点からも適当ではありません。

メールで情報を送るということは、いくら宛先限定としていても受け手を制御できませんからノーガードと同じです。

メールを減らす活動例

ですからチームの中では情報伝達方法を変えます。まずは情報共有可能なリポジトリに全部つっこっんでしまいます。

ではどうやって情報共有をするかというと、朝会、ミーティングなどチームの中のエンジニアと共有するので、対面で伝えます。

メールを使うのはリマインドやねんのためのことだけにします。

これが浸透するとチーム内のメールがかなり減ります。

そうすると、メールで情報伝達されるのは社外からのメールになるので社外からの重要なメールを見落とすことが減ります。

社外ともセキュアなクラウドストレージで情報共有が可能であれば、添付をするようなメールは撲滅が可能です。

情報のリンクを送り、用件だけを伝えるように仕事の仕方を変えることができるのです。

チームを立て直すには「新しいフレンズは誰かな？」より「フレンズ（メンバ）のできること」を探す

こうして過去に振り返ってみるとトラブルプロジェクトの火消しとか大規模プロジェクトで炎上し始めたところで立て直したりとか、そんなプロジェクトの方が印象が強いのは何かしら自分にとって成長や検証してみたかったことを検証できたことなどなどの学習効果があったのかもしれないですねぇ。

「新しいフレンズ（お友達）は誰かな」

あるプロジェクトが始まってひと月もせずにあるブロックを立て直して欲しいと懇願されるわ、当時の役員からしょうがないからとか説得なのか同情なのかわからないご助言をいただいたことがあって。当時担当していたプロジェクトは後任に任せ他ところそっちもおかしくなるしと、なんだかな、と言う経験をしたことがありまして。

で、しょうがないプロジェクトルームに入ってみたら最初に言われたことが

「新しいフレンズは誰かな」

ですと。マジで。

フラグですよね。それもめっちゃ死亡フラグですた。

今なら「新しいフレンズだね」と言えば争いものけものもないある意味サンクチュアリー的なジャパリパークで安寧な世界観に浸れますが、当時はそういった社会的認知はありませんでしたら単なるフラグでしかありません。

それもいきなりボスキャラ的なフラグですけど。

フレンズのできることを探す

立て直しを頼まれたプロジェクトですから先にチームがあるのです。そこにはこれから一緒に活動するメンバがいるのです。

いつも述べていることですが、プロジェクトの目的を達成するためのチームとしてのスキルセットとスキルレベルに対応してチームメンバが持っているスキルとレベルを紐づけて不足がないかを調べる必要があります。

立て直しのプロジェクトですから当時の心境はこんな感じだったでしょう。

でも、仕事です。やってみればわかります。

やっぱり仕事です。プロジェクトですから力になってくれるフレンズもいるのです。

力になってくれるメンバはフォロワーです。とにかく、トラブルプロジェクトに関わらず、一人目のフォロワーを作ることが必要です。そうしたインフルエンスを起こせるメンバとチームを変えていきます。

チームとしてスキルとレベルがでこぼこであればプロジェクトの目的を達成できるチームに変化させなければなりません。

・プロジェクトの中での教育
・スキルのストレッチ

 プロジェクトの中での教育は、作業プロセスの標準化に伴うものやトラブルに至る原因の除去も含めて行います。

計画したことを計画した通りに終わらすことや自分たちで決めたことを守るなど、大の大人がないがしろにする基本をいつでもできるチームに変えるのです。

そのためにはチームのメンバが何が「得意なフレンズ」かを知る必要があるのです。

ねんどろいど けものフレンズ サーバル ノンスケール ABS&PVC製 塗装済み可動フィギュア

後輩ちゃん「先輩、胡散臭いコンサルがロジカルシンキングを振り回してうるさいんですけど」

「先輩！あの、お時間いいですか…」
「ああ、いいよ。どうしたの、今仕事何やっているの」
「某お客様の今オンサイトプロジェクトやっているんです。この前飲んだときに話したじゃないですか。忘れたんですか、ひどいですね。それは今度ワイン１本で許してあげます。それでわざわざ先輩の席までよったのはですね、プロジェクトの横並びのベンダーが五月蝿くてうるさくて。うちに被害はないんですけどね、隣のベンダーでロジカルシンキングを振り回しているコンサルぽい胡散臭いリーダの人がいるんですよ」
「うちの話じゃないのか。じゃあ気楽だ。しかし胡散臭いコンサルとは」
「見た目も胡散臭いですけどね。それでそのコンサルがドヤ顔でチームのメンバをダメ出ししているんですよ。真横でやられるからうちの若手に悪影響してもヤダなぁって」
「優しいねぇ」
「茶化さないでください。こっちは真剣なんですから」

「ごめん、これ以上奢るの増えても困るので真面目に聞くよ。どんな感じでロジカルシンキングを振りましているの」
「資料を作らせては『これはロジカルじゃない』みたいなことを言うんですよ。下手にロジカルシンキングにネガティブなイメージを持たれるのもどうかと」
「なるほどね。それで後輩ちゃんはロジカルシンキングについてはどう捉えているの」
「MECEとか、抜け漏れがないようにしようというアレですよね」
「アレって言われても」
「私の理解はいいじゃないですか。それより」
「いやさぁ、背景くらい確認しておきたいからさ」

「それでどうしたらいいですか、先輩」
「後輩ちゃんのチームではそうしたロジカルシンキングはどうしてるの」
「わざわざロジカルシンキングなんて言わないですね。淡々とインプットを要件で整理していく感じですけど」
「後輩ちゃんのチームではロジカルシンキングを前に出して作業をしているわけではないけど、ベースとしては使っているんだよね。そういうことだね。ただ、横の方で同じようなツールとしての論理的思考を考える方に使うんじゃなくて、アウトプットを批評する道具として使っているから、若手に勘違いされると迷惑千万だ、と」
「そこまで品なく言わないですけど、まあ、そういうことです」
「品がないって…ひどい。そうだねぇ。気にしなくていいんじゃないの」
「エェェェ。そんなこと言わないでくださいよ。わざわざ忙しいところを時間を割いて先輩の席まで参じてきたんですから。何はお土産ください」
「その心配性はリスクの識別に使ったほうがいいと思うけどさぁ」
「それはそれでやっておきますから先輩はこの課題をやってください」
「いつから自分の課題になったんだい」
「先輩に選択権はありません。いつものことです」

「論理的思考、ロジカルシンキング。どれでもいいけれどさ、あれは仮説を立て、検証して間違いだと気付いた時に素早くピボットするための道具なんだよ。覚えてるかな」
「あ、そうだったかも」
「仮説を立てるじゃん。その仮説が対象とするスコープ、さらに中での分類など段階的にふるいにかけ、処理をするじゃない。そうした組み立てには根拠の情報を必ず紐づけるじゃん。そうして立てた仮説を検証した時に間違いが見つかる時がある。それを見つけるのが検証なんだけれど。間違いが見つかったときにどこまで立ち戻ってどこからピボットすればいいかのルート分岐を決めてあるからその分岐の裏付けの根拠が間違っているのか、分岐の場所が間違っているのかとスコープを見直しやすくするのがロジカルシンキングのそれっぽい使い方だと思うんだよ」
「ロジカルシンキングぽいって相変わらず曖昧な先輩」
「でもさ、界面を決めるには根拠が必要だし、それは前提条件や制約条件で決まることだし。導きたいゴールは仮だし」
「それで先輩はどうしろと」
「後輩ちゃんたちの仕事の進め方、プロセスにそうした思想が織り込まれていて、プロセス通りに進めるだけでロジカルシンキングを使うことによる期待が得られるならそのままでいいじゃん、ってことだよ」
「そうなのかなぁ」
「いいんだよ。よそはよそ、うちはうちで」

考える技術・書く技術―問題解決力を伸ばすピラミッド原則

エンジニアには会議に出席するのではなくコミュニケーションスキルを発揮することを期待されている

PMBOKの第6版は、もうそろそろ出るはずではなどと思いつつ、久しぶりにPMBOKを開いてざっと眺めていたらプロジェクト・コミュニケーション・マネジメントの章でこんなこと書いてあったんだ、と今更ながら驚いてみたりするのです。

PMBOKもPMPを取るバージョンはしっかり読むけれど、取ってしまった後はそれほど見ようとは思わないから。
＃まあ、今回はたまたまパラパラとPDFでページ送りしたわけですが

プロジェクト・コミュニケーション・マネジメントの章立てで目に留まったのはこの部分です。

端的に言えば、プロジェクトの中でコミュニケーションをマネジメントするには、以下の11のスキルが必要であると要求しているのです。11のスキルを活用しないとプロジェクトの内外とのコミュニケーションが上手くいかない、ということです。

・積極的かつ効果的に傾聴すること
・確実に理解するためにアイデアや状況を質問し、正しく調べること
・チームがさらに効果的に活動できるように、チームの知識を増やすための教育を行うこと
・情報を特定し、または確定するために実態を調査すること
・期待を設定し、マネジメントすること
・行動を起こすように個人または組織を説得すること
・励まし、安心させるために動機づけること
・パフォーマンスを改善し、求める結果を達成するためにコーチングすること
・当事者が相互に受入れできる合意に達するように交渉すること
・深刻な影響が生じないように、コンフリクトを解消すること
・要件をまとめ、整理し直し、次の手順を特定すること
　※プロジェクト・コミュニケーション・マネジメントの概観図は略
引用　PMBOK 5th

11のスキルを眺めると、プロジェクトチームのマネジメント、つまり、プロジェクトマネージャが発揮するスキル群（黒色）とプロジェクトメンバがアクティビティを実行する際に発揮しなければならないスキル（水色）と分けられます。

「期待を設定し、マネジメントすること」についてはマネジメントとキーワードが入っていますが、メンバ自身のアクティビティで得たい成果があり、他者に働きかける場合

はメンバ自身が期待する結果を得られるようにコントロールしなければなりません。

実際にコミュニケーションを行う場合、総合に意思伝達をすることが目的ですから、双方の間で交換されるのは情報です。

その情報を中心にコミュニケーションを駆動するために識別する必要がある事項が次の７項目なのだな、と理解することができます。

・誰が、どの情報を必要としているか、また、その情報へのアクセス権限が与えられているのは誰か
・いつ情報が必要となるか
・どこに情報を保存すべきか
・どの形式で情報を保存すべきか
・どのように情報を検索するか
・タイムゾーン、言語の障壁、および文化の相違に配慮する必要があるかどうか
引用　PMBOK 5th

最終的には、会議体としてプロジェクト・コミュニケーション・マネジメントとして整理されるのですが。

この会議体に行き着くまでにも次のことを考慮しなければならないのです。

・内部（プロジェクト内）と外部（顧客、供給業者、その他のプロジェクト、組織、一般の人々）
・公式（報告書、議事録、概要説明）と非公式（電子メール、メモ、その場限りの話し合い）
・縦方向（組織内の上下関係）と横関係（オフレコのコミュニケーション）
・公認（ニュースレター、年次報告書）と非公認（オフレコのコミュニケーション）
・書面や口頭、および言語と非言語（ボデーランゲージ）
引用　PMBOK 5th

奥が深いですねぇ。プロジェクトマネジメントの計画書のテンプレートがある組織であっても、こうした背景の説明はされずにいきなり会議体の設定になりますからね。

ましてや、プロジェクトマネジメントの計画書がない場合は、過去の経験知だけでしかも思い出せたものだけでしかセッティングされませんから。

会議体だけで眺めてしまうとプロジェクトのメンバは、ただ参加すればいいとか、ある会議で資料を作らないといけないと自分で分担する作業ばかりを考えてしまうけれど、本来は、そうした分担を成功裏に導くために自らのスキルを発揮することが必要であるとプロジェクトマネージャは働きかけなければならないのです。

アウトカムで目標を設定するという新しい考え方

通常、目標管理制度などでは年度の目標を立て、設定した納期を目指し、活動の成果をアウトプットすることで、期初の目標と期末のアウトプットを比較することで業績評価を行います。

端的に言えば、活動から生み出すアウトプットを評価しているわけです。こうした考え方は、業績に対する評価制度としては適当かなと思うのですが、キャリアプランにおいて同じように活動をとおしたスキルの伸長ではスキルが有形でない分、救えきれないなぁと思っていて、有形でないからこそ運用で対処するしか手段がないかと思っていたのでした。

アウトプットでの評価

ejje.weblio.jp

設定する目標に対し、活動を経てアウトプットで評価をすることは従来の目標管理制度の基本ですし、アウトプットで言い表わせる有形の生産物を評価すること自体はとてもわかりやすく、評価が合意しやすいです。

アウトプットで言い表わせるということは定量的であると表現できます。数量、時期、諸元など誰が見て比較しても同じ尺度で生産物を評価できる特性を持っているのです。

ところで、以前のエントリで目標管理制度では定量的な目標に少しだけ定性的な目標を入れておく方が評価者にとっても評価の幅を持たせられるので好ましいと述べていました。

この定性的な目標を新たな基準として持つことでより適切に運用できるようになります。

アウトカムでの評価

ejje.weblio.jp

ここでのアウトカムは

「活動によってもたらされる効果」

として捉えます。

効果とは「働きかけによってもたらされる望ましい結果」の意がありますから、目標設定により取り組む業務活動によって望ましい結果を得られていれば成果として評価できることになります。

dictionary.goo.ne.jp

望ましい結果がある以上、現場は望ましくない状況であり、望ましい結果とのギャップを捉えることができることになります。つまり、活動による効果測定ができるようになるということです。

こうしたアウトカムによる目標設定は、活動による効果を望ましい結果として捉える必要があり、定量的な目標よりは活動により影響を与える対象と影響を与える事象の仮説検証をする必要があり、よりレベルの高い目標と位置付けることができます。

ロジカルシンキングなどの仮説検証型のスキルの育成機会を設けたい、自ら創出したい場合は、アウトカムでの評価を前提とした目標設定をすると良いでしょう。

追求されない進捗報告

進捗報告の場で突っ込まれたり追求される原因はほとんどが報告するエンジニア側にあるのです。別にプロジェクトマネージャやマネージャの立場だからってそちら側の目線で、というわけではありませんよ。

こんな状況を見た経験はありませんか。進捗報告の場で報告するエンジニアがしどろもどろになっていたり、プロジェクトマネージャと空中戦をしている場面を。

そんなつまらないことに時間をかけてしまうのは嫌ですよね。

先が見えているなら突っ込まれない

進捗報告の目的は、プロジェクトの進捗上の障害の有無をプロジェクトマネージャが知り、必要な対策を打つ判断をすることです。

進捗する作業はメンバが担っているので進捗状況はメンバが行います。

ここまではよろしい？

PMはプロジェクト全体の進捗の先行きのあたりをつけたいと思っています。なぜなら、先に述べたとおりプロジェクトの進捗上の障害があれば回避するのか除去するのか策を打つ判断をするのがPMの仕事だからです。

ですから、進捗報告をする際に先まで見通しが立っているなら正直、PMとしては

「予定どおりやっってて」

とお任せして、他に進捗上の障害がないかを探したいのです。

進捗で何を伝えるか

では、進捗を報告する担当としては何を伝えれば良いのでしょうか。

今使っている進捗報告のフォーマットやチケット管理システムのビューを思い出して見ましょう。どんなプロジェクトでも、計画に対し実績で差異が生じる可能性があるから進捗報告で進捗上の障害を見つけようとしていることを忘れないでください。

進捗報告で伝えなければならないことを３つあげてください。さてさっと言えましたか。

・実績
・予定
・課題

至極当然で「それで」という感じですが、これがベテランでもきっちりと押さえて報告している人は多くないのです。

進捗をどう伝えるか

実績、予定、課題を伝える、報告するのは、まあそうだとしてどう伝えれば突っ込まれないか。忙しい最中だし、変に突っ込まれて宿題なんてもらいたくないですし。

立場を変えて、PMならどんな進捗報告だったら、スルーするかを考えてみましょう。

・予定した作業は予定どおりに着手したかな
・いつ終わるか見通しは立っているのかな
・差異があるなら原因は何かな
・誰かのサポートが必要なのかな
・予定している作業は予定どおり着手できるのかな
・予定と違うことがわかったりしていないかな

と、こんなことを考えているものです。そうだとすれば、これを満足する情報を流せばいいわけです。

上記のことをカバーするのが、

・開始数/開始予定数
・完了数/完了予定数

なのですよね。それで差分があるのが課題で共有されるのです。

・完了予定と実績に関する差異の原因の掌握状況
・予定している対処
・プロジェクトに対するリクエスト
・後続作業への影響
・想定していた前提との差異 

 この予定している対処の裏付けである、差分の状況把握は割と重きを置きます。現状把握ができていないということは対処までどれだけ時間がかかるか見積もりもできないという事態ですから。

差分が生じたら、この状況把握を一人でどこまでやるつもりかを意思表示し、合意していくのが良いです。さらに悪化するようだったら、その前に割り込みをしてでも情報を。共有することで信頼感を得られますし。

 ということで、

・開始数/開始予定数
・完了数/完了予定数

 で報告するとして、課題があればPMが知りたい要点を押さえて報告しましょう。これが進捗報告で突っ込まれないエコシステムを作る基本です。