たびと－ソフトウェア保守のブログ

対話ケース５（再びユーザ企業IT部門の若手技術者）-19話

Tue, 24 Jul 2018 11:38:54 +0900

＜顧客別保守チームはどのチームも仕事の内容が類似？＞
たびと「相手の担当分野を犯さない？」というような，チーム間や担当間の境界線の存在を，依頼先にことさら強く意識させるのは良くないと私は思っています。
保品ということは，こちらは依頼したいときでも「何ならそちらの仕事もバーターでやりますよ？」というスタンスでの依頼ですか？　何かすごく卑下し過ぎのように僕は感じます。
たびと「卑下し過ぎ」と感じますか？　それにお答えをする前に，一つお聞きします。チームや部門のミッションが異なっていても，共通する仕事はいっぱいありますよね。
保品チームのミッションは違っていても，同じような仕事が大半であるチームは僕の周りにも確かにありますね。
たびと保守チームの場合，担当する顧客が異なるだけで，対象システムが同じなら，同じことを別チームでやることも珍しくありませんよね。
保品おっと，そうですね。それなら，たとえチームは違っていても，ほとんど仕事の内容は同じになるかもしれません。
たびとそんな組織関係なら，お互いに余計な壁の意識を作らず，卑下なんて言わずに，一方が忙しい時には，連携して応援しあう関係のほうが良くありませんか？

＜要員不足ではチーム間に良くない壁を作らない＞
保品ですが，競争心を上司から煽られたりすると，こちらだけがいつも応援する側になってしまうのは，どうしても損な役目と考えてしまいますね。
たびと同期で優秀な社員が複数いると，適正なチーム規模というような名目でわざとチームを分け，同じようなことをさせて競わせる組織運営をすることもあります。実は私が以前部長級の役職だったとき，条件がそろったのでそういう競争をさせたことがあります。
保品でも，純粋にソフトウェア保守業務を中心に考えた場合は，そのような競争は条件がそろわないと安易に行わないほうが良いのですよね？
たびと競争させるには，対応するリソースに競争させるだけの余裕があることが大きな条件です。私が競争させたときは，たまたま若手がいつもの年より多く参画してきて，チーム内でのいろいろ創意工夫を検討・議論する余裕があったのです。
保品リソース不足というその逆のケースでは競争させてはダメなんですね。
たびと「競争させれば生産性が上がるからリソース不足の対策になるはず」と余裕も全くないのに安直な考えでやらせてしまうのは，非常に良くないと私は考えます。
保品そんな上司はうちの会社にいっぱいいそうです。チームの双方のリソースが足らないときは，助け合うほうが重要という発想は微塵もなく。
たびとただ，助け合える場合でも，依頼元が依頼前に工数を掛けている証拠とその結果を具体的に示すべきです。自分たちでやれなくはないが，相手チームのほうが手馴れていて，生産性や品質に優れているところに絞ってお願いするのがポイントです。

＜依頼元ができる努力が伝わるようにすれば依頼は簡単？＞
保品何もせず，いきなり「緊急なので後はすべてお願いしたい。よろしく」となれば，依頼を受けた側は「誰でもできる準備までも含めやらされる」と思うとたまったものではないですね。強みのある技術分野の補完ではなく，単なるマンパワーの融通ならやりたくないですよね。
たびとさらに，依頼側が何か「どうしよう。どうしよう」とオロオロした状態で依頼すると「おい，他の案件は大丈夫か？」と余計な心配をされてしまいます。
保品そんな依頼元の混乱を見せないために「依頼を請けられないはずはない！」と上の力を借りて偉そうに依頼するのは，もっとアウトということですね。
たびと依頼側がより権限の強い上司を使い，強制的に他チームにやらせることも，ある種のヒューマンスキルに含める人もいますが，私はその考えは好きではありません。
保品僕も上層部の力を利用して他の組織を動かすことがヒューマンスキルの重要ポイントだとは思っていません。
たびとさらに，実態を無視し，説得力や交渉力のみがヒューマンコミュニケーションスキルだというなら，そんなスキルをひけらかしても，技術力がいかに低レベル化かを依頼先に見透かされてもよいということになります。
保品お互いのチームや組織に対する技術力・品質・生産性などの実力に対する尊敬と信頼の念が重要で，「相手に負けるな」とハッパをかける上司の言うとおりに動いては，協力し合う関係は生まれにくいということですね。
たびとチーム内も同じです。私はリーダや管理者のときでも，担当者より優れた実務技術者でもあり続ける意気込みを持ち続けようと努力しました。担当者に任せる場合でも，自分ができる作業として具体的手順を指示して，担当者にもっと良い方法があるかの意見や考えを聞きました。
保品担当者を信頼して，たびとさんのイメージを伝え，相手の考えを聞くのですね。
たびとただ，こちらが手順を提示すると，中には「私を信頼していないのですか？」と突っかかる担当者もいました。そういう担当者のほとんどが，手順検討など事前の準備をほとんどしていないケースでしたね。それを見透かされるのが嫌で突っかかるのです。
保品依頼先が「依頼元側でここまで調べてくれたんだ」という気持ちになってくれれば，協力度や信頼関係も増してくるわけですね。
たびとそれもありますが，案件の切迫感が，こちらが何をしてきたかで相手に具体的に伝わるのです。すでにしっかり対応や検討をしていれば，説明が上手い下手はあんまり気にする必要はありません。
保品依頼前に何もしていないと相手に感じられてしまうと「丸投げかい？」「担当チームとして責任放棄？」「ちゃんと管理しているの？　対応優先度も分かっていない？」と依頼を受けた担当の対応モチベーションは下がるばかりですね。
（20話につづく）

