はじめに
今回はQiitaで↓のマネジメントのイベントをやっていたので、マネジメントに関する記事を書いてみました。
想定読者
「もっとエンジニアとうまく付き合いたい」という非エンジニアの方や、「周辺をもっと良くしたい」と思うエンジニア
エンジニア組織のマネージメントには周辺環境も大事
これまでエンジニア組織のマネジメント歴はそこそこあり、0から作る事もたくさんやってきたんですが、いろいろやってきて、ある時当たり前の事に気付きました。
同じようにエンジニア組織や人が育っても、成果が上がる場合とそうでない場合があるということです。
むしろ「この組織、今までで一番すごい組織になったな」と思った組織でも、なぜか思うように成果が伸びない事があります。
はじめは、「であれば、もっと自組織を成長させる」に終始していたんですが、一旦立ち止まって客観的に成果の出た組織とそうでない組織の違いを見ていった時に、
「ああ、エンジニア組織自体でなく、その周辺の組織や人によって、結構違いが出るんだ」
という当たり前のことに気付きました。（もちろんそれが全てとは言いませんが）
初期の未熟なエンジニア組織は、そんなことよりもっとやるべき事があったりするわけですが、一定水準の自走する組織になれば、自組織の力よりも、上司も含めた周辺の環境の方が、組織の成果や成長に与える影響度合いが大きくなると感じています。
エンジニア組織のマネジメントにおけるミッションとは、言わずもがな、そのエンジニア組織が会社にとって最大のパフォーマンスを出せるようにしていくことです。
ですので、それを突き詰めた時に「エンジニア組織自体ではなく周辺環境を準備していく方が効果的」というフェーズなのであれば、マネージャーとしてより効果的な「周辺環境」に注力するべきなんだろうと思います。
そういった意味で、関わる人に エンジニアが成果を出しやすい環境を理解してもらう ことも「マネジメント業務の大事なコトだよなー」と思い、その一部を書いてみることにしました。
エンジニアとうまく付き合う人と、そうでない人
他にもいろいろあるんですが、今回はその中から「エンジニアとうまく付き合う人と、そうでない人」という主題で、エンジニアとしての僕の実体験を書いてみます。
これは日頃、非エンジニアの人から
- 「どうやったらエンジニアとうまく付き合えるの？」
- 「エンジニア組織をマネジメントする時の注意点を教えてほしい」
といった相談を受ける事もあるので、その時に紹介してきた「この人は付き合い方が上手だったな」と思う自らの実体験を、その方々への感謝も込めて、まとめてみました。
実際に参考になったという方もいるので、周辺の人たちからこのような相談があった時に読んで頂けると、理解につながるかもしれません。
うまく付き合える人は結果的にビジネスや組織もうまくやっている印象があり、特にIT業界ではそれが顕著だと思われます。
（IT業界以外もDX化により今後顕著になっていきますが・・・）
「もっとエンジニアとうまく付き合いたい」という非エンジニアの方や、「周辺をもっと良くしたい」と思うエンジニアにとっての参考資料の一つになれば幸いです。
また、これ以外にも、エンジニアの数だけいろんな考えや事例があると思いますので、よければ教えて下さい。
新米エンジニアを助けてくれた営業のプロフェッショナルのSさん
- 尊敬する人
- 営業のSさん
- 実体験の背景
- A社さんの運営している某サイトの運用保守担当を、僕とペアでやっていました。
- 営業側はSさん、システムエンジニア側が僕です。
まだエンジニアとしては駆け出しだった僕は、データベースの定期メンテナンスで初歩的なミスをやらかし、2時間貰っていたメンテナンス時間を大幅に超えてしまい、なんと一日近くも止めてしまうという大失態をしてしまいました。
A社さんにとって、その間サイトが動かなかった損失は計り知れないんですが、その時Sさんが
「お客さん側は大丈夫ですよ、僕がなんとかしとくんで！」
と言ってくれました。
その一言で勇気付けられて、僕は復旧作業に集中し、かなり時間はかかってしまいましたが、なんとか復旧できました。
そして、お客さん側は・・・本当にSさんがなんとかしてくれたんです。
これだけの事が起こったのに、A社さんからのクレームもなく、もちろん賠償などの話にもならず、その後も引き続き良い関係を継続できました。
どうやらSさんは、日頃からA社さんに、システムの特性や仕組み的に、一定発生するエラーや負荷などに関して、きちんと説明していたようです。
今回は一定発生するものというより完全に僕のミスでしたが、日々の説明のおかげで、事なきを得たとのこと。
ごめんなさいとありがとうをいつまでも連発する僕に、
「こんなの営業として当たり前ですよー。」
と軽く言ってくれるのが、またカッコよかったです。
僕はその出来事を通してデータベースに対しての慎重さが身につきましたし、Sさんに恩返しができるよう、今まで以上に努力し、スキルを上げながらA社さんから頂く多くの案件をこなしました。
当たり前かもしれませんが、今回のSさんのように営業としてのプロフェッショナリティを見せられると、エンジニア側も「なんとか答えたい」「釣り合うプロにならねば」と思います。
たまに、同じITやシステムを売る営業でも、システムの特性に対する知識が足りてないなーと感じてしまいまう人がいます。
フロントに立つ人が理解していない場合、お客さんから「聞いてた話と違う」とクレームを貰う頻度が上がります。
慌てて謝りに行って「もう起こさないように言っときますんで」と帰ってきますが、エンジニアが原因などを説明しても、難しくて理解しようとしなかった場合、結局また発生して頭下げに行き、繰り返す事でお客さんの信頼を失う、という事もありえます。
その点、Sさんは、原因と再発の可能性をきちんと聞いてくれ、理解した上で
「じゃあ予めこういうふうにお客さんに説明しておけば良さそうだね」
と、若手エンジニアには苦手な「交渉や説明」の領域で助けてくれたすごい人でした。
エンジニア駆け出しの頃に、Sさんと組めたのはとても幸運だったと思います。ありがとうございました。
エンジニアにしか分からない笑いで和ましてくれたHさん
- 尊敬する人
- 事業責任者のHさん（元営業）
- 実体験の背景
- とある事業の責任者がHさん
- エンジニアチームの部長が僕
ある朝のこと。HさんがエンジニアチームリーダーのTさんに近寄ってきて、
「おはようございます！Tさん、あれですよね、今はやっぱりDockerですよね。」
「まぁ、そうですね、うちも使ってますけど・・・」（なんでいきなり？？）
「コンテナと呼ばれるOSレベルの仮想化環境を提供するオープンソースソフトウェアですよね、合ってますよね？」
「まぁ、合ってますけど・・・」（wiki丸暗記？ｗ）
「ですよねー、やっぱDockerですよねー。今日も頑張ってくださいね！」
多分、朝出社前に、技術ワードをググって、単純に丸暗記するだけだと思います（笑）
まわりで聞いてるエンジニアのみんなが、最初は（えっ！？Hさんが？）と一瞬驚いたあと、最後に心の中で（丸暗記やん！）と突っ込んで、くすくす笑ってほっこりします。
このネタを、よく挨拶のようにやってくれました。
意外に、チョイスするワードが最近流行りの技術だったりするので、どうやって仕入れてるのかだけは不思議でしたが、こんな些細な事で、しかも技術の中身を理解してなくても（きっと理解している！）エンジニアの心を掴めるんだなーと関心しました。
元々の明るくて面白いというキャラや、ネタだから面白い、というのもありますが、これを事業責任者がやってくれるというだけで、朝からエンジニアとの距離はグッと縮まります。
知ってる知ってない、というより、少しでも知ろうとしてくれてることが嬉しいんですよね。ありがとうございました。
エンジニアと直接話ができるだけで喜んでくれるMさん
- 尊敬する人
- 事業責任者のMさん
- とある大手IT企業から来た企画／営業畑の方
- 事業責任者のMさん
- 実体験の背景
- とある事業の責任者がMさん
- エンジニアチームのマネージャーが僕
まず入社して最初に、
「エンジニアと直接話ができて、すぐにやってもらえる！」
と驚き、感動してました。それが当たり前だと思っていた僕は「？？」でした。
どうやら、元々いた大手IT企業では、エンジニアの工数を使うためには、どんな小さいことでも経営会議まで通さなければいけなかったらしく、よほどでないと、直接エンジニアと話が出来なかったそうです。
昨今のIT企業で考えると、確かにエンジニア不足が事業成長のボトルネックになる事も多く、採用も難易度が高い中では、今ある工数をいかにビジネス優先度の高い部分「だけ」に充てるかは重要事項であり、経営判断レベルになるのはうなずけます。
そのシビアさは「さすが大手IT企業だな」と思いますが、元々そのような環境にいたからか、直接話ができる事にありがたみを感じて、感動してくれるんですね。
とかくエンジニアの話を良く聞いてくれたり、「SQL出来るようになりたいから教えて欲しい」と頼んできたり、すれ違い様に絡んでくれたりして、エンジニアと関われる事自体を喜んでくれる、大切にされてるという感じがします。（もちろん、エンジニア以外にもそう接してると思いますが）
一緒に仕事したずっとあとの話ですが、Mさんの事業でやってるエンジニアとこんな会話をしました。
エンジニア：「保守系のタスクがちょっとたまってきてるんですよね」
僕：「そうなんだ、Mさんなら言ったら分かるんじゃない？」
エンジニア：「それは絶対聞いてくれます。絶対分かってくれます。」
エンジニア：「今は事業面で大事な時期なので、ここを乗り切ったら言ってみますね」
と熱く返答してくれました。相変わらずエンジニアからの絶大な信頼を掴んでるなと思いました。
エンジニアと直接話が出来るのを「当たり前」だと思ってる人や（僕もそう思っていましたが）、中には下請けのように上から目線で扱う人が多い中で、話せることだけで「ありがたい」と感じてくれるMさんの存在は、こちらこそ、とてもありがたかったです。ありがとうございました。
ガンガン自分で作っちゃうAさん
- 尊敬する人
- マーケティングチームのAさん
- マーケティングを中心にスキルを磨き、後々複数の組織を束ねる部長になった方
- マーケティングチームのAさん
- 実体験の背景
- AさんがWEBマーケの一般社員
- エンジニアチームの一般社員が僕
Aさんがはじめに配属されたWEBマーケティングチームでは、WEB広告の出向データや実績をダウンロードして、Excelで分析して、次のアクションにつなげる、という事をやっていましたが、Aさん、勝手にExcelのマクロをガリガリ勉強し始めて、毎日の分析作業を片っ端からVBAで自動化していきました。
そのうち単なるマクロのレベルを超えはじめ、VBAからブラウザを立ち上げて、DOM操作でボタンをクリックし、目的のページで検索をかけ、ダウンロードしたCSVファイルをExcelに展開し、必要な計算や集計をかけてグラフを作る、といったところまで全部自動化されてました。普通の人の午前中の作業が、Aさんは朝出社した時点で終わってるんです。
いわゆる「作業」にあたるものを自動化したので、マーケティングを「考える」時間がどんどん増えて、メキメキと成果を出していきました。
WEB広告の次にSEOを挑戦した時は、自分でWordPressを立ててカスタマイズするだけでなく、得意のExcelを使って記事投稿をしやすくするツールを作ったりしていました。
どこにサーバーを立てるべきか、など、要所要所ではエンジニアに確認してくれますが、あとは基本的に全て自分でやってしまいます。そして、SEOでも成果を出しました。
何度か「エンジニアにならない？」と聞いてみましたが、やはり「マーケがやりたくて、そのために必要だからやってるだけ」とのことで、毎回あっさり振られていました（笑）
エンジニアからは何も教わっておらず、全部独学です。
今の時代、ネットで検索したら大抵の事は勉強できるので、一定のところまではエンジニアに頼らずやれるんですよね。
エンジニアとしては当たり前の事ですが、マーケッターとしてここまでやれる人はなかなかいないです。
そして、後日Aさんが組織を束ねるようになってくると、管轄する組織は「出来るところまでは自力でやるのが当たり前」な風土になります（流石にAさんほど出来る人はなかなかいませんが）
どうしても出来ないところだけエンジニアを頼るという感じです。みんな一定のリテラシーを備えてくるので、エンジニア側としてはとてもありがたいし、頼られた時も建設的且つ的確な議論が出来、話が早いです。そういう組織の依頼は率先してやってあげたくなります。
非エンジニアであれば「手作業が多くて大変だ、忙しい」と言ってても、調べたり自分でやろうとまではしない人が普通です。
「なんでエラーが出るんですか？」と怒られたり、説明しても理解しようとしてもらえなかったり、「それはエンジニアの仕事ですよね」と線を引かれてしまったりする現場も少なくないと思いますが、もしそういう組織と、Aさんの組織があった場合、やっぱりAさんの組織と一緒に仕事したいって思っちゃいます。ありがとうございました。
自分で理解するまできちんと聞いてくれるFさん
- 尊敬する人
- 事業責任者のFさん
- 元営業
- 事業責任者のFさん
- 実体験の背景
- Fさんが事業責任者
- エンジニアチームのマネージャーが僕
ある時、大きめの不具合が見つかりました。当時僕がエンジニア側の責任者でした。
事業開始時はスピード優先の突貫開発で、且つ経験の浅いエンジニアしか充てられなかったこともあり、大きめのサイトで必要な処理が抜けていました。そして僕もチェックが出来ていませんでした。
事業開始時はサイト自体が小さいので、問題はありませんでしたが、事業がうまくいきアクセス数が多くなるにつれて、少しずつ発生していました。
明るみに出た時点では、積み重なった不具合が大きくなっており、影響範囲も当時の事業からすると、ちょっと見過ごせないレベルのものでした。この時、事業責任者のFさんから
「なんで発生したのか教えてほしい」
ということで、その日Fさんと一緒に出張していたエンジニアから伝えてもらいました。
非エンジニアであるにも関わらず、分からないところは細かく、かなり技術的なところまで、理解しきるまで聞いてくれたようです。
開発当時の状況、不具合のレベル感、発見の難易度、などを的確に理解した上で、Fさんが、
「今回は仕方ない。この不具合は当時を考えると難しい。むしろよく発見したし、原因特定までよくこの短時間でできたね。次起こらないようにしよう」
と言ったんです。
正直、泣きそうになりました。
通常、非エンジニアにしてみれば、
「なんてことだ、エンジニアめ、こんな不具合起こしやがって」
となるものだし、原因を説明すればするほど言い訳と受け取られがちだったり、結果にしかフォーカスが当たらないのが常です。もちろんビジネスなので僕も理解するところです。
こういうとき、エンジニアの責任者としての役割は、ビジネス視点の叱責は受ける一方で、エンジニアスタッフには技術的原因を元に、適切なフィードバックを行います。
今回の原因も、技術が分かる人にしか分からない内容で、当時を考えると一切スタッフのせいにできないものでしたし、何より僕がチェックをしなければいけない部分だったので、スタッフが責任を感じないように考えていました。
ところが、まさか、非エンジニアの事業責任者が技術的な部分まで理解して、僕がエンジニアスタッフに言おうと思っていたフィードバックがそのまま降りてきたんです。衝撃でした。
もちろんFさんもエンジニアに指摘する時はありますが、技術的な原因まで事実確認をして、理解した上での指摘なので、むしろエンジニアにとっては嬉しいものです。
「難しいことはいいや、要はいつまでにできるの？」
「不具合を起こすとか、未完成品じゃないですか」
というような、技術の複雑な過程や原因を見ようともしない人は多いので、Fさんと一緒に仕事ができたのは本当に幸運だったなと思います。ありがとうございました。
技術で解決できないか・作れないか、という相談が多い
また、事例には書ききれませんでしたが、今まであげた方々にもう一つ共通してあるのは、相談や依頼も多いということです。
難易度の高いものでも、意外と気軽に、
「こういうのできないかな」
と結構相談してくるんです。
「ここのサイトでやってるんだけど」とか「こういう記事見かけたんだけど」とか言いながら。
スタンスは、高圧的ではなく、かといって「エンジニア忙しそうだから」と遠慮することもなく、「あのSaaSでいけそう」で相談せず入れちゃうほどシステムを甘く見てたりもせず、ただただ単純に**「どうしたら出来るようになる？」**という感じです。
例えば工数がネックだった場合に「それなら僕でもできる。調達してくる」と言ってくれたり、自分にできるところは協力してくれたりもします。
もちろんエンジニアは無理難題に対して頭を悩ませますが、内心かなり嬉しかったりします。
これは、裏を返すと僕らエンジニアのフィールドである**「技術」への期待や、「技術」への可能性**を持ってくれていないと生まれない相談なんです。
そして、僕らを信頼しているからこその相談でもあるので、受けるエンジニアも「なんとかして解決したい」となるし、元々そういうのを考えるのが大好きなので、嬉々として取り組みます（余りにもパツパツな時は別ですが）
そして、意外とすごいのができちゃったりします。
そしたら結構喜んでくれます。
そうすると、もっとやりたくなります。
共通項は？
せっかくなので、共通項ってあるのかな、と自分なりに考察してみました。
- 技術に興味や関心を持ってくれている
- 技術に可能性や期待を持ってくれている
この2つかなと思います。
技術そのものを持っていなくてもOKです。
興味や関心、可能性や期待を持っているかどうかが重要かなと思います。
「どうしても分からなすぎるから関心を持ちにくい！」という方も、せめて持とうとする姿勢やスタンスだけは・・・それだけでもだいぶ違うと思います。
最後に
今回は、僕の経験上、最も印象に残っている5人の事例を紹介させて頂きましたが、他にも、ここに書ききれなかった素晴らしい人がたくさんいますので、機会あれば紹介したいと思います。
もちろん、エンジニアといってもいろんな人がいますので、全ての人に共感が得られるわけではないと思います。あくまで僕の経験上の話なので、参考程度に捉えて頂けると幸いです。
また、変にエンジニアを擁護したり、無闇に甘やかしてほしいわけではなく、あくまで、ITを駆使したサービスを運営したり、システムによる効率化を図る事がビジネス戦略上重要な企業で、且つ、それを担うエンジニアの獲得や定着に難航している場合に限り、こういったものも役に立つかもしれないと思った次第です。
そして、いずれの方々も、僕にとってはかけがえのない人達です。この場を借りて感謝を伝えたいと思います。
エンジニアとしての人生で皆さんと出会えた事は本当に幸運でした。ありがとうございました。
これからも宜しくお願いします。
Qiita運営の皆さんへ
以下のアップデートによって、今回みたいな記事が書きやすくなりました。ありがとうございます。
アウトプットも少し頑張ってみようかなと思うこの頃です。
※ 他にもこんな記事書いてます