相談内容の可視化は新しい知識にフィードバックされる
予定していた夜の部会の延期が決まった後にその部会メンバから予定が空いているままなら会わないかとDMでお誘いを受けたので仕事を片付けて行くことにしたのです。
DMの内容はその部会について話したいと書かれていたので、何かあるなと思いつつ、作っておいた資料をみてもらえば良いかと思っていたら件の話になったんですよ。
使ってナンボ
部会向けの資料は企画ネタのもので、ただ前回の資料は大分具体性が有り過ぎて2−３歩下がって資料の理解を得るところがアクティビティになってしまっていたという反省をどうしようかと思案しつつ、スタートアップやアジャイル開発系で使うことが多いキャンバスやマッピングなどのツールで整理しなおせばいいのではと思い当たって仕事の気分転換に前回資料のおさらいといくつかのツールに落とし込んでみるといくつかの項目の表現が今二歩くらいあったけれど、何をやりたい企画なのかがすんなり入ってくるようになったので、やっぱりツール類は素振りじゃなくて実践的に使わないと労力を使うリターンが少ないなぁと実感したり。
使ってナンボですわ。
描いて共通理解を確認する
今回の資料はA4に押し込んでコピーを渡してざっと整理した資料の読み合わせをしたら、するっと理解してもらえたようで、じゃあ、次そちらの番だねと振ると実はと切り出すところからやはり勘は当たっていたようで（バンザイ）。
ざっくりまとめるとプロダクトマネジメントをすることになった中堅エンジニアが今まで企画畑で開発経験がなくプロダクトの立ち上げはいいけれどデリバリのところに入ると試行錯誤になってしんどいから、プロジェクトマネジメントを教えてあげたほうがいいのだろうかと抱えている悩みを共有してもらったんですが。
これはシステム開発でのプロジェクトの4層フレームワークの最下層にあるマネジメントプロセス（例えばSIerのシステム開発ならPMBOK）と第3層システム開発手法（例えばウォーターフォールやアジャイル開発）にプロダクト開発であれば何を当てればいいのかってことと、それを踏まえてプロダクトマネージャに何をインプットすればいよいか探り出す必要があると思って、言葉の意味合いから事象として起きていることや客観的に押さえている情報をひと通りホワイトボードに描くことで可視化されるとだんだんとわかってくることもあるのです。
共通理解から得られたのは新しい知識
システム開発畑なので第4層はPMBOKで第3層はシステム開発手法でと経営からのモニタリングに耐えられるプロジェクトの計測、監視と制御が無意識に当てはめてしまうけれど、プロダクト開発の場合は、違うなと。特に、プロダクトやサービスを企画からクロージングというアクティビティなので第4層はPMBOKではミスマッチというか機能不全になるのです。そこはプロダクトマネジメント、プロダクトのライフサイクルを KPIで計測、制御するマネジメント手法が適切なのです。
件のプロダクトマネージャはそこは問題はないので。次は第3層のシステム開発手法ですがキャリア的にここが圧倒的に力不足というか形式知がないに等しいのかもしれません。ここはウォーターフォールがとかアジャイルがとかよりはプロダクトを完成してリリースするための作業プロセスの組み立て方の知識と実践力をいかに身につけさせるかを具体的な活動に落とし込んだほうが良いなと。
相談者への囁きは、前述後段ですが、自分自身の気づきは、第4層はPMBOKばかりじゃないということです。元々は形式知として得た知識をひとつ増やすことができてよかったと。
時間外に勉強しても年収が上がらないエンジニア
もう、エンジニアが時間外に勉強するとかしないとかは終わったかと思えばこんなのが。
あー、はいはいと思いつつ読んだら勉強するしないは好きにしたらいいとかぶん投げているのに、勉強しないと給料が上がらないという方向に持って行っているんだから、結局時間外に勉強しろよ、と言っているんじゃん。
ちょっとおさらいするよ。
使用者（経営者）労働者に技術を身につけさせる理由
使用者が労働者に技術を身につけさせたいと考えるのは、事業の業務遂行上に必要となるからです。業務上必要な技術を身につけさせることで、期待する成果を得られるように訓練するのです。職業訓練、です。
労働者（エンジニア）自身が技術を身につけたいと思う理由
労働者であるエンジニアは自身に業務上の職業訓練に置いて技術を身につけることは使用者が求めることで、これは同じ職種の労働者は基本的に同じように身につけることは必要とされることです。なのでこの範疇で技術を身につけるためにかかる時間やリソースの費用は使用者が支払います。
ところが、労働者（エンジニアに限りませんけれど）自身が業務の時間外の、個人の時間を使って業務に関連する技術を習得しようと考え、自腹を切って勉強する人もいます。こうした時間外の技術習得の動機は何かと言えば、
- 業務での技術習得の補習的なもの（時間内にやれよっていうのは棚に上げます）
- 同じ職種よりアドバンテージを得たい
- 単なる興味
の３点に大別できます。ネット上で時間外に勉強しないと的に語られているのは２番目を暗黙で言っていますよねぇ。
はい、おさらいおしまいです。
勉強しているのに給料は…
エンジニアで勉強しているエンジニアはものすごく勉強しているようです。ただ、勉強している人が全員給与が上がっているかといえばそうでもないです。
例えば高度情報処理技術者資格を取るマニア的なエンジニアをときどき見かけますが中堅のまま滞留しているエンジニアが少なくないです。
なんででしょうね。
というか、勉強しているんだけどさ、資格もたくさん持っているし。でもさ、持っているだけなんだよね。そのエンジニアの可能性を引き出したくてリーダにアサインしてみたら当てが外れたこと複数ケースあるんですよねぇ。
多分ですけれど、勉強する＝資格取ることが目的になっているんでしょうねぇ。
興味を持った領域の知識を身につけるのはそれを実戦で使うためです。使えた成果の記録を資格に交換することはいいと思うんですよ。
勉強して年収を上げたいなら
エンジニアが技術を勉強して年収を上げたいと願うなら、年収に関与する手法や技術を習得しないければ単なるリソースの消費で終わります。
では、なにが年収に関与するのかを考えます。
所属する組織の組織構造を書き出してみてください。階層構造で。トップはCEOですね。一番下は平社員。それもどこでも似たようなものだと思いますがエンジニアであれば技術職の職位レベル的なものがあってそれにテーティングされていると思います。
その上で、職種の中でのロールが構造的にあるでしょう。
今位置付けられている職種の役割メンバ、リーダ、プロジェクトマネージャ。組織構造としての役割の担当、係長、課長、部長…という構造。
それを1つ上がるためにどんな手法、技術、知識、経験が必要かを知らなければ今やっている時間外の勉強は空振ります。
メンバのエンジニアであれば、まずはプロマネになることです。多くの組織では、エンジニアからビジネスの素質があるエンジニアがマネージャに引っこ抜かれますので。
そのコースが嫌でエンジニアで年収を上げたいなら、ご指名買いやヘッドハンティングのオファーが来るように外で技術で認知されるような技術を身につけ名前を売ることが必要です。
当たり前な話ですよね…。ただ、いつ気づくかというのは人によって様々ですけれど。
＃ワタシは遅かった…。
1 on 1でマネージャはエンジニアに語って欲しい
目標管理の年次の目標設定や業績評価はマネージャとエンジニアの1 on 1、つまり対面で１対１で対話形式で行います。えっ、当たり前だってですって。なら、どうしてエンジニアは自分から話しかけてこないんですかねぇ。例えば20人のエンジニアがチームにいたとして、1 on 1で対話をすると自分からあれこれしたい、というエンジニアの人数は数えるほどしかいません。担当する組織が変わっても比率は同じくらいなのでエンジニアの特性か組織の家風なのかもしれませんけれど。
と、思いつつ、自分に人差し指を向けて思い出すと…、あらキャリアをピボットするまではその自分から話をしない側だったかもしれません。あらら。
やりたいことを支援したいから
マネージャは組織の中のミッションを遂行するのがお仕事ですが、何をして遂行するかは担当する業種なり、担当なりの範疇であって儲かりそうならやりたいんですよ。中には従来のビジネスだけでいいというオペレータのようなマネージャもいるけれどそういうマネージャと働いても楽しくないので異動したほうがいいかもね。
それで、ネタはなんとなく探しているけれど限界はあるのでエンジニアがやりたいことが担当業務の領域の中であれば裁量の範疇で支援できるのでエンジニアのやりたいことを応援したい＝機会を作りたいと考えるんですね。
ただ、エンジニアのやりたいことはエンジニアしか知らないんですよ（ここ大事）。
だから、エンジニアがやりたいことや明確じゃないけれどあっちの方に手を出してみたい的なことでもいいので「こんなことを考えているよ」と教えて欲しいんです。
言葉にして伝えてくれると頭の隅に（書類を使う面談であれば記録としても）残るので、関連することがあれば他の条件と兼ね合わせて成り立てば優先的に名前が上がってくるんです。
だから、エンジニアがやりたいことや興味あるよということを教えて欲しいのです。
困っていることを支援したい
やりたいことと同じように組織の中で働く上で困っていることがあれば（それは職務でもあるけれど）解決する支援をしたいと思っています。
エンジニアが働く上で困ることは私生活（エンジニア自身の体調、家族環境など）があるし、組織の中での対人関係もあるし、業務の遂行上のことだってありますし。
そう言ったことを難なく自己解決するエンジニアもいるけれど、不得意なエンジニアがいたっておかしくないのです。得手不得手があることは自分を振り返れば納得できるでしょう。
お仕事の関わる範囲に限定されますけれど。
例えば、組織内の対人関係や仕事の遂行上の困っていることは、マネージャの方が顔が広いことが多いし、どこで繋がっているかはエンジニアが知らないところで繋がっていたり（以前同じプロジェクトにいたとか）するのでマネージャを頼ることも必要です。
マネージャも頼られると少し嬉しかったりするんですよ。
準備をしておこう
機会は年に数回だし、時間は短いし。
プロジェクトのレビューや技術検討などで担当するテーマに割いてもらえる時間が短いときは、準備をしてその時間で得たいゴールにどうやって合意しようとか、判断してもらおうとかを考えますよね。
同じように準備をしましょう。キャリアなのか、困っていることなのか。何を話そうかを。
準備をすることは結局、自分の内面にあるものを整理する時間になるのです。
それでも、準備をしようとして考えてもそれでも何もなければ、今技術的に関心のあることを話してみましょう。
エンジニアが何に関心を持っているかもマネージャは知りたいのです。
ヤフーの1on1―――部下を成長させるコミュニケーションの技法
- 作者: 本間浩輔
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2017/03/25
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
設計する力は衰退しました
「あいつはダメですよ。全然製品仕様を調べていないんですから」
「え、どうしたの」
「あれじゃあ要件を満たす製品の組み合わせをできない」
「だからさ、どうしたの」
「設計資料を作らせているんですが、仕事は遅いし、機能要件を満たしているかどうか確認しないで聞いた話だけで資料を作っているから裏付けがないんですよ。設計力がないんですよ」
「仕事が早いかどうは人それぞれだからさ、マニュアル読まないのがダメだって言っているのかな」
「ああ、すみません、言い過ぎました」
製造業で技術力が落ちていると言われて久しいような気がしますがシステム開発でも同じなんでしょうね。
でもですねぇ、どうしてそうなっているかをはっきりと突き詰めてないと。単に最近の若者は、中堅層のエンジニアの技術力がなくなったなんていうのは簡単なんです。それに無責任。それが組織の仕事なら。
中堅のエンジニアになったらミッションの1つに次世代の育成があります。それを履行してこなかったから今の事態になっているのではありませんか、とまずは自分に人差し指を向けて問うてみましょう（自戒）。
「それで」
「設計する力がないんですよ。あいつはもういいベテランですよ。それなのに自分で裏を取ることもしないで人から聞いた話や製品ベンダがいうことを疑いもしないんです」
「まあ、マニュアルに書いてあったとしても動かないことあるしねー」
「それはそれで製品を直させればいいんです。仕様を押さえないところが許せないんです」
「痛い目に合わないと学習しないタイプかな」
「そんなことされても困りますって。リカバリしなくちゃいけないじゃないですか」
やらないと身につかないですよね。それは設計書を書くとか設計書に書く前のデザインをするとか、デザインする前の機能仕様の情報を集めるとか、機能仕様の元になるシステム要件から仕様を抽出するとかそう言った情報を集めて、作業の目的を設定して、それを達成するアウトプットを作る作業は特に。
エンジニアに限らず、人は知っていることからしか発想できないし、知っているということは見聞きしたことよりは実際に体験したことからの方がより鮮明に具体的にこれからやろうとしていることを想像することができるのですよね。
やらないと覚えないし、身につかないし。でもですねえ、システム開発のお仕事は、どれ一つ取っても同じ作業がないんですよ。何かしら条件なり要求が違うんです。一つのやり方を覚えれば、あとは繰り返し作業、というのはないんです。
それでも仕事のお鉢が回ってきたら、始末しなければならないのです。過去の類似の経験を引っ張り出してきて。
それをするためには練習しなければ身につけられないのですが、練習する場がないのですよ。PCで開発できるようになったりクラウドが出てきて手軽に練習ができるようにはなりましたがそれをやっている人は一握りですね。観測範囲では。
でも、それで諦めては仕事にならないです。次世代を育てるミッションのところが達成されない。それもまた簡単にはできないのですけれど。
「でもさぁ、やらせないと覚えないよ」
「時間があればそういう手段もできると思います。否定はしませんが、今はそう言っていられないんです」
「それも正論だし、現場のリーダとしたらそうなんだと思うよ」
「それでもさ、いきなり身につけられたりしないじゃない」
「経験は必要です」
「それが今なんでしょ。リーダとしては葛藤するかもしれないけれど、考えさせて手を動かさせないとね。期待しているんでしょう、その人にだって」
「それはそうです。工数使っているのですから」
「それは一面だけを見すぎているという感じかな。楽するために今かけられるコストを使うという考え方もあるよ」
エンジニアが何かをアウトプットするには情報を集めてアウトプットの形態に合わせて処理することが必要ですが、情報を集めるだけでもどこまで集めればいいかという判断をしなければなりません。
そうなんですよね、決断力が必要なんです。それが甘いエンジニアが少なくないのですよね。リーダさんもちゃんとマニュアルを読んで、製品仕様を押さえて（裏を取った上で）エンジニアとして機能仕様をデザインしなさい、って言っているのは全くそのとおりです。
決断力を裏付けも持たずにエイって博打を打っているじゃないのっていうエンジニアが多いんですよ。そんなのちょっと考えたらわかるだろうとっていうところをやらない。そのちょっと考えたらの多くは情報をとる範囲を少し広げたら、ということです。広げすぎるとキリがないのでどこかでバウンダリの線引きをしないといけないですがそれにも決断する力が必要になりますけれど。
何度かエントリで書いていますけれど、練習させないと身につかないし、とは言って、仕事でそうそう練習する時間は取れないし、時間が確保できたとしても練習する材料が都合よく手配できるわけでもないし。そうすると元に戻って現場で工数の枠の中でやらせるしかないんですよ。
ただ、職人制度ではないので技術は身につけてもらわないといけないのです。技術移転ですね。それを意識的にやらないと。工数の半分をマイルストーンにやらせて、チェックポイントで修正させるようなやり方をするしかないかもしれないです。いちいち口出すのも違いますし、最後まで行ってダメだったもやりきれないですし。
設計する力がないんじゃないと思いますよ、教える側の不作為と機会を与えていないことが原因で次世代の設計する力を衰退させてしまったんです。
ガガガ文庫 電子特別合本 人類は衰退しました ガガガ文庫電子特別合本
- 作者: 田中ロミオ
- 出版社/メーカー: 小学館
- 発売日: 2015/03/27
- メディア: Kindle版
- この商品を含むブログを見る
なぜ重大な問題を見逃すのか? 間違いだら けの設計レビュー 改訂版
- 作者: 森崎修司,日経SYSTEMS
- 出版社/メーカー: 日経BP社
- 発売日: 2015/09/17
- メディア: 単行本
- この商品を含むブログ (1件) を見る
Re:ゼロから始めるエンジニアの組織改革
文句を公然と言うエンジニアはときどきいますね。大規模プロジェクトになると1人くらいいますね。そう言うエンジニアは時と場所を選ばず、プロジェクトのコミュニケーションツールに別の会社のエンジニアが入っていようが気にせずに文句を垂れ流すのですよねえ。それ、別の会社のエンジニアから見たらどう思うかとか考えないんですよねぇ。別の会社のエンジニアの立場になれば、そんなのそちらの会社の中でやればとか大変ですねーとか思うわけです。
そう言った不平不満じみたものは、多くはコミュニケーションがプロジェクトチームの中で成り立っていないから起きるのであって、コミュニケーションは相互で意思伝達するものだから、不平不満じみたことを言っているエンジニアも実は原因の1つになっているのだけれど、大体は気づかないで子供が気を引こうと泣いているようなものです。
こうした事象は組織においてトラブルのようなもので、煙が立ち上がってしまったのだから炎上する前に適切に消火しなければならないですね。
多くは、上司が呼びつけて士気に関わるからとか色々理由づけをして諌めるのですけれど、これじゃ次もおきますね。ただ、みんな見えないところでガス抜きをやっているので。
チームの中で意思疎通が上手くいかないのは組織の文化がそうした意思伝達方法を好んでいるからです。組織の文化は組織の価値判断により醸成されるものですから、それが気に入らないと言って変わるものじゃない。
これ大事。
じゃあ諦めるのかといえば、そんな後ろ向きなこともしなくていいと思いますよ。エンジニアが組織の意思疎通なり、価値観を変えていきたければ変えられる権力を身につけることです。
エンジニアにとって権力とは裁量を持つことです。まあ、エンジニアに限りませんけど。何れにしても裁量を持つためには相応のロールにたどり着く必要があるのです。
気に入らないから正面から文句を言うのは今時小学生だってやりません（ほんとかな）しアニメならそんなシナリオ通りません。
エンジニアが裁量を持つためにどうしたらいいか。これも単純なことでビジネスで貢献すればいいわけです。エンジニアがビジネスキーパーソンであれば、相応の裁量がビジネスと共にお鉢が回ってきます。稼げる人を組織は抱えるので。
プロマネ、プロダクトマネージャ、アーキテクトと前面に立つエンジニアのロールについてビジネスを作ることで裁量を手に入れるのです。裁量で自分の世界観を作れるようになったら始めましょう。
文句を言いたかったことを解消する施策を。裁量の中で、ビジネスを引っ張っているうちは誰も気にしません。小さな試みから始めるのです。小さな試みと小さな成功を積み重ね、裁量の範囲での世界の中でフォロワーを作るのです。そうですね、パーティを組む。元々集められたチームメンバを施策のフォロワーに変えるのです。
あとはじわじわと布教活動というなのクエストをするのです。
と書いているとこれ転生モノのラノベと一緒だと思い当たるなど。でもねぇ、今ある組織は今の価値観でできているからすぐには変えられないんですよ。変えるのは変えたい範囲での裁量を持つロールに立つ人なんですよ。世界観を変えたければ、転生ものの物語の主人公を演じないといけないのです。パターンとしては何度も立ち上がらないといけないのは現実もラノベも同じですけど。
写経で学べるプログラミングといきなり前線配備のプロマネと
子どもがプログラミングの授業で苦労している風だったのでアーキテクトにどうしたらいいものかねぇと聞いてみたら
「本を買ってひたすらタイプですね（ニッコリ」
とご教授いただきつつ
「それ写経じゃん」と返したら
「そうかもしれないですね」
と。
それを子どもに伝えたら自分で本を探してきてAmazonで手配してと言ってきたんですね。こうした気持ちってその気になっているうちに手をつけた方がいいと思ったんですね。自分がそうだから。
それですぐ欲しいのと聞いたらそうだというので近所の大型書店の在庫を検索したら品薄であったのでお店に行ったらAmazonより早く手に入れられるよと教えてあげたら「行ってくる！」と。開店までまだ時間あるけどね。帰ってきたら２冊抱えてきました。
生産ラインとソフトウェア開発の文化的背景の差異
標題がちょっと大げさですけど。
プログラミングもそうですが仕事で使う道具は誰にとっても同じですがどう使うかはそのエンジニア次第です。同じ道具（手法、ツール）なのにどんな風に使うかもエンジニア次第というところが面白いというか悩ましいというか。
生産ラインであれば、決められた手順に決められた道具を基準値の範囲の中で使うことを求められます。設計したとおりの仕様と品質にするために必要なことですし、事故を防止するという安全衛生の観点もあります。
一方、ソフトウェア開発ではフレームワークやプラグインまでは開発標準として指定されてもその使い方はエンジニアに委ねられているというか裁量というか丸投げされているわけです。
まあ、そういう文化の業種なので指定が多いとあれこれと文句をいうエンジニアが多いですけど。便利なプラグインとかは共有してみんなの環境に入れればいいのに。
そうした道具に対する文化的な背景があるということは改めて押さえておいた方がいいと思います。
動くと嬉しい
話を戻してプログラミングは写経で覚えるといいよいうのの1つには、タイプをすることでタイピミスをでバックしたりするけれど動くプログラムを実感することができるということです。
やっぱり動くと嬉しいし。
タイピミスをしてデバッカーでトレースして動きを知ること自体が学習を進めるわけです。
プロマネはやってみる手段がない
さて、このプログはプロジェクトマネジメントがメインなんですけどね、プロマネを勉強する方法でこの写経に当たるものがないのです。
これ、問題でしょ。
練習して学ぶ手段がないんですよ、プログラミングのように写経する場がないんです。プログラミングならPCにコンパイルする環境を作れば動かせるわけです。乱暴に言えば。でも、プロジェクトマネジメントはそうした環境が実践しかないのですよね。
もう、実戦でやるしかないんです。
知っている限りでは、このことを言及している書籍ってないですよねぇ。まあ、ワタシの勉強不足だけかもしれませんけど。
研修やセミナーでワークショップがあるじゃないと思った方もいると思いますが、それケーススタディなんですよ。実際に動かして何度もやり直せないんですね。
ネガティブに言えば、ケーススタディでやった気になれるけれど、現実と乖離がある（モデルケースでやるので）実感が得られないのです。
まあ、こんなことをエントリのネタにすること自体で気づきがあったわけですけれど。さてこれどうするかな。
KPTでふりかえったつもり病と処方箋
普段から取り入れている改善手法をやっているのに同じことがまた起きた、なんでだろうと相談を受けることがたまにあります。こちらからする話ではないので先方が話の流れで話していたらこれどうしたらいいんですか、と。
改善手法は取り入れて続けていても始めてみたばかりだけれどとどちらのケースもあるので改善手法の慣れの関係はなさそうです。
同じ失敗を繰り返してしまうんですが
例として開発の終わった後のふりかえりでKPT（ケプト）を取り入れていて、重大なトラブルに対する対策は必ずやっているが、やった方がいいよね的ないわゆるmustではないwant系の改善テーマについてはKPTをするとやった気になってそのままになってしまう、と。それをどうしたらいいんですか、と。
ふりかえりをしても重大なトラブル以外は誰も事後の進捗をトレースしないから、結局、誰も気に留めないというか後続の開発に意識が行ってしまってなおざりになってしまっているんだろうなぁと思いつくんですけどそれは経験というか年の功なのですかねぇ。
意識づけだけでは履行されない
ふりかえりに限らず、何かを変えたいのなら変えなければ変わらないのです。
例えば、意識を変えようということでKPTのTryをしたとしたとき、意識を変えて何が変わるのかは誰がどう共通認識を持てたのでしょうか。
多くのケースでは意識をすることで改善を期待をしても結果は改善されません。意識づけの共通理解をしてはいないことは意識する個々のメンバが脳内で勝手に思い浮かべるので達成基準が違うし、各人の意識づけだけが言語化されているのでしなければならないという振る舞いに形式化されていないからです。
行動に組み込む
改善をwant系でも期待するのであれば、それは普段の業務の中の振る舞いに組み込まなければ変化が起きません。
want系をやっているかをトレースする方法もありますが、それではお母さん役を作り、そのお母さん役が「宿題終わったの」と聞いて廻るようなものです。つまり、改善の負担を誰かに押し付けているだけです。
夏休みの終わりも近いですが連日お母さんから宿題が終わったかと聞かれるたびに不機嫌になっていたとしたら、それを成人済みのエンジニアに同じことを繰り返すなんて馬鹿げてします。
まあ、バブみがあるという輩がいたら絞めてあげて。お前の給料から宿題終わったかのトレース分を引き落とすぞって。喜んで差し出す奴もいたら世の中広いなーと思うしかないですが。
変えたいことを可視化する
改善しなければならないのは誰なのか。そうした基本に立ち戻ることをして欲しいのです。つまり、エンジニアが改善することで利益を得るわけですから、受益者負担を促せばいいし、改善によりエンジニアが楽になるために変わって欲しいことを可視化すればいいのです。
じゃあどうすればいいか。当たり前のことで驚きはないのですけれど。見えるようにすればいいのです。改善によりエンジニアが楽になるために変わって欲しいことを。
印刷して貼っておけばいいかって。そうしたポスター的な啓蒙で改善されるならすでに解決していると思うのですけれど。もっと強制しないと変えられませんよ。
作業の振る舞い、仕事の手順に組み込むのでそれをやらないと仕事が進まないようにすればいいことは過去のエントリになんども書いてきたのでアレかと思う方もおられるかもしれませんが悩みを新たに持つ新任のリーダは毎年何人も生まれるので、こうした繰り返しも優しさの一つです。
