チームを自律させた次に目指す先は変動組織へ

エンジニアのチーム運営は、プロジェクトマネージャやマネージャのトップダウン的な指示からチームに権限をデレゲート、つまり、権限移譲することで裁量を増やしてチームが自立し、さらに自律へステップアップする方向に遷移するのが当面の目標だと思うのです。

意思決定の判断基準は文化である

現実には、指示命令系が強い組織では、指示され、確実に作業の成果を報告することが行動する際の判断基準になっており、それが定着して空気のような文化になっていることが多いのです。そのような文化にいきなりチームに権限移譲して、チームを自律さえて運営してね、というのがどれだけカルチャーショックかは、想像できるのではないでしょうか。つまり、自立させて、さらに自律、自らを律するためには、行動の価値判断基準を総取っ替えが必要なのだ、ということです。

全面展開しない

権限移譲されたことがないチームにいきなり権限移譲をしてもチームは今までやってきたことがないので経験値を持っていません。ここを理解しないで組織にビックバン的に一斉展開するとなんでも一緒で確実に失敗してしまいます。

小さく、限定的に始めて成功体験を1つのチームに得させることが最初のポイントです。その上で、組織内にフォロワーを作ることから徐々に展開を進めることが必要です。その際には、最初のチームが後からついてくるチームの相談相手になると良いです。

自律したチームが次に目指すのは

チームは自律して活動をできるようになるということは、チームの目標を自ら設定し、マネージャに修正されること(はほぼ)なく、チームが担うビジネスを回すことができるモードに入っている状態です。

自律したチームが目指す先、ステージはどこなのでしょうか。

エンジニアの性として対象のオブジェクトはスケールアウトしたくなるものです。1チームで自律出来るようになったら、2つのチームを自律したい。それの表れは、上述の先行する1番目のチームがフォロワーのチームの相談相手になる、という考え方です。

アメーバでも有機的でもない次へ

このスケールアウトしたいというのはどこにそうしたいと思う要因があるのでしょうか。心理的に大規模プロジェクトを想定しているのだと思うのです。複数のチームで複数のサブシステムを開発するプロジェクトを指示命令型や調整型で経験しているともう少し上手に、トラブルを少なくやりたい、と。

メンバが自律してチームを自律させる。だったら、スケールさせて、チームを自律させて複数のチーム(ズ)を1つの個体として自律させる。

これ、アメーバ経営に近い考え方のような気がしますが、(直接的に)経営をしたいわけではないのでちょっと違うと思うのです。

有機的組織かといえば定義が今ひとつ曖昧なので言葉の意味合いだけでいえば、変動組織運営なのかもしれません。

PM「なんで毎日進捗確認してるかわかる?」SE「…」

はーい、ここでみなさんに次の質問に適切な選択肢を選ぶか、答えていただきまーす。さあ、どうぞ。

 

Q「なんで毎日進捗確認しているかわかる?」

A1「(エンジニアが質問を守らないからかな?)」

A2「(わからない、知らない)」

A3自由回答「                」

 

進捗を確認する理由

システム開発において進捗は、計画の進度を実績で把握するのでとても大切です。

大事なのですが、実績を把握することが目的ではなく、計測した実績により計画を変更する必要がある場合は、変更させるために大切なのです。

 

PMBOKではプロジェクト統合マネジメントの中でプロジェクト作業の監視・コントロールとして取り扱われています。

その監視・コントロールプロセス群は「プロジェクトの進捗やパフォーマンスの追跡、レビュー調整を行うために必要なプロセスから成り、計画への変更が必要なエリアを特定し、それに相当する変更を開始する」

引用 PMBOK5th

 

進捗を確認するサイクル

あなたが参画しているプロジェクトの進捗はどのサイクルで実績を確認していますか。

  1. 日次
  2. 週次
  3. 隔週次
  4. 月次

では、どうしてそのサイクルで進捗を確認するかを知っていますか。

 

なんて答えましたか

冒頭の質問の答えにつながります。

 

Q「なんで毎日進捗確認しているかわかる?」

A1「(エンジニアが質問を守らないからかな?)」

A2「(わからない、知らない)」

A3自由回答「                」

 

 

どのように回答しましたか。それとも自由回答にしましたか。もちろん、1と2を選択したらPMはブチ切れるかもしれませんね。でも、正解を回答をしたら、

 

PM「わかってるのになんでちゃんと報告しないの!」

 

と返って突っ込まれそうです。

 

マネジメントするため

