『いいですね』から話せば伝えたいことを聞いてもらえる

あるチームは年齢層が高く、それぞれの専門性が尖っていて、何か裏も取らずに言おうなら「素人なのですが、その○○については…」と例の物言いで始まるのだ。気が抜けない。実際はそんなニュアンスで、なのだが。

そういった中で学んだことがある。その学びを実践できるようになるまでには、随分と時間がかかったというか、時間掛け過ぎじゃないかと思わなくもないが、それでもやはり、学びを実践して上手く使えるようになるとニンマリとしてしまう。

自分の考えと違うことを言っているときに

 仕事を任された以上、自分の経験から満足できるアウトプットをしたいと考えるだろうし、実際、自分の裁量で資料のレイアウトや自分で考えた流れに言葉を選び、資料を作っていると思う。

コードもこれまで経験してきたやり方や、やってみていい感じのスタイルで処理を書いていると思う。

そうして持ち寄った資料やコードを説明したり、レビューにかけたりしていると思う。

さて、メンバが作った資料が自分の知見から言えば、ああした方がいいとか、こうした方がいいと思ったとする。

「○○さん、それじゃダメですよ。そこはこうしないと」

せっかく、自分の意見を言ったのに、反応が悪い。なんか他のメンバも微妙な雰囲気に感じる。なぜだ。自分は自分の経験から『良い』と思ったやり方を教えただけじゃないか。結局、自分が意見したコメントは受け入れられなかった。

なぜだ。

自分の意見が受け入れられない

 エンジニアなのだから、議論するテーマについて自分の意見があれば、それを発言するのはチームのためにもなると考えるのは普通のことだろう。

実際、それそれのメンバが経験して持っている経験知を共有することで、他のメンバがその知識を使ってくれれば、同じ技術レベルに近づくだろうし、逆のシチュエーションになれば自分の勉強にもなって、それこそ、メンバ同士で相乗効果が生まれるのだ。

では上記の会話でなぜ意見が受け入れられなかったのだろうか。

自分が経験してきた中で、より良いと『思った』意見を伝えたいままに受け入れられるケースと上の会話のように受けれらないケースがあった。それが今は大体の意見が好意的に受け入れられるようになった。

聞く耳を持てない

それまで、つまり、学んだことを思うように、自然に振る舞えるようになったのは、最初の一言を変えてからだ。

「こんなスケジュールで進めようと考えています。何か意見ありますか」

「そんなスケジュールじゃダメですよ。このケースはどう考えているんですか」

 つい、こんな風に言いがちだけれど、こう言ってはいけない。言っていることは間違っていないが、こんな風に言われたら気持ちよく受け入れてもらえるわけがない。

立場を入れ替えてみよう。半日かけて書いたスケジュール案をいきなり全否定されるわけだ。素直に聞く耳を持てるだろうか。

さらに、自分が考えたスケジュール案に対して、足らないことを言われるだけで、じゃあ具体的にはどうすればいいかと質問に質問で返したくなる。肝心のアドバイスも全くないのだから。

こんな物言いをされても素直に意見を聞けるのは相当の熟練者か、成果しか信じないツワモノのエンジニアだ。

マジックワードを使う

 自分が学んだことは、ある意味マジックワードを手に入れたことに近い。もし、自分と意見が違う時にはこんなマジックワードを使う。

「こんなスケジュールで進めようと考えています。何か意見ありますか」

「いい感じですね。そうだ、○○はどこに入っているんでしたっけ」

マジックワードと言う言葉を使ったが、大したことは言っていない。ただ、この言い方をすると100％は言い過ぎかもしれないが、指摘したことは必ず入れてもらえるようになった。

二つの違いは何かを言えるだろうか。

「そんなスケジュールじゃダメですよ。このケースはどう考えているんですか」

「いい感じですね。そうだ、○○はどこに入っているんでしたっけ」

単純なこと過ぎて返って気づかないかもしれない。シンプルで単純な構造の方が気がつかないものだ。

前者は『否定』から入る。それも全否定だ。後者は『同意』から入る。それも労いが感じられる。

でも本質は、そのあとの文章が受け入れらるかどうかだ。足らないケースを反映させることが発言の目的なのだ。だから、『このケース』を反映してもらわなければ発言した目的は達成できない。

後者はどうだろう。『○○は』と欠けているものを具体的にしているのは同じだが、考慮されているだろうけれど、記載を忘れているのか、書き忘れか。どちらにしても考慮されているんだよね、と確認しているだけと受け取れる。

