外注を叩けない性格だけど

最初の会社やその次の会社（前々社）に居た頃、外国へのオフショア含め、システム開発を外注していたことがある。
その時にどうしても同僚達と共有できなかったのが、外注を「叩く」という感覚。

もっとも、一般的な外注を叩くというレベルがどの程度のものなのかよく判らないし、同僚達が叩いている、というレベルだったのかどうかはよく判らないけれど、少なくとも私は同僚ほど外注にきつく出れなかった。

単に非コミュな性格のせいもあるけど、自分達の方の発注仕様書が、それで満たすべき項目として必要十分なのか、判り易く書けているのか、全く自信ないし、ウォーターフォールで発注したといいつつなんだかんだで仕様変更とか入りまくって、そんな状況での開発を自社でせずに外部で請け負ってもらっているのに、強くなんかでれるわけないやん、と個人的には思ってた。
ウォーターフォールどころか、しょっちゅうコンタクトとって状況確認して、実装完了危なそうだったら早めに仕様変更提案したり、Perlみたいに自分で関われる言語での開発だったら、危なそうな時は切り分けられるところの機能はインタフェース切り分けて、逆請負よろしくこっちで開発引き受けて渡したりもしていた。
オフショア時代、綿密に状況確認するために、外注先との意思疎通にメールじゃなくメッセンジャー使ってたのって俺くらいじゃなかったか。

前々社時代に役員が見つけてきた外注、頼んでみたら携帯サイトの開発経験もあるしPerlも使えるって話だったはずなのに、いざ任せてみたら何も判ってない状態。
なので開発の一部引き受けてノウハウもフレームワーク化してやって、役員からはそんな事はするな、それはお前の仕事じゃないと言われたけど、んなもん丸投げで納期だけ決めて、正月休みも返上させて突貫工事で叩いて叩いて作らせたところで、元々スキルもノウハウもないところで人月だけ費やさせても、いいもんができるわけないだろうと。
確かにスキルもノウハウもないくせにある振りをして受注した外注側の経営や営業も悪いんだけど、それをもう受けてしまった以上あっちの現場叩いたってスキルやノウハウが沸いて出てくるわけじゃなし、むしろ士気が落ちるだけなのだから、積極的に支援して梃入れするしかないじゃないか、と思ってた。
安いというだけで頼りない外注を見抜けず選んできたのはそっちの責任なのだし、いい加減な外注先経営陣に文句つけるのはそっちでやってくれ、こっちは使える手駒で少しでもよくなるよう手を打たないといけないのだから、好きにやらせてくれ、と思ってた。
別に気が弱いから、外注先が可哀想だから叩けないとか、そういうのだけじゃなくて、そういうのもあるけど、スキルもノウハウもないのにさらに士気が落ちればもうどうにもならんし、どうせ徹夜するんなら、もうギリギリでこちらとしてもソースに手が出せないような状況になってからイライラと待つだけの徹夜を3日するくらいなら、まだ精神的余裕のあるうちに関わって、1日徹夜し目処をつける方がマシというのもあったりして。

そういうのをやると、よく責任分解点が、とか何とか言われるんだけど、そもそもサービスが止まったり、客先からクレームが来たり不具合でたりした時に、そんなボールのなすりつけ合いするのかよ、とか思う。
どこの責任とかじゃなくて、客先に不利益生じさせないのを最優先で対応すべきだろうとか思う。
某清掃工場にオフショアで開発した運転記録集計システム収めた時、納入後にデータの収集が一時止まったりしたんだけど、普通に不具合対応のスキームに則ってたら状況を持ち帰って、レポート書いて外注先に投げて原因を調べさせ、修正されたものを再度テストして再納品、とかになるわけだけど、そんな手順踏んでたらログからデータ復旧できないレベルで停止してしまい、客先のデータ消失してしまうの間違いない。
なので現場でノートPCから携帯電話で回線繋ぎ、VPNでオフショア外注先と繋いで、現場でのログやパケットキャプチャ結果や送り、メッセンジャーで原因を議論しながらバグを特定して修正してもらい、その場で修正版を納入し、データの復旧までやったこともあった。
今と違って携帯回線なんて細かったので、データの転送だけでも時間がかかり深夜まで何時間もかかった作業だったけど、外注先の担当者は快く引き受けてくれた。
正規の手順を踏んでいないという点で全然褒められたものではないかもしれないけど、個人的には客先にデータ消失させずに問題解決できたことも、またそんな無茶なやり方に付き合ってくれる関係を外注担当者と築けた事も、よかったと自分では思ってる。
（そもそも不具合を出すな、という話もありますが...）

突貫の開発とか極限の状態にある時に人を動かすのは、叩いたりして追い込むことではなくて、いかに士気を引き出すか、担当者にやる意味、意義を感じさせるか、だと思ってる。
まずその第一は感謝する事だし、次に大事なのは、単に必要な仕様だけを投げて作らせるんじゃなく、その作っているものの本来の意味・目的をいかに伝えるか、感じさせるかということと思ってる。
だからオフショア開発した際には、日本の文化も判らないしこちらの業界も判らないし、ましてや作っているシステムがどう使われるのかも判っていない開発チームに、無味乾燥な仕様を与えるだけじゃなく、まず日本ではこういう制度があって、こういう業界があって、そこではこういう作業が発生するのでこのシステムがこう使われる、というのを伝えるところから始めた。
その結果、こっちが伝えた仕様だけではなく、逆にそういう事がしたいのならこう処理した方がいいんじゃないか、といった逆提案ももらえたりした。
自分の作ったシステムが日本のどこでどんなふうに使われ、またその場所はどんなことで有名なところ、とか、そんな事も伝えた方がより自分達の開発に親しみを感じてくれるんじゃないかと思って、納入レポートまで作ろうとしたりもしてた...残念ながらそれは、完成させて彼らに渡す前に、退社してしまったので実現しなかったけど。

もっとも、綺麗事？書いてるふうかもしれないけど、最初の会社の元同僚ながら後に海外で独立して「オフショア外注を受けるほう」に回った友人の1人からも、また前々社でむちゃくちゃな経営陣に振り回され一緒に辛酸を舐めた同僚からも、「大塚さん、強く出るときは出た方がいいですよ」と忠告されたことは、1度ならず何度かある。
だから、もしかすると私のやり方は度が過ぎているのかもしれないし、そもそも非コミュでうまく強いことが言えないのを、逃げて美辞麗句で誤魔化しているだけかもしれない。
でも、私はこのやり方しかできないので、これからもできる限り心を大切にしていきたいと思う。

今の会社でも一部外注を使っているのだが、今の部署・上司は比較的私の自由にやらせてくれるので、大変助かっている。