チームを止めるのは価値観をupdateしないエンジニア

エンジニアは経験を重ねて複雑な技術を組み合わせて問題を解決する。それがお仕事である。であるから、当然経験を積み続けなければ、新しい問題を解決できないときがやってくる。そうした新しい問題は、足音を立てず、そっと後ろに佇み、エンジニアが経験を積むことをやめたとき、そのエンジニアに憑依する。

 

エンジニアは経験で価値観を作り上げる。それは、仕事を手渡されてから自分で完成したと告げるまでの間に、エンジニア自身で行った意思決定の集成のようなものだ。思うように行かなかったことや思いかけず上手くいった結果に繋がった、そうしようと決めたときの気持ちの牙城だ。

 

その価値観の中身は、エンジニアの経験の証のようなものか、はたまた、単なる思い込みでしかない。エンジニアとして経験したいことは山ほどあるが、自分は一人しかいないから、最初叶わない願いだ。

 

それをやめてしまうということは、新しい問題を解決できる方法を取り入れないということでしかなく、目の前の年下のエンジニアの価値観を理解も共感もできなくなってしまう。

 

プロジェクトのチームの中で、それ、つまり、経験で価値観を作り続けることをやめたエンジニアは障害にしかならない。少なくともプロジェクトチームの中で起きる新しい課題を解決する技術を更新しなのだから、そのエンジニアの持っているだけのプアな価値観で解決しようとする。そのとき、チームを止めるのは、経験で価値観を作ることをやめたエンジニアなのである。

 

困ったことにこうしたエンジニアにはこのくらいの年齢というものがない。管理ばかりやりたがるエンジニアもどきには潜在的に多そうであるが、そうしたエンジニアはどの年代にもいるから注意が必要である。

 

大概、鏡を見るとそこに写っている。

 

 

【Amazon.co.jp限定】みんなで!  [2CD + Blu-ray] (Amazon.co.jp限定特典 : [複製]サイン入り デカジャケ 付)

【Amazon.co.jp限定】みんなで! [2CD + Blu-ray] (Amazon.co.jp限定特典 : [複製]サイン入り デカジャケ 付)

  • アーティスト:沼倉愛美
  • 出版社/メーカー: フライングドッグ
  • 発売日: 2020/02/12
  • メディア: CD
 

 

 

 

スピード感を持って仕事をしたいなら

スピード感を持って仕事をするとか、自走するとか、仕事を自分事としてやりたいと思うなら、宿題を作らない仕事の仕方を覚えると実現しやすい。

 

やはり、これは現場の仕事だから現場にやってもらうとか思った瞬間から、スピードも無くなるし、自分で仕事をコントロールできなくなるし、他人事になってしまう。

 

ミーティングで意思決定をすることが目的なら、意思決定をした後のアクティビティまでざっと出して、期限と担当を決めてしまう。アイデアをディスカッションするなら、方向性、目的を共有までやってしまう。説明をするなら、その場で一緒に作ってしまう。

 

共通しているのは、ボールを渡さないということである。

 

ここで求められるコンピテンシは、何か。そこを押さえないと闇雲になってしまうし、場当たりすぎる。

 

その成し遂げたい仕事のゴールのイメージから逆算してあらすじ、台本を書けるようになりたい。

 

台本とは、台詞を言う役名の下に台詞がある形態のものだ。言い換えれば、誰にどの仕事をやらせたいかを考え、描いたように行動に影響を与えるものだ。

 

これには、行動に影響を与える対象に、台本を書いている自分も含まれていることに注意しなければならない。実現したいことは、自分自身から変えないと誰も動いてくれない。

 

自分も台本の中に入って役者と同じように役を持ち、自分のやることは自分でやるから、それを見て他の役者も同じように踊ってくれるのである。

 

自分だけ傍観者というわけにはいかない。何せ実現したい仕事の張本人なのだから。

 

 

 

 

 

 

 

 

リモートワークのよろしくないところ

ときどきリモートワーク、在宅勤務をするのであるが、これがよろしくない。いや、勿論良い面もあるがつづけるとよろしくないような気がする。

 