プロジェクトは細工するで進捗を把握するのはそのサイクルで実態を把握して、必要に応じ策を取りたいからです。遅れていることがわかったら、スケジュールを見直すのか、遅れた原因を特定するとか、リソースを追加する判断をするとか、です。

 

あと大事なのはなぜプロジェクトマネジメントをするかということに立ち戻る必要があります。なぜでしょうか。

プロジェクトは、プロジェクトオーナの業務課題をシステムで実現する課題解決策です。マネジメントが投資をして行っているプロジェクトが事業の業務課題に直結するのでプロジェクトオーナにレポートする必要があるのです。

プロジェクトオーナもまた、プロジェクトの進捗でプロジェクトの進行若しくは停止を判断するのです。その源泉が進捗把握のなのです。

 

 

 

PS4 どっちにしよう…

 

PlayStation 4 ジェット・ブラック 500GB(CUH-2000AB01)

PlayStation 4 ジェット・ブラック 500GB(CUH-2000AB01)

 
PlayStation 4 Pro ジェット・ブラック 1TB (CUH-7000BB01)

PlayStation 4 Pro ジェット・ブラック 1TB (CUH-7000BB01)

 

 

エンジニアだもの、業務時間をハックして勉強時間を確保しよう

ライフワークバランスはだいぶ死語になってきましたが、働き方改革がまだ息をしている間に業務時間をハックして、エンジニアに必要な勉強時間を確保しましょう。

エンジニアはどうして勉強しないといけないの

それはね、新しい技術や技術の更新速度が速く、そうした技術を広く認知させ、売り込むためのバズワードに踊らされる顧客がそれを望むからだよ。

従来の技術は年月とともにコモディティ化すると技術料が下がり、既存のエンジニアを抱えられなくなるから単価の安いエンジニアに切り替えてしまうんだ。

 ビジネスの基本な考え方として、技術は高級化させ、単価を上げて利益を確保することが必要なんだ。

エンジニアの技術料を向上させるために技術を身につける=勉強することが必要になるんだ。

エンジニアはいつ勉強すればいいの

組織として取り組む場合、多くは企業内研修でエンジニアを教育することが多いんだ。企業内で教育できない場合は、教育専門会社に依頼することもあるよ。

エンジニア自身が自己研鑽として業務時間の内外で勉強することもあるよ。多くは業務時間に時間が取れなくて、業務時間外に勉強をしているエンジニアもいるよ。

残業が多くて勉強する時間がありません

大変だね、でも、残業が多いからといって、勉強を怠るとどんどんと技術の更新に置いていかれるよ。

まずは、1日の時間の使い方の調査から始めてみよう。時間を有効に使っているつもりで実は無駄に過ごしていることがおおいいんだよ。

業務時間内も何に使っているか計測してみよう。重複作業、手戻り、無計画な作業は思った以上に見つけられるよ。

なかなか作業時間が短縮できません

まずは、仕事を予定工数の8割で終わるように作業スピードを向上させてみよう。

作業スピードの向上は、手作業のツールで代替するんだよ。手作業を速くできるようにするのはすぐに限界がくるよ。生産性の向上を狙って作業スピードをあげるなら手段であるツールを取り換えるんだよ。

外部の勉強会に出て行く時間が取れません

業務が終わったら勉強会に行こうと思っていたらいつまでも行けないよ。

先に行きたい勉強会の予定を入れちゃおう。予定を立てたら勉強会に行けるように業務に集中して作業を終わらそう。

家に帰ってから勉強しようと思ってもいつの間にか時間がなくなってしまいます

優先順位を決めよう。勉強をすることの優先順位が高いなら、2ページ読んだら5分だけツイッターしてもいいと、自分でルールを作るといいよ。

勉強のために何かを禁止するのは続くかないよ。先に決めた分量だけ済ませてからリラックスする時間に使おう。

宿題をやってから遊びさないってママに言われていたでしょ。

本当に業務が忙しくて時間が…

一日中座って仕事をするのは健康にもよくないよ。15分でいいから技術書やPCを持ってコーヒーショップや一人で会議室を確保して篭っちゃおう。

気分転換に集中して本を読んだり、コードを読むといいよ。

外部の勉強会に行くといい顔をされません

仕事は期限までに終わらしちゃおう。日中なら有給を使うこともできるよ。有給なら文句を言われる理由はないよ。

それより日中に業務として勉強会に行って、勉強会にいかないエンジニアにフィードバックをしたほうがいいよ。

