トラブルを組織として対応するときのパターン
小さいお子さんが亡くなられているので、子供を持つ親としてはなんとも言いようのない気持ちで流れてくるニュースを断片的に眺めている。
危惧するのは、市教委の担当者の処分（若しくは辞職）で終わってしまうと、この市教委は次に同じようなケースが起きると繰り返し事件を起こすのではないかという憂いである。
エンジニアとこのような暴力による事件に何かしら関連があるかというと全くないわけではない。少し、個別の事案の特性をフィルタリングすることでこうした事案の対応に対する必要性を理解できるのではないかと考える。
例えば、IT企業においても社会的な事案を起こせば、主義主張を行う団体がやってきくる。一度こうした輩に目をつけられると厄介なのである。
もう少し、エンジニアが身近に捉えられるケースを示すと、開発プロジェクトで進捗がものすごく遅れプロジェクトで問題になり、債務不履行の手前まで行くと発注者側からなんとかしろと（場合によっては弁護士を連れて来るぞと言われたり）いう交渉をしなければならないことが（稀に）ある。
引用した事件でもSIerのトラブルプロジェクトでも、共通事項がある。それをパタンとして以下に示す。
要約
担当する業務推進上の障害となる事案について、対外的な人物、組織からの要求があった場合、組織の意思決定として対処しなければならない。特に威圧や暴力の示唆などを感じるようなケースにおいては、組織内の専門部署（通常は総務部門や法務部門）に対応を依頼し、対応の専門知識を持たない部署だけでの交渉を行なってはならない。
状況
以下の引用（女児死亡 父親にアンケート渡した野田市教委の担当者が謝罪 | NHKニュース 引用は適宜改変）から次の事態が起きていた（と状況把握する）。
- 小学校を訪れた際、「暴力は振るっていない。一時保護といって子どもを引き離された者の気持ちがわかるか」などと抗議し、アンケートの回答を見せるよう強く迫った
- ３日後に市の教育委員会を訪れた際にも、威圧的な態度で要求した
- 『恐怖感を覚え精神的にも追い詰められて影響を深く考えられなかった。』
- 上司の教育長をはじめ、児童相談所などにも相談していなかった
- 市の情報公開条例に違反する
フォース
威圧や暴力の示唆に対する専門知識を持ち、そうした事案に対する主管部門が対応するか、主管部門と業務担当部門の共同チームで対応する。事案の説明、根拠とする規程に沿って業務を行なっている説明以上の情報はコンプライアンスを盾に自組織で判断できないことを伝える（説明のみで説得しない）。言い換えれば、お役所仕事に徹し、現場での判断を一切させない。直接接触する回数は減らし、会談する場合は音声、録画等の証拠保全を行う。説明した内容、要求事項は都度確認し、記録し、会談の最後に再確認する。会談後は、対応する主管部署又は共同チームで、組織の規則、法律等に則り対処方針案を作成し、その責を負う責任者に意思決定させる。
問題
業務推進上の障害となるトラブルは起きるものだ。
何かを業務で行うとき、全くトラブルも発生せずに業務を完了することは滅多いない。程度の問題もあるが、その程度が大きく振れることを含め想定していなければトラブルの識別をしないで始めているから初動を遅らせたり、対処を間違えるのである。
引用した事案での問題は、一見市教委という組織で対応しているように見えるが、威圧や暴力の示唆を感じていることから、通常の業務の範囲を超えていることを踏まえ、そうした対応に長けている対外交渉のノウハウを持つ部門の支援を受けるべきであった。
（引用した記事が全てではないか恣意的に担当者を人身御供にする意図があるとしても）決められた通り正しく確実に報告をされていないことが伺えることから、異常事態に対するreport toが機能していないことは明白である。
解決
- （トラブルを一括りにして良いが）正常処理以外の対処（要はトラブル）の対応方針を決める
- トラブル（異常事態）の対応体制を方針に含める
- トラブルは即報告する業務オペレーションができているか管理職がモニタリング（異常を検知できる報告をさせる）する
- 作者: ロジャーフィッシャー,ウィリアムユーリー,金山宣夫,浅井和子
- 出版社/メーカー: 三笠書房
- 発売日: 1989/12/19
- メディア: 文庫
- 購入: 19人 クリック: 155回
- この商品を含むブログ (53件) を見る
自分はもっとメンバと雑談をしたほうがいいのかもしれない
廊下を歩いていて、ちょっと気になっているタスクがどうなっているのかが気になった。そういえば、1週間くらいステータスを聞いていない。
そうしたことはままある。そうした気になることを確認する方法もたくさんある。メールやchatで聞くこともできる。席に行って尋ねてもいい。ミーティングの場を作ってもいい。
ただ、文字ではニュアンスを伝えきれなかったり受け止められないこともある。こちらが立ったまま聞くのは構わないが聞かれる方は威圧的に感じるかもしれない。ミーティングになると予定を入れ、場所を取るのでかしこまった感じがする。
こちらとしてはもっとカジュアルに話をしたい。ちょっと気になるタスクから話を広げて情報を得られるならそうしたい。様子をみて、どうやら集中して作業をしているようではないから、声を掛けてみる。
『今雑談する時間取れるかな』
『いいですよ』
オープンスペースのテーブルでその気になるタスクのステータスがどうなっているかをカジュアルに聞く。『あーそういえばさぁ、アレは…』風に。雑談に連れ出したメンバは別のことかと思っていたようだ。
『ちょっと気になっていてね』そう切り出して、ステータスというよりは誰がボールを握っているのかから確認を入れる。
ボールを握っているのはもう一人のメンバで、どうやら話を進めていてくれたらしいのだが、あまり良くない状況だったのだという。ボールを握っているメンバから言えばある意味、情報を先にリークさせてしまったようなものだ。
雑談のいいところはここからである。そのもう一人のメンバの忙しい理由について色々と情報が出てくる。担当する仕事上での立ち位置や、周りとの関係性や本人の性格が出てしまって招いている結果など。
悪口や陰口ではなく、もう一人のメンバから『そう見えている』と教えてくれる。
雑談をしているメンバに対して助言をする。同僚なのだから、気づいたことで相手の負担を下げる（必要があると思ったら）ことを伝えていいと。そこは遠慮をするところではないし、こんな感じの雑談の中で伝えればいい、と。
『え、そこまで言っていいんですか』と聞くから『いいよ』と返す。ちゃんと気にしているよ、見ているよ、というメッセージにもなる。雑談が手助けして欲しければ伝えられるタイミングにもなる。
雑談は良いコミュニケーションの1つの道具だと思った。
自分はもっとメンバと雑談をしたほうがいいのかもしれない。
家ではほぼ仕事の話をしない話
自分は仕事から帰ってきてワイフに仕事の話をほとんどしない。仕事関係で話をするとすれば出張や帰りが遅くなると言う予定、いつもより給与振込が多いときの理由（交通費や期末賞与的なものだとかの情報）を伝えるくらいだ。
あとは仲の良い役員と飲みに行くときの予定か（気の進まない）組織での催し（飲み会）など、ほとんど予定しか話さない。
それはどうしてかと言うと、子供の頃の体験が反面教師としてそうさせているのかもしれない。簡単に言えば、親が仕事から帰ってくると毎日延々と一方的に話をしている風景をみていた。話の内容に知的好奇心を擽るようなテーマがあれば子供心にも一緒に聞いたかもしれないが、そんな知的な話ではなかった。一日の仕事を逐一話しているのである。
自分が結婚をするとき、仕事の話をひたすらに聞かせるのだけは止めようと思った。
『仕事の愚痴の内容が聞くに堪えないこと（同僚に対する人格攻撃）や、
聞に堪えない愚痴』
だから、増田の気持ちが少しわかる。人の話を聞くのは体力がいる。聞いているふりをするのも気を割り振っておかなければならないからしんどい。聞いていないときに限って話をしている方は気づく。なんで聞いていないんだ、と。
もう一つ。
同僚などの人格攻撃や愚痴を言ったこともない。そう言った話を聞きたくもない。だから、組織の催し（要は飲み会）で愚痴っぽくなるとスルスルと場所を移動する。勉強会のアフターの懇親会でも愚痴っぽい話をし始める輩がいると別のネタを差し込み、話を切り替えさせる。勉強会は主宰であるから組織の飲み会のように放置するわけにもいかない。
どうしてしないのかと言えば、酒が不味くなるからである。なぜ、高い会費を払った上でつまらない愚痴を聞いたり言ったりしなければならないのか。そんな酒なら飲まないほうがいいし、家で愚痴を言って聞いてもらう相手に愚痴を言う側の負の嫌な気持ちを伝播させる必要もない。安心して自分を開放する場所で闇に闇を上塗りしなければならないのか。
仕事の話をしない理由の後付けの理由はコンプラである。ここ10年くらいの話だろう。身内だとコンプラのガードが下がり、組織内のあれこれを話している旦那は多そうだ。話した相手の家族、ご婦人の他のご子息やご令嬢は小さくても聞いているものだ。そしてポロっと幼稚園や小学校で話すのである。既知の情報以上は話せないし話さないのが吉である。
愚痴を話すより、同僚の人格攻撃をするより、ワイフが笑うネタを話すほうを選んでいるだけのことだが。
メンバに仕事を任せるときに気をつけている幾つかのこと
ここ数年、意識的に自分の業務のうち、デレゲートできる業務はメンバに移譲するようにしている。意識的にしている理由は、端的に言えば自分が今のポジションから抜けても残されたメンバが困らないように実務で訓練する機会を先出しして作るためである。可能であれば全ての業務を何度か任せることでひと通り経験させたいが、ロールに紐づく仕事もあり、そうならないのが組織というものでもある。
業務の移譲という考え方は割と難しい。上司の仕事を部下に丸投げするのとは違う。機会を作り、その機会から継続する業務を受け持ったとき、慌てることがないようにしておきたいという狙いがあるから成功体験を得させたいのと、ルールのある業務であればバイオレーションに引っかからないような仕事の仕方を知ってほしいのである。
業務も蓋を開ければ定型業務と都度内容が変わる業務がある。定型業務はワークフローなり、手続きなりが主管部署により決められているので頻度が少ない業務でもフォローを主管部署がしてくれる。それ以外の、アドホックな業務や企画ぽいものはその都度変わるので定型化のしようがない。それでも企画やオポチュニティを案件化に持っていくようなテーマは、継続的に活動することが必要であるが、キャリーするリーダにより途端にダメになってしまう。そうならないようにしておきたい。
こうしたテーマをメンバに移譲する際に気をつけていたことを箇条書きにしておく。
ゼロから考えさせないのは、知らないことはできないからという理由である。過去の資料を参考に何をすればいいのか共通項を抜き出させる。目的、完了をイメージさせ、口頭ではなく言語化（含む図表化）させるのは頭の中で理解したことをこちらが理解するためでもある。進め方のストーリはプロセスを具体化するためである。
リーダにされるエンジニアにとっては初めのことばかりであるから、それを伴走しながらイメージアップする。イメージアップさせるのはリーダ自身がこれから何をするのかを自分で理解できるだけ具体的にできなければ、他のメンバに仕事を振れないからだ。これで１巡できれば、そのあとのアレンジはお任せである。
あとは相談に乗るくらいしかやることはない。
個々のエンジニア、チーム、組織のどれを優先するか
アジャイル界隈のカンファレンスのテーマの変遷を思い出すと興味深い。誤解やツッコミをしたくなるだろうが乱暴に書けば、開発方法論（vsウォーターフォール）→実践（ビジネスで使え）→チーム→組織→プロダクト（事業＋開発）と変遷していると（浅い理解であるのだろうが）感じている。
開発方法論は2013年くらいまでで、2013年あたりから実践せよと境目が変わってきた。そこから5年程度で普通になった。普通とは、自社のソリューションビジネスや製品開発をしているSIerにとっては日常と言う意味で、である。エンジニアのリソースを売る人売りSIerとは一線を画す。
ここ最近、チームビルディングやプロダクト開発における組織の在り方の講演テーマやスライドをみると、関心が変遷する中で人的リソースの括り、つまり、エンジニア個人、チーム、組織と活動単位で捉えたときに、それぞれの課題と解決がコンフリクトを起こし、どうしたら良いかという投げかけを見かけるようになった。
具体的には心理的安全性をチームの中で確保しようとするとき、活動単位はチーム内での事象に対する課題設定と解決になる。そこで議論されるのはチーム優先である。とこで心理的安全性は見方、視点を変えれば個人のパフォーマンスを最大限に発揮することが根底にあると考えている。それをチームベースで話しすぎると個人のパフォーマンスはスポイルされる懸念があると考えている。
なお、このエンジニア個人とチームのコンフリクトに対する投げかけ、気づきはまだとても少ない。
自分の捉え方はまだこれだと整理できているとは思わない。エンジニア個人、チーム、組織という活動単位を分けることは活動単位での課題を取り扱う上では便利であるからどうぞご自由に程度であるがそうして分けたときにコンフリクトを起こして困る的な感じで言われると、その分けて考えられていること自体に疑問を保たれれば良いのではないかと思ってしまうのである。
活動単位は、エンジニア個人、チーム、組織である。その組織も事業というビジネスの上に構築されるロールである。ロールはミッションを分掌する。結局、組織がビジネスで生き残るためにどうすればいいかの話であるから、困ったときにはビジネス、事業で捉えなおせば良いのだと思っている。
エンジニア個人とチームがコンフリクトするとき、どちらを優先しなければならないかと迷ったらビジネスとして成果を得られる方を選べば良いのである。その判断にバイアスを掛けるのがコーポレートとしての行動規範や価値観を意思決定すれば良いのである。
エンジニア個人のパフォーマンスとチーム内での心理的安全性とを折り合いをつけたければ、組織としての意思決定で優先される価値観を適用することで結果は得られる。そこでエンジニア個人にパフォーマンスの制御を要求することになったとしてもそれは組織の共通した価値観に基づくものであるから組織として、ビジネス上の判断として方向性は一致しているのである。
端的に言えば、組織文化で判断すれば良いのである。
【Amazon.co.jp限定】Acer 4Kモニターディスプレイ ET430Kbmiiqppx 43インチ/HDR Ready対応/IPS/4K/16:9/5ms/DisplayPort ・HDMI
- 出版社/メーカー: 日本エイサー
- 発売日: 2018/04/11
- メディア: Personal Computers
- この商品を含むブログを見る
『文系プログラマ』『文系エンジニア』2018年に書かれたエントリまとめ
金曜日に文系エンジニアのエントリを書いたのは引用したブログを読んだからで、そういえば『文系プログラマ』でどのくらいエントリがあるか、コーヒーでも飲みながら調べてみよう。
追加条件に『2018』を入れておく。
まずは引用した件のエントリである。
次はブログタイトルに『文系プログラマ』とあるので文系を売りにしているのだろう。Chromeでトップページを表示すると、一瞬記事のサムネイルが3つ並んだあと真ん中と右の記事が飛んでしまうのだが意図している表示なのだろうか。
3つ目に引っかかったのはQiita。SPAでのSEO事例に貼っていあるリンクが上の2番目の人のブログだった。
4つ目は『詳説GraalVM』を書かれている文系プログラマの方のエントリ。
5つ目は文系プログラマの方をイラストで描かれている。それで検索に引っかかったようだ。
6つ目はTOEICの点数すごいっすね、なサイト。検索はRails5のエントリ。
検索結果はこれでおしまい。
もう一つなので『文系エンジニア 2018』でも検索してみる。
仕切り直しの1つ目はDeep Learningだった。
2つ目は文系エンジニアと言いつつもサイトのタイトル下の説明を読んで『CS（コンピュータサイエンス）の修士じゃないの』と突っ込みたくなるエントリ。
3つ目はat mark ITの記事だ。
4つ目はインタビューだ。文系エンジニアから機械学習エンジニアに転職した話である。
5つ目は約1年前の3月に58歳文系エンジニアの方が書かれたエントリ。自分のエンジニアとしての価値を向上させるためにMachine Learning講座を自ら受講された経緯が書かれている。
6つ目は2017年だが引っかかった。中ぐらいに『文系エンジニア』のキーワードを書かれている。
最後はおまけなのだが、それはさておき『文系プログラマ』や『文系エンジニア』のパワーワード感がありすぎて、それに引き換えエントリは少ないのはどうしてだろう。文系プログラマや文系エンジニアを揶揄することでガス抜きをしているのだろうか。
観測できる範囲とすると所属する組織である。新人配属してきたエンジニアやメンバのエンジニアには自ら出身学部を話す人もいる。そうした人達の中は一定の割合、いやかなりの割合で文系がいる。
これは特異で、実は言われているほど多くないとか、文系プログラマや文系エンジニアは自らエンジニアとしてのコンテンツを作らない『消費ばかりで卵（コンテンツ）を産まないエンジニア』なのだろうか。