対話ケース５（再びユーザ企業IT部門の若手技術者）-18話

Fri, 06 Jul 2018 14:32:15 +0900

＜リソースが足らないチームの運営ポイントは？＞
保品あの～，また「たびとさんに怒られる～」を覚悟で．．お聞きします（笑）。リーダになったらすぐ「担当技術者卒業」と考えるのは確かに良くないとは僕も思います。ただ，限られた要員数の中で複数の保守案件を素早く捌くには，必ずしも技術的能力だけではなく，応援が必要な部門との役割調整など，リーダには円滑なヒューマンコミュニケーション能力が重要だと思うのですが．．。
たびと確かにリソースが足らないとき，リーダの依頼調整力，説得能力，交渉力，上位層を動かすといったヒューマンスキルもチーム運営のキーポイントの一つかもしれません。でも，私は，そのようなヒューマンスキルが最も重要だと考える組織が良い組織だとはあまり考えていません。
保品そのような組織に出てくる問題とはどんなものとお考えですか？
たびと例えば，「トップダウンによる的確で迅速な意思決定と組織運営を目指す」という美辞が飛び交う組織をイメージしてください。
保品その言葉のどこが問題なのですか？

＜「トップダウン」と「上意下達」はどう違う？＞
たびと「トップダウン」を「上意下達」，「的確で迅速な」を「拙速な」と変えたら問題のイメージが際立ちませんか？
保品トップの組織運営能力が，聞きかじりだけでなく，十分な実績に基づく経営科学的な能力に優れていなければ，単なる「上意下達」，「拙速な」となるだけということですね。
たびと「トップダウン」「的確で迅速な」という言葉を，経営トップが使った組織目標に書いたというだけで，言葉が独り歩きさせるようなリーダばかりがいて，現場担当者にはその言葉を伝えただけ。「上の指示だから」と繰り返すだけで，何のリソースの手当や具体的な対応方法を示さず，現場担当が簡単に「早く」「的確に」に，そしてさらに「安く」できるようになるわけがないのです。
保品現場が他のリソースを活用したりして活性化するには，現場担当者や担当部門間の信頼関係が重要なのに，その信頼関係を崩すのが「トップダウン」や「的確で迅速な」という，検証されていない美辞麗句的指示なのですね。

＜上を意識しないで協力し合える関係は良い？悪い？＞
たびとそうです。基本は他部門や他チームのみなさんには「いつもお世話になり，いろいろご迷惑をお掛けしている」という気持ちで，リーダも担当も接すれば，依頼先部門も早い解決に向けた協力を惜しまずやってくれます。
保品たびとさんは簡単そうに仰いますが，多分は私は上の美辞麗句的指示のプレッシャーに負けて，すぐ信頼を無くす下手なことをやってしまいそうです。たとえば，やってはいけない悪い言い方というのは，どんなことですか。
たびと「本当は頼みたくなかったのだけれど，切羽詰まって，やむなく急ぎで頼んでいる」という雰囲気が相手に伝わった途端，言葉でどううまく説得しょうとしても完全にアウトですね（笑）。それに加えて，自分はリーダで実務担当を卒業しているので，上を通して依頼するのがメインの仕事みたいに相手に受け取られるとダブルプレー（笑）でアウトです。
保品やっぱりですよね～（笑）。「拙速な対応」をしてしまい，すぐやるべき対応が後手後手に回ると，どうしてもそんな「とにかくお願い」的な雰囲気でのお願いになってしまいそうです。ヒューマンスキルに頼って何とか凌ごうとするではなくて？
たびと私がお願いする場合は，こちらではここまで工数を掛けて調べ，ここまで分かったが，その後の詳細部分は専門の貴部門で調べてもらった方が断然早いという雰囲気でお願いするのです。
保品相手の専門分野を勝手に侵さないという原則ですかね？
（19話につづく）

対話ケース５（再びユーザ企業IT部門の若手技術者）-17話

Wed, 20 Jun 2018 18:42:18 +0900