フィードバックを前提にすると必ず何か学びをしないとフィードバックができなくなるから勉強会への参加意欲も違ってくるよ。

 

 

チームのゴールとエンジニアの働くモチベーションのギャップと対策

チームのゴール設定はマネージャ(が考えていればマネージャ)のミッションを実現するためにミッション最適化で方策を考え、チームのゴールとしてチームのメンバに

 

「この(マネージャが考えた)ゴールを目指そう!」

 

と年度始めにやるわけです。で、

 

「じゃあ、キミがチームのゴールに貢献するための目標を設定しよう!」

 

とメンバ一人ひとりに目標を設定するように言い(迫る)ますよね。

 

チームのゴールあるある

チームのゴールってこんな感じですかね。

・売り上げNN%アップ
・カスタマーサテスファクション5%向上
・密なコミュニケーションによる生産性向上 
・リリースサイクルの短期化
・大規模障害0件
プロマネ育成N人

開発チームも結局、儲けなければチームを維持することができませんから、技術よりはビジネスよりの目標が混入して来たりするかもしれません。

それと大体は、昨年のトラブルで印象に残っていることの対策をチームのゴールにしたりするんですよね。トラブルの原因の本質まで辿り着けていないマネージャは印象に残っている負の経験を焼き直してチームのゴールにしがちです。そういった目標が混在しているかどうかでマネージャがどれだけ考え、目指すチームの姿を洗練化しているかを見極めるためのカナリアに使うこともできますけど。

 

 

エンジニアの働くモチベあるある

 一方、エンジニアが働くモチベ、つまりモチベーションは現実的であり、曖昧なのです。

 

・お金たくさん欲しい
・仕事で認められたい
・楽したい
・好きな技術は覚えたい
・課金するのでお金欲しい
・役職につきたい
・最新の技術をやってみたい
・なんとなく
・特にありません
推しのためにお金欲しい

 

現実だと言うのは、お金を稼ぐ、評価されたい、昇格したい、と言う類のもの。これは立派なモチべーです。一方、特にありません、考えたことありません、と言う層も一定量の人数がいるんですよね。普段、言われたから、仕事だからやってます、的なエンジニア。

その上で、自分の興味がそそられる仕事を楽しく仕事できたら、くらいなんですよね。多くのエンジニアは。ときどき、歯ごたえのある仕事の方を好むエンジニアやプロマネがいますけど。ええ、ワタシです、はい。

 

マネージャとエンジニアの考えていること、考えていないことのマッチングのズレがひどいことこの上ないですね。でも、そんなものなのです。

 

 

ゴールとモチベのギャップ対策

どれだけゴールとモチベがずれていても、組織で、会社で働き、外貨を稼がなければチームは解散です。

結論から言えば、マネージャのゴールが達成されるかどうかです。ゴールに辿り着くまでのルートや手段や道具、ツールはエンジニアが決めればいいのです。ゴールを実現するのはエンジニアなのですから。

 

ただ、マネージャはゴールを決めたらエンジニアのチームを放置するのではなくゴールに辿り着くまで伴走し、進む方向を間違えないようにしなければなりません。

 

一つはエンジニアが一人で成果を出すよりもチームとして成果が出せるように促さなければなりません。エンジニアを集めたからといってチームになるわけじゃないのです。チームに信頼関係を作る必要があれば、エンジニア間の距離を近くして信頼を相互に得られるための働き方をさせなければなりません。

 

エンジニア自身がチームのゴールを理解し、チームのメンバが同じ方向に向かって考え、行動できるような価値観を共有させる必要もあります。

 

さらに、ゴールに到達するための技術を身につけ、レベルを上げて行く取り組みもチームとして必要です。

 

さらにあんなことやこんなことまでやらなくてはなりません。ふー。いつも書いていることだったですねー。

 

 

 

 

 

常駐はプロジェクト適用技術の最適化で技術力をスポイルしてしまう

中堅くらいまではある時期を除けば、ほぼプロジェクトから抜けるたびにプロジェクトルーム若しくは客先が変わるので勤務地が移っていたんですね。

プロジェクトが変わると通勤経路が変わるのでそれはそれでそのプロジェクトに参画しなければ経験できないことなので割と好きでしたね。

 

プロジェクトルームと自社の位置関係

プロジェクトのほぼ100%、プロジェクトルームの方が自宅から所属する会社より近いんです。図式化するとこんな感じ。

 

 自宅 ーーーーーー プロジェクトルーム ーーーーーー 会社

 