まず、通勤がない。おかげで朝食を済ませたら、直ぐに仕事を始められる。まあ、先に日々の日課をするのだが、それはリモートワークかどうかにかかわらずなので無視して良い。

 

自分は着替えて、電車に乗ることでスイッチが変わる。そう思っていたが、最近はそんなこともなく、仕事を始められるのでただの思い過ごしなようだ。

 

通勤がなくなったことで失うものがある。通勤時間での移動による運動である。リモートワークになると、ほぼ終日リビングで仕事をするので致命的に運動がゼロによっていく。

 

これでは意識的に運動をする時間を取らなければならない。通勤をやめたのに運動を代わりにするなんてどうなんだろう。しかし計画的に運動を取り入れたほうが身体の柔軟性や体型維持には良さそうであるがやはり時間を確保するのが面倒である。

 

通勤時間の正味と運動に割り当てる時間を考えれば、運動に割り当てることは十分可能なのだが。

 

昼食もいけない。ランチタイムは、勤務地の周辺のお店を開拓するのが面白いのだが、在宅勤務となると家で済ますか(ホント済ます的になる)、近所の知ったお店に行くしかない。

 

ついつい懇意のお店に行きそうになるのは、チェーン店は安定しているからこそ、普段はチャレンジしてお店を開拓したいのである。ときどき勉強代を払ったなと思うこともあるが、一見のお店に入るときの不安感は楽しい。

 

リモートワークでは、周囲は繁華街ではないからそうしたお店は限られるし、ランチタイムの時間制限もあるから(自由にすれば良いのだけれど)、のんびりもしてられない。気を抜くといつのまにかミーティングスケジュールが入っていることもある。

 

ミーティングもオンラインになるとアイコンで済ませられる。仕事着に着替えなくてもいける。これも気を抜くと仕事着は意識しなくなり、いざ出勤するときに着ていく服がない状態になりかねない。

 

家族が出払っているのでリビングには1人である。ちょっとまずいなと思うのはメンバとの雑談がないのである。意識的にslackで「そう言えば…」と振ればいいのだがまだそれは慣れていない。

 

 

 

 

 

 

 

 

 

エンジニアの頃とプロマネになってからの意識の違い

プロジェクトマネージャをやるようになってから、エンジニアの頃の意識の違いを感じるようになったのは、計画と進捗の実績の較差だな、と思う。

 

この計画と実績の較差を知りたいと思うのは、プロジェクトはリスクを識別して、コントロールすることが全てだとわかったからである。

 

進捗、計画と実績の差と言うと、ほとんどのエンジニアは顔を顰めて背けるかもしれない。何しろ、進捗会議や朝会や夕会などで予定の作業は終わったかとチーム全員の前で、現実の進捗を聞かれるのだから。

 

自分の若い頃は、ろくにテストが進んでいないのに、どうリカバリするかと詰められたくないから、出来ていないことを自ら懺悔などしたくないと思えば、なかなか進んでいないけどオンスケですかね、などと惚けて自分の首を絞めていた。

 

こんな杜撰な言い訳で煙に巻けるようなプロマネも大概、パチモノか、なんちゃってでしかない。

 

計画と実績の較差(格差ではない)は、2つのリスクが隠れている。1つは、スケジュールは納期までに収まるのか。もう1つはコストは計画どおりになるのか。

 

プロマネをするのは、結局のところ、その2つの観点を見ているだけに過ぎない。PMBOKでEVMSだとかなんだとか計算しているのは、プロマネが現場を把握しきれないからで、それを数字で代替しているだけの話である。

 

いくらプロマネが現場を把握して予実の較差を知るとか、把握できないから数字で把握しようとしても、(過去の自分のように)出来てもいない架空の実績を実績として報告してしまうと、そうした数字はチームとしていくらでも膨張してしまう。

 

だから工程設計を標準化して、作業ステップのどの作業を終えた(Doneした)のかとか、ステップを加重して計画値と較差を捉えるとかするわけだ。ただ、SIプロジェクトでこれをわかってやっているプロジェクトに出会ったことは過去にそれほどない。ほとんどは、工程設計の標準化をしていないし、することの意味もわかっていないし、知識を持っているプロまねも少ない。

 

