金融・COBOL・保守要員でエンジニアの成長は積むのか
新卒で入社したITベンダーでCOBOLを教え込まれ、金融機関にシステムの保守運用要員として送り込まれたら、一巻の終わり。「失敗は犯罪的行為」という金融機関のIT部門の文化にどっぷりつかり、要求された通りに保守作業などを続けていれば、ビジネスパーソンとして、技術者としての成長はおぼつかない。
「 一巻の終わり」なんだそうだ。一巻の終わりとはエンジニアとしての成長がおぼつかないのだそうだ。まあ、そういうエンジニアもいるのでしょうね。
この記事では、エンジニアの成長には失敗をすることで成長するのが前提らしいけれど、失敗をしなくていいならしない方がいいじゃない、と思うのだけれど。
それは挑戦をしないということではなくて、用意周到に準備をするとか、進むステップを刻んでピボットするとか、やり方を工夫して、という意味で。
なんとはなく、記事の背景には、
それなりの失敗を重ねること＝エンジニアの成長
という図式があるのではないかしら。
例に突っ込んでも記事で言いたいだろうと思われることと外れるかもしれないけれど、「失敗は犯罪的行為」の犯罪的という表現はともかく、金融、例えば銀行の勘定系で失敗、計算が間違っていたら犯罪というより、一預金者として預けておいたら気が気じゃないのではないか、と思うんですが。少なくとも嫌ですよ、そんな勘定系システムは。
失敗＝エンジニアの成長ではない
これまで「失敗をしよう」というテーマでエントリを書いてきているけれど、失敗の前に「小さな」としているのです。
あえて「小さな」としているのは、小さな失敗なら軌道修正してリカバリをできるようにするためです。
金融・COBOL・保守要員であれば行内NWに閉じられた閉鎖空間だから、新しい技術やツールを気軽に導入することはできないけれど、エンジニア自身の仕事の仕方の工夫などテクニック的なものやマインドセットのようなものまではいくら金融だとしても制御できないです。
小さな失敗と二度と繰り返したくない失敗と取り違えてはいけない
小さな失敗をしよう。なぜなら、エンジニアとしての改善を続けることに繋がるからだし、プロセスを見直す習慣にもなるからです。さらに、小さく進めることで期待する結果と期待していた結果を測定する習慣も身につくのです。
一方、二度と繰り返したくない失敗というのもあります。その経験で得られるものはリスクを識別する能力を学習することです。
まあ、トラウマになる経験ですね。
そんな経験はしなくでいいです。ほんと。身の危険を感じますよ。進退も。
失敗する機会、タイミング、程度があるのです。
金融・COBOL・保守要員は積むか
金融は技術的な閉鎖空間の意味合いがあるのでしょう。分散系であってもIE6とかjavaの古いバージョンが重荷になっていた時期があったものです。枯れている技術を採用する傾向が強いので、プロジェクト開始時点で安定しているバージョンを選びますから。
COBOLは古い言語だからシンボル的に挙げられていますけど、じゃあCはとかアセンブラとかはどうなんでしょう。分散系の言語の更新の方が早くないでしょうか。廃れてしまう言語を学ぶのもいいですが、使い切る前に新しい言語を学ぶようでは、使いこなすという習熟をどこで学べば良いのかしら。
保守要員ほど他人が書いたコードを読み取って新たな要件を追加することで影響を見切るのはそれなりの技量が必要だと思うのです。
金融・COBOL・保守要員で積まないエンジニア
経験から言えば、金融ほど標準化が進んでいる業種はないと思うのです。ある時期はどのベンダーも金融に一番優秀なエンジニアを配置していました。今は違うのでしょうか。
学ぶ情報、プラクティスは金融がいいのではないか、と。色々と継ぎ接ぎだらけなのかもしれませんが、そうしたプラクティスから自分なりに体系を抽象化することで得られるものは他のインダストリーにはないと思います。
言語も学習方法を学ぶことで対応力の幅が付いてきます。
多重請負であるとアクセスできる情報できる裁量は限られますが、それは他のインダストリーに行っても同じことです。
少しパラメータは違えど、超大型案件の中の時間が確保できるプロジェクトでプロジェクトマネジメントの体系的な学習と実務で使うツールを身につけた経験から言えば、このまま埋もれたくないとエンジニアが行動するだけで結果は付いてくるのです。
人月商売の裏でエンジニアが悶々と感じていることとアフターフォロー
一昨日のエントリに対してコメントが思っていた以上についたので珍しく読んでみたらアフターフォローというか、エントリでカバーできていなかったあたりの補足説明になるといいな、と思ったので、今日はこれで行きます。
こういったコメントは直接勉強会的な場でやり取りできると学びがあるんですよねぇ。
さて、
人月商売がエンジニアをすり潰す - 室長のひとりごち
- [SIer]
人月商売つらいなあ。有償稼働下げるとあかんというのは分かるんだけどそのせいで自分が成長できないと感じ辞めていく人を何人見たことか...
2017/04/08 18:15
自分がリーダ役であれば、仕事を分担する際にその仕事を通して何を経験できるか目標を設定することができます。多重下請けの場合、参画できるプロジェクトの適用技術、工程でしか目標を設定できないところに制約が出てしまいますが。
人月商売がエンジニアをすり潰す - 室長のひとりごち
世の中一括請負で出来る仕事だけではないし、松竹梅でもスキルを正しく評価できてるなら何ら問題ないだろ。人月商売は多重派遣で低スキル要員集めがちなのが問題なだけ。
2017/04/08 16:26
揚げ足を取りではありませんが、多重派遣というより二重派遣は法律で禁止されているので、多分、多重下請け（請負契約で）を指摘されているのだと思います。
多重下請け構造でも、契約の履行で必要な技術要素を他社から買うことで実現できるなら自社で育成する時間を買うという観点や技術特化している場合はありだと思います。問題は、過去のエントリでも書きましたが調達する側も売る側もプロジェクトの要素として必要なスキルセット、レベルを要求、供給できないマネージャ、営業、エンジニアが関わっていることかと思います。
プロジェクトの目的達成のためにプロジェクトチームとして必要なスキルセット、スキルレベルを棚上げした上で、需要側は請負契約にすることで供給側に履行責任を丸投げしたり、供給サイドも現場でよろしくやってくれと必要なスキルレベルに達していないエンジニアをドナドナするから現場が不幸になるんですよね。
人月商売がエンジニアをすり潰す - 室長のひとりごち
人月商売なんてそんなに技術更新いらないところの話じゃないの？コボルできる人募集〜〜とか、JAVAとデータベース使える人募集とか、そんな感じな気がする。
2017/04/08 14:47
技術更新が要らないところでも、供給されるjavaエンジニアがjavaをちゃんとしたjavaで書けるのかと突き詰めればどれだけいるかはご存知なのでは。
技術更新ではないと思っているのですが、製品のバージョンアップがマイナーだとしてもガラッと変わっているエンプラパッケージを時々見かけます。こうしたバージョンアップ対応プロジェクトもそうしたパッケージの差分を現行システムに影響を与えずに適用するの手間がかかりますよね。そうしたことを考えられるエンジニアがそこそこ必要なのですが、そうした考慮しなければならないことを考慮しつつ仕事に落とすことができるエンジニアがとにかく少ないのです。
まあ、そうしたことを考慮してプロジェクトの中に落としていくことができるエンジニアはアーキテクトの素質がある人かアーキテクトそのものかパッケージに特化したスペシャリスト（特化型アーキテクト）なんですけどね。
人月商売がエンジニアをすり潰す - 室長のひとりごち
人月商売は本当にダメだと思う。成果じゃなくて時間で稼ぐ形になるから、効率化や新技術とは無縁になる。
2017/04/08 13:16
人月商売はダメだ、については同意します。発注側がダメな点を挙げると、成果で見る技術を持っていないから、唯一判断できる時間だけで評価をするわけです。それしかメジャーメント持っていないから席に１人月座っていることを評価するのです。
受注側は、技術評価されないことを知っているから人月商売をすることがあります。毎日、プロジェクトルームに行きさえすれば、契約上の債務を履行していることになるのです。だから、その辺に歩いている人ならエンジニアの経験があってもなくてもドナドナするのです。で、現場で育ててくださいとか言い始める。
そこそこ経験をエンジニアが積むと時間で縛られていることを学習するので、プロジェクトで求められる成果をアウトプットしようとはせずに、指示された仕事の成果だけをアウトプットするオペレーションをするようになります。指示されたものしか作らないのは、時間に縛られているので効率を上げると余計に仕事をしなければならないのに給与などのリターンは変わらない（160時間内であれば）ので効率的に仕事をする必要が見出せないのですよね。
ましてや新技術なんてプロジェクトに関係ないですもの。心底、そのプロジェクトから抜け出したい、同じ言語は飽きたみたいな場合、抜けられる道具として新しい技術を習得して「新技術できるよ」と営業やマネージャにアピールする、と。
多くのエンジニアはそれさえもしませんけど。
人月商売がエンジニアをすり潰す - 室長のひとりごち
いつでも転職できるように入社当初から貪欲に勉強し続けてたら、今や無双状態で快適よ。業界の構造なだけで誰かが悪い訳ではないので、それを逆手に取らないと。
2017/04/08 10:26
転職する、しないに関わらず、転職するつもりで市場に自分の技術をレーティングしておくことはとても大事です。技術の成長を比較するのは今日と明日の自分ですが、外でどれだけで売れるエンジニアとしての価値を知っていることはとても情報を知っているだけでもアドバンテージがあります。
どんな環境下にあるとしても学習することを継続し続けるかどうかはエンジニア本人のマターです。自分で何ができるようになるかは対自分との絶対評価ですが、世の中に出れば相対評価です。技術的優位点が多ければ多いほど、市場価値は上がりますし、それは日々の技術習得で成長しているから実現できることです。
で、それを武器にしよう、と。
人月商売がエンジニアをすり潰す - 室長のひとりごち
孫請けより下のSIerは間違いなくそうなる。元請けや親密企業は新技術の教育に熱心だよ。
2017/04/08 06:32
おっしゃるとおり、一部の二次受けくらいまではその可能性はあります。ただ、いくら熱心に教育に力を入れているといっても、エンジニアが受けたい教育かどうかは、また別の話になってしまう…か。話が逸れました。
人月商売がエンジニアをすり潰す - 室長のひとりごち
"顧客からは今持っている技術で実現したいことがシステム化できてしまうなら、使う予定もない新しい技術の習得に対して魅力を感じるでしょうか。" わかってるじゃん。
2017/04/08 02:04
ありがとうございます。
人月商売がエンジニアをすり潰す - 室長のひとりごち
うーん。普通では？エンジニアに替えが効く（としたら）SIerはエンジニアを勉強させる必要がない。だって勉強させてすぐ辞められたら損じゃん。
2017/04/08 00:03
はい、普通の日常的に起きていることです。
ところで、エンジニアに変えが効くかどうか、は、プロジェクト側がプロジェクトに必要な技術要素、技術レベルをきちんと把握していて、あと業務知識も必要ならそれもですが、調達する社内外のエンジニアと紐付けしていれば、それが実現できます。
というか、それができていないプロジェクトは最初から積んでいます。だって、把握できていない時点で属人的にプロジェクトが遂行することが決まっちゃうんですから。
勉強させて辞められたら損だという点はエンジニアのマネージャの立場でしたらそのとおりです。良い観点です。仮に3ヶ月新人研修をするとして、4ヶ月目に辞められたら、新人エンジニアの給与※３倍くらいの費用をドブに捨てていることになります。20万が給与であるとしたら、180万くらいですね。180万の給与は将来現場に出て回収するための投資として行なっているので、投資先である新人エンジニアが辞めてしまったら投資した資金は回収できなくなるんですね。なので、教育に行かせることは将来の商売のためなんですね。
人月商売がエンジニアをすり潰す - 室長のひとりごち
エンジニアの技術更新を組織がやってもいいけど、認めるだけでも全然違うかな
2017/04/07 23:14
組織が技術更新をする場合、組織の都合（事業計画的な意味合い）が強くなりますね。今だとIoTとかAIとかでしょうか。それとエンジニアの関心は別ですけれど、それも話が逸れてしまいますね。
何にフォーカスするかは別として、稼働を下げてまで時間を割り当てるという経営判断ができる組織は人月商売だとしても延命するでしょうね。
人月商売がエンジニアをすり潰す - 室長のひとりごち
優秀なエンジニアなら、そんな働き方しないでしょう。エンジニアに見向きされてない中小企業で働きなさい。エンジニアが自分一人だから、神様のように振る舞えますよ。
2017/04/07 23:11
優秀なエンジニアは優秀なのでマネージャに引き上げられて売る側に回るのですよね。以下ループ、と。ただ、マネージャが嫌なエンジニアは、逃げ回って現場に居続けるか転職してしまうのですけど。
ところで、
エンジニアに見向きされてない中小企業で働きなさい。
が理解できなかったのですが、中小企業ならエンジニアは事業組織の中では間接部門だし本業ではないこともあるのと情報技術は誰もわからないから治外法権になるよ、ということかしら。
実際そうだと思うのですが、200人以下の中小企業を100社くらい回ったことがありますが、そういった企業のIT担当者は1人や2人が精一杯でほとんどが総務や営業と兼務のケースがほとんどでした。知っている限りでは専任は珍しいです。
それで神様になれますが、神様に些細ないこと全て問い合わせが来ますし、事業優先で現場が強いことも多くトラブルとものすごいクレームなんだそうです。そのあたりの運用を捌ければ神様も良いかもしれません。
人月商売がエンジニアをすり潰す - 室長のひとりごち
成果物を小出しにしておちんぎん貰いながらダラダラしてる奴もいるんで一方的には言えねえなあと思う
2017/04/07 14:20
ほんこれ。こういう仕事をするエンジニアに限って文句はいうし、品質はひどいし、納期は守らないし、言い訳ばかり。速攻で退場いただきたいものです。
人月商売がエンジニアをすり潰す - 室長のひとりごち
ロストテクノロジーの意味が微妙に違いそう。内容については同意
2017/04/07 23:41
あーすみません、気付いちゃいましたか。
書きながら「違うな」思いつつもタイムボックスの時間切れと確信犯でやらかしたのでした。
だってなのはが頭をよぎってしまったんですもの。
エンジニアがプレッシャーを討伐するには
前日のエントリは幾つかの場でネタとして話していたことを思い出して取り上げたのでした。「すり潰す」はたまたま前夜にピングドラムのOPを見かけた記憶が繋がったのでしょう。それより、思いの外のアクセスがあって、はてブがそこそこつくとこんな風に感じるんだーという経験が新鮮でした。
ブログは決めた時間の中で思いつくまま書いているので、場で話したことキーワードが後まで印象に残っているとそれで書けるか判断してパッとやってしまうので広く考えれば様々なケースが考えられるけれど、タイムボックス優先なのでカバー仕切れなくて気になることはまた別の機会に思い出せば書くこともあるでしょう。
言葉にすれば昨日のエントリも日常的に見かける「普通」のことで、誰もがそう感じたから「そうそう」とブクマしたのだと想像するのです。
それにつけても、育成を蔑ろにしているのか、育成自体をミッションと思っていないマネージャが多いことよ、と。そう思うのはエンジニア育成ネタを振ると同意する人が多いからなんですけどねー。
プレッシャーはどこから来る？
最近の記憶に残っているキーワードは仕事上の「プレッシャー」です。
プレッシャーというとワタシ的には
「プレッシャーは掛けられるものではなく自分で掛けてしまうもの」
だと思うのです。そして、そのプレッシャーも仕事の順番を間違えたり放置したりした結果に差し迫った納期に感じるケースが多いです。
他人、例えばマネージャとか顧客からはプレッシャーを受けないのかといえば、受けないです。納期が短ければスケジュールを調整したり他の作業と入れ替えたり作業を分担したりしてしまうので。
自滅系プレッシャーは手遅れ
作業の納期にプレッシャーを感じるのですから、そのプレッシャーの元から断てばいいのですが、自滅系（！）のプレッシャーはすでに手遅れですからそうした始める前のハックは使えないわけで。
目の前には納期と仕事がある環境下に置いてしまったのは自分なのです。さて、どうしようか、と。
どうしたらプレッシャーを無くせる？
プレッシャーを感じる環境に揃っているのは、差し迫った納期、見切れていない仕事、自分のスキルです。
プレッシャーは差し迫った納期と終わりがサイズを把握できていない仕事のボリュームとやり切れるか見切れていない自分のスキルが混じり合った心理的な現象です。
逆にいえば、いくら差し迫った納期だとしても自分のスキルがあれば（若しくは周りと分業しても構わないけれど）目の前の仕事をやりきれそうと見切れればプレッシャーを感じることはなくなります。
見積れる粒度に仕事を分解しよう
差し迫った納期までに「やれそう」と見切れればいいわけです。何を？仕事を、です。
ですからやることは仕事を自分で高い精度で作業を見積もるために分解をするのです。ここで留意しておきたいことは仔細に分解しすぎないということです。
エンジニアは放っておくと細々と見積もりし始め不必要なところまで深掘りしすぎるのでそうならないようにしなければなりません。
なぜ深掘りしすぎないようにしなければならないかは、自分が知っていることに人は興味を持つので、作業を見積もると言いながら実は興味を持った作業の実行にまで着手してしまうからです。
必要なことは「これならやれそう」と見切れることです。見切ることでプレッシャーを感じなくて良いようにするのですから。
人月商売がエンジニアをすり潰す
SIerなどに見られる人月商売はエンジニアをすり潰すのです。すり潰すのはエンジニアが持っている技術を、です。
では、なぜすり潰されてしまうのでしょうか。
人月商売の値段付け
人月商売は、エンジニアを月単位に値段をつけて売るビジネスモデルです。大体は、松竹梅のような３ランクなどのランク分けをして値付けします。
いい加減なSIerだと売りたい価格にエンジニアを紐付け、売った先に送り出してしまいます。真っ当な（？）SIerであれば、エンジニアを技術評価してランク付けをしなければ顧客からクレームが来るのでそうしたことが起きないようにするものですが…。
いづれにしても、月単位に値段がつけられているところがポイントです。
買う側の理屈
エンジニアの技術料に対して費用を支払う取引とは思っていません。人月商売は、月あたりの費用ですから1ヶ月に160時間（8時間勤務＊20日）の稼働ができる場合、160時間働いてもらうつもりで買っています。
これは買う側の仕事だけで160時間成果を出してね、ということです。
160時間稼働して起きること
顧客の業務で160時間稼働するということは、1ヶ月の稼働全てを顧客のために使うということです。今持っている技術を投入し続けるということです。
ところで、世の中の情報技術の進化は早いですね。さて、160時間という月単位で売られたエンジニアは一体いつどこで技術の更新を図ればいいのでしょうか。
例えば、SIerで技術研修を用意していたとしても、顧客からは今持っている技術で実現したいことがシステム化できてしまうなら、使う予定もない新しい技術の習得に対して魅力を感じるでしょうか。
エンジニアの善意に頼るのは間違い
エンジニアになったのだから、生涯勉強は続けなければ世の中の技術革新に遅れてしまうのだから、自ら率先して技術習得をするべきだ、みたいなことを言う人がいたら、
「お前はどのくらいそれに時間をかけているのか話してみろ」
と小1時間くらい問い詰めたいですね。
まあ、勝手に勉強会に行ったり、技術書を読んで新しい言語を習得したり、クラウドサービス環境で遊んで見たりするエンジニアも多少はいることはいますが、そうしたエンジニアは稀です。
それにそれはそのエンジニア本人の意思でやっていることでそれを仕事にフィードバックする義務もありません。
技術更新をさせなければスキルがロストテクノロジーになる
エンジニアの技術更新はエンジニアが組織のリソースであると位置づけるのであれば組織が対応すべき仕事です。
ですが、人月商売で月単位でエンジニアを売っているビジネスをやっているSIerには、エンジニアには大切な財産であると言いながら、160時間の稼働を下げると間接コストが増える要因になるので技術更新をするようなことはしませんし、やっても特定のエンジニアに対してだけ行うことで直接コストと間接コストの比率に大きな影響を与えないようにするのです。
結局、人月商売をしているようなSIerでエンジニアの技術更新を積極的にしない組織は、エンジニアの持っている技術は古く陳腐化し、ロストテクノロジー化するのです。
参画時はそこそこだったとしても、時間が経てば持っている技術は目減りし、技術そのものが擦り切れ空になってしまうのです。
口頭の補足が苛立たせる理由
あるチームの進捗報告を毎週聞いているのですが…でてくる情報は、荒いメッシュのガントチャートと遅れているカミナリ線しか情報が記載されていないのです。
まあ、他の他社のことなのでどうでもいいのですが、近々エンドユーザがキレるのではと楽しみに待っています。
報告では書いてあることを伝える
進捗報告はプロジェクトの公式文書です。ですから、報告内容に嘘、偽りがあってはいけません。なぜなら、報告を受けた側が誤った判断をしかねないからです。
第三者が検証できる情報を報告する場で求められる粒度に揃えてまとめ、伝えることが進捗報告の仕事です。
進捗報告をする際には、まずは、その報告書に書かれていることを補足せずにポイントのみ伝えれば良いです。
では伝えるポイントをどう選ぶかですが、計画どおりに進捗している箇所は計画を事前に伝えていれば不要です。報告を受ける側が意思決定の判断をする必要がある事項を進捗報告の記載のとおりに説明すればいいのです。それにより、受け手が判断するのです。
補足は悪手
よく見かけるし、ワタシもやらないとは言い切れませんが、書いていないことを自ら補足の説明をすることは悪手です。
補足説明は、報告内容に対し受け手が質問をしてきた際に、質問された報告内容の追加情報を付け加えるという形式で行うものです。
ただ、報告直前に入手した情報や緊急性のある情報であれば、公式には次回の報告で伝えることを前提に速報としてと断りを入れて伝えるのであれば受け手もそう認識して授受できるので良いでしょう。
なぜ口頭で補足をしてしまうか
ではどうして補足をしてしまうのでしょうか。
端的には報告するポイントを考えずに報告書を作っているところに真因があります。得てして、補足しようとする事項は、進捗に問題があることを報告する側が認識しており、それを負い目に感じ言葉にすることを避けるために報告書に記載しないことから生じます。
一方、進捗状況が芳しくないことも事実で、それをあるタイミングで伝えないとおおごとになった時点で最悪の事態を迎えようなら不信感を買いかねないことも承知しているのです。
だから、補足説明という形で逃げようとするのです。
そんなことをするくらいなら最初からさらっと課題があります、と書いておけばいいのです。大きな問題になるくらいなら危ないかも、とボールを投げてしまった方がいいのです。
「仕事が遅い…」と感じたときの対処方法
「仕事が思うように進まない」
「仕事の出来が遅くて全体のボトルネックになっている」
リーダかメンバかで受け止め方は違うけれど、予定していた通りに完了しないことは共通項です。どちらの立場にしても本来であれば計画した日付で作業を完了させたかったのですから。
メンバの立場であれば、そうした状況に陥ったときに自分を責めてしまいがちですが、そんなことをしても仕事は進捗しないという事実を認識して、1ミリでも進むことのために時間を使いましょう。ここはハートを折るような人生にとって深刻で重要なイベントではありません。たくさんある仕事の一つに過ぎません。
リーダの立場なら、ここで理詰めでメンバを追い込んでもこれまた同様に1ミリも進捗しません。返って、萎縮して交代してしまうかもしれません。
いずれの立場であっても実現したいことは仕事を進捗させることです。
リーダは停滞している原因を見つけなさい
進捗が滞っている当事者のメンバは、自分で嵌っているのでその原因を見つけることはできないのだ、ということを認識しましょう。自分で見つけられるくらいなら、相談に来るか自己解決していますから。
リーダは、仕事を進める上での進捗上の障害を見つけるのが最初に手をつけなければならない仕事です。
進捗上の障害は可視化されないケースが多いので、決めつけや思い込みは対処を間違えるので注意が必要です。
不慣れやスキルレベルが原因であれば
そうしたケースは仕事の理解度や習熟度にも関わるので、仕事の塊を他のメンバより小さくしましょう。例えば、１時間や２時間程度で終わる粒度まで仕事を分解します。
粒度を小さく分けた仕事は、小さな仕事ごとに完了した際の完成イメージを着手する前に説明しましょう。もちろん、小さな仕事をするメンバが理解しているかをメンバの言葉で説明してもらいましょう。ここで仕事を説明したこちら側も間違って指示していないか確認しましょう。
作業に入る時には、必ず、小さな仕事が終わったらアウトプットを確認して、完了条件を満たしていることを確認しましょう。この確認により成功体験を積み重ねることができます。
リーダが介入することなのか
プロジェクトマネージャでもリーダでもどちらの立場でもいいのですが、計画したとおりに作業が進捗して初めてプロジェクトが完了に近づきます。
プロジェクトは有期限性の活動ですから、期限までにプロジェクトの目的を実現しなければ失敗プロジェクトになってしまいます。
さて、リーダの役割から考えるとプロジェクトの進捗上の課題がある場合、それは誰が排除するのは素早い対処になるかを考えてください。
とはいえ、進捗上の作業を変わって作業をするほどリーダにリソースの余裕があるわけでもありませんし、それは最終手段です。メンバが一人ひとり期待する成果を出せる環境作りはリーダの仕事です。
リーダが助けることで助け合うチームに
リーダが直接介入し、それも、理詰めで責めたり、納期でプレッシャーを与えたりするような方法で対処するのではなく、障害を取り除く手助けやサポートであれば、周りのメンバも自分が進捗上の障害が発生した際には同じように少なくともリーダから支援されることをメッセージすることができます。
こうしたサポートがあるという環境作りは、メンバ同士が障害に突き当たった場合に情報を交換したり、解決案を出し合うようなチームの関係に移行を促すのです。
新任のプロジェクトマネージャに知ってほしいこと
4月3日からプロジェクトマネージャにアサインされ、プロジェクトをスタートしたプロジェクトマネージャも少なくないと思うのです。そのプロジェクトは全くの新規案件かもしれませんし、引き継いだ継続案件かもしれません。何れにしても、プロジェクトマネージャにアサインされそのロールを担うことになった新任のプロジェクトマネージャに知ってほしいことがあるのです。
心の引っ掛かりを見過ごさない
トラブルはいきなり発現するわけではありません。些細なこと、気にかけていなかったことがトラブルの原因になったり、誘発したりします。
日常の中で次々と判断をするのがプロジェクトマネージャの仕事です。その判断をする際に心の引っ掛かりを感じたら一旦立ち止まりましょう。
その心の引っ掛かりは、過去の痛い思い出やトラウマや横でトラブっていた事例などの記憶の断片から呼び起こされているシグナルです。
見過ごしてはいけません。丁寧に処理しましょう。
メンバとは対等に
プロジェクトマネージャもアーキテクトも一人のエンジニアも全てプロジェクトに必要なロールを担う人的リソースです。
誰ひとり欠かすことはできないのです。単に、そのプロジェクトでは、そのときのスキルとレベルから役割を分担しているに過ぎません。
エンジニアに対してリスペクトだとか尊敬だとかは感じる必要もありませんし、強制するものでもありません。そんな想いは重すぎるのでゴミ箱に捨ててしまってください。
必要なのは、ロールで定義した役割を全うすることです。そのためには対等に接することです。
対等に接するとは、エンジニアの特性を理解し、受け入れ、チームのルールでロールに応じた貢献をすることです。
体制図などでは上下や左右でツリー構造を描くため上下関係があるように思えますが、プロジェクトマネージャのミッションはエンジニアとプロジェクトで要求されている成果を実現することです。
成果のあるアクティビティを
プロジェクトはプロジェクトとしての目的を達成するために活動します。全てのアクティビティは、最終的にはプロジェクトの目的に収斂するために行われるものです。
ですから、アクティビティの成果がない活動はする必要がありません。予定されているからといって会議の目的を明確にせずに会議を開いてはいけません。エンジニアを動かすのであれば、投下した分だけの成果を確保してください。
チームのルールを増やさない
プロジェクトチームのエンジニア全員が守らなければならないルールを最小限に設けましょう。そのルールを一番に守らなければならないのはプロジェクトマネージャです。
プロジェクトマネージャが守らないルールは誰ひとり守りません。エンジニア全員が守らなければならないルールが必要になったら、作業プロセスの中に組み込んでください。そうすることでルールを減らすことができます。
笑顔はコスト０
笑顔はコストゼロです。何もヘラヘラして仕事をしようとかいうわけではありません。要件や仕様を考え方の違いで議論するのは激突しても構いません。というか、そうしたエンジニアとしての念持や主義主張は激しくぶつかってもいいのです。
ただ、それが終わって決めるものも決めたら笑顔でランチでも行きましょう。仕事です。趣味じゃないんですから、笑顔で。
