積み本

トヨタ生産方式にもとづく「モノ」と「情報」の流れ図で現場の見方を変えよう!!

Value Stream Mapping: How to Visualize Work and Align Leadership for Organizational Transformation

リーダになったらそっとやっておくこと

前提として、リーダはプロジェクトマネージャに置き換えても結構です。ただ、マネージャは違うかな。マネージャはマネジメントのオペレータ兼決裁者でリーダはミッションの目的を果たさないといけないから。

手近なところのミッションを持った組織を考えるにはチームが何かと便利で誰でもだいたい同じようなイメージを持てる（はず）なので、チームの中のリーダの人若しくは今この瞬間にリーダになった、とします。

さて、何を気にかけて何をそっとやっておく必要があるでしょうか。

SPOF

SPOFは、Single Point of Failureの略です。そう、１系統しかなくそれが死んだら機能が停止するアレです。チームの中でリーダやプロジェクトマネージャはロールにアサインされる人数から一桁というか機能的役割分担からそれぞれ一人しかいません。

メンバもチームを構成するスキルとスキルレベルの一部分を担うという観点では同じですが、リーダやプロジェクトマネージャを担うだけの人はメンバと比較して代わりを見つけることはたやすくありません。

リーダやプロジェクトマネージャになった人は、そういう意味合いのある役割だということを押さえておきましょう。

リーダがいない…

リーダが、プロジェクトマネージャを担うエンジニアが突如チームからいなくなったらどうなるでしょうか。

そのままいつまで昨日までと同じように作業を進捗させていられるでしょうか。

経験から言えば２−３日は大丈夫。でもそれを過ぎた頃からメンバは仕事の手が止まります。

対外的な段取りをするリーダが不在となり、計画されている会議や検討するテーマをセッティングすることがままならず、誰がどのタスクをすればいいのかもメンバでは決められず、１週間もするとメンバはそろそろやばいのではと気づき始めます。

プロジェクトを継続できるチーム作り

チームのエンジニアが現場から離れる理由は色々ありますが、それがリーダやプロジェクトマネージャに起きるとは誰も考えていないものです。マネージャでさえ、そう。このリーダはプロジェクトが終わるまでは健康で何事もなく推進してくれると思っています。

でも、そんなことはありません。現実にいくつものプロジェクトでリーダやプロジェクトマネージャが倒れたり、離れてしまうことはいくらでもあります。

もしそうなってしまったら残されたメンバが仕事を止めないようにするためにどうしておくのが良いか。

・プロジェクトの計画の元となる考え方を刷り込む
・作業プロセスを作り込んでおく
・決め事、判断ポイントはメモやチケット形式でも良いので判断に至った過程を残す
・セカンダリを指名しておく

 少なくともこのくらいはしておかないと、仮に一時的にもマネージャが代行するにしても過去の決め事は制約条件になるのでリファーできる記録が必要です。

セカンダリを指名することはそっとやるよりは、チームのメンバの役割自体も全部セカンダリを決めておくのがよりベターだし、明示されるので好ましいです。

エンジニアの自由より自律

トラブルを抱えているチームの特徴に意思疎通の欠如があることが多いのですが、そうした事象は当事者のメンバも意思疎通が十分でないことを認知しているにも関わらず、自分からその問題を改善しないというわけのわからないループを回して一向にブレークするつもりがないのはどうしてなんでしょうねぇ。

チームの存在意義を考えれば、存在を継続するためにも目的を達成しなければならないのに、チームを構成するメンバが自らそれと反することをし続けるということはただ自分で自分の首をジワリと締めているだけなのに。

そうしたチームを立て直さなければならなくなったらどうしたらいいのでしょうか。

砂場を作る

物理の砂場ではなくて、幼稚園にある砂場をチームのワークプレースに設けます。場として。

幼稚園では、外で遊ぶ時間は園庭で好き勝手に遊んでいたのではないかと思うのです。ワタシの記憶も好きに遊んでいたのではないか…と。友達（？）と一緒に遊んだり、一人で遊んだり。

チーム活動は役割に応じて、その時々の出番に必要なメンバは全員参加してもらわなければなりません。いつでも顔を突き合わせられる場が明示的に必要なのです。

認識させる

意思疎通が不足しているチームに必要なことは、自分がすることをする前に伝えることです。

自分がすることを伝えることで相手に認識させることで関係性を再構築します。得てして、エンジニアは独りよがりの行動をとることが多いいのは、自分を基準とした判断に基づいて行動することです。

誰か他のメンバから働きかけを待っているのでは自分が担当する仕事の成果を出すには至りません。チームで分担をするのだから。

