意識低い系エンジニアこそ価値の居場所を作る

カンファレンスや勉強会に参加しているようなエンジニアを十把一絡げに『意識の高い系エンジニア』だよと聞いたときは、そういったように見えるのかと思ったことがあったが、『お前もな』と言われたときは『はっ、何いっているの』と思ったのは事実だ。意識の高い系のエンジニアは、こう、もっとパリピーぽくawsうぇーいとかazureわーい的な感じだと思っていたのだが、どうやら違う切り口でこられて面喰らった。

それはさておき、生存戦略には居場所を選ぶことが必要だ。居場所なので、移動可能だから、居る場所を変えることは差し支えないし、自分の自由意志で判断して構わない。

この居場所は物理でもあり、概念的なものでもある。

多くのエンジニアは、ご自身がお持ちの実践知や知見に対する価値を低く評価している。であるから、お持ちの価値を外にひけらかすようなことには消極的である。

自分の見解を申し上げれば、皆さんの知見や実践知はいくら頑張っても自分にはできない、得られないものだから、自分にとって有用であったり、気づきを与えてくれるだってきっとある。そう思っていなければ、外にいってエンジニアの話を聞いたりしない。

自分に必要だと思った課題解決の手法を知るために、それなりの情報を必要だろうと考え、カンファレンスやいくつかの勉強会に赴くのはそこに有期限性の物理的な居場所があるからである。そうした場で自分の仕事での課題解決に必要な何かが1つでも得られればその場に出向いた価値がある。

そうした機会を分けていただけるのもエンジニアなのである。

もちろん、解題はそのうち解消する(だろう)し、課題1つ解消すれば次の課題が出てくるのが課題の性質である。そうすると、同じ場所でい続けても課題のスイートスポットからずれていく。自分から動いて、スイートスポットに当てるようにしなければならない。

そのうち、そうした活動を通してそうした活動のスペースを気持ちの中で持てるようになる。ここで、自分の持っている価値を流し込み、価値を育てる。

 

 

 

嫌われた『なぜなぜ5回』

もう、時効なくらい前の話だが、部下になったプロジェクトマネージャやそのチームのメンバとランチを摂っているときに、プロマネがこんな話を切り出してきた。

以前の配属先で何某かの仕事をするときに、どうしてそうやっているかを知りたくて、そのとき知っていた『なぜなぜ5回』を使って続けざまに質問したのだという。

