＜リーダになると保守対応の実務作業卒業？＞
たびと 今まで多くの後輩ITエンジニアを見てきましたが，リーダになったら実務を直接担当する技術者という役割を「卒業した」みたいに考える人が多いから，保守現場はおかしくなるのです。
保品 僕もリーダになって，報告書作成等の事務的な仕事が増えてくると，「保守対応を卒業したいかな」という気持ちに揺れることがあります。
たびと 対応件数はメンバのときより少なくても良いのです。リーダが率先して実際の保守対応もすれば，保守対応の仕方や案件の捌き方の例をメンバに見せる良い機会にもなると私は考えます。
保品 たびとさんが手本を示すのは，よほど実務技術者としての自信をお持ちだからですよね。それとも，リーダの事務的な役目はあまり重要視しないため？
たびと ちょっと違いますね。私が保守対応の実務をやったからといって，ベストな結果にならないことも少なくないのです。
保品 えっ？ リーダがカッコよく手本を見せたが，結果が思わしくないと，メンツ丸つぶれでメンバの信頼を無くす恐れはないのですか？ 僕なら自分がやって失敗してしまった恥をメンバに見せるのは，やはりリーダとしては避けたい気持ちになりますよね。
＜不足リソースを担当に押し付けるのがリーダ？＞
たびと そうですか？ リーダが結果責任を気にすることは必要だと私も思います。でも，ソフトウェア保守対応チームの場合，常に並行して複数案件対応が必要になります。
保品 確かにうちのチームも保守対応要の残案件が完全に無くなったり，一人が1件のみ対応で人が足りるなんてことはありませんね。
たびと 足らないリソースの中ですべての案件について100点満点の結果を求められてもできない。リソースが足らないときは，限られたリソースの中で全体として最大点を目指すことはしても，全案件を100点満点の対応にこだわるのは現実的でないというのが私の考えです。
保品 でも，足らない時間の中でも，頑張って100点満点を目指そうと真面目な技術者は考えそうです。
たびと リソースが足らない責任は担当技術者側にあるのではないのに，足らない状況を是とし，真面目な技術者の犠牲を強いているリーダや管理者に問題があるのです。そういう人たちは「できないのを工夫してヤリきるのが担当の仕事」だと，自分はできもしないくせに決めつけるから。保守対応のリソース不足にまったく気が付かないケースが多いのです。
保品 そういえば，僕の上司は「簡単な修正なんだから」と，当然のごとくすべての案件対応を期限内に完璧にやれと言わんばかりで，プレッシャーを掛けてきます。
たびと 私の場合では，上司がそんなことを言おうものなら「どうぞ，代わりにやってください」と私から言われるのを上司自身が分かっていますからね。
＜メンバはリーダの手本をちゃんと参考にする？＞
保品 「できないものはできない」と判断できるたびとさんの経験を，組織として共有されている点がうらやましい限りですね。
たびと ソフトウェアに限った話かな？と思うけど，「大した修正じゃないから，やってみないとできるかどうか分からないよ。まずはやってみようよ。何かあれば相談に乗るから」という上司やリーダにも，現場経験の少ない，担当任せの考えの持ち主で，その場主義の場合が多い。あくまでも私の個人的な経験からですがね。
保品 確かに。僕が保守担当メンバのときの経験から，その見方にも同意できる部分が多い気がします。では，リーダ自らがやって見せるポイントは何ですか？
たびと ポイントは，メンバよりも豊富な保守対応経験から，メンバが気づかない視点まで考え，先を読んで対応していることを示せればよいのです。私が，メールで関係部門との調整を淀みなく，かつ丁寧に進めている状況は，逐一メンバにも写しを入れていますから。
保品 でもですね，メンバはちゃんとそういったたびとさんのメールを読んでくれますか？
たびと それを確認するのが月曜の定例ミーティングの目的の一つですよ。毎回確認する必要なんか全然ありません。たまに「何月何日に運用部門の○○さんに私がメールで確認した意味はわかる？」とミーティング時にメールをプロジェクタに表示して参加者に聞けばよいのです。
保品 一見何気ないようなメールを選んで，その発信目的を理解できているかを参加者に確認し，説明するわけですね。
たびと そう，選ぶのは全員がその送信目的を理解していることは無さそうな「何気ないメール」です。送信目的のポイントのみ丁寧に説明をします。そのときのメンバの顔を見るだけで，すでにちゃんと読んである程度理解しているメンバと，私のメールをスルーしているメンバはすぐわかります。
（18話につづく）