ポエム

非エンジニアと仕事をするあなたが生産性を上げる、たった3つの考え方

はじめに

この記事は東京理科大学Advent Calendar 2017の19日目の記事です。18日目はmiyuki-sさんの記事、20日目はrisagonさんの記事です。

頭悪そうなタイトルで申し訳ないです。ポエムなので開き直ってみました。
この記事にはコードは一行たりとも登場しません。僕がエンジニアにとって明確に必要にも関わらず軽視されがちだと考える、チーム間におけるコミュニケーションに必要な考え方を3つ挙げました。

世間の先輩エンジニアの皆様には当然の内容かもしれませんが、エンジニアとしてほぼ一年働いて感じたことを区切りとして一度文章にしようと思った所存です。
他にもこれが大切だ、などあればぜひ先輩エンジニアの皆様方からご指摘いただければと思います。

自己紹介

東京理科大学理学部第一部応用物理学科を休学しています。来年2年生として復学予定で、現在は小規模なベンチャー企業でエンジニアインターンとして今年2月から働いています。プログラミングを始めとして色々なことを吸収してきました。直近ではプロダクトマネジメントなどサービスの極めて上流を考える仕事をしています。

僕のインターン先は非エンジニアの割合が高い会社で、他部署からくる依頼の一次対応も僕が担当していました。その中でコードを書く以外の部分で実体験を伴うノウハウが蓄積してきたので、年の瀬にアウトプットしておこうと思います。


1. プログラミングは問題 / 課題 解決の方法であると知る

ギークなエンジニアにありがちですが、プログラミングはあくまで問題や課題の解決方法の一つに過ぎません。どれだけ優れたプログラミングスキルを持っていても、問題を発見、あるいは認識できないエンジニアのする仕事は(特に属人的な傾向が強いベンチャーなどでは)極めて限定的です。

プログラミングの能力を高めるということは、解決できる課題や問題が広がる、ということに過ぎません。それ以外は娯楽としてのプログラミングであり、ゲームをしているのと何ら変わりないと思います。
ゲームを否定するつもりもありませんし、娯楽としてのプログラミングを否定するつもりもないのです。しかし仕事におけるプログラミングは、あくまで問題や課題の解決が前提にあるということを認識する必要があります。

そもそも、非エンジニアはエンジニアリングについて明るくありません。よくわからないけどこれ解決して欲しい!くらいのテンションだと知ってください。あなたが技術的にどれだけすごいエンジニアなのか、彼らにはわかりません。課題を解決することでのみ、その組織におけるエンジニアとしてのあなたの価値が決まりますし、非エンジニアとする仕事においては課題解決能力のみがあなたのエンジニアとしての能力の指標です。

2. あなたが言いたいことは、あなたしかわからないと知る

自明すぎることですが、働いていると忘れがちなことだと思います。「なんでこんな仕事を投げてくるんだ」「これはお前の仕事じゃないのか」「この機能確認してくれと言ってるのになぜやってくれないんだ」…etc.

特に他部署と関わって仕事をするとき、そもそもお互い自分たちが「どんなテンションで」「どんな業務内容を」「どんな周辺環境の中で」その仕事をしているのか正しく把握できていないケースが多いです。環境や得意な仕事、タスク量、体調などを雑談程度でも共有しておくべきです。

自分から他人がどんな状況にいるのかを知ろうとする努力も必要です。「1. プログラミングは問題 / 課題 解決の方法であると知る」につながる話ですが、他人の現状の働き方を知らなくては課題や問題を発見することが難しくなります。患者の容態を知らずには、医者は正しい治療を施すことができません。相手が何を言いたいのかを知るために、相手の今いる文脈を知る努力をしてください。

また、自分が言いたいことを他人がいつもわかってくれるという認識の過ちは、自他双方の心理的な負担にも繋がります。私たちは、できていることに対する正の評価を疎かにして、できなかったことに対する負の評価に注目してしまいがちです。また、わかってくれているという思い込みで事業を進め、取り返しがつかなくなってからディスコミュニケーションが発覚してしまえば心理的負担のみならず、事業全体に対する大きな打撃につながってしまいます。