『こうやってくれ』
『なぜそうやるんですか』
『こうやることにしている』
『なぜそうなったんですか』
『理由は知らない』
『なぜ知らないでやれるんですか』
『いいから言われたままにやればいいんだよ(怒』

大分前のことなので正確性はゼロに近いかもしれないが、いずれにしろ、自分のターンが乗ってくると早口になるタイプなので、同じような口調でやったのだろう。

プロマネ曰く、『どうしてそうやるかを答えられないなんて』的な物言いをしていた印象が残っている。

自分は、そうした物言い自体、なんというか、人に尋ねるのだから相手が話したくなるように聞けばいいのに、と思ってしまう。

本来、なぜを5回も繰り返し聞くのは、起きた出来事から真因を探り、起きてしまった振る舞いの土壌になっているルールや暗黙の文化を炙りだすために使う道具のはずである。

そう使わなければ、なぜと聞いても意味がないし、聞かれる方は次々と責められるように感じても仕方がない。心理的に圧迫されるのだから、ストレスに弱い人は年齢に関係なく怒るか、自分に非がなくとも自分を責めてしまうかもしれない。

そのプロマネは『なぜ5回』を使って、相手の反応を楽しんでいただけだ。これを仕事場でされては堪らない。

別に『なぜ』を使わなくても、知りたいことは聞けるし、知っているかも知ることができる。

『こうやってくれ』
『そうなった経緯がわかる資料残ってますか』
『こうやることにしている』
『(経緯もどうしてそうやっているかも知らないんだな)引き継ぎされたんですか。じゃあ経緯はわからないですよね。引き継いだ方はもういないんですか』
『いない』
『(これはいくら根掘り葉掘り聞いても何も出てこないな)誰か知っていそうな人ご存知ありませんか』
『Aさんなら知っているかもしれないなぁ』

 このコミュニケーションの目的は、経緯を知って、付加情報を手に入れておけば、自分でその資料の範囲で対処できるからとか、業務の知見を増やしたいとか、そういった目的を持っているはずである。

素朴に、どうしてそのような業務(手続きや手順)になっているか、自分のこれまでの実践知とは違い違和感を覚えたからかもしれない。ここはこうやった方がいい、的なものだ。ただ、背景がわかれば理解できることもあるし、実践知から工夫した方が良い点も薄々気づいているのかもしれない。

どんな手法でも同じなのだが、その手法の狙いを理解できるとアプローチは自分のいる環境に合わせて使うことができる。自分の思い込みで道具を使うと怪我をする。

 

 

 

『正しい』を使うのは小さく、早く進めるようになったアプローチと矛盾しているのではないか

それでいつ頃、何かがあったのだろうかと思い出してみようとしてもその辺ははっきりしない。自分はいい加減な人間なので、キッチリとしていないから仕方がない。一緒に働く人からしたら、ところどころ細かく突っ込んでくるので『何を言っているんだか』とつっこまれるかもしれない。

何れにしても、仕事で『正しい』を使わなくなった。正確に言えば、システム開発では、プロジェクトマネジメントでは、と限定した方がより正確かもしれない。

なぜ『正しい』を使わなくなったか。

それは、システム開発の目的である製品やサービスを手に入れるための活動において、このやり方でなくては目的を達成できないとか、目的の製品、サービスはこれだとプロジェクトが終わりもしないで言い切れないからだ。

第一、プロジェクトオーナでさえ、その目的である製品やサービスをみたことがないのであるから、何を根拠に正しいと言えるのか、ということである。

様々なインプットを必要なタイミングで集め、複雑な制約や身勝手な前提条件を踏まえてアウトプットを段階的に具体化する活動において、何を持って正しいと言えるのか。

『正しい』と思う方が居られてもそれは一向に構わない。そう思われる方はそう思っていていただければと思う。

でも、『正しい』とお思いになるその人の中では、である。

それを製品やサービスに押し付けられるのは時期尚早であるから、しばらく待っていただく。何かしらの動く物を見てから、プロジェクトオーナがご判断されれば良い。『正しい』と振りかざす方がプロジェクトオーナでなければ少しお静かに。

一方、right personという言葉を使うときがある。これは、何らの専門的な知見や権限をお持ちでこちらにその見識がない場合、意見照会をさせていただく相手になる。例えば、手続き、法、業界スタンダード、など、解釈が困ることに対してご意見を伺う。

でも、やはり、そういったコメントを横に置きながら、プロジェクトとしてどう判断するかはこちらで決定する。

コメントに照らし、判断するタイミングに入手できる情報で。

などと書き進んで、多分、自分は意思決定する役割をするようになってから、『正しい』は使わなくなったのだろうと思う。

ではなぜ使わなくなったかというと、『正しい』は言葉が強すぎるからだ。それ以外を認めない、余地がないように感じられる。『許容できる範囲に収まっている』くらいでしか実現できないのではないかと思う。もちろん、法などがあって、それにピタリと一致していなければならない場合は、準拠している様でなければならないのは当然であるが。

それに『正しい』を使うエンジニアは、拠り所を探し、それに依存しているのではないか、とも感じる(そう受け止められる事象を知っているだけの話である)。

システム開発のあちらこちらに『正しい』があるわけない。ないから不確実性の中で手探りで、できる限り大きな失敗をしないように小さく、早く進めるようになったのではないか。

 

 

メモの魔力 The Magic of Memos (NewsPicks Book)

メモの魔力 The Magic of Memos (NewsPicks Book)

 

 

声の大きい人もしくはリーダ的な人の仕事を上手に取り上げる

良いと思って導入したプラクティスが機能しない。おかしい。このプラクティスはチームの内情を可視化したり、スループットをよくする筈ではなかったのか。カンファレンスやスライドで共有されているような効果は感じられないな、うちには合わないんじゃないか。これもまたダメか。

もし、現場でこのような事象が起きていたら、そのプラクティスを導入した人はどんな立場で、そのプラクティスをどのように運営しているかを観察してみよう。

それがあなた自身だったら、なぜ導入しようと思ったか、どのように運用しているか答えられる筈だ。ただ、導入した理由も、運用も答えられたからと言って、導入して解決したかった理由を解消できるような道具の使い方をできているかといえばできていないし、これから他のプラクティスを導入しても何も期待するものは得られないだろう。

例えば、朝会や昼会のようにデイリースタンドアップミーティングを導入し運営しても、一向にチケットが進まない、進捗が進まない言い訳じみた説明ばかり聞く、メンバが積極的にならないなどの症状がみられたとする。

原因は何か気づいているだろうか。

原因の1つは、声の大きい、そのデイリースタンドアップミーティングを仕切っているあなたにあるかもしれない。

可能性があるなら、あなたは一度、デイリースタンドアップミーティングの立ち位置を変えてみたらどうだろうか。

どうせ、今は期待するような効果を得られていないのだから、それがあと1週間続いたとしても何も変わらない。

だったら、変えてみよう。

1つは(あなたはそう思っていないかもしれないが)あなたの大きな声を黙らせることから始める。運営をチームのメンバに全部任せよう。

もう1つ、物理的に立ち位置を変えてみる。デイリースタンドアップミーティングをやる輪から2−3歩引いて全体をみられる位置に下がって観察しよう。

これはデイリースタンドアップミーティングを別のプラクティスに置き換えてもいい。

2−3歩引いた位置からでなければ見えないこともある。

それも1つの収穫だが、声の大きい人はリーダ的な発言や場を仕切りたがる。それを剥がすことも必要である。面と向かっては言い出しにくかったり、導入した期待する効果を得られなければ、輪番制にするなどと恣意的にメンバに移譲させる。

あと、あなたは任せたのだから、論評をすることも控えよう。それでは変えた意味がない。論評したくなった理由の真因を確かめ、それをどうしたらチームから遠ざけたり、回避させることができるかを考える方に注力した方が良い。

 

 

 

 

 

 

これをウォーターフォール型のシステム開発手法と呼んでいいのだろうか

自分のプロジェクトでは次のプロジェクトのポリシーを伝え、価値観を共有できるメンバと推進する。価値観を共有し定着するまで何度も、それこそ毎日伝える。価値観を伝えるだけではなく、エンジニアの作業プロセスに組み込み、その価値観に自然となじめる環境で一緒に働く。価値観を理解して行動するメンバにはメンバを守ると伝え、メンバ自身のエゴに基づく行動をした場合は、一切擁護しないと伝える(もちろん、程度もあるし、伝え方は相手を尊敬した上で)。

作業プロセスや成果物を変えようとするとき、その変更で価値を失わないならいくらでも変えていいと宣言する。プロジェクトマネージャの知っているやり方は、知っている実践知から作ったものだし、第一、成果物を手に入れる作業プロセスやチームのルールはチームメンバであるエンジニアのものだ。目的である成果物の価値が損なわれないなら、いくら変えてもらってもいい。

成果の価値は出来上がればすぐにでも届けたい。もちろん、実現可能なスケジュールで、自分たちのチームで合意した品質を満たしていなければならない。

成果の価値の変更はあって当たり前だ。なぜなら、それは誰も見たことがないものをチームで作ろうとしているのだから。見たことがないから変わることは当然だし、それはそれを必要とする顧客も、我々チームも同じだ。ただ、価値に向いているシステム開発手法をとると手法の制限によりどこまで変えられるかと言う制約がつく。予め想定がつくなら、それに見合ったシステム開発手法を選ぶのもエンジニアの成果に対する価値観の現れだと考える。

時間を長く取ってしまうとリリースするまで考えることができそうだが、実は別の割り込みが入ってしまうためいいことはない。だから区切りを設けて成果を形作っていく。成果をケーキの断面を縦で届けるか、横で届けるかは、成果の性質による。ただ、横にすると全容を理解するまでに時間がかかってしまう。だから、アウトラインからみせ、動くものを見てもらう。これは顧客にそれで業務が成り立つかを判断する材料にしてもらう意味合いを持つが、チームでの実現性を検証する意味合いもある。

自分のプロジェクトでは、業務を取り扱うから業務を教えてもらう。知っている業務の知見を絵に描き、それをどうしたいかを考えてもらう。この方法の良いところは、成果の作り方の一番早い方法を知っているエンジニアが早く成果を届けられること。顧客は雛形の業務で何をするかを決めてもらえばいい。まだやったことがない業務なら、学びながら組織の情報を集めて割り当てれば、技術的な方法を考え示すことができる。こうした場は濃厚に持つ。それこそ本業に影響するくらい割いてもらうがこれは顧客の明日を疑似体験してもらっている。だから、真剣に作り上げる。でも、やったことのない業務だから、多分こうだろう、と言う前提でしかない。それを昇華させるために、組織内に向けたアクションを取ってもらうことで使える業務になるかを判別してもらう。これをプロジェクトの最初の工程からやる。

こうした活動は、顧客を含めた一つのチームとして一体感を作っていく。もちろん、対面で。

顧客の上司への報告や属する組織の都合で色々と管理のためのレポートも作るが、それはそれを必要とする人がいるからだ。

自分たちのチームはこれをウォーターフォールと呼ばれるシステム開発手法でやってきた。

ところで、これをウォーターフォール型のシステム開発手法と呼んでいいのだろうか。

 

 

 

 

 

 

カンバンあるある病からの脱出

カンバンスキーなので、カンバンを使っているのを見ると、どのように運用しているか興味を持つ。

あるチームのカンバンがあるのを知って見たら、これはすごい(褒めてない)と思わず黙り込んでしまった。カンバンを使っているチームの中で、カンバンが機能していればどんなカンバンでも、運用でもいいわけだが、2−3日立ち会って見たら、どうも機能していないし、カンバンを見ながらやっているデイリースタンドアップミーティングも暗い。重力が二倍くらいあるのではないかと思うくらい重い。

自分から見えるDSMの風景は、こんな風に見えていた。

  • ToDo…チケットの中身が曖昧のまま。Readyな状態になる前にDoingに突入してしまう。
  • Doing…仕様や完了の定義が曖昧、つまりReadyでない状態のまま突入している。アサイメントも、リーダが割り当てている(これはこれで別の問題があることを認識していながら一方リーダが指名すると言う矛盾)。
  • Done…作業が終わっているからDoneに移すのだが、本人が移すことは少ない。リーダを含めた1−2名でDoneに移している。これだと終わった!を時間できない。

 

自分がそれとなく会話したことは以下のとおり。

  • Doingの中から今日終わらすのはどれかを聞いてみる
  • 1日の作業時間とDoingのチケットの時間で定時を超えていないか聞いてみる
  • 期限が先なチケットはToDoに戻したら、と促してみる
  • 何が終わったら終わりなの、と聞いてみる
  • しばらく、新しいDoingを増やさないように促す
  • そんな中でもDoneしたら、労いの一声と感謝を伝える

 

少し経つと、カンバンのDoingの列に隙間ができてくる。それが進むとチケットが一人2枚くらいまで減ってくる。得られた効果は次のとおり。

  • 1日一つとか、2日で1つのチケットとか終わるようになる。まだチケットのチャンクが大きいような気がするが、複数の部門を跨る仕事が多いのでチケットに複数部門を書き込み、中で消し込みしているので進んでいる実感は得られやすい
  • たくさんチケットを抱えて、全部終わらない病から抜け出せる
  • どれか、誰かのチケットがDSMごとに完了するのでチームで進捗感を体感できる
  • Readyな状態を気にするようになる
  • WIPの流量をコントロールできるようになっている

 

別の課題がある。それは上記で伏線を張っているのだが、リーダがアサイメントしていると言うやつだ。これは実はリーダ役が自分から属人性やSPOFを作っている。これに気づかないのはリーダに考える時間が少ないことが原因なのだろうとみている。

この課題の解消は、やってみたいと言えるくらいのReadyな状態にする習慣づけだと思っている。

手順がある、自分の時間の空きを(Doingが減ってWIPも制限されたから見えてくる)知ることできるようになると、助けよう、と言う気持ちになってくれれば嬉しい。

 

 

 

『この会社で初めて尊敬できる人と仕事できました』と言われて

話ながら、ランチから戻るエスカレータ上で『本当ですよ』と言われたことがある。ご本人は専門職の方なので、ご自分の仕事の能力は素晴らしいのだろうが、着任してから色々とあったようだ。

自分とチームを組むようになって2週間もしないうちに、懸案だったプロジェクトが動き出した(ように見え始めただけだが)ので、鬱積してたものが解消し始めたのかもしれない。

自分としては、そのプロジェクトを含めた業務領域をやって欲しいと依頼を受けたのでそれをやっているのだが、ご本人は現状のチグハグな業務の片棒を担いだと責任を感じているのかもしれない。

専門性を持っていると当たり前だが、専門の知識を持っているから、その専門性から『こうしなければならない』と強く思う。これは自然なことだ。

だが、その専門知識のベストプラクティスを適用しようとする現場は、適用前であるからそれに耐えられる体力も能力も持ち合わせていない。

こうしたプロジェクトでは現場を知っているメンバを入れるから『そのままでは、現場は受け入れられない』とあたかも代理のように、障害になるような意見を言う。

それでも意見を並べて、双方の理解に務め、どこに着地すれば良いか協議できれば良いのだが、そうしたプロジェクトでは得てしてスケジュールの制約を外部から受けたプレッシャで優先が納期になってしまう。

結果、運用できない業務が出来上がり、運用フェーズで自分の首を締めることになる。

そういった状態で入っていくのはとても難しいことではない。

なぜなら、今以上に悪くなる要素が少ないからである。

運用に入っているといってもマイルストーンと外部に依存するスケジュールが決まっているだけで(これも動かせるものもある)、どうにでもなる。

と言うか、課題を設定し、スコープを決め、ToDoに優先順位をつけ、ざっくりとした且つ自分のリソースとあてにできるだろうリソースの半分程度でできるスケジュール感を見切れれば、ひとまずプランニングはできたようなものだ。

ある意味やらかしたご当人たちには不憫な思いをしたんだねと言うスタンス(実際そうだろうし、味方である)でインタビューして背景をその人ごとに見えていた(過去形)風景から得られる情報を手に入れ、補強する。

何一つ魔法は使わないし、魔法を使えるほどの器でもない。やることは当たり前のことをやるだけである。

  • 仲間として話す(心理的安全性を提供する)
  • 過去の出来事はその発言通り受け止める(否定しない)
  • 収集した情報は可視化する(マインドマップなどでMECEに整理する)
  • 時期感を可視化する(マイルストーンとして)
  • なんでも共有する
  • 笑顔で接する
  • 主要なステークホルダからもヒヤリングする(本当のニーズの確認)
  • できるリソース、時間、スコープを確保する(背水の陣出始めない)
  • ランチを一緒に食べる(できれば1回ひとりに絞る)
  • 大丈夫だよと安心させる

当たり前のことが当たり前にできない現場が多い。後から入る人が立て直せるのは、第三者の視点を持っている限り、実現可能性は高い。

 

 

 

 

 

公式ガイド&レシピ きのう何食べた? ~シロさんの簡単レシピ~

公式ガイド&レシピ きのう何食べた? ~シロさんの簡単レシピ~