エンジニアがプレッシャーを討伐するには

前日のエントリは幾つかの場でネタとして話していたことを思い出して取り上げたのでした。「すり潰す」はたまたま前夜にピングドラムのOPを見かけた記憶が繋がったのでしょう。それより、思いの外のアクセスがあって、はてブがそこそこつくとこんな風に感じるんだーという経験が新鮮でした。

ブログは決めた時間の中で思いつくまま書いているので、場で話したことキーワードが後まで印象に残っているとそれで書けるか判断してパッとやってしまうので広く考えれば様々なケースが考えられるけれど、タイムボックス優先なのでカバー仕切れなくて気になることはまた別の機会に思い出せば書くこともあるでしょう。

言葉にすれば昨日のエントリも日常的に見かける「普通」のことで、誰もがそう感じたから「そうそう」とブクマしたのだと想像するのです。

それにつけても、育成を蔑ろにしているのか、育成自体をミッションと思っていないマネージャが多いことよ、と。そう思うのはエンジニア育成ネタを振ると同意する人が多いからなんですけどねー。

プレッシャーはどこから来る？

最近の記憶に残っているキーワードは仕事上の「プレッシャー」です。

プレッシャーというとワタシ的には

「プレッシャーは掛けられるものではなく自分で掛けてしまうもの」

だと思うのです。そして、そのプレッシャーも仕事の順番を間違えたり放置したりした結果に差し迫った納期に感じるケースが多いです。

他人、例えばマネージャとか顧客からはプレッシャーを受けないのかといえば、受けないです。納期が短ければスケジュールを調整したり他の作業と入れ替えたり作業を分担したりしてしまうので。

自滅系プレッシャーは手遅れ

作業の納期にプレッシャーを感じるのですから、そのプレッシャーの元から断てばいいのですが、自滅系（！）のプレッシャーはすでに手遅れですからそうした始める前のハックは使えないわけで。

目の前には納期と仕事がある環境下に置いてしまったのは自分なのです。さて、どうしようか、と。

どうしたらプレッシャーを無くせる？

プレッシャーを感じる環境に揃っているのは、差し迫った納期、見切れていない仕事、自分のスキルです。

プレッシャーは差し迫った納期と終わりがサイズを把握できていない仕事のボリュームとやり切れるか見切れていない自分のスキルが混じり合った心理的な現象です。

逆にいえば、いくら差し迫った納期だとしても自分のスキルがあれば（若しくは周りと分業しても構わないけれど）目の前の仕事をやりきれそうと見切れればプレッシャーを感じることはなくなります。

見積れる粒度に仕事を分解しよう

差し迫った納期までに「やれそう」と見切れればいいわけです。何を？仕事を、です。

ですからやることは仕事を自分で高い精度で作業を見積もるために分解をするのです。ここで留意しておきたいことは仔細に分解しすぎないということです。

エンジニアは放っておくと細々と見積もりし始め不必要なところまで深掘りしすぎるのでそうならないようにしなければなりません。

なぜ深掘りしすぎないようにしなければならないかは、自分が知っていることに人は興味を持つので、作業を見積もると言いながら実は興味を持った作業の実行にまで着手してしまうからです。

必要なことは「これならやれそう」と見切れることです。見切ることでプレッシャーを感じなくて良いようにするのですから。

人月商売がエンジニアをすり潰す

SIerなどに見られる人月商売はエンジニアをすり潰すのです。すり潰すのはエンジニアが持っている技術を、です。

では、なぜすり潰されてしまうのでしょうか。

人月商売の値段付け

人月商売は、エンジニアを月単位に値段をつけて売るビジネスモデルです。大体は、松竹梅のような３ランクなどのランク分けをして値付けします。

いい加減なSIerだと売りたい価格にエンジニアを紐付け、売った先に送り出してしまいます。真っ当な（？）SIerであれば、エンジニアを技術評価してランク付けをしなければ顧客からクレームが来るのでそうしたことが起きないようにするものですが…。

いづれにしても、月単位に値段がつけられているところがポイントです。

買う側の理屈

エンジニアの技術料に対して費用を支払う取引とは思っていません。人月商売は、月あたりの費用ですから1ヶ月に160時間（8時間勤務＊20日）の稼働ができる場合、160時間働いてもらうつもりで買っています。

これは買う側の仕事だけで160時間成果を出してね、ということです。

160時間稼働して起きること

顧客の業務で160時間稼働するということは、1ヶ月の稼働全てを顧客のために使うということです。今持っている技術を投入し続けるということです。

ところで、世の中の情報技術の進化は早いですね。さて、160時間という月単位で売られたエンジニアは一体いつどこで技術の更新を図ればいいのでしょうか。

例えば、SIerで技術研修を用意していたとしても、顧客からは今持っている技術で実現したいことがシステム化できてしまうなら、使う予定もない新しい技術の習得に対して魅力を感じるでしょうか。

エンジニアの善意に頼るのは間違い

エンジニアになったのだから、生涯勉強は続けなければ世の中の技術革新に遅れてしまうのだから、自ら率先して技術習得をするべきだ、みたいなことを言う人がいたら、