後者は実際、考慮漏れだったら、素直に『あっ、忘れてました』と反応するだろう。考えていたとしても書き忘れていたら素直に『ありがとう』と言えると思わないだろうか。

 繰り返すことになるが、発言する目的は言ったことに対して聞く耳を持ってもらい、それを実行してもらわなければ発言した意味をなさない。

マジックワードを使おう。

あなたソレでいいんですか(1) (イブニングKC)

システム開発で一度も失敗したことがないPMが実践していること

先日、facebookで元部下が誕生日だとわかり、久しぶりに会うことにした。facebookの良いところは、友人などの誕生日を教えてくれるところだと思う。流石に一人ひとりの誕生日を聞くことはないし、でも、知っていれば飲む口実が作れる。ソーシャルネットワークでは友人の近況を投稿から知る機会があるので物理的に会っても久しぶりな気が全く起きないが、それでも会話することでソーシャルネットワークではかかれないリアルさを知ることができる。

かれこれ2年振りくらいに会って会って、近況をお互いにとてもフランクに尋ね合う。自分は上司なんていっときのたまたまマネージャがロールの人くらいしか思っていないので、所謂、上司風を吹かせなかった（つもりだ）から非常にタメ口ウェルカムである。

そんな感じで色々と注文した肴を突きつつ、ふと、質問をされた。

「そう言えば、プロジェクトを一度も失敗したことがないんじゃないですか。そんな話は誰からも聞いたことがないし」

突拍子も無い質問をされると理解するまで時間がかかるが、これも言われてみればその質問のとおりである。自分がやってきたプロジェクトで所謂（QCD）失敗したことがない。

「そう言えば、そうだね」

「コツを教えてください」

そう言われても、である。やることを終わらせる。約束したことは履行する。ダメそうなら相談する。つらつらと思いつくことを言いかけるが、少し、空想する。頭の中の記憶を引っ張り出しても上手く言えない。

なぜなら、計画が計画したとおりに進むように色々と手はずをするからだ。こうしたことをそのまま伝えても多分、本質は伝わらない。もう少し、具体的にした方が良いし、箇条書きぽく短く、単純にした方が良いのだろう。

オジサンになって嫌われるのはくどくどと長ったらしく話すことだ。

• キーとなる人的リソースを揃える
• スコープを明確にする
• チーム・ステークホルダと確認するプロセスを回す
• 曖昧なまま手をつけない
• 上手くいくなんて思わない

少し上の空間を眺めながら、こんなことを言ったはずだ。システム開発は技術を持ったエンジニアで成り立っている。プロジェクトだけの観点で言えば、プロジェクトの制約条件、前提条件を満たすことを確認して始めなければならない。その筆頭なのが、エンジニアの技術力である。チームとしてプロジェクトが必要とするスキルセットとレベルを揃えていなければキックオフしてはいけない。

スコープが明確でなければ同じように始めてはいけない。定量的な仕様若しくは定性的でもキャップがかかっていることを確認しなければならない。それでもスタートするのであれば、何が起きるかリスクを識別し、プロジェクトのコンテンジェンシプランを作ってから始めなければならない。

チームメンバとも然り、ステークホルダである顧客とも然り、活動ごとにゴールを確認してそれが終わった状態であるかを確認するプロセスを回さなければいつまで経ってもその活動を終われない。その状態だと次の活動、工程に突入できない。見切りで突入した途端、終わっていない活動にリソースを取られたまま次の活動のリソースが足らずに始まるので混乱するだけだ。そして全く成果が出ず、曖昧なまま、さらに進んでしまう。良いことは何一つない。

曖昧さを残したまま進めてはいけない。システム開発はコードを仕様に沿って書く。数値や文字列を比較し、操作する。曖昧さはコードで表現できない。曖昧さをなくすために活動の工程を分割し、詳細化を図っているのだし、曖昧だから小さく、短い期間で作るプロセスを回し、都度確かめるのである。その点で言えば、これが欲しいのかとと尋ねるよりは、これが欲しかったものかと尋ねられる手法の方が良いのは決まっている。

何より、いくらプロジェクトチームのメンバが精査したとしても、プロジェクトの骨格は自分の経験と他所のアイデアを思いつきで混ぜて考えた考えでしかない。何より、計画はそのプロジェクト用に初めて作ったもので、どこでも一度も試したことがない。この事実をもっとプロジェクトマネージャもプロダクトマネージャもスクラムマスタも認識すべきである。つまり、上手くいく確証なんてどこにもないのである。基本は、大局的は楽観的に、局所的には悲観的に物事を考える志向が必要である。

