貧困プロジェクト、チームは赤字ラインから浮上せず

プロジェクトは、プロジェクトの目的を達成するために必要なリソースの何か1つが揃わなければ、足らないリソースを補填する別のリソースでカバーできなければ必ず失敗する。人的リソースが不足していれば、不足する人的リソース分の時間を多く消費する。人的リソースの面積(人員*期間)は理論的には変わらないが完成時期が延伸されるのでビジネス的には機会を逸してしまう。

プロジェクトチームの中を見れは、チームの中の必要なリソースが欠員しているのだから、チームとしてのスキルセットも応じて欠落している。目標達成のキーとなるスキルとスキルレベルが確保できていれば良いが、キーとなるスキルを持つリソースがチームとして持ち合わせていなければ、プロジェクトの目的の達成に対するマイナスのリスクが高まる。言い換えれば、キースキルの部分を持ち合わせていないチームが、持っているスキルだけで充足しようとするので要件を実現できないリスクが高まる。

同じ様にリソースとしての時間を確保できないプロジェクトは、無理なスケジュールを納期から作らなければならないため、実現可能性が低い日程を自ら組んでリスクを高めてしまう。

人的リソースにしろ、時間にしろ、コストにしろ、プロジェクトの目的を達成するためのリソースが欠損すれば、リスクは高まるし、全てがプロジェクトを遂行するエンジニアにしわ寄せすることになる。

エンジニアに限らず多くの人は自分に甘いので、余裕があり過ぎる計画は計画いっぱいまで使ってしまうシンドロームにたやすく陥ってしまうが、リソースが欠けているプロジェクトでは余裕自体が存在しない。

チームに余裕があり、リソースが欠けているという事実の認識をできるならば、不足しているリソースをカバーする代替手段や生産方式の置き換えなどを考えたり、試行することができる。ただ、それをするための予算的裏付けが必要となる。

これは、予算があれば大体のリソースの欠損についての対策ができることを物語っている。つまり、プロジェクトが貧困、貧乏では上手くいかないということだ。

予算さえ確保できていれば、プロジェクトの時間がカットされたとしても高いギャラで優秀なエンジニアを調達することでカットされた部分のある程度の回復は可能であるし、新しいか早い生産手段として自動化の措置を予算として措置すればそっちの面からも対応する可能性を高められる。

何より、チームのメンバはお金で対処するという選択肢を持つと、心理的な余裕が生まれ、想像力を働かせて生産手段や手法で対処を考えられる様になる。

プロジェクトでは不可欠な予算を確保できない貧困プロジェクトは、最初から成功しないし、赤字ラインの水面下から浮上することはありえない。

  

 

 

 

Yellow Submarine

Yellow Submarine

 

 

エンジニアはマネージャに話を聴いて欲しがっている

気がかりなメンバが二人いた。一人は中堅どころのエンジニアである。もう一人は中堅に入ったばかりで本来であれば自分で独り立ちして欲しいエンジニアである。

気掛かりなこととは、担当するプロジェクトの業務に流されて1年間終わった後に経験知しか残らないことである。

エンジニアに必要なスキルは、基礎スキルと技術スキルだ。

基礎スキルは、定性的なスキルかもしれない。なぜなら、エンジニア自身の仕事の仕方に深く結び付いているからだ。

基礎スキルには、仕事をやり切るとか意思伝達とか交渉とか後進育成などが含まれ、技術スキルには方法論、手法、言語、技術の適用などが含まれる。

業務による経験知の習得ではよくないのは、基礎スキルにしても技術スキルにしても体験したことが本人の内面で、それも成功体験だけが強調して記録される。

その経験知に足らないものが術や手法、それと方法論などである。

業務に流されてしまうと、その不足部分を欠いたまま1年歳を取ってしまい、それが繰り返されると外からプラクティスやパターンを取り入れることができないエンジニアが出来上がってしまう。

これが気掛かりなのだ。

目標管理制度を導入している組織では、目標設定、中間、評価と最低3回の場を持つ。この3回が曲者だ。なぜなら、目標の進捗から軌道修正をさせるタイミングが中間の1回しかチャンスがないためだ。

目標設定時から中間までに目標の進捗に手がついていないエンジニアが中間の1回の機会で軌道修正できるか。できるわけがない。できるなら最初から手をつけているはずだ。と言うことは、手法や方法論を身につけることの大切さを伝えるには回数が必要なのだ。

回数を増やすのはどうしたらいいか。

例えば目標設定時、中間、評価でそれぞれ1時間をミーティングに使っていたら、エンジニアの目標に年間3時間しか使っていないことになる。そのうち、軌道修正のタイミングは1時間しか取れていない。1時間で修正できないなら、時間を増やすしかないがただ増やせはいいと言う問題ではない。必要なのは繰り返し伝えることと取り組んでいなければその障害を取り除くことが必要になる。