「お前はどのくらいそれに時間をかけているのか話してみろ」

と小1時間くらい問い詰めたいですね。

まあ、勝手に勉強会に行ったり、技術書を読んで新しい言語を習得したり、クラウドサービス環境で遊んで見たりするエンジニアも多少はいることはいますが、そうしたエンジニアは稀です。

それにそれはそのエンジニア本人の意思でやっていることでそれを仕事にフィードバックする義務もありません。

技術更新をさせなければスキルがロストテクノロジーになる

エンジニアの技術更新はエンジニアが組織のリソースであると位置づけるのであれば組織が対応すべき仕事です。

ですが、人月商売で月単位でエンジニアを売っているビジネスをやっているSIerには、エンジニアには大切な財産であると言いながら、160時間の稼働を下げると間接コストが増える要因になるので技術更新をするようなことはしませんし、やっても特定のエンジニアに対してだけ行うことで直接コストと間接コストの比率に大きな影響を与えないようにするのです。

結局、人月商売をしているようなSIerでエンジニアの技術更新を積極的にしない組織は、エンジニアの持っている技術は古く陳腐化し、ロストテクノロジー化するのです。

参画時はそこそこだったとしても、時間が経てば持っている技術は目減りし、技術そのものが擦り切れ空になってしまうのです。

口頭の補足が苛立たせる理由

あるチームの進捗報告を毎週聞いているのですが…でてくる情報は、荒いメッシュのガントチャートと遅れているカミナリ線しか情報が記載されていないのです。

まあ、他の他社のことなのでどうでもいいのですが、近々エンドユーザがキレるのではと楽しみに待っています。

報告では書いてあることを伝える

進捗報告はプロジェクトの公式文書です。ですから、報告内容に嘘、偽りがあってはいけません。なぜなら、報告を受けた側が誤った判断をしかねないからです。

第三者が検証できる情報を報告する場で求められる粒度に揃えてまとめ、伝えることが進捗報告の仕事です。

進捗報告をする際には、まずは、その報告書に書かれていることを補足せずにポイントのみ伝えれば良いです。

では伝えるポイントをどう選ぶかですが、計画どおりに進捗している箇所は計画を事前に伝えていれば不要です。報告を受ける側が意思決定の判断をする必要がある事項を進捗報告の記載のとおりに説明すればいいのです。それにより、受け手が判断するのです。

補足は悪手

よく見かけるし、ワタシもやらないとは言い切れませんが、書いていないことを自ら補足の説明をすることは悪手です。

補足説明は、報告内容に対し受け手が質問をしてきた際に、質問された報告内容の追加情報を付け加えるという形式で行うものです。

ただ、報告直前に入手した情報や緊急性のある情報であれば、公式には次回の報告で伝えることを前提に速報としてと断りを入れて伝えるのであれば受け手もそう認識して授受できるので良いでしょう。

なぜ口頭で補足をしてしまうか

ではどうして補足をしてしまうのでしょうか。

端的には報告するポイントを考えずに報告書を作っているところに真因があります。得てして、補足しようとする事項は、進捗に問題があることを報告する側が認識しており、それを負い目に感じ言葉にすることを避けるために報告書に記載しないことから生じます。

一方、進捗状況が芳しくないことも事実で、それをあるタイミングで伝えないとおおごとになった時点で最悪の事態を迎えようなら不信感を買いかねないことも承知しているのです。

だから、補足説明という形で逃げようとするのです。

そんなことをするくらいなら最初からさらっと課題があります、と書いておけばいいのです。大きな問題になるくらいなら危ないかも、とボールを投げてしまった方がいいのです。

「仕事が遅い…」と感じたときの対処方法

「仕事が思うように進まない」
「仕事の出来が遅くて全体のボトルネックになっている」

 リーダかメンバかで受け止め方は違うけれど、予定していた通りに完了しないことは共通項です。どちらの立場にしても本来であれば計画した日付で作業を完了させたかったのですから。

メンバの立場であれば、そうした状況に陥ったときに自分を責めてしまいがちですが、そんなことをしても仕事は進捗しないという事実を認識して、1ミリでも進むことのために時間を使いましょう。ここはハートを折るような人生にとって深刻で重要なイベントではありません。たくさんある仕事の一つに過ぎません。

リーダの立場なら、ここで理詰めでメンバを追い込んでもこれまた同様に1ミリも進捗しません。返って、萎縮して交代してしまうかもしれません。

いずれの立場であっても実現したいことは仕事を進捗させることです。

リーダは停滞している原因を見つけなさい

進捗が滞っている当事者のメンバは、自分で嵌っているのでその原因を見つけることはできないのだ、ということを認識しましょう。自分で見つけられるくらいなら、相談に来るか自己解決していますから。

リーダは、仕事を進める上での進捗上の障害を見つけるのが最初に手をつけなければならない仕事です。

進捗上の障害は可視化されないケースが多いので、決めつけや思い込みは対処を間違えるので注意が必要です。

不慣れやスキルレベルが原因であれば

