感情はエンジニアの進捗のおジャ魔女どれみちゃん

もし、仕事で疲労感やストレスを感じていると思ったら次の質問を自分に問いかけてみよう。

• 自分が担当している仕事は私のものだ
• 一緒に仕事をしているメンバが思うように動いてくれない

担当している仕事は自分のものではない

仕事は、対価を支払うスポンサーがやるべきことを契約の範囲で代行しているのです。あなたの「もの」ではありません。

あなたは、仕事で求められるアウトプットを品質要求を充足するように仕上げるのが分掌なのです。

ですから、仕事はあなたのものではない、と思い直してください。

しなければならないこと

しなければならないことは、様々な制約条件、前提条件を考慮しつつ、期日までに如何に早く、確実に仕上げることだけを考えて、作業を段取り、進めることを考えてください。

私情を混入させない

担当している仕事が自分のものだという感情を付加すると、仕事を進める上での判断に私情が混入してしまいます。

私情は自分の不作為から来ている

この私情は、あなたのものだと思っている仕事の不都合なこと（出来上がっていない、品質要求を満たしていないなど自覚していること）に対して話題されること自体を不快に感じるようになります。

自分で進捗の邪魔をしない

私情を持ち込まないということは、心をロボットにするという意味ではありません。感情があなたの進捗の邪魔をするのです。

それを取り除きましょう。

あ、おジャ魔女どれみちゃん…。

いいと聞いて

人間工学設計 低反発まくら 首・頭・肩をやさしく支える健康枕 いびき防止 頸椎サポート 頭痛改善 肩こり対策 快眠 洗える ピロー

チーミングでは「こんなものだ」と思うことが心理的安全を作る

ベテランエンジニアと入社数年のエンジニアではあまりにも技術力の差があって勝負にならないというか、仕事を一緒にするのは大変なことなんですよ。反対に、同じくらいの年齢層のベテランのエンジニア同士だと専門とする技術は違っていても、（それぞれがやることをやっていれば）和気あいあいというかベテランエンジニアの馴れ合いですべるダジャレを投げ合いつつも仕事が進むのです。これは若いエンジニア同士でもすべるダジャレはないかもしれないけれど、和気あいあいさ加減は同じなんですよね。

チーミング

チームを構成することを個人的にはチーミングと呼ぶようになって10年以上経つんだけれど、たぶん、どこかで誰かが使っていた言葉をいいなと思って使っているんだと思います。いいなと思って、使ってみていいなと実感できることは続けるのです。

チーミングで必ず起きること

さて、チーミングするとどうしてもチームに必要なスキルとスキルレベルが組み合わせになるので年齢層も持っているスキルも多様になるわけです。多様とはいえ、チーム自体はこじんまりとしたものなので人数は少ないのです。ここで組み合わせによるコンフリクトが起きるのです。

それは、ベテランエンジニアと若手エンジニアの様々なギャップです。一番大きなギャップは経験知ですね。40代のベテランエンジニアと20代の若手エンジニアなら20年のストックの差があるわけで。

この経験知の差を認識できないベテランエンジニアが少なくないのです。さを認識できないとどうなるかというと、若手エンジニアに対して、自分と同じレベルの仕事の仕方を要求するわけです。

責任感が強いと自分を責めるから…

若手エンジニアも経験知がない分、自分に能力がないと自責するんですよ。ここにお互いに心理的に安心できる場所をみすみす作れずにギクシャクしてしまうんです。これを若手エンジニアに配慮しろというのは酷なことです。経験知でアドバンテージがあるベテランエンジニアが配慮することです。リーダなのだから。

心理的安全を作る6か条

1. ベテランエンジニアは若手エンジニアより経験知が絶対的に多いと認識する
2. 若手エンジニアが理解できているかを言葉や行動で確認する
3. マネージャなど第三者の視点で一方通行のコミュニケーションになっていないか確認する
4. 若手エンジニアにどれがいいか判断する機会を与える
5. 若手エンジニアの成長を時間軸で計測する
6. 自分も若手の頃は「こんなものだ」「これよりひどかった」と思い出す

助け合うことが心理的安全の近道

諦めるのではありませんよ。自分もこんなもんだったのだから、同じように育つことを助けよう、と思うようにしようね、ということです。自分が若い頃になんだかんだベテランエンジニアに助けてもらったことを思い出します。

親になれば子供の成長を見守ることしかできないように、大の大人であっても若手エンジニアの成長に関与できることは育つ環境を整えるしかできないのです。

お互いに助け合うチームこそ心理的安全の近道です。

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

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

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

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

全面展開しない

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A１「（エンジニアが質問を守らないからかな？）」

A２「（わからない、知らない）」

A３自由回答「　　　　　　　　　　　　　　　　」

進捗を確認する理由

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

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

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

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

引用　PMBOK5th

進捗を確認するサイクル

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

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

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

なんて答えましたか

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

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

A１「（エンジニアが質問を守らないからかな？）」

A２「（わからない、知らない）」

A３自由回答「　　　　　　　　　　　　　　　　」

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

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

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

マネジメントするため

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

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

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

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

PS４ どっちにしよう…

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

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

アイドルマスター プラチナスターズ - PS4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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