しかし、失敗していないのはこれまでであって、次も失敗しないとは言い切れない。なにせ、やったことがないのだから。

失敗の本質―日本軍の組織論的研究 (中公文庫)

転職できる技術を身につけておく

自分は転職を薦めるか転職を薦めないかと訊ねられたら、我慢をしていなければわざわざ転職することは薦めない。何か理不尽なことがあって、我慢をしているのでなければ。

では、安穏と与えられてた仕事をしていればいいのかといえば、それは違うと思う。

togetter.com

経営者は、いつ経営判断のミスを犯すかエンジニアにはわからない。気づいたときには

岐路の選択を迫られることだってある。だから、エンジニアは高く売れる技術を持っている必要がある。このことについてはこれまで何度か書いてきた。

書いてきたことは、自分の技術は自分でしか育てられないのだから、自分のリソースを使って継続的に技術を更新しなければならないということだ。

ただ、エンジニアが所属する会社を辞め、他の会社に移る理由は、何も理不尽なことを押し付けられ、我慢ならないからばかりではないと思う。

経験してきたことの延長線上にやりたいことがはっきりと見え、今のキャリアではそれを実現する可能性がないと見切れれば、それを実現できるところへ移ることだって一つの理由だ。

でも、多少の理不尽さはどこでもあるだろうと許容し、安定した収入を得ておきたいという理由もあるだろう。

ゴールデンサークルという手法がある。３重輪のそれぞれにwhy,how,whatを中心からプロットする。文字で表現すると　( ( ( why ) How ) What )　な感じになる。

whyに実現したいことが当てはまり、手段に転職、whatに実現できる仕事に就く、を入れれば良い。

もし、転職しようと思ったエンジニアは、whyを明確にしておこう。転職は手段でしかない。同じように理不尽な環境に置かれているエンジニアもwhyでなぜその仕事を続けるかを自分に尋ねてみよう。

人は思ったより、ぼーっとして生きていることがわかる。

転職もいつの間にか、転職することが目的にすり替わってしまうと、実現したいことを遠回りする選択をしたり、年収を下げてしまったりする。そんなふうに、流されて判断をすると 前の方がよかったと後悔する。確実に。

どこの会社で働こうと思っても、理不尽なことはある。ただ、どこの会社で働くにしてもそれを超える何かがないと続けられない。それを見つけられるのが技術なのだと思う。

ＷＨＹから始めよ！―インスパイア型リーダーはここが違う

キングスマン： ゴールデン・サークル (字幕版)

『我々はなぜここにいるのか』でチームの行動様式を変えた実話

そう言えば、あるチームの意識を変えないとそのチームに組織（マネジメント）から期待された成果を出せないと思いチームの立ち上げから繰り返し言い続けたことがあった。

組織の中でチームを設立する際には何かしらビジネスニーズが存在する。そのニーズの実現こそ、チームの存在理由である。

しかし、そうしたチームの存在理由は得てしてそこに属するメンバの目には止まらない。メンバは自分がどこに属したか、ただそれだけに関心を持つ。だから、メンバは、チームが目指す方向性を知る機会を自ら失っているのだ。

そういった行動を責めることはできないのかもしれない。何より、それまでエンジニアを組織の都合で、今日まではここで、明日からは向こうの現場で、とアサイメントしてきたのだ。エンジニアは、何をやりたいとか、これをやっていこう、と考える習慣を持たない。今日使う技術を覚え、明日からはアサイメントされた現場で使う技術を覚えなければならないのだから。そういった積み重ねがエンジニアをアサイメントだけに関心を持たせるようになる。

そういったエンジニアが集まったチームができた。少しずつ、それもとても少数の人数が増えていくチームだ。

チーム活動をすると、メンバが話す言葉に印象が残ったものがあった。それを聞く度に、組織の狙いとしてチームを作った理由とずれていることが少しずつ理解できていく。

これは、『自分たちの存在理由を理解し、それをベースに意思決定していないからそういった発言をしているのではないか』と思った。

それから、チームが集まる時間で、チームの活動を決めていくテーマを話している中でメンバからそういったチームの存在理由に反する意見や組織の期待と反対のポジションに受け取れる発言があったとき、繰り返し話した。