そうしたケースは仕事の理解度や習熟度にも関わるので、仕事の塊を他のメンバより小さくしましょう。例えば、１時間や２時間程度で終わる粒度まで仕事を分解します。

粒度を小さく分けた仕事は、小さな仕事ごとに完了した際の完成イメージを着手する前に説明しましょう。もちろん、小さな仕事をするメンバが理解しているかをメンバの言葉で説明してもらいましょう。ここで仕事を説明したこちら側も間違って指示していないか確認しましょう。

作業に入る時には、必ず、小さな仕事が終わったらアウトプットを確認して、完了条件を満たしていることを確認しましょう。この確認により成功体験を積み重ねることができます。

リーダが介入することなのか

プロジェクトマネージャでもリーダでもどちらの立場でもいいのですが、計画したとおりに作業が進捗して初めてプロジェクトが完了に近づきます。

プロジェクトは有期限性の活動ですから、期限までにプロジェクトの目的を実現しなければ失敗プロジェクトになってしまいます。

さて、リーダの役割から考えるとプロジェクトの進捗上の課題がある場合、それは誰が排除するのは素早い対処になるかを考えてください。

とはいえ、進捗上の作業を変わって作業をするほどリーダにリソースの余裕があるわけでもありませんし、それは最終手段です。メンバが一人ひとり期待する成果を出せる環境作りはリーダの仕事です。

リーダが助けることで助け合うチームに

リーダが直接介入し、それも、理詰めで責めたり、納期でプレッシャーを与えたりするような方法で対処するのではなく、障害を取り除く手助けやサポートであれば、周りのメンバも自分が進捗上の障害が発生した際には同じように少なくともリーダから支援されることをメッセージすることができます。

こうしたサポートがあるという環境作りは、メンバ同士が障害に突き当たった場合に情報を交換したり、解決案を出し合うようなチームの関係に移行を促すのです。

新任のプロジェクトマネージャに知ってほしいこと

4月3日からプロジェクトマネージャにアサインされ、プロジェクトをスタートしたプロジェクトマネージャも少なくないと思うのです。そのプロジェクトは全くの新規案件かもしれませんし、引き継いだ継続案件かもしれません。何れにしても、プロジェクトマネージャにアサインされそのロールを担うことになった新任のプロジェクトマネージャに知ってほしいことがあるのです。

心の引っ掛かりを見過ごさない

トラブルはいきなり発現するわけではありません。些細なこと、気にかけていなかったことがトラブルの原因になったり、誘発したりします。

日常の中で次々と判断をするのがプロジェクトマネージャの仕事です。その判断をする際に心の引っ掛かりを感じたら一旦立ち止まりましょう。

その心の引っ掛かりは、過去の痛い思い出やトラウマや横でトラブっていた事例などの記憶の断片から呼び起こされているシグナルです。

見過ごしてはいけません。丁寧に処理しましょう。

メンバとは対等に

プロジェクトマネージャもアーキテクトも一人のエンジニアも全てプロジェクトに必要なロールを担う人的リソースです。

誰ひとり欠かすことはできないのです。単に、そのプロジェクトでは、そのときのスキルとレベルから役割を分担しているに過ぎません。

エンジニアに対してリスペクトだとか尊敬だとかは感じる必要もありませんし、強制するものでもありません。そんな想いは重すぎるのでゴミ箱に捨ててしまってください。

必要なのは、ロールで定義した役割を全うすることです。そのためには対等に接することです。

対等に接するとは、エンジニアの特性を理解し、受け入れ、チームのルールでロールに応じた貢献をすることです。

体制図などでは上下や左右でツリー構造を描くため上下関係があるように思えますが、プロジェクトマネージャのミッションはエンジニアとプロジェクトで要求されている成果を実現することです。

成果のあるアクティビティを

プロジェクトはプロジェクトとしての目的を達成するために活動します。全てのアクティビティは、最終的にはプロジェクトの目的に収斂するために行われるものです。

ですから、アクティビティの成果がない活動はする必要がありません。予定されているからといって会議の目的を明確にせずに会議を開いてはいけません。エンジニアを動かすのであれば、投下した分だけの成果を確保してください。

チームのルールを増やさない

プロジェクトチームのエンジニア全員が守らなければならないルールを最小限に設けましょう。そのルールを一番に守らなければならないのはプロジェクトマネージャです。

プロジェクトマネージャが守らないルールは誰ひとり守りません。エンジニア全員が守らなければならないルールが必要になったら、作業プロセスの中に組み込んでください。そうすることでルールを減らすことができます。

笑顔はコスト０

笑顔はコストゼロです。何もヘラヘラして仕事をしようとかいうわけではありません。要件や仕様を考え方の違いで議論するのは激突しても構いません。というか、そうしたエンジニアとしての念持や主義主張は激しくぶつかってもいいのです。

ただ、それが終わって決めるものも決めたら笑顔でランチでも行きましょう。仕事です。趣味じゃないんですから、笑顔で。

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

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

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

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

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

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

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

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

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

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

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

作業を見切る

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

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

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

ゴールを設定する

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

メールのダメなところ

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

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

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

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

メールを減らす活動例

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

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

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

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

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

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

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