＜リーダになると保守対応の実務作業卒業？＞
たびと今まで多くの後輩ITエンジニアを見てきましたが，リーダになったら実務を直接担当する技術者という役割を「卒業した」みたいに考える人が多いから，保守現場はおかしくなるのです。
保品僕もリーダになって，報告書作成等の事務的な仕事が増えてくると，「保守対応を卒業したいかな」という気持ちに揺れることがあります。
たびと対応件数はメンバのときより少なくても良いのです。リーダが率先して実際の保守対応もすれば，保守対応の仕方や案件の捌き方の例をメンバに見せる良い機会にもなると私は考えます。
保品たびとさんが手本を示すのは，よほど実務技術者としての自信をお持ちだからですよね。それとも，リーダの事務的な役目はあまり重要視しないため？
たびとちょっと違いますね。私が保守対応の実務をやったからといって，ベストな結果にならないことも少なくないのです。
保品えっ？　リーダがカッコよく手本を見せたが，結果が思わしくないと，メンツ丸つぶれでメンバの信頼を無くす恐れはないのですか？　僕なら自分がやって失敗してしまった恥をメンバに見せるのは，やはりリーダとしては避けたい気持ちになりますよね。

＜不足リソースを担当に押し付けるのがリーダ？＞
たびとそうですか？　リーダが結果責任を気にすることは必要だと私も思います。でも，ソフトウェア保守対応チームの場合，常に並行して複数案件対応が必要になります。
保品確かにうちのチームも保守対応要の残案件が完全に無くなったり，一人が1件のみ対応で人が足りるなんてことはありませんね。
たびと足らないリソースの中ですべての案件について100点満点の結果を求められてもできない。リソースが足らないときは，限られたリソースの中で全体として最大点を目指すことはしても，全案件を100点満点の対応にこだわるのは現実的でないというのが私の考えです。
保品でも，足らない時間の中でも，頑張って100点満点を目指そうと真面目な技術者は考えそうです。
たびとリソースが足らない責任は担当技術者側にあるのではないのに，足らない状況を是とし，真面目な技術者の犠牲を強いているリーダや管理者に問題があるのです。そういう人たちは「できないのを工夫してヤリきるのが担当の仕事」だと，自分はできもしないくせに決めつけるから。保守対応のリソース不足にまったく気が付かないケースが多いのです。
保品そういえば，僕の上司は「簡単な修正なんだから」と，当然のごとくすべての案件対応を期限内に完璧にやれと言わんばかりで，プレッシャーを掛けてきます。
たびと私の場合では，上司がそんなことを言おうものなら「どうぞ，代わりにやってください」と私から言われるのを上司自身が分かっていますからね。

＜メンバはリーダの手本をちゃんと参考にする？＞
保品「できないものはできない」と判断できるたびとさんの経験を，組織として共有されている点がうらやましい限りですね。
たびとソフトウェアに限った話かな？と思うけど，「大した修正じゃないから，やってみないとできるかどうか分からないよ。まずはやってみようよ。何かあれば相談に乗るから」という上司やリーダにも，現場経験の少ない，担当任せの考えの持ち主で，その場主義の場合が多い。あくまでも私の個人的な経験からですがね。
保品確かに。僕が保守担当メンバのときの経験から，その見方にも同意できる部分が多い気がします。では，リーダ自らがやって見せるポイントは何ですか？
たびとポイントは，メンバよりも豊富な保守対応経験から，メンバが気づかない視点まで考え，先を読んで対応していることを示せればよいのです。私が，メールで関係部門との調整を淀みなく，かつ丁寧に進めている状況は，逐一メンバにも写しを入れていますから。
保品でもですね，メンバはちゃんとそういったたびとさんのメールを読んでくれますか？
たびとそれを確認するのが月曜の定例ミーティングの目的の一つですよ。毎回確認する必要なんか全然ありません。たまに「何月何日に運用部門の○○さんに私がメールで確認した意味はわかる？」とミーティング時にメールをプロジェクタに表示して参加者に聞けばよいのです。
保品一見何気ないようなメールを選んで，その発信目的を理解できているかを参加者に確認し，説明するわけですね。
たびとそう，選ぶのは全員がその送信目的を理解していることは無さそうな「何気ないメール」です。送信目的のポイントのみ丁寧に説明をします。そのときのメンバの顔を見るだけで，すでにちゃんと読んである程度理解しているメンバと，私のメールをスルーしているメンバはすぐわかります。
（18話につづく）

対話ケース５（再びユーザ企業IT部門の若手技術者）-16話

Mon, 11 Jun 2018 10:58:15 +0900

