エンジニアのモチベーションについて
はじめに
2016年11月8日現在、自分がアサインされた案件がかなり大炎上している。 燃えている要因を数えだしたらキリがないが、大きなものでも5つはある。 それはお客さんにもあるが、チーム内（というか上司がデカい）にもやはりある。 そんな中（自分も含めて）エンジニアのメンバーが意識やモチベーション高く仕事をしているかと言えば、 もちろんそんなことはなく、かなりストレスや不満を溜めた状態で仕事をしている。
意識の変革のために、ある記事が凄く参考になった
本当の本当にデッドライン（これを超えたら出るとこ出てましょうか）に差し迫っていて、チーム内も切羽詰まって来ている中、 自分の意識が変わるようなエントリがあった。それが以下。
この記事を読んだ上でいったん置いておくw 自分の書きたいことを先に書いて、最後にこの記事の内容を引用して終わろうかなと思っているので。
上下関係なんかなく、あくまでチーム
○○マネージャとか△△リーダーとかいるじゃないですか。この「役職」っぽい役割がまたエンジニアのモチベーションを下げる要因。
受託であろうと、社内システムであろうと、有志で集まって作っているアプリであろうと何であろうと、一緒に作っていくことには変わりなく、 その作業・役割が違うだけで足並み揃えて作っていくチームである。そこに上下関係なんかない。誰が偉いとかなく、もっと言えば全員が偉い。 例えばECサイトを作るとしよう。そのためには以下のような役割が必要になってくる。
- プロジェクトの進捗管理、仕様を決める人
- エンジニアのサポートしつつエンジニア以外の人との橋渡しをする人
- エンジニア（インフラ）
- エンジニア（コーディング）
- デザイナー（html, css, デザインにカラムjsコーディングまで）
- 品質を担保する人（テスター含む）
受託開発では、さらに
- 仕事を持ってくる人
- 会計や諸手続き（書類周りなど）する人
も必要になってくる。
もちろん作る物によっては不要な役割もあるが、何かを作るにはいろんな役割があり、皆が自分の役割をしっかりこなして初めて作ろうとしているものが出来上がる。 この中の誰が欠けてもECサイトは完成しない。（少なくとも実際に運用できるものはできない）
これを皆が理解して、相互に助け合っていけるチームが最高だろうな。 何か問題があったとしても、最後はその役割を担当していた人が対応するであろうが、手を動かす人・対応策を考える人・確認する人がいる。 結局はチームでその問題に対応していることになる。これが理解できないと、正直対応する人（大抵がエンジニアだが）が辛いだけだ。
受託の場合は、発注側も含めてチーム
これは発注側・受注側ともに意識できてないことが多いイメージがある。古来からある開発手法であるウォーターフォールだと特にこの傾向が顕著。 今回はウォーターフォールについては言及する気はないので置いておくが、この開発手法を理解すると、 まぁほぼ確実に発注側もチームという意識なんかお互いにないだろうな。
もちろん手を動かして発注側の青写真を形にするのは受注側であるが、各機能がどういう仕様なのか？はもちろん発注側が答えを持っている。 実際に使って運用するのも発注側である。そして、
受注側が作ったプロトタイプを育てるのも発注側である。
最初から育てる気がなく、機能の追加などもしない。またはどこかで使い捨てるというのであったとしても、 全て機能の仕様を最初の要件定義で100%理解できるはずがないし、発注側も運用に必要な機能を全て覚えていることは少ない。 だからお互いにコニュニケーションをとりつつ、一緒に作っていくことが必要になる。それって、チームじゃない？
正論じゃ人は動かない
これは自分への教訓だが、正論は文字通り正しい。でも人は動かないし、人が動かなければビジネスも動かない。 何があれば人は動くか？それは「納得」だ。
- 納期に納得
- 工数見積もりに納得
- 費用に納得
- 仕様に納得
- 方針に納得
- やり方に納得
- 出来栄えに納得
- デザインに納得
- …etc
いっぱいあるが、全てにおいてまず「納得」いくか否かが根本にある。お互いに納得したうえで、じゃあやろうか、ってなる。
チームが最高に機能するには
最後に、先程の記事の内容にふれます。 記事内で伊藤氏は次のように述べられています。
僕が最近すごく気に入っている考え方がありまして、それが「心理的安全性と責任」という話なんですよね。『チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ』に書いていたもので、ここでもやはり「2軸で切りましょう」というコンサルタントみたいな話なんですけど、これはすごく本質だと思って見ていました。
基本的に、そのチームが最もベストな状態になるのは、責任が大きくて心理的安全性が大きい状態を指します。
それが、きちんと責任と心理的安全性が高くなると、人は学習をしながらチームできちんと問題を解決していく状態になるんですね。
「責任が弱い」とぬるま湯に浸かるようなもので、チームとしてパフォーマンスが出ない。よってアウトプットがない。 はたまた「心理的安全性が低い」と、ただ責任だけが重くのしかかってくるので、嫌々仕事をする羽目になる。 そして「責任もなく心理的安全性も低い」と、人が会社を辞めていってしまうことになると。
よ〜く分かる。自分の経験上、凄くこれは共感する考え方。更に伊藤氏は一休内で両極端なチームを引き合いに出し、 どういう施策をしてどう改善したかを述べられている。それが「フレーミングをちゃんとやる」ということだった。
聞きなれない言葉だけど、簡単に言い換えると「意識改革」くらいになるかな。 メンバーに何らかの仕事を振るとき、例えば「これは作業」と伝えるのか、「これは学習・成長につながる」と伝えるのかで、 メンバーのアウトプットが全然違うことがあると。
良くある話で、Redmineのチケットをメンバーにアサインして、内容を説明してよろしく。これだけだと単なる「作業」の指示でしかないので、
メンバーもこれは作業という意識になる。これでモチベーションが上がるはずがない。（少なくとも自分は上がらない）でも、「これは君にしか頼めない」とか
「君のこの力を貸してくれ」と伝えると、これは「成長のチャンスだ！」と捉えることができる。些細なことだけど、これが本当に大事なこと。
終わりに
まだまだ自分も駆け出しエンジニアで、チームづくりとか、マネジメントとかを少しずつ学び始めた段階なので、悩みは付きないが、 やっぱりいいチームでいいメンバーと、良好な関係を保ちつつ仕事をしていきたいし、いろんなものを作っていきたい。
そういう意味で、もっと外部に出て人と会って話し、その人のノウハウを吸収していこうと思う。