正しくお互いを理解をするために、自分が「どんな目的で」「いつまでに」「誰に」「どのくらい切実に」「何を」やって欲しいのかを伝えることを意識してください。相手がこれを意識していないことも多いです。相手に何かをお願いされた時も、同じ文脈の中で必要な要素がなければ確認するようにしてください。これらの要素の多寡は文脈によって変化するものだとは思いますが、これらを理解することで少なくとも業務におけるコミュニケーションの密度は上がります。

課題発見、心理的平穏、事業の成功のために、自分が言いたいことは言い、他人の言葉を聞いてください。そして、お互いが理解するために言葉を交わせる関係性を構築したいものです。

3. 一目置かれる人間であろうとする

僕自身が他人からリスペクトされる存在であれているかという議論は一旦棚にあげてこの項目を書いています。リスペクトされると「2. あなたが言いたいことは、あなたしかわからないと知る」が容易になります。一目置かれる存在であれば、結果的に同僚には気にかけてもらうことができますし、こちらの質問や依頼に比較的スムーズに対応してもらうことができます。
リスペクトされると言っても、尊敬される必要はありませんし、お硬い役職も全くもって不要です。ベンチャーなど少人数では属人性が高まるため、自然と一目おかれる存在になりがちです。逆に言うと、お互いがお互いをリスペクトできる関係性が社内で構築できていれば、社内でのコミュニケーションがスムーズに進んでいると言えそうです。いくつかのチームを見てきましたが、うまくいっていなかったフェーズではお互いに対するリスペクトが著しく欠けているチームとして極めて不健全な状態にあったと確信します。逆に滞りなく進んでいる段階において、チームメンバー間には程度の差はあれ双方に敬意が感じられていたように思います。
リスペクトされる存在になる方法はいくつかあると思いますが、僕が意識していた点をいくつか羅列しますので参考になることを願います。

  • (エンジニアは課題解決のための役割と解釈していたので)他チームの課題も発見・解決するためのコミュニケーションを意識した
  • チームにかかわらず、疑問・意見を積極的に発信した
  • 相手が話しているときは、それを遮って話さないようにした
  • 意見が違うと思った時には、対案などを挙げた上で再提案した
  • できないことは、できないと伝えた
  • 会話で相手の時間を奪っていることを自覚した
  • リスペクトされる存在であろうとしてきた

ぜひコメントで皆さんが意識していたことや、他の人のこんなところがリスペクタブルだった、と教えていただきたいです!お願いします。

僕は、一番最後の「リスペクトされる存在であろうとすること」が最も大切だと思います。自分の言動が自分の品格を決定します。くだらない発言や行動で自分の価値を落としてはいけないし、他人からの信頼を貶めてはいけないという意識を持つことは僕にとって大きな効果がありましたし、今後も継続していこうと思っています。

また、この意識は生産性にも直結すると思っています。「エンジニアとして」リスペクトされる存在であるためにはエンジニアとしてのスキルを高く持っている必要があります(くどいですが、コードを書くことだけではありません)。「プロダクトマネージャーとして」リスペクトされる存在であるためには、実際に自分が描いたビジョンやロードマップ、実現のための要素を高いレベルで共有しなければなりません。(同上)
お互いがリスペクトし合える存在であるために、まずは自分が一目おかれる存在でありたいと思います。

終わりに

僕はこの一年間で、チームがバラバラになってしまう現場を見てきました。チームがまとまろうとする様も見てきましたし、まとまって進んで行こうとしている真っ只中にいます。一つだけではなく複数のチームに所属していたため、母数は少なくあるもののプロジェクトが崩壊しかけつつも生き返る様をいくつか見ることができる環境にありました。

私たちはエンジニアである以前に一人の人間であり、プロジェクトのメンバーもエンジニア・非エンジニアに関わらず人間です。成長途上の学生エンジニアにはありがちだと思いますが、専門性ばかりを追求してもチームがうまくいくわけではないということを理解した上で、専門性を追求していきたいですね。お互い鎬を削って頑張りましょう!
先輩エンジニアの皆様も、ぜひご指導ご鞭撻ください。長々と稚拙な文章をお読みいただき、ありがとうございました。