他のメンバとの関係性を作り、保つためにも自分の存在意義を示す必要があるのです。

自律＞自由

チーム活動では個々の判断に基づいて行動されては纏まるものも纏まりません。チームの基準づくりが必要で、そうしたチームの決め事が必要なのは一人で活動することを否定しているからです。

こうした行動の基準を変えることはメンバの行動規範を変えることにつながりますが、チームで活動する上では個人の自由なんて二の次です。チームとして成果の出るルールに基づく行動の強制と結果が必要です。

自由に活動して結果を出しているチームの事例があるとしたら、自由の裏で見えていないところでチームのために守らなければならないルールがあることまで想定しなければなりません。

技術を収入に変える

ある場でエンジニアのキャリアについて話をしていたとき、キャリアとしてというよりは転職をする場合に考えなければならないコストについて言及したところ思いの外共感を得たのが（それは自分で気づいたので当たり前だよねぇなどと思っているので）以外な反応でした。

それでその場では上がらなかったキャリアの中で大事な収入について思っていることをつらつらと。

何も月曜日から重そうな話をしなくても、と思うのですが乗りと勢いで。

収入は制約されている

エンジニアとして自分の関心事とアサインされる仕事が一致していれば誰もジョブアサイン的なことで悩む必要はないのです。

現実問題は、関心事とアサインがずれまくるのです。そのズレをある意味自己消化するためのハックとして仕事の楽しみ方を学ぼう、となるのであって関心事にジャストミートするならそんなハックも無用です。

ところで、仕事にアサインされ、成果を出すことで収入が生まれます。その成果も事業にとって大きな貢献であればそれなりに評価され、収入に反映されます。

このことから収入は仕事のアサインに制約されているということができます。

関心事は収入に結びつかなない

一方、関心事はあくまで個人の興味であって事業と関わりを持つとは限りません。偶然にも現行の事業に関心を持つこともあるかもしれませんが、そういったマッチングが多いとすればもっと専門家が多くいても良いと思うのですが、複数の観測範囲ではエンジニアのどこのエリアでも登壇などで見かける人は決まった人が多いです。

特に新しい技術の関心事については、事業化の可能性を判断する前（なら随分進んでいると思いますが）や全く事業にするなど誰も考えていない場合は、諦めるか自分で事業を立ち上げること方策をしなければなりません。仮に活動をして事業化にたどり着いたとしてもそこから収益を得られるまではそれなりの収入にしかならないでしょう。

＃多くの組織では事業化するだけでも十分に評価対象だとは思いますけど。

仕事を収入に変えていく

それでもただアサインされることを待つのではなく、関心事若しくはそれに近いことを自分の仕事としてアサインされるように、事業の行き先を中期計画などを読み込んだ上で自分に都合よく解釈して、事業に反映するようなポジションや技術を先回りして組織の先駆者として推進することはエンジニアの関心事を収入に変えていく錬金術の一つです。

事業ですから必要とされる価値を提供することは、組織の中で評価される一番まっしくぐらなチートですし王道でもあります。

図式化すれば単純なことで、この図式に関心事のキーワードをプロットして、それに事業からのリクエストを反映してどれを選択すれば良いかを評価すれば良いのです。

「尊敬」という言葉を持ち出さないと成り立たないようなチーム運営ってなに？

はてブがついてたスライドを見ているとチーム開発というテーマの中に「尊敬」の標題が出てくるのです。

これは個人的な受け止め方なので同意される方は限られるとは思うのですが、チームでシステム開発をする際に、「尊敬」「リスペクト」というキーワードが出てくるとなんで「尊敬しないといけないの」と思うのです。

もちろん、ワタシを「尊敬」してほしいなんて1ミリもないのです。お互いに

「尊敬なんて言葉を持ち出さないと成り立たないようなチーム運営ってなに？」

と思うんです。

尊敬の前に一個人として認識しているの

まず一つ目の違和感に、チームのメンバを尊敬する前に一個人として認識して受け入れているのかなぁ、と疑問を持つのです。

成人済みも大分過ぎて、もう初老なのではないかと思うお年頃ですが、周りを見渡してみるといい年過ぎた方々がまるで10代から成長していないのではないかと感じる所作をする方も少なくないので大人がもっともらしいことを言うのはあてにできないな、と。

一人でできないから人の力、スキル、技術力を集めてチームにするのです。

誰一人同じ経験をしていない、同じ力量のエンジニアはいないところで、一つのチームとして成果を出さなければチームの存在意義はその瞬間にパージされるのです。

一つのチームはチームとしての成果を得るために存在すると言ってもいいです。そうしたことを理解していれば、どんなキャラであろがチームとしての目的を達成するためには欠かすことができないと言うのが大前提だと思うのです。