これでどんなことが起きるかというと

 

 自宅 ーーーーーー プロジェクトルーム ーー x ーー 会社

 

会社に行かなくなるんですよ。行く必要もないと1年に1回も帰社しなくなるんですね。こんな話をしてくれたベテランがいました。

 

「久しぶりに会社に戻ってさ、なんとなく打ち合わせコーナーに座っていたらお茶を出されたよ」

 

社員証で気づいたらしいですが。こういうのって笑えなくて、ジワリと帰属意識(が必要かどうかは別にして)を削ぎますね。確実に。俺はどこの会社の社員なのかって。

 

 自宅 ーーーーーー プロジェクトルーム ーー x ーー 会社

 

全員がこのパスになるわけじゃないですけれど、途中にあってもパススルーしますし。

 

 自宅 ーーーーーー (会社) ーーーーーー プロジェクトルーム

 

プロジェクト最適化が技術を陳腐化する

 常駐ばかりしているエンジニアを見ていると、自宅ーープロジェクトルームの往復になるんですね。で、どうなるかというとプロジェクトに必要なことはプロジェクトルームに集約されるので、技術がプロジェクトに最適化されるのです。

 

プロジェクトに最適化されるということは、プロジェクトで最新技術が要求されないと技術情報の更新も習得も止まるということ意味するんです。

 

これやばいです。プロジェクトルームにある技術だけで仕事ができちゃうので外にも情報を取りに行かなくなってしまう。

 

仕事に必要なければ誰も情報を取りに行かない

この状態を作っているのは、こうした常駐形式の契約をしている営業とマネージャです。一方、最新技術を、などと言って勉強させようとしても作業環境がそれを必要としないので、必要に迫られなければエンジニアは誰も勉強しませんよね。

 

だって、プロジェクトで使わないのですから。それをわざわざ外に技術情報を取りに行ったり、プロジェクトルームより遠い自社まで行って研修なんて受けますか、ってことです。

 

そりゃ、技術力は落ちるし、新しい技術力なんて身につかないんですよ。

お勧めできないエンジニアの頑張れる限界点の見つけ方

タイトルからやばそうなのでお勧めしませんが、自分なりのどこまで頑張っていいのか、その一線を越えたら無責任に仕事を放り出してしまうかもしれなよという限界点の見つけ方のご紹介です。はい。

 

やばい体験

20年くらい前にひどいプロジェクトがありまして。ええ、自分がプロマネしていないプロジェクトはそんなのばっかりでそうでないまともなプロジェクトは例外みたいなものです。まあ、その当時はまだプロジェクトマネジメントも一般的ではありませんでしたしPMBOKも1996年版でしたから。

 

20年前のプロジェクトで、特に、人間関係でだいぶやられまして健康診断でだいぶ痩せましたね、このまま維持できるといいですね、と保健師さんから言われるくらい痩せたんですね。あれはひどかった。指輪難なく抜けましたから。

 

実体験で、あれはやばい、です。あれに陥ってはいけない。毎朝、家を出ると胃酸が上がってくる感じになってはいけない。それが限界点の一つ。

 

二つ目は、労働時間的なもの。週1回は終日休みを除き、平日は9時から終電まで。1日5時間くらいの残業。ただ、これはチームは自分でコントロールしていてチームのPMではあったので人間関係は普通(メンバとは役割分担がちゃんとできていた)だったので。ひとつ目とコンボだと続かなかったですね。若しくは、週1の休みもなかったらダメだったかも。

 

やばい体験との比較

 これはやばい体験として自分はここまで頑張れた。ただし、20年前なら、とか、5年前なら、とかの条件付きで。

今なら、9時5時でどう成果を出すかを考えますけど。

で、どうやって頑張れるかという限界点=この一線を越えたら壊れるという薄氷を踏みながらどこまで進んでいいかというチキンゲームみたいなものです。

こうした所の見極め方は、突っ走ってはいけないのです。自分で頑張れるとやっても見ないことを根拠なく信じないことです。

一歩いっぽ足を出してみる。今ある自分の認識を大事にすることも必要です。

そのためのも、ヤヴァイ体験がなければどこまで頑張れるか比較できないのですが。

 

そこで、別の趣味を持っているとそれが楽しめるか、そっちにリソースを確保できる仕事の仕方ができているかで頑張れる限界点の閾値を知るという方法を取るのが良いでしょう。

気分転換も維持できるので。