ブリッジSEをやった経験を少し記事にまとめて後悔公開してみたのですが、
その最近Twitterにこんな投稿があって盛り上がってるよ、というのがありました。
今さらながらこれを見てわかりみ、というか、身につまされるところが多かったので、少し散文的ではありますが実際の例を上げつつ掘り下げてみたいと思います。
外国人が「言われたことしかやらない」のは本当か
そもそものTwitterの書き込みを引用してみますが、
みずほの件がお昼のニュースで取り上げられてたけど『言われたことしかやらないような担当者の意識を改革する』って言ってた。
— syacyo (@syacyo_twit) 2022年1月14日
これは日本独特の考え方。日本以外の作業者は普通は言われたこと以外はやらない。なので欧米はマネジメント層が優秀だし高給。
だからオフショア開発で外国勢に作業依頼したときに成果物が酷くてなぜ◯◯していないんだ、と問い合わせると
— syacyo (@syacyo_twit) 2022年1月14日
オフショア『それは指示されていない』
と普通に返ってくる。
これで怒る日本人は自らのマネジメント能力の欠如を気づいた方がいいって事。ふんぞり返ってるだけじゃ誰も動いてくれないよ。
という話は、よく言われるし、オフショア開発の管理の経験上、総論としてはこれは事実であると言っていいと思います。
ただし、逆説的に言えば、彼らは『言った(頼んだ)ことは必ずやってくれる』ということでもあります。一部例外がありそうな気もするのですが、基本的には「頼んだら必ずコミットする」「頼んでいないことはやってくれない」という考え方で正しいと思います。
ここで注意しなくてはいけないのは、彼らは「頼んでいないことはやってくれない」という言い方。ニホンゴムズカシイネ。
『言われたことしかやらない』という言葉を文字通りに取れば、指示通りのこと以外は絶対にやっていない、と言う意味になりそうですが、おそらくこの発言をした(元ソースである)みずほ銀行の頭取だかの発言には言外に「言われなくてもわかるでしょ、ということも気付いてほしい」と言っていると思いますし、そう言う意図をもってこのような発言をしたのだろう、と思います。
言われなくても分かる、という言葉にもいろいろと意味を含んでいると思いますが、「暗黙の了解」と、「現場の共通認識」は私も躓いたところですので、経験を含めた考察をまとめてみます。
「暗黙の了解」
外国人に限らず、私たちフリーランスエンジニアが現場に入って最初にぶつかる壁ではあります。「暗黙知」と言い換えてもいいのですが、よくある「え？そんなことも知らない(でやってる)の？」というヤツです。
エンジニアが躓く一般的な「暗黙知」として挙げられるのは、例えば開発するシステムをどのような使い方をするのか、という、業務知識と呼ばれるものです。ECサイトを例にとれば、商品の購入時にどのような支払方法を選択できるのか、というのが挙げられるでしょう。
商品を購入する場合に、支払方法として代引きと口座振替、クレジットが選べると仮定します。その商品を購入するのはもちろん購入者なのですが、その購入した商品は必ずしも購入者の手元に届くわけではありません。いわゆる「ギフト(贈答品)」として商品を送ることが考えられるわけですが、もし商品を自分のところには送らずに、ギフトのみの注文とした場合に、支払方法を代引きにすることはできない(してはいけない)はずです。だって贈り物ですから。贈り物なのに送った先に「この贈り物は代引きです」っておかしい話ですよね。
しかし、システムの使い方(使われ方/ユースケース)がわからないと、商品の支払い方法が設定されていればその通りに設定してしまうわけです。贈り物なのに代引き設定をしてしまう。これは本来要求仕様や設計に明記されなければいけないはずですが、「そんなことはわかってるでしょ」という暗黙知があるからこそ起こりうる問題です。
「現場の共通認識」
業務知識と異なり、現場における共通認識はより「形式知」化させやすいはずなのですが、そうなっていないことで暗黙知化してしまうことが多いのですが、コレは基本的に「形式知化するためのリソースが足りない」といった理由で起こります。あえて暗黙知と分けている理由は、この形式知化しやすいかどうか、という点にあると考えています。
コーディング規約は現場共通認識の最たる例だと考えています。私自身は普段小さいプロジェクトで一人でコーディングすることが多いので意識することもないですが、大きなプロジェクトで複数のメンバーが並行して開発している場合は多少規約、というか簡単なルールを決めておかないと結合テストレベルでの不整合が起こったりするので軽く取り決めをすることはあります。
他にも、「ターミノロジー(専門用語)」も現場共通認識に含まれると思いますが、特に専門用語に関しては、世間一般で使われる言葉の意味と現場で使われる言葉の意味が異なるケースがあることに注意が必要でしょう。
また、元ネタであるみずほ銀行などのケースだと、現場における危機感といったものも共通認識として持っているのが一般的だとは思いますが、外部メンバー、特に外国のメンバーはそう言った現在の状況や過去の歴史などを知らないこともあるでしょうから、危機感の共有は明示的にしないといけなくなるはずです。
「言われなくても分かる」から明文化へ
ざっくりと暗黙知の話としてまとめますが、言葉も文化も違うしわからない人たちと仕事をする上で、「言われなくても分かってほしい」というのはそもそも難しいのです。もちろん、今回の元ネタの発言がどの程度の職位の人が言ったか、にもよるとは思いますが、仮に危機感を共有するレベルでこの発言に至ったのだとすれば、この発言をした人は責任感のない人、責任を他人になすりつける人、という印象を持たざるを得ないですし、オフショアという話に限定すれば、この状態でのオフショア開発はおそらく上手くいかないはず。
もちろん、他人事の逆の意味での「自分ごと」として考えて欲しい、という現場へのメッセージだとしても言葉足らずです。そうではなく、自分ごととするためにどうするのか、という具体的な方法がない。頭取レベルならそれでもいいですが、これが技術畑のトップの発言だとしたらたぶんイケてないです。
みずほ銀行をけなすための記事ではないので話を本筋に戻しますが、暗黙知が多ければ多いほど伝言ゲームが上手くいかなくなるのです。だとしたら、業務知識やターミノロジーなどをどのように明文化していくのか、また、システムの全体像などについてもどこまで詳細に明文化されているかなど、初めてジョインする人*1が資料を見て内容を理解できるように仕組みづくりをすることがオフショア開発では大切だったりします。
マネジメントスキルの違いとか
日本は精神論、根性論を盾にマネジメント層が圧力をかけて作業者がなんでもかんでも気を利かせて動くように強要する文化ができあがってしまっている。
— syacyo (@syacyo_twit) 2022年1月14日
本来はマネジメントする側が綿密に各自の作業内容を分担して、それ以外はやるな、とまで指示するのが正しい姿なのよ。
マネジメント論というかマネジメントスキルというか、そう言う違いもあるのだろう、と思うのですが、私自身実は海外の上司というものを持ったことがないので、海外のマネジメントがどのようなモノになるのかわかりません。そのうえで、経験や書籍などから得た知識をもとに「こういうモノなのではないかな」ということを探ってみます。
前項でも触れているように、そもそも暗黙知があるということを前提にすると、マネジメントの立場から言えば「これは言わなくても分かるはず」という一種の甘えみたいなものは生じるはずです。それ自体は日本固有の問題だとは思っていないですが、そう言った問題をできるだけ生じさせないようにしたいと考えるのが海外(欧米？)の考え方なのではないかな、と考えています。
ただ、そう考えると、それは「マネジメントスキル」なのか？という疑問もわいてきます。Togetterで見ると元スレに対してのレスにマネジメントスキルとしていくつかキーワードが出てきていますのでその中で出てくる「指示」「管理」「属人(化)」というキーワードを使ってもう少し深堀してみたいと思います。
適切な指示を出す？
このキーワードはかなり正論というか、コレが大切なんだな、というのがBSEとして仕事をしているうえで気を付けていることなのですが、指示があいまいになることは確実に成果物に影響を及ぼします。よくある例えとして、地図が間違っていたら違う場所に着いてしまう、というのがありますがまさにそれです。ただ、地図が間違っていたとしても、「暗黙知」の存在によって情報の補正がされることもある、ということは事実です。
先ほどの例と同じくECサイトを例にとりますが、暗黙知として「購入者の住所に送る商品が存在しない場合には代引き支払いをしてはいけない」ということが、顧客と開発者の間で共有されているのであれば、「ではどのような条件で支払方法の制御をするのか」という話題が生まれるし、それを設計なり要件定義なりで明示すればいいのですが、暗黙知が共有できていなければ贈り物を送る先で支払いをするという事態が起こってしまうわけです。
どちらがいいのか、暗黙知を形式知化してあらかじめ情報共有をするのか、その都度開発要件としての指示を出すのか、これはケースバイケースだとは思いますが、いずれにしても指示を出すときに明確であることは必須です。
適切な「管理」をする？
私自身はあまり「管理」という言葉を多用するのが好きではないのですが、そもそも「管理*2」とは何をすることなのかが明確でないし、これは日本固有かな、という気もしますが、かなりあいまいな定義で使われるケースが多いと思っています。
だから、というべきなのでしょうが、いわゆる管理職の人たちがきちんとした「管理」をしない、またはできない、という問題が起こるのではないかな、と思います。海外(欧米)との差異として、マネジメントを専門的に学んでマネジメントスキルを取得する欧米的な考え方と、現場たたき上げのマネージャーが多いという日本という図式を示していた方もおられましたが、いわゆる「管理」のやり方が画一的ではなく、いかにも日本的な「背中を見て仕事を覚える」やり方が、マネジメント層のレベルの低さにつながっているのかもしれない、とは思えます*3。
自分の例をあげるのは失敗例になってしまいそうなので少し心苦しいですが、「マネジメント」の仕事をする時には業務の隙間が相当できることが多くなることから、かなり容易に「あぁ、他の業務も兼務しますよ、できる範囲で」と請け負ってしまうことが多いのですが、それによってマネジメント業務の抜け漏れが発生することは結構あったりします。できるだけそうならないように、とは思っていても、やはり自分自身のスキルの足らなさを感じることは多いです。
「属人化」は適切ではないのか？
この手の話題の中で必ず出てくるのは、「属人化傾向が問題」という話。業務が属人化すること自体は私も好ましいと思っていないのですが、かと言って、誰でも同じレベルで仕事ができるように、というような意味あいでの「非属人化」を目指そうという方向性に向かいがちなのが日本っぽい気がしています。
マネジメント業務のところでも触れているのですが、マネジメント業務は他の業務と異なるスキルセットが必要になるという理解をするとすれば、同様にエンジニアスキルとしても全員がフルスタックエンジニアである必要はなくて、バックエンド専門、フロントエンド専門、DB専門、みたいな、特化したエンジニアスキルセットを持ったメンバーが結集したチームである方が作業効率がいいケースもあると感じています。
私自身は、自分の売り込みをするための謳い文句として「俺フルスタックエンジニアだもんね」と言うことはありますが、業務の内容によってはその一部のスキルセットだけで振る舞うことも当然あるわけです。PMという業務を例にとれば、PMとしてSQLを取り扱うスキルは、業務の一助にはなりますが基本的に使わないわけです。むしろ、どのように仕事を振り分けるか、どのように納期までのスケジュールを担保するかなどの業務を行うわけで、そのために「えっとこいつは確かバックエンドが得意だからこっちのタスク任せよか」とか考えるのがマネジメント業務なわけですからね。
あまねく教育をして、という話もあるわけですが、それをやりだしたら業務はいつになっても始まらないわけです。Laravelに慣れているからと言って、CakePHPベースの開発をするからとCakePHPを覚えさせるよりは、最初からCakePHPがわかっているメンバーを集めた方が効率がいいわけで、そんなことをするよりは暗黙知の明確化であったり、「常識」の共有のほうが先に行うべきことなのではないかと思います。
とは言え耳が痛い
では「おまいちゃんとできてんのかよ」と聞かれれば、もちろんできていないことも多かったし、結局プロジェクトの火消しをせざるを得ない状況に置かれてしまいましたし、結局、オフショアPMとしての経験が浅かったこともあり、できてないよなぁ、と思いながら元記事を眺めていました。
ただ、経験をして言えることは、
- しつこいくらいにコミュニケーションをとること
- 説明が足りないと後で血を見る(質問の嵐＋成果物の不具合)
- 「文化」の違いが意外に大きい
と思っていて、特に日本と海外のメンバーの中での認識の相違(フィットアンドギャップ)は早急に埋めないとかなり痛い目を見る、ということは感じました。
どうすべきか、というのはそれぞれのチーム編成にもよるでしょうし、またチーム内のメンバーによっても異なると思いますが、どれだけギャップを埋めて一丸となって事に臨めるのか、というのがカギになると思っています。
結論がすごく日本的な言い方になっていますが、欧米的な「あくまでも仕事という関係性のなかでのビジネス的な関係性」の上に成り立つ、ただ的確な指示だけ出して仕事を全うしてもらう、というやり方よりは、よりチームとしての動きを持った方が仕事もやりやすいと思うんですよね。私自身日本生まれ日本育ちの純血日本人なので。「チーム」という考え方は世界共通ですしね。