さて、この要件は何かに似ていないだろうか。

そう、進捗管理である。ただ、作業の進捗管理と違うのは、やらなかったら評価にプラスにならないと言うことだけだ。もちろん、業務はプロジェクトで進捗管理しているので計画と実績から様々なアクションが取られる。

それでどうしたかというと、アジリティを働かせた。

回数を増やす。ただし、時間は短く。

毎週1回、15分時間を取るようにスケジュールの枠を複数作り、部下達は自分の都合の良いコマに自分からアサイメントする。

始めてみると、最初はいきなり目標管理の進捗状況を尋ねられるから、中間でもないのにと後ろ向きな反応をするが、2−3回やってみると部下からあれこれ聴いて欲しいと話し出すようになった。

この経験から得られたことは、部下は自分のことを話したがっていたということだ。

話してくれるようになったのは、マネージャが本気で部下達の目標達成を支援するためにマネージャの時間を使う意思表示をしたからではないだろうか。

もちろん、エンジニア達が何も手をつけていなければ、耳が痛いことを言われるかもしれない。たとえそれを言われても、それを上回るものが得られると気づいたのかもしれない。

マネージャが本気で動いていると受け入れられたから、部下達は本音を聴いて欲しいと思う様になったのだろう。

部下の、エンジニア達の目標達成は組織の目標達成の主要で大きなポーションだから、マネージャがメンバにリソースを使うこという意思表示を見える形で実行することが伝われば良いのだ。

 

 

愚痴をいうエンジニアより悩みを話すエンジニアと飲みたい

あるコミュニティの後、習慣的に飲みに行く。中堅どころや若手エンジニアもいるのでその層のエンジニアが何を考えているのかを聞ければいいと思っている。実際は中堅も後半のエンジニアやシニア層のエンジニアが組織に対する愚痴や自分の不甲斐なさを自虐的に吐露し始める。

多分、誰でも同じなのだろうが、仕事が思うように上手くいかなかったり、評価をされなかったりして不満の一つや二つはあってもおかしくはないだろう。今ここにもっともらしく書いている自分だって、この年齢になっても「なんだかな」と思うことは組織に対してもあるし、仕事にだってある。

愚痴は何も進まない。

それを聞いた周りは気分は聞き流していたとしても聞く前よりは気持ちのレベルは下がるし、それを話す当人はスッキリするわけがない。嫌なことを言語化することで自分の気持ちを可視化できるようにしてしまうのだから。

でも、悩みを聞いてもらうのであればそれはいいと思う。

悩みは話すプロセスを経ることで悩み自体が整理され、内心想定していた結論の輪郭を構築するからだ。

自分ではどうしていいか迷っていることを聞いてもらったら、なんとなく解決していた、と言うやつだ。これも誰もが経験していることなのではないか。

悩みを話すことは、本人は悩みを共有することで解決する手がかりを得られる可能性があるし、悩みを相談された方は一助となることができる。酔っていると断定や言い過ぎるケーズが多いので一概には言えないが、それでも、愚痴よりは100万倍いい。

では飲みに行くのをやめて仕舞えばいいじゃないかと思うかもしれないけれど、新規参加者がいると、やはりコミュニティの古参メンバと相互に名前を呼び、会話して欲しいと思うところもある。あと、コミュニティ活動がテーマだけでいっぱいでその中でパスを作るのは限りがあると言う事情もある。

少し話のネタ、テーマで縛って話させる方がいいのかもしれない。そんなことを思う週末前の金曜日。

TGIF

 

 

わかばちゃんと学ぶ Git使い方入門

わかばちゃんと学ぶ Git使い方入門

 

 

調達 エスケープ・ベロシティ~キャズムを埋める成長戦略

エスケープ・ベロシティ~キャズムを埋める成長戦略

エスケープ・ベロシティ~キャズムを埋める成長戦略

イライラとアジャイルな組織を目指して

週次でミーティングを持っている。いわゆる進捗会議ではなく、プロジェクトの付帯的な活動やその他の活動の状況を聞く。ああ、活動状況を聞いているのだから進捗会議と同じではないか。ただ、違うのはマネージャからの周知のようなものは極力しない。そういったものはchatツールで済ませてしまう。そのほうがログが残るのでメンバが忘れていても遡れて良い。何より、メンバを集めて1時間使うなら、メンバが使った方が良い。

ある回で、シニアのエンジニアが今日は2件話したいと言った。ちょっと言い方がいつもと違うな、と感じた。自分の意見を持っているし実力もあるエンジニアだが、周りに合わせる柔軟性も持っている。そのエンジニアが、である。

実は、その回の前日にそのエンジニアが他組織と某案件で場を持つことを知っていた。更に言えば、前日にその他組織の担当と会話をしていて、担当が案件をどう考えているかを知っていた。まあ、人が悪いという人もいるかもしれないが、マネージャとは清濁を合わせ飲む混んでおくものであるし、情報源を捕まえておくのが仕事だ。