＜チームリーダが窓口になって緊急案件のフォロー者に対応＞
たびとフォロー問合せ者が安心してくれる理由は単純です。チームリーダの私が当該案件の詳細を十分把握して話しているからです。その十分さの程度は，私自身が担当として動いても対応ができ「すぐ修復に動く必要があるほど切迫しているなら，私自身が修復に動きますがいかがいたしますか？」という雰囲気が相手に伝わればよいのです。お互い知らない中ではないので，大概は本当の状況がそのやりとりで共有されます。
保品まるで，「担当の優秀な外科医が今手術中ですぐの対応はできないが，今すぐ直すことが必要なら外科医長の自分が執刀しますよ」という雰囲気ですね。
たびと実際は，運用でとりあえず回避されている場合も多いので「分かりました。対応報告をお待ちします」と，安心して引き下がってくれる場合がほとんどです。
保品僕の経験からも感じますが，フォローの問合せは案件対応が放置されていると困るから，様子見に連絡してくる場合がほとんどですね。
たびと相手を安心させる捌きをすることで，問合せ者からのフォローの負担を担当者に感じさせる度合を大きく軽減でき，担当者は集中して次々と緊急案件の対応を着実に進めることができるのです。

＜問合せ管理システムの活用でフォロー問合せ数を減らす＞
保品でも，相手が納得せず，たびとさん自身が対応せざるを得なくなったり，問合せ対応に忙殺され，リーダとしての対応がおろそかになったことはありませんか？　たとえば，複数の利用者の上層部が怒っている場合とか？
たびと私がいつもフォロー者に対して状況を的確に説明し，最後にある一言を伝えると，フォローの問合せ数がどんどん少なくましたね。
保品「いいかげん何度も連絡してくるんじゃないぞ！」と付け加えるのですか（笑）
たびとこら！（笑）。「今後の対応状況は問合せ管理システムをとりあえず見ていただいて，ご心配のところがありましたら遠慮なく何度でもフォローしてください」と付け加えます。
保品フォロー者には，もっとプレッシャーを感じさせるひと言ですね。問合せ管理システムへの適切な情報更新と共有が，ここでも生きてくるわけですね。
たびと実は，その一言を言うときはチームの担当メンバーにわざと聞こえるよう大きな声でいいます。
保品問合せ管理システムの更新を作業の都度入れればフォローは少なくなるという担当者への間接的なメッセージですね。
たびとそのうち，担当者は問合せ管理システムの画面をいつも開き，対応作業とシステムへの更新がほぼ同期するようになりました。もちろん，私は更新される都度直ちに中身を確認し，必要な場合は情報補足，担当者への助言や指示も入れます。

＜たびとが考えるITチームのリーダとは？＞
保品それを見ずに超エライ人が騒ぐ場合もあると思うのですが，その場合やはり大変でしょう？　僕の場合，問合せ管理システムを十分更新できていないこともあるためか，そんな経験がここ何回も続いていて。
たびと保品さん。リーダという仕事の範囲や重きを置くところを少し勘違いしていませんか？　
保品．．。
たびとリーダは，自分一人ですべてできる能力がないといけないというのが私の持論です。ただ，できるスキルはあるけれど仕事の量が多いため，チーム体制を任され，案件や役割の分担を検討し，さらにチームのシナジー効果を活性化させ，人数以上の成果を目指している立場がの私が考えるリーダのイメージです。
保品僕の場合，利用者の上層部が怒っているとい言われると，すごく追いつめられ感が出て，その対応にすべての精力を使い果たそうとしてしまいます。
たびとリーダは，チームをまとめたり，上司や利用者の評価を下げないことが最大の仕事ではないのです。実案件対応のスピードアップは担当者をフォローするしかないと考えてしまうもそんな対応になってしまうのです。私はそんな上に気を遣う時間があれば，チームの案件対応状況の共有や私自身も含めた保守案件対応能力向上に磨きをかけようとしていますよ。
保品あっ！　そうだった。たびとさんはソフトウェア保守対応の現役エキスパート技術者でしたね。何か，リーダとしてのたびとさんと保守のエキスパートのたびとさんが別にいるようで，頭の中で結び付けられませんでした。
（17話につづく）

対話ケース５（再びユーザ企業IT部門の若手技術者）-15話

Tue, 05 Jun 2018 08:59:06 +0900

＜緊急案件が重なったら？＞
たびとトリアージとは，大規模災害時や伝染病大流行時に，医療関係者の人員や薬剤などのリソースが圧倒的に不足した場合，すぐ治療すべき患者と少し後でも大丈夫という患者などに分け，緊急対応度に色分けされた札を患者や負傷者に付けることです。
保品なるほど。何度が災害訓練のニュースでそんな言葉を聞いたことを思い出しました。でも残っているのが保守の緊急案件ばかりだったり，あるメンバに緊急案件が重なった，またさにそのような場合はどうするのですか？
たびとその時は，私自身が決めた保守案件のトリアージに従い，私が支援や対応作業に入りました。具体的には緊急度の高い案件を私が分担したり，多くを担当しているメンバの担当案件の捌（さば）きをしたのです。緊急の連絡や「どうなっているんだ！」という対応フォローが多く実対応担当メンバに次々と入ってしまうと，担当者がその対応に追われて，保守作業対応そのものができなくなるを防ぐためです。
保品次々入ってくる新たな緊急案件の状況を聞いている間に，対応中の保守案件の対応がどんどん遅れていくというやつですね。
たびとそんな状況でも担当者に任せっきりにして「何とか治まってくれないかなあ」と願うだけの，手が動かない管理者が多い組織は最悪ですね。