「私たちのチームの存在理由は○○なんだ。各人が意思決定をする際には、その存在理由に沿っているかを考えて欲しい」

○○はチームが作られたときにチームに期待されことである。存在理由が揺らぐ発言がある度に、繰り返し伝えた。

時間を掛け、繰り返し言い続けることが人の意識を上書きすることもある。しばらくして、チームは、存在理由を意識するような行動をするようになった。

ふと、昨日の夜、これはウォーターフォールのシステム開発方式を採用したチームでも、組織の機能分解したチームでもやらないことだ、と思った。そして、アジャイルなチームでは（多分）全てのチームがやっていることではないかと思った。

インセプションデッキの『我々はなぜここにいるのか』をチームを立ち上げる際にやればいいのだ。何もアジャイルのチームの専売特許というわけではない。

いやいや、システム開発のプロジェクトマネジメント で『プロジェクト憲章を作るじゃないか』と思うかもしれない。しかし、チームに存在理由をとうことはあるか。プロジェクトチームとしての目的は書くかもしれない。でも、それはプロジェクトマネージャが書く。チームめんば一人ひとりに尋ね、メンバが納得して発言したことではない。

肝心なことは、ウォーターフォールだろうが、機能分解した業務チームだろうが、 アジャイルなチームと同じように『我々はなぜここにいるのか』を繰り返し問い続け、チームのメンバの存在理由を肯定する意思決定をさせることである。これだけではないのかもしれないが、チームの行動は少しずつ変わった。

まあ、あれだ。アジャイル開発界隈では12年ごろから組織論やマインドセットにウエイトがかかり始めたと思っていたのだが、振り返ってみれば、この事例は、ウォーターフォールのシステム開発などの従来のやり方の組織論やマインドセットが出来上がっているわけではないということの証左なのかもしれない。

アジャイルサムライ−達人開発者への道−

SIerのエンジニアのスキルを顧客が育てる悪循環

SIerが事業転換というか、人月商売の頭打ちから『何かイノベーションを起こそう』（もう、こんなことをマネジメントが言い出す時点でヤバいのだが）と新規事業や投資をしようと取り組むが一向に新規事業のタネも見つからずにいるのを見かけると、そりゃそうなるだろうとしか感想が出てこない。

なぜ、SIerの新規事業が上手くいかないか。

イノベーションのジレンマなどの本を何冊か読み、Sier自身の事業を並べ、今の組織と意思決定プロセス、KPIを並べて考えればわかるはずだ。

それがわからないのはそのマネジメントが新規事業に必要なファクタを理解できていないからだ。

別の見方をすれば、マネジメントがイノベーションを言い始めたらビジネスの限界を感じて危機感を持ったと言えるかもしれない。どういうことかというと、ビジネスの成長しろがなくなった、ということだ。事業として成長しろがないということは、商売上、売るものが底をつきかけていると解釈できる。

エンジニアの目線で見ると、こんな風に将来を予測できる。例えば、賞与が業績連動となっていたら、今がピークであとは下がるしかない。

人月商売というビジネスの成り立ち上、売るもの＝エンジニアが底をつくことは、稼働が高い状態であるから、エンジニアは立ち止まり、次を考える余裕なんてない。働き方改革やブラック企業認定されてたくないとか、労基の立ち入りや是正勧告やらに巻き込まれたくないと労働条件をホワイト側に持っていことすれば、ますます持って、エンジニアは仕事の成果を出し続けなければならず、枠の中に仕事を詰め込んでいく。

結果、起こる将来は、世の中はIoTだ、サーバレスだ、RPAだと進むが、SIerのエンジニアは取り残されるのだ。1年ならまだしも、何年も、である。

そして予測した将来がやってくる。案件が打ち切られ、稼働が下がってくる。次の案件で適用する技術は進んでおり、そういった技術を今持っているエンジニアをリクエストされる。ここで技術のミスマッチが起き、売れないエンジニアが在庫として積み上がっていく。

そういう意味では、SIerのエンジニアの技術は顧客のプロジェクトの中で育てられているのだ。ただ、すぐにものづくりを始める今のビジネスニーズではそれを受け入れないだろう。そうすると悪循環に陥る。エンジニアはもっとひどい案件に安く引き取られるのだ。

君の膵臓をたべたい

いつになったらconnectedな時代になるのだろうか

90年台前半はRASでインターネットに繋ぎ、そのあと暫く、PHSやモバイル通信機器を介してPCをネットワークに繋いでいる。そう言えば、PHSでデータ通信は割と良くて東海道新幹線の移動中でもなかなか切れずに繋がっていた。