そう言ったことを背景にすれば、色々な特徴を持っていたとしてもメンバとしては、

「個人ごとに特性を持った一人のエンジニア」

であると受け入れることが必要なのだと思うのです。

尊敬されるよりロールの責任を果たす

チームとして欠かすことのできないメンバで構成するチームなのです。だから、個人として特性を持ったメンバを受け入れる。

この受け入れるは

「そういうエンジニアなんだ」

というレベルです。

それ以上でも以下でもないのです。あるがままのキャラを理解する。でも、受け入れたからと言って何か気を回すこともないのです。

チーム活動なのですから、チームとして成果を出さなければなりません。それがチームの存在意義なのですから。

あとは、チームとしての成果を出すために活動をするだけです。そこに必要なのは成果であり、一人ひとりが担うロールの役割を果たすことです。

仮にあるメンバがチームの活動で成果を出すことに苦労していたら、専門家なのだから、ロールだからと突き放すことはせず、チームにとって必要な行動をその時のチームの状態、作業のプライオリティで判断して課題解決をするのです。

そこに「尊敬」は不要です。

必要なのは、

・一個人としての特性を受け入れること
・ロールの責任を果たすこと

です。

もっとプライオリティの高い行動指針は、

「メンバはチームの存在意義を達成するための意思決定する」

ことだと思うのです。

積み本

D25 地球の歩き方 インドネシア 2017~2018

D21 地球の歩き方 ベトナム 2016~2017 (地球の歩き方D21)

B01 地球の歩き方 アメリカ 2016~2017

バッチは小さく

バッチとはバッチ処理のバッチですが、ここでそのバッチ処理をするリソースはエンジニア自身の作業を対象に取り上げます。

そういえばバッチはもともとどのような意味があったっけ、と思って辞書を引いてみると

dictionary.goo.ne.jp

《名詞》(1)一束，一組；一団，群れ (2)（パン・陶器の）一焼き，一焼き分 (3)【コンピュータ】バッチ

（3）にコンピュータとあるのでこの意味で良いですね。さてコンピュータ用語の意味としてはどの意味を指しているかといえばやはり（1）でしょう。ある塊をバッチと呼ぶわけです。

ではバッチ処理というとある塊を処理する、という意味に変わります。もちろん、コンピュータですからデータを処理するのが機能ですから、データの塊を処理する機能がバッチ処理になるのです。

ではエンジニアはバッチ処理をするかといえば、人の所作を観察することでわかります。作業をアサインされ、情報を集め作業を行い成果を出すのでエンジニアの作業もIPO（input/process/output）になっているので人も作業をするのはバッチ処理をしているということができます。

バッチサイズ

事務処理系、例えば管理会計の集計処理などに限らず、バッチ処理は業務要件から制約を受け、業務で求められるタイムスパンで処理を求められます。

処理には日次、週次、月次などの処理の単位があり、要件によりどのスパンで処理をするかを洗濯します。

こんなバッチ処理はいやだ

 もし日次処理、週次処理を行わずいきなり月次処理だけするとしたら何が起きるでしょう。

考えられることはデータ量がわからないといつ終わるかわかりません。

さらに、月次処理の最後にデータの不整合が発生したら今やっていた月次処理はデータの不具合の扱いを決めてから、最初からやり直しです。

 だから、そうした工夫として日時や週次で小さい時間で処理を済ませておいて、扱いたい集計の単位で括り直すことで小さな時間で処理を確実に完了させるのです。

エンジニアは仕事のバッチサイズを考えているの？

エンジニアが仕事の対象としての処理設計では上の図のように処理の単位を小さく分けて処理する工夫をするのに、エンジニア自身は仕事を小さく分けて作業をしているでしょうか。

日次の単位で作業をせずに月次の単位で作業をしていないでしょうか。もしかすると作業計画自体の単位が大きすぎるのかもしれません。

作業自体のサイズが大きすぎると赤い×印のように終わる直前になって×がわかることになるのです。

でも、×とわかってからでは遅いですよね。それまで掛けた時間、コストは戻ってきませんから。

事務処理のバッチ処理を小さな括りで処理するように、エンジニアの仕事も小さくして、小さいサイズで処理をして結果を検証して、次に進めたほうが確実時に終わりますし、途中で×が出たとしても、それまでの処理結果はパーになることはありません。

×になった処理の入力を整えるか、×になった処理をピボットして別の処理に置き換えて進めれば、それまで終わっている小さな作業が無駄になったりしないのです。

エンジニアのバッチ作業も小さくしましょう。