＜誠実な対応の仕方は「まず謝罪」か？＞
保品それってわが社のことですかね（笑）　そうしますと，たびとさんは緊急案件が重なったとき「今は緊急案件が多数入っていて，対応に追われ，もう少し時間をいただきたい」と問合せ者にまずは謝罪をして，まず時間稼ぎをするのですかね（笑）。
たびと「謝罪」？　いえいえ，そんなことは基本しません。形式的謝罪だけでしたら，ヘルプデスクでもできますからね。そんな日本的な「まずは謝罪」メインの捌き方は，私に言わせればまだまだ落第点ですね（笑）。
保品やっぱり，そのように怒られそうな気がしました（笑）。さて，たびさんはどんな捌き方をされるのですか？
たびと相手にもよります。ただ，こちらの忙しいことを言い訳にすることはどんな相手に対しても基本しません。
保品でも，実情は緊急案件に追われているのですよね。

＜当事者であることを意識して事実を丁寧に説明する＞
たびと言い訳をする暇があったら，問い合わせを受けた案件の対応状況を私は説明します。そのために，問合せ管理システムがあるのですから。
保品例えば，どんな状況説明を？
たびと「現在，詳細ログデータや関係データ○○の採取を顧客運用担当者に依頼中」「採取データの入手がすべて完了して，順次解析中」「一部標準ソフト○○の動きに疑義があり，当該ソフトのサポート部門に至急調査を依頼中」「直接原因○○によるらしいのですが，それを引き起こす根本原因が当該アプリとは別にあると考えており，その調査のための再現テスト準備中」など，事実に基づき，誤魔化さずに実際に対応し，検討している具体的なこちらの動きを丁寧に説明します。
保品他の案件対応をそれ自体の対応が進んでいなくても？
たびと対応スピード感が人によって大きく異なる理想値より遅いとか早いとかの説明に価値を私は感じません。そんな説明しても，早く対応してほしい一心の問合せ者の気持ちを変えさせることは難しいですからね。
保品確かに，対応が遅れていることに対して，謝罪や言い訳をされても，対応に満足されることは少ないと僕も感じることが多いです。
たびと事実に基づいた対応方針を具体的に説明するのと併せ，同時にしっかりした対応見込みを説明することで，問合せ者は安心してくれる場合が多いのです。
保品それは何故なんでしょうか？
（16話につづく）

対話ケース５（再びユーザ企業IT部門の若手技術者）-14話

Tue, 29 May 2018 15:15:42 +0900

＜問合せ管理システムへの入力はみんなを助ける？＞
たびと簡単なことです。問合せ管理システムは最終更新日時の降順に案件を最終更新者の名前入りでリスト出力する機能をもっていました。更新者対して，漏らさずお礼を言っただけです。
保品えっ? お礼ですか？
たびとそうです。「○○さん。□□番案件の情報を午前中に情報追記し，併せて３件の新規登録をしてくれて，ありがとう」と，みんなに聞こえるように大きな声で言うだけです。
保品入れたら褒めてくれるのだと思わせるのですね。
たびと「褒める」とは違います。あくまで「入力作業への感謝」です。「入力するのが当たり前」という雰囲気が入力を阻害する元凶ですから，「忙しい中入力してくれたのです。みんなで感謝の気持ちでちゃんと見ましょう」ということを伝えるのです。
保品あっ，そうですね。「褒める」という言葉は完全に相手に対して上から目線ですね。また，勉強になりました，気を付けます。
たびとそのお礼をバカみたいに私が続けると，その週の曜日を追うごとに問合せ管理システムの更新が進み，登録も増えていきました。

＜2回目の月曜ミーティングは？＞
保品正に「たびとマジック」ですね。2回目の月曜ミーテイングはどう進められたのですか？
たびとメンバが保守対応と問合せ管理システムに更新情報を入力するだけで精一杯だったのを私は知っていますので，更新リストを用意して，この1週間に新規登録されたものから順に，担当メンバから，プロジェクタに投影して説明してもらいました。
保品どんな案件が新規に登録されたかを全員で共有するのですね。
たびと共有の効果は，まだまだこの時点では私は期待していません。みんなの前で対応状況を説明することに慣れてもらうことがこの時点で一番私が期待していることです。
保品入力が進むように仕向けた後，次は説明までさせるのですか？
たびと説明してもらうことで，説明も場慣れするだけでなく，実は入力の質が揃うのです。説明してもらうと必ず「入力がまだなんですが」と補足説明が入ります。その補足を，入力を説明者の宿題にせず，その場でキータッチが最も早いR君に問題点管理システムに入力してもらいます。アッという間です。

