「運用フェーズになった自社サービスを抱えた会社のエンジニアってどうやってモチベ―ション維持してるの？」、というイベント、略して「うんもち」。
イベント紹介文の、
- 自社サービスを抱え運用フェーズに移行していると新しい技術や挑戦をなかなかできない。
- 運用が忙しくて手が回らない。
- そしてまた、新しいことへの挑戦が遠のく悪循環！！
- みんなどうやって、エンジニアとしてのモチベーション保ってるんだろう……
といったフレーズが刺さり、参加してきた。
会場提供は、千駄ヶ谷のアニメイトラボさん。wifi も完備の素敵なオフィスでした。ありがとうございます！（まちがって pixiv さんにチェックインしちゃった(ﾉω・)ﾃﾍ）
ちょっと早いけど (@ ピクシブ株式会社 (pixiv Inc.) - @pixiv in 渋谷区, 東京都) https://t.co/hb7rELsJOc
— いのうえ (@a_know) 2015, 8月 4すごい(すごい) pic.twitter.com/J0D4Cai5Nq
— いのうえ (@a_know) 2015, 8月 4ぼくとぼくの組織・チームの状況
ぼく自身は、実は「新規開発」と「運用フェーズのサービスの運用」の両方を担当していたりする。といっても、「運用フェーズのサービス」の方はもう殆ど手のかからない状態で、月の工数の平均数%をわずかに掛けている、という状態。「新規開発」の方も、リリースとしては既にしてしまっているサービスなんだけど、まだまだ追加したい機能も多くて、日々活発に動いているプロダクト。そういう意味では「モチベーション」はこの「新規開発」の方から得ている、と言ってもいい状態。つまり、ぼく自身に関しては「モチベーション」という観点では大きな問題は感じていなかったりする。
でも、同じ社内を見渡してみると、「完全に運用フェーズのサービス（ぼくが担当しているのとはまた別の）」の専任担当者、というエンジニアさんもいて、そういった方の助けとなるようなもの・ヒントがあれば知りたい、という問題意識もあった。
アジェンダ
「うんもち」のアジェンダは、以下のとおりなかんじだった。
- 「残酷な運用のテーゼ」 @16bit_idol さん
- 「ぼくがかんがえたさいきょうのモチベーションを維持するための環境づくり」ハイロウテック しおばらひろあき さん
- 「運用にモチベを求めるのは間違っているだろうか 」GMOくまポン システム部 伊藤大輔さん
- 「手段の目的化のために僕らがやるべきこと」spice life 五十嵐邦明 開発部長
- 「挑戦と安定と職人気質」アニメイトラボ CTO こしばとしあき さん
どの話にも「あるある！」「なるほど...」といった点はあったのだけど、その中でもぼくは特に、ハイロウテック・しおばらさんのお話から、「やっぱりエンジニアにはモチベーションって大事なんだ」ということと、spice life 五十嵐さんのお話から、「"僕の組織における" 現実的なモチベーションを高めるための "仕事づくり" のヒント」を、それぞれ得たような気がした。ので、その２つに絞って書いてみる。
ハイロウテック・しおばらさんのお話
しおばらさんのお話の構成は、ざっくりと以下の様な構成になっていて、なんというか、とても理論立ったというか筋道の通った構成で、個人的にはとても腹落ちするものだった。
- そもそも、「モチベーション」という心理的な要素が、なぜ必要なのか？
- なぜ、モチベーションの維持が難しくなるのか？
- 承認欲求の充足は、なぜエンジニアにとって重要なのか？
- なぜ運用フェーズを請け負うエンジニアの承認欲求が満たされづらいのか？
- それを解決するために、仕組みとしてどんなことができるのか？
そもそも、「モチベーション」という心理的な要素が、なぜ必要なのか？
そう。まずはここから始める必要があると思ってる。「モチベーション」、あるならある方がいいよね、というのは当然のことながら、一方で、「モチベーションで仕事をするな」という言葉があって、その言葉に対して「......なるほど。」と思っちゃうくらいには訓練されている僕。うん、まずはここから始める必要がある。
「モチベーションで仕事をするな」とか、あとは「仕事の対価としてお給料が払われてるんだからいいじゃん」というのは、「生産性は報酬・環境で管理できる」という考え方に基づいた、旧来型の管理手法、らしい。これに対して、ホーソン実験 という実験の結果、「心理的要素が生産性に大きな影響を与える」ということが立証された、という。つまり、「モチベーション」を含めた心理的要素は、生産性などのことを考えると、やはり大事だ、ということだ。
なぜ、モチベーションの維持が難しくなるのか？
これには、二要因理論を理解する必要がある、んだそうだ。二要因理論とは、すべての要因は「満足を招く要因」と「不満を招く要因」のいずれかに分類される、ということ。「何かを開発し、リリースする」という「達成」という要因は、「満足を招く要因」。一方で、例えば「給与」などは「不満を招く要因」であり、「満足を招く要因」とはなりにくい、と。そういうことらしい。そして、「満足を招く要因」が運用フェーズには少ない、それがモチベーションの維持を難しくしている原因の一つのようだ。なるほど。
承認欲求の充足は、なぜエンジニアにとって重要なのか？
続いて、「マズローの欲求５段階説」という、なんだか見たことがあるようなないようなフレーズが出てきた。マズローの欲求５段階説とは、以下の5つの欲求のこと。
- 生理的欲求
- 安全の欲求
- 社会的欲求 / 所属と愛の欲求
- 承認（尊重）の欲求
- 自己実現の欲求
なるほど、と思ったのが、「生理的欲求」「安全欲求」など、下の階層に位置する欲求が満たされないと、人間は上の欲求を満たそうとしない、ということ。そりゃそうだよね、生命の危機にさらされてるのに「自己実現が...！」なんて言ってられないもんね。
そして、最もクリエイティブな方向に働く欲求......「自己実現」は、最も上に位置しているということ、エンジニアは、基本的にクリエイティブな職業・技術を通じて何かを実現することができるお仕事だということ。そういったことと、先ほどの「下の階層に位置する欲求が満たされないと、人間は上の欲求を満たそうとしない」ということを考えると、4番目の欲求である「承認の欲求」を満たすことこそがエンジニアにとって大事である、と。うーん、なるほど。
なぜ運用フェーズを請け負うエンジニアの承認欲求が満たされづらいのか？
その要因として、しおばらさんのお話では「個人への無関心」「組織間での無関心」「コミットへの無関心」の3点が挙げられていた。承認欲求が満たされる瞬間は「成果を認められること・褒められること」だけど、それを大きく損なう瞬間は「怒られる・けなされる」ことよりもむしろ、「無視される・無関心であること」だ、と。
個人的には2点目・3点目の「組織間での無関心」「コミットへの無関心」が大きいのかな、と思った。やっぱりどうしても、「何も起こらないで当たり前」「もうリリースしたし、システムはそこにあるんだから、あとは淡々とそれを維持していくだけだよね」みたいな考えになってしまいがちかな...と。
それを解決するために、仕組みとしてどんなことができるのか？
これらへの対策として、しおばらさんのお話では「タスクの共有、コミュニケーションの場の構築、などの対策をツールへ落とし込む」「そのツールを全員を巻き込んで使う」ことを提案されていた。のだけど、うちの場合は、ツールを使うこと以上のなにか・解決策を求める必要がありそうだなと、思った。というのも、うちの会社では既に Redmine も使っているし、slack も使ってる。基本的に全員で。
ぼくのいるところで、チームで、"無関心" を "関心" に変えるためには、しおばらさんのところとは違うアプローチが必要になりそうだ。そう感じた。
spice life・五十嵐さんのお話
エンジニアにとってモチベーションはやっぱり大事で、それは運用エンジニアだけでなんとかなく問題ではなく、周りの人達と目の前のシステムを巻き込んでやっていかなきゃいけない......、という、おおまかな方向性は、しおばらさんのお話でよくわかった。じゃぁ、ぼくの現場で、具体的に・現実的にできそうなことってなんだろう？ その疑問へのヒントを得たように感じたのが、spice life・五十嵐さんのお話。
いきなり冒頭で「実はモチベーションでは困っていない」と五十嵐さん。と、いうのも五十嵐さんは開発部長であり、「エンジニアのモチベーションと事業利益のベクトルをあわせる」ことを仕事とされている方。
「エンジニアのモチベーションと事業利益のベクトルをあわせる」
発表のタイトル「手段の目的化のために僕らがやるべきこと」にも表れているように、どちらかというと避けるべきものとして知られる「手段の目的化」を、運用フェーズのサービスにおいてはむしろ、できるだけやっていこう・やっていくための障害があるのならそれを上となる人が取り除いていこう、ということを話されていた。
これはつまり、「エンジニアにとっての "技術的挑戦" を "事業利益要素" に置き換えていこう」ということ。例えば。エンジニアにとって「高負荷にも耐える仕組みの構築」とうのは一つの挑戦だったりするのだけど、それを「これをすることで TV への露出にも耐えられるアーキテクチャが手に入ります！」と言って説得をする。もしくは、そういった「エンジニアがやりたいこと」......「高負荷にも耐える仕組みの構築」をさせてあげるために、私が、事業を成長させるのだ、と。これを「ナチュラルな手段の目的化」と呼んでいた。素敵。
あと、「セキュリティ対策は、何か他の新しいことを一緒にやるチャンス」とも言われてて、すごく頷いてしまった 笑。「セキュリティ対策のため、xx をします」は、魔法の言葉。ｗ
明日からどうする？
冒頭で書いた通り、自分のいる会社での運用フェーズにあるプロダクトに対して、ぼく自身が直接の利害関係者ではない......しょせん外野、といったところもあるので難しいところなのだけど。。
ひとつ思ったのは、五十嵐さんのように立場が上であるわけではなくても、エンジニアに対しても非エンジニアに対しても、今運用フェーズにあるプロダクトのあれこれに関心を持たせる・向かせる・そのプロダクトへの日々のコミット具合をわかりやすくする、......といった工夫は、運用エンジニアとしての職務のひとつとして必要なのかな......とか思った。
運用をやってくれているエンジニアさんがいるから、このプロダクトは日々何事もないように動いているんだ、そういうことを関知できるような仕組みづくりはやっぱり必要だし、企画側（ディレクターさんとか）の人も、そういった仕組みもやはり、そのプロダクトを健全な状態に保ち続けるために必要なんだ、ということを知る必要もあるかな、と。
あとはやっぱり、エンジニアにとってモチベーションは必要なものだということ、そのことに全員で正面から向き合うこと、も必要なんだよね、きっと。
......といったところかな？ みなさま、お疲れ様でした！