こうした考え方は、理想に過ぎないとか思うかもしれない。だけれど、工程設計を初めからしてあって、たとえ途中で改善することがあったとしても、全くない状態で工程を始めて工程終了直前でダメ出しをされてて戻りするとか、進捗は実はありませんとかテロのようにしれっと現実を知るよりは、1000万倍ましである。プロマネは、アクティビティの実績がリニアになれば、エンジニアからアクティビティにフォーカスできるようになる。

 

これはエンジニアにとっても同じ価値がある。何しろ、チーム全員が同じプロセスをすることになるが自分の進捗を取り繕う必要から解放される。嘘をつき、それを破綻しないようにする必要がなくなる。それはエンジニアとして向き合うのではなく、アクティビティで会話できるのである。

 

もう1つのリスクはコストである。これは進捗の予実に密接に結びつく。化石時代のプロマネは予算消化の推移と進捗の予実の較差を紐付けない。だから進捗がオンスケでもコストオーバーランになる。

 

これは予定の作業時間内で予定したアウトプットが仕上がらなければ、自動的にコストオーバーだと認識するところから始まる。これのコントロールをアクティビティごとにやり過ぎるとプロマネもエンジニアも苦しくなって窒息死する。

 

だからプロジェクトの工程単位やマイルストーンで括り、バッファをもつ。ここでCCPMの考え方を使うのであるが、それもリスクコントロールのためである。

 

この2つ目のリスクも大元を辿れば、進捗の較差に収斂することを気づくことができれば、工程設計をあらかじめしておくこと価値に気づけるはずである。

 

まあ、精神論な化石時代のプロマネではその発想はできないし、嘘をつくようなエンジニアはチームにはいられないのであるが。

 

 

 

 

IT系イベントをオンラインでやる馬鹿っぽいアイデア

新型コロナウイルスの影響を受けて、IT系のイベントの中止が矢継ぎ早にアナウンスされ始めた。東京マラソンの一般参加も中止になった。

 

スポーツの東京マラソンはさておき、IT系のイベントで物理の授受が生じないイベントは、これを機会にネットでの開催を試みて、失敗事例を収集するチャンスと捉えることはできるだろうか。

 

新型コロナウイルスというコントロールできない外部からの制約条件は、ある意味においてブレークスルーする機会と見ることができる。

 

今ある技術を運用で乗り越えるか、スーパーエンジニアがサクッと制約条件を回避したり、発想を変えたアプローチを試みたりするには、良さそうではある。

 

これを書き始めて、自分も無意識に囚われていたと思うのは、IT系のイベントはリアル、オフラインで参加するものだと思い込みだ。

 

日ごろからリモワに馴染んでいるにも関わらず、イベントはオフラインでと思い込んでいる自分に呆れたというか、自分にオンラインでやればいいじゃんというツッコミを入れられただけでもこのエントリを書いた意味はある。

 

今あるもので、ぱっとできそうなアイデアを思いついた。馬鹿っぽいアイデアの先にスーパーエンジニアがもっとかっこよくしてくれるだろう。

 

馬鹿っぽいアイデアだが、物理的に授受するイベントでも適用できそうだ。

 

前準備

・ページを用意する

・ジャンルか島毎にテーブルを切る。

・列をトラックにして、コンテンツ提供側を配置

・行を時間にする

・セルにハングアウトのURLを貼る

 

運用

・コンテンツ提供側は、時間指定かイベント時間帯にオンラインで常駐する

・一般参加者は、コンテンツ提供側のいる時間に入る

・コンテンツの説明を受けたり、qaをする

・有償の頒布物を欲しい場合は、入手可能なサイトで物理なりデジタルなりを手に入れる

 

コンテンツ提供側は物理コンテンツをサイトを介して捌けるし、欲しい側は交通費分を送料の一部にあてられる。

 

単発のイベントなら即座に出来そうである。ハングアウトに何かしら制限があれば、そこまでではあるが。

 

 

 

 

 

 

 

チームのエンジニアの目標を共有する効果

 