＜メンバ自らが入力の質を高める？＞
保品次回からは，補足説明の記述も事前に入力されてくるようになるのですね。
たびとその通りです。メンバには「説明すべき大事な情報を入力していないのはいけない」という気になってもらうのです。
保品これだけ丁寧に入力させると週当たりの案件の対応数が大きく減るのではないですか？
たびと最初は少し対応件数が減ったかもしれません。それも各自日に入力に要した1時間分だけですけれどね（笑）。逆に，対応優先度付けに的確さとメリハリができ，1ケ月ほどしたら緊急案件の対応放置や大幅な遅れで，ユーザから怒られることが激減しました。
保品優先度付けはメンバの判断ですか？
たびといいえ。多分月曜日ミーティングで案件ごとに対応のトリアージを私自身がしたか，私が思うトリアージレベルになるようメンバに仕向けたと思います。
保品トリアージ？
（15話につづく）

対話ケース５（再びユーザ企業IT部門の若手技術者）-13話

Sun, 27 May 2018 09:57:30 +0900

＜自分を客観的にチェックする自分を別に作る？＞
たびと他人の目で相互にチェック効果もあります。でも，もっと重要なことは，各メンバの自分の心の中にチェックマンを養成するということなのです。
保品たびとさんの得意な心理学的対応とでもいうやつですか？
たびと各メンバが自分で一生懸命作成した障害報告書，修正仕様書，修正設計書，修正プログラムなどが書けたら「できた！」とすぐ思うのではなく，別の人格である自身に内在するチェックマンが「では，本当にできたかチェックを始めるぞ」と自分の成果物をついて客観的に確認するようにしてもらうのです。
保品別人格？　「二重人格とでもなれ」ということですか？
たびといえいえ。客観的に自分の成果物を確認する場合，「自分が」やるという認識が強いと，どうしても「自分は正しい」「低レベルな間違いはしないはず」というフィルターを掛けて見てしまうのです。そのフィルターを自分で取り払うことができるような状況を別人格と表現しただけです。
保品そのあたりまで，じっくりと先を見越した人を扱う自信というか，やり方の信念という点で，私はたびとさんに比べまだまだですね。私のチームミーテイングがうまく行かない原因はすべて私にあるということがだんだん見えてきました。
たびとそんなに落ち込む必要はありません。私の経験でも状況は常に違いましたし，うまく行かないことも数えきれないほどです。当の私も完全に自分の成果物を自身で客観的にチェックできているわけではありません。ただ，現状を打開するには自分の経験から良いと信じることを，最初は全然100点満点でなくても，地道にやり続けるしかないのです。
保品でも，一人の力では，いくら信念が強くても，進みが厳しい現状もあるのではないですか？

＜やらずに「信念」を語るのはどうかな？＞
たびとたぶんその通りかもしれません。ただ，保品さんは「いくら信念が強くても」と言われていますが，その信念は周囲がやり方を変えることへの抵抗感に負けている程度の信念ということですよね。
保品たびとさんは，痛いところを突きますね。強い信念でやりもせず，今私がいった信念は，最初から不可能な場合のことを考えてしまう程度の信念だと仰りたいのですね。
たびと結局，自分が一番仕事をするのだということをそれこそ信念をもって相手に伝えられれば，周囲もいずれは付いてくる可能性が高くなると私は強く感じています。
保品逆に，最初から誰かにやらせることを考えたり，周囲の力に頼ろうとしてしまうと，周囲の抵抗に負けて，うまく行かないとお考えなのですね。
たびと周囲に頼ろう，周囲に任そうとする「人間の弱さ」から，最後はそのうまく行かないとその原因をどうしても自分以外のせいにしてしまうです。
保品なるほど，人間の弱さですか．．。その「弱さ」という点については，後でもう少し詳しくお聞きしたいと思っているのですが，月曜ミーティングの話の先をお聞きします。Hさんの反応はどうでしたか？

