仕事の考え方
現場では考え方が違ってぶつかる事もある。
7年目にして初めて、仕事の考え方が全然違うリーダーとぶつかった。
しかもお互い相性が悪く、バチバチしまくってるのでログとして残しとく。
今後に活きるように。
大事なのは、相手はこういう考え方の人で、自分とは違う考え方なんだな、って落とし込む事。
相手を変えようとしても変わらんし、自分がイライラするだけ損なので。
「具体的に教えてくれ」に対して
事象
なにか不具合や課題があったとして、それに対する原因と対策を伝える必要があるとする。
当然ながら、まずはヒューマンエラーだとか、仕様誤認だとか、根本原因を書く。
そのうえで、「このコードのこの箇所をこういう風に直す」と書いたとして。
相手がSEでコード書いてる人だから、そっちの方が解りやすいと思ってそうしたが、「そんなん見せられてもわからない」との事。
実態
自分にとっての具体的とは、「この箇所をこう直す」というレベルのものなんだけど、リーダーにとっての具体的は「サルでもわかるレベルで、適度に抽象化した日本語のみの説明」というものだった。
改善
可能なら、そのリーダーが過去に対応した説明資料を見て、その人の「具体的」の基準を推測する。
「実現可能か確認してくれ」に対して
事象
例えば、「HTTPヘッダを追加してくれ」という依頼があり、サーバー設定を変えないといけないとして。
ローカルはtomcatしかないとする。
しかし本番環境はapacheか何かで動かしていそうに見える時。
自分は、本番環境ではどういう構成で動いているから、どのファイルを編集しないといけないかを事前に明らかにしておきたい。
ローカルはtomcatで動いている、しかし本番は違う構成で動いていたら「実現可能か確認した」事にはならないはず。
だから、apacheなのか、nginxなのか、また違う技術で動いているのか
それを事前に確認した上で、tomcatはこれのファイルをいじればOK、apacheはこのファイルをいじればOK、という形で進めたい。
自分では本番環境に触る権限がないとしても、このファイルをこう編集してくれ、と依頼するのがSEとしてやるべき仕事のはず。
実態
しかし、ローカルのtomcatだけで実現できるか先に確認しろ、本番でできるかどうかは別の話という考え方のリーダーもいる。
全体を捉えて、筋道立ててから対応するのではなく、目の前の事をまず解決してから次を考えようってタイプだと思われる。
僕がなぜ全体を捉える必要があると考えたか、その理由を説明すると、「技術に頼りすぎ」という謎のお言葉を頂いた。
全然納得できないけど、仕事だからやるしかないね…。
改善
リーダーがいるなら、ここのあたりを会話で見極める。
指示通りやらないと怒る人なのか、先回りで対応したほうが嬉しい人なのか。
先回りでやる事が、必ずしも喜ばれる訳ではないようだ。
「例え話」が通用しない
事象
何かに対する説明をしたとき、理解できてなさそうなので例え話を出すとする。
「例えば、OSレベルの違いと同じだと思ってもらえれば。WindowsとLinuxくらい、やるべきことが違うという話です」
実態
「今回の案件でWindowsだとかLinuxになんの関係があるの？」と「例え話」と言ってるのに、例え話の内容に集中してしまい、さらにリーダーが混乱する。
改善
なんでもない話の時に、例え話をしてみて、それが通じる人かどうか、見極める。
仕事で例え話をすると、通じない時にお互いにイライラが募るので。
相手が理解しやすくするために、例え話をすることが、万人に通じるとは限らないようだ。
提案の仕方
事象
問題に対する対応案が複数浮かんだとき、それを文章にまとめて送付する。
過去に説明済みの内容なので、文章のみで説明が通じると思って送付した。
すると、わからないといわれてしまった。
実態
過去に説明済みの内容でも、再度新しく資料を作り直す必要がある。
また、メールも引用返信で履歴がついてても、そんなとこ読む暇はないから資料化してくれとの事。
改善
工数は増えるが、資料を作ってあげる。
しかし、資料化する前にまず口頭ベースで話してくれ、というリーダーもいる。
この辺は一回試してみて見極める。
不具合の証跡を残す
事象
単体テストレビューで自分が気づかなかった不具合を指摘してもらったので修正。
ソース修正とともに証跡も取り直した。
しかし、不具合発生時の証跡も欲しいとの事。
改善
レビュー担当によって、不具合の証跡が欲しいかどうかは変わると思われる。
自分は6年間やってきて、不具合の証跡保存を求められる現場はなかった。
※本番障害は別。
逐一確認するようにする。
DBのハードコピー
DBダンプを残す際に、Excelに貼り付けてOK派と画像じゃないとNG派がいる。
あと、DBダンプの上にselect文貼り付けてくれっていうよくわからん指摘を貰う事も…
ヘルプで入ってもシステムをすべて理解している必要がある
助けてくれ！って言われて、一切やったことないシステムの保守案件にトライ。
レビュー出してると、特定システムの細かい謎仕様の指摘を貰った。
特定データの細かい仕様とか理解してないと、レビュー工数増えるからやめろ！って怒られたりする。
エラーメッセージはわかりやすく
細かく伝わるように作らないといけないらしい。
具体的に＊＊＊というデータが＊＊＊なので＊＊＊できません みたいな。
朝令暮改
何度繰り返されても、心穏やかに受け入れる。
後から指摘
各工程のレビューを通しても、あとからコレこうしろ！って修正依頼がきたりする。
それをレビュー工数増えるとか言われて怒られたりする。