エンジニアの仕事は1人では成り立たない。だからチームを組むわけなのだが、じゃあチームになったとき、協力がスムーズにできてメンバのパフォーマンスを発揮できる環境づくりができるかというと、そうもいかなかったりする。

 

ところで年度が変わった組織はすでに2か月が経っていて、設定したエンジニアの個々の目標も記憶から薄れかけている頃だろう。

 

ここのエンジニア目線で見れば、評価時期に成果なり、到達したコンピテンシレベルを評価して欲しいとそのときになって思うものだが、実際には実績が追いつかず評価されないか、やっているにもかかわらず認知されないから評価されない。

 

一つのやり方として、年度始め(始まっていたら今からでも)個々のエンジニアの目標をスライド一枚でこれをやるからと組織やチーム内で宣言することを勧めたい。

 

どっちにしろ、業務としてはチームの中で働くことには変わりはないし、個々のエンジニアとしても業務を介して目標を達成することには何ら変わらない。

 

それよりは、チームで働くときの、業務に対する関わり方やエンジニアの関心のある方向を共有できることでメンバ同士の関心が芽生える。

 

マネージャとエンジニアの2人の世界で作られる目標は、結果的にエンジニア本人にも忘却され、なんとなく1年を過ごしかねない。

 

であれば、チームで共有されていることで、そのエンジニアがなにに関心を示しているのか、どうなりたいのかを話すことで、一緒に働くエンジニアが支援したり協力をしやすい土壌を作れる。

 

共有された目標が評価されると、どのくらいの結果を出せば評価されるか目の前の事例として理解しやすい。

 

さらに、自分で自己評価をするときに達成レベルのモデルとなる(他のエンジニアと比較するという意味ではない)。

 

共有するときに、それを聞いている他のエンジニアは、ただ形式的な拍手をするのではなく、サポートする表明をするか、発表するエンジニアからサポート役を指名させてもよい。

 

マネージャとしては、誰かではなく、全員のコンピテンシをあげたいのだから。

 

 

 

白いネコは何をくれた?

白いネコは何をくれた?

 

 

 

 

 

 

 

 

 

チームのエンジニアの目標を共有する効果

 

エンジニアの仕事は1人では成り立たない。だからチームを組むわけなのだが、じゃあチームになったとき、協力がスムーズにできてメンバのパフォーマンスを発揮できる環境づくりができるかというと、そうもいかなかったりする。

 

ところで年度が変わった組織はすでに2か月が経っていて、設定したエンジニアの個々の目標も記憶から薄れかけている頃だろう。

 

ここのエンジニア目線で見れば、評価時期に成果なり、到達したコンピテンシレベルを評価して欲しいとそのときになって思うものだが、実際には実績が追いつかず評価されないか、やっているにもかかわらず認知されないから評価されない。

 

一つのやり方として、年度始め(始まっていたら今からでも)個々のエンジニアの目標をスライド一枚でこれをやるからと組織やチーム内で宣言することを勧めたい。

 

どっちにしろ、業務としてはチームの中で働くことには変わりはないし、個々のエンジニアとしても業務を介して目標を達成することには何ら変わらない。

 

それよりは、チームで働くときの、業務に対する関わり方やエンジニアの関心のある方向を共有できることでメンバ同士の関心が芽生える。

 

マネージャとエンジニアの2人の世界で作られる目標は、結果的にエンジニア本人にも忘却され、なんとなく1年を過ごしかねない。

 

であれば、チームで共有されていることで、そのエンジニアがなにに関心を示しているのか、どうなりたいのかを話すことで、一緒に働くエンジニアが支援したり協力をしやすい土壌を作れる。

 

共有された目標が評価されると、どのくらいの結果を出せば評価されるか目の前の事例として理解しやすい。

 

さらに、自分で自己評価をするときに達成レベルのモデルとなる(他のエンジニアと比較するという意味ではない)。

 

共有するときに、それを聞いている他のエンジニアは、ただ形式的な拍手をするのではなく、サポートする表明をするか、発表するエンジニアからサポート役を指名させてもよい。

 

マネージャとしては、誰かではなく、全員のコンピテンシをあげたいのだから。