＜批判的だったHが少しずつ理解を示す？＞
たびとその後H君と少しやり取りした後。彼は「要するにたびとさんが言いたいことは，僕が風邪で休んだときでも，誰かが対応できるようにしたいということですね？」と理解を示し始めてくれたのです。
保品一番批判的なHさんが理解を示したことは大きかったのでは？
たびと私は最後の一押しの言葉を彼に付け加えました。「まったく，そういうことなんですよ。Hさんの休んでいる間，『私が』Hさんに代わって対応できるようにするためですよ。どっちが対応能力が高いか勝負だね（笑）」とね。ここで，12時前になったので，「来週までに，みなさん毎日必ず1時間を使って，担当している案件を問合せ管理システムに順次登録してください。登録するために要した1時間分案件対応が遅れても構いません。」と言って終了しました。
保品 1回目は終った後，その週のメンバの仕事ぶりはどうでしたか？
たびとメンバは自分の担当している残件について，ゴソゴソと確認を始めました。たとえば，メンバ間で「この案件って，そっちにボールが行っているよね」「あっ，そうだった。ゴメン放置していた」「じゃ，問合せ管理の状況をそちらにボールがある状態にしてくれる」「了解」などとコミュニケーションが密に始まりましたね。
保品自分以外に見えない状態にしておくことを「楽」と感じるか，相互にはっきり見える状態のほうが「楽」と感じるか。後者のほうが「楽」だと感じるように少し変わったのですね。
たびとそんなにすぐに変わりません。ただ，ここからが勝負です。うまく行き始めたから，手を抜いてよいと考えるとすぐ元に戻ってしまいますから。
保品では，たびとさんは追加でどんな手を尽くしたのですか？
（14話につづく）

対話ケース５（再びユーザ企業IT部門の若手技術者）-12話

Mon, 21 May 2018 16:27:41 +0900

＜本人が間違いに気づかないときには？＞
たびとまず本人は気が付いていない間違っている部分の説明を，説明理由を伝えず，本人にしてもらいます。そうすると，7～8割は場合，説明しているうちに本人が気づきます。
保品それでも本人が間違いに気づかない場合には？
たびと説明が終わった後，少し時間をわざと取って，本人が気づくのを待ちます。その間は，当然ですが場は沈黙が続きます。
保品説明した本人に「何か変だな？」と思わせる訳ですね。本人がもう一度自分が今説明した情報をその場でよく再確認しますから，気づく確率が高くなるわけですね。
たびと実は，それをしても気づかないことがあるのですが，本人も沈黙に耐えられず「どこか変なところがありますか？」と大概は聞いてきます。
保品そこで，ようやくビシッと間違いを指摘するのですね。

＜間違いの指摘はまだしない＞
たびといいえ。本人に対して「こちらの理解が足らないのかもしれなんだけれど，○○の部分の説明が少し分かりにくくてね」と断定的に間違いの指摘はしません。
保品そこまで限定されると本人も完全に気づくでしょう。
たびとまあ，ほとんどそうでしょうけど。稀にそれでも本人が気づかないときがあります。そんな場合は，「○○の部分の△△の説明は君は分かった？」と他のメンバー，それもできるたけ若手に聞くようにします。
保品若手に言わせる意図は何ですか？
たびと若手でも間違いに気づくようなことを，思い込みが邪魔をして気が付かないことを本人に気付かせるのです。
保品かなり我慢が必要と思いますが，こうすると，全体としてどんな効果があるのですか？

＜リーダは指摘しかしないチェックマンではない？＞
たびと一番の効果は，本人の思い込みの強さを是正させることではなく，私が誤りを厳しく指摘するチェックマンではない。これをみんなに浸透させることです。その結果，メンバが私に話しやすくなるのです。
保品何か言うと頭ごなしにすぐ間違いを指摘するようなリーダの下だと，やはり話しにくいように感じますからね。
たびとトンチンカンな報告や相談でも，まずはそれを聞いてあげる。最初からリーダの価値観を押し付けないことが，メンバを委縮させない重要な要素だと私は思っています。
保品それだと，リーダしてのメンバに対するチェック能力やリーダシップ面の力が落ちませんか？
たびと確かにチェックするのはリーダの選任タスクだと思ってしまうと，そういう恐れがあるでしょう。ただ，今までの私のやり方から分かってほしいのですが，チェックマンは各メンバ自身になってほしいのです。
保品メンバ間で相互チェックをさせるということですか？
（13話につづく）

対話ケース５（再びユーザ企業IT部門の若手技術者）-11話

Sun, 20 May 2018 13:03:52 +0900

＜メンバには入力する癖をつけてもらう＞
たびと「ただ，私はリーダとして，その記録されて内容をすべてしっかり読みます。内容をよく確認せず，担当者に振るだけして，やみ雲に案件対応数を増やすことよりも，対応内容の質を揃えたいのです」と私はメンバに伝えました。
保品最後に「質を揃えたい」と仰ったあたりがたびとさんの意図のポイントですね。
たびと保品さんは，相変わらず鋭いですね。情報の質を揃えるためには，必要十分な情報かどうかは別にして，まずは入れないことには始まりませんからね。
保品情報自体が無ければ，揃える揃えない以前の話ですね。まずは，無駄が多いのや言葉足らずなのや，いろいろ入力させて，比べて見て，入力情報の良否をたびとさんが指導し，良否を判断できる能力をメンバに養われせようということですよね？
たびと保品さんは，相変わらずせっかちですね。
保品おっと，やっぱり結論を急いで求め，安心したがる僕がいるとのご指摘ですね。