ここ5年くらいは、外出先でwifi環境も提供されるようになったが、あくまでもスポット（電波の届く範囲のエリア）でしかない。wifiスポットを提供している店から出てしまえば4Gの世界に戻される。

スポット、電波の届く範囲の意味であれば、携帯電話だって基地局を中心としたゾーンに入ることで電波を繋げ、ネットワークに接続するから同じようなものだ。

いつになったら、wifiルータを接続して、PCを繋ぐという儀式から解放されるのだろうか。PCにモバイルsimを入れて使えばいいと思うかもしれないが、手順がなくならないことに煩わしさを感じているのだ。

では、もしPCなどのIT機器を儀式を経ずに、常時接続できる技術が提供されたらどんな社会になるのだろう。少なくとも通信キャリアは中抜きされるだろう。間に入っているものを取り替えることで、これまで当たり前だと思っていたことから解放するのがイノベーションであることが多いのだから。

しかし、ほんとネットに繋ぐのが面倒でしかない。

つながり 社会的ネットワークの驚くべき力

今の時代に必要なマネジメントスタイル

ここずっと、マネジメントのスタイルについて考えさせられる機会があるのだが、結論から言えば、『このマネジメントスタイルにせよ』的なことを言う輩がいたらさっさと離れた方が良い。

不確実性と複雑性の高い時代に、これで全部対応できるなんて方法があるわけない。万能は、万能な働きをしない。うわっペリを拭う程度でしかなく、最悪、汚れを広げてしまい被害を撒き散らすだけである。

エンジニアの生産性を高めるために

生産性を高めるためには、まずは惜しみなくHWやSWを揃え、環境に依存する障害取り除くことである。 要は、金で解決できることは札束で解決する。グダグダと高いだの相見積もりを取れなど難癖を言って、マネジメントがエンジニアから生産する時間を奪うのは本末転倒でしかない。

次にエンジニアが生産するための時間をチャンクになるような仕事の仕方ができるように環境を作る。

エンジニアに自律性を持たせるために権限を委譲する。委譲しまくるために、組織の判断基準に基づき、マネージャが請け負える（腹を括れる）範囲（＝権限、分掌）で、判断基準を明確に示す。

これだけで良いのはないか。

必要なマネジメントスタイルは

 ではどのようなマネジメントスタイルが必要か。

HWやSWの環境の件は、トップダウンで決めないと意思決定に時間がかかる。トップマネジメントが『業務で使うなら好きにしたらええ』とすれば、悲しいかな、組織文化の中での常識の範囲でエンジニアは意思決定する。

稀に、突拍子も無い価値観を持っているエンジニアもいるがそう言ったエンジニアは思考に芸術肌の要素を持っているが、そう言ったエンジニアは稀なので相対的には誤差の範囲でしかないため、問題にならない。自分で決められないエンジニアは先行するエンジニアを真似る。結局、平均的な数字になるだけだ。

エンジニアが生産性を確保するためのチャンクの時間を確保するには各所へ事前調整しておく調整型のマネジメントスタイルが必要になる。まあ、筋を通しておけばいいだけというか。ネゴシエーションができれば良い。

エンジニアに自律を自覚させ、実行させるマネジメントスタイルは、サーバントリーダシップが必要になる。エンジニアがあれこれしている間は、黙って見ているか、エンジニア自身が気づけるようにヒントがある場所に連れていくだけだ。

結論

全部必要である。全部必要であるが、置かれる状況により、適用するマネジメントスタイルを使い分けなければならない。

サーバントリーダ シップを発揮するためには、バックグラウンドとしてエンジニアが自律性を行使出来るための組織の文化のインストールが済んでいなければ成らない。つまり、マネジメントは、組織文化にトップダウンでサーバントリーダシップが円滑に機能するための環境づくりを一貫して置かなければ成らない。

そして作られた組織の環境が期待するように運用されるために、調整型のマネジメントスタイルを発揮しなければ成らない。

結局、1つのマネジメントスタイルだけでは今の時代にマネジメント自身が生存し続けることができなくなってしまう。

そう言った1つのマネジメントスタイルだけしか持ち合わせていないマネジメントは老害としてエンジニアの前に憚るのである。

マネージャーの問題地図 ~「で、どこから変える?」あれもこれもで、てんやわんやな現場のマネジメント