話を戻して、普段とは違った印象を持ったエンジニアは冒頭からイライラとしている様子が伺える。もともと、話のファシリティはもう少し技術を身につけると更に良くなると思っているが、それはまた別の話だ。それでイラつているから話を始めると2つあったどっちの話から始めようとするのか分別せずに話し始めるので、どちらから話すのか、どんな内容なのかと問いかけるとイライラは更に募るのがわかる。

1件は某案件の進捗、2件めは他組織との新たな仕組みを作りたいという。

1件目の進捗なら(任せているので)いらないというと、イライラに不機嫌を重ねる。これは何かあると思って少し聞いてみると、様々な制約条件や前提条件の中で厳しいスケジュールでやっているので無茶な段取りで進めざるを得ないと。

どうしてそうなったかを聞くと準備期間に別のタスクを振っていたのがだだかぶりしていたからだとイライラ度も最高潮を迎えた。

プロジェクトや活動にはゴール設定が必要だ。それに向かって仕事をするからだ。でも、限られたリソースでできることとできないことがある。それと、自分が考えられる段取りの組み方や進め方は過去の成功体験の焼き直しでしかない。それを知っていれば、行き詰まったとき、周りのメンバとブレストをするのが打開策となることが多い。

ブレストでなくても、コーヒーでも飲みながら雑談しながら話すだけでキーワードを拾えることが少なくない。つまり、一人で悶々とイライラしながら自家発電するより、周りを巻き込んでしまう方が生産的なのだ。たとえ仕事を分担しているとしても、そのためにチームがある。

あるものはなんでも使う。

確かにエンジニアは難しい活動を担当している。だからこそ、周りのリソースを少しずつ借りて進めた方が良いのだ。それは中堅や若手のエンジニアに難しい活動をするときのリニアでリアルな仕事のやり方を教えることになるのだから。

その回は終わる時間の5分前に他のメンバに出てもらい、1on1の形で諭すように話しかける。イライラしている原因に自分(そのエンジニア自身)も含まれていること、それを踏まえた上で、自分の感情と切り離してことを見ないと視覚が狭くなり、イライラするループに陥ってしまうこと。

多分、届かないのだろうけれど、それを伝えるのもマネージャの仕事である。

 

 

 

調達 誰からも「気がきく」と言われる45の習慣

 

誰からも「気がきく」と言われる45の習慣

誰からも「気がきく」と言われる45の習慣

 

 

育成への期待は半分で気長に

中堅になりたてのエンジニアがまとめた資料を見る機会があった。レビューというようなものではなく「できた資料を確認してください」程度のもの。できれば、そんなこともしないで次工程に回してしまいたいが、どうも気がかりなことがあったので時間をとることに。

気がかりなこととは、同じように作成してもらった資料を見て、アレコレと聞いてみたら資料上での判断が曖昧だったり、裏付けがなかったことがあった。資料の性格上、それは拙い。いや、エンジニアが手掛ける成果に曖昧さがあってはいけないだろう、と思った。

その資料を作成する際に、ごく稀に国内のエンジニアだと知らないだろうという情報が紛れ込んでいる場合がある。今は便利な時代でインターネットがあるから国外のことでも(ネットにアップされていれば)どうにかこうにかたどり着くことができる。

言い換えれば、製品のホワイトペーパーのappendixを探し続けるようなものだ。そこまで到達しなければ、まとめた資料の信憑性はなくなってしまう。エンジニアとしてそこまで調べ、裏付けを取らなければならない。もし、そこをわからないままで資料を作ってしまうと、その報告を受けた人は裏付けがあやふやな資料の情報を鵜呑みにしてしまう。将来、鵜呑みにしてしまったことがトラブルを引き起こしかねないとは言い切れない。だから、資料を見たのだが。

 

「資料のN番目の調査結果は」
「これこれです」
「そう、それ。えっと、この点は調べた」
「そこまで調べてません」
「そーか。でも、この点まで調べないと根拠にならないよ」
「…」
「調べた方がいいんじゃなかな」
「はい」
「こっちのこれは」
「初めて見たものがありました」

「へー、なに。うーん、それ何」
「よくわかりません」
「それでその評価なんだ」
「…」
「こっちのこれの資料の調査は実はわかりません、とは言えないじゃん。もう少し調べないとさ」
「調べたんですがそれが見当たらなくて」

「そーか、でも調べて調査した根拠はとっておかないと」
「…」
「調査が曖昧なままで結果を渡してしまったら、その調査をもらった人は間違って判断してしまうからね。根拠を持っておこうね。それでも間違っていたら訂正すればいいからさ。でも、曖昧なままで渡してしまうとあとで説明に困るからさ」

 

これをきっかけにこの仕事の観点を覚えてくれればいい経験になると思うのだが。まあ、育成への期待は半分で気長に。