＜最初は入力データにケチをつけることは厳禁＞
たびとそんな指摘をするつもりはありません。最初は記述内容が下手でも，詳しさが揃っていなくでも良いのです。まずは，入力する癖をつけてもらうことです。
保品その入力をメンバーに徹底してさせるのが，なかなか難しいと私は思うのですが．．。
たびと何でもそうですが，最初から上司やリーダが，完璧な入力にすぐ近づけようとして，良否をどんどん評価して悪い部分を次々指摘してしまうと，メンバは入力する気が出なくなるし，気持ちが萎縮し，情報を隠そうとするのです。
保品でも，事実と違った明らかに誤った入力内容は，そのままにはできないでよね。
たびと保品さんも早く指摘してメンバに直させたい方なんですよね（笑）。

＜事実と異なる入力は本人に気付かせる＞
保品う～ん。リーダになるとなぜか気が焦ってしまうのでしょうか。どっしり構えられません。この場合，たびとさんらしいやり方をされるのですよね。聞かせてください。
たびと基本は間違いを指摘するのではなく，本人自身に間違いを気づかせるように仕向けます。簡単に聞こえますが，気づき方は個人の性格や発想の柔軟性によってまちまちですから，一概「こうすれば良い」と言えないため，結果として結構面倒な対応になるのです。
保品たびとさんの丁寧さには敬服しますね。
たびと保品さんは違いますが，相手に合わせた多様な対応が面倒なリーダは，つい間違いの指摘をして終わらせようとするのです。
保品私もその部類になりそうです（笑）。具体的にはどんなことをして気づかせるのか，一つだけでも良いので教えください。
（12話につづく）

対話ケース５（再びユーザ企業IT部門の若手技術者）-10話

Fri, 11 May 2018 18:04:36 +0900

＜たびとの説明に不満を持つメンバが発言開始＞
たびとそこでこのチームに入ってしまったことにもっとも不満をもっていそうなH君が突っ込んできましした。多分，ソフトウェアの仕事について「保守中心の考え方」を持つ私が相当変わり者の人間だと周りから吹き込まれてきたのでしょう。
保品たびとさんが変わり者であることは，私も全然否定しませんが．．（笑）。どんなことをHさんは行ったのですか？
たびと「担当分けをせず，チームの全案件をみんなで観ろということですか? 　みんながリーダになれというのと同じじゃないですか？」と言ってきました。
保品たびとさんは，多分「みんなが他と連携しつつ進めるリーダの意識でやってほしい」と仰ったのですよね。
たびとそんな意味のことを確かに言ったと思いますね。そしたら，H君は「それって，究極の労働強化だと感じますし，結局だびとさんが最も楽をしょうとしているしか思えません」と。
保品かなりストレートな発言ですね。

＜ようやく，不満表明が出てきた？＞
たびと H君のこの程度の言い方は全然もの足らないくらいですね。こういう不満や疑問に思う気持ち，公然と反論したい気持ちを溜めずに思ったときにすぐ言えるチームの雰囲気を私は目指していましたから。
保品その覚悟が今の私に少ないということですね。そういった「ネガティブな発言が少ないほうが良い」とつい思ってしまう自分のやはりどこかにあるのでしょうか。
たびと何も不満がないことに越したことはありません。でも，ソフトウェア保守を仕事の一部として兼任担当している担当者は，不満感を持っていないことがあり得ないと考えるべきだと思います。
保品それはどうしてですか？

＜保守作業には今だに市民権がない？＞
たびと以前お会いしたときにもいいましたが，ソフトウェア保守作業の進め方，成功事例，保守で高評価を得るための達成項目などが多くのIT組織では明確に規定されていないからです。
保品わが社は，あれから1年半経った今でも「保守はやって当たり前」の雰囲気があり，不満はたまりやすい状況に変わりはないですね。前回たびとさんとお話しする前の自分がまさに保守に対して不満だらけでした。
たびと現状を正確に把握せず，頭の固い開発中心のパラダイムに侵された，または毒された人々が組織や業界を動かしている限り，そう簡単に保守作業の市民権は得られません。
保品そのあたり，リーダになってしまうと，チームをまとめようとするあまり，発想が逆になるから不思議ですね。最初チームミーテイングの続きが聞きたいですね。
たびと私は「Hさんがそう思うのも，もっともです。担当者割り振るだけでなく，その対応も細かく記録させ，さらに細かく指摘するなんて労働強化以外にないし，リーダは何をするのか？という疑問は当然です。よく言ってくれました」と反論はしませんでした。
保品そして？
（11話につづく）