IT社畜犬くわっちょのはてな

青森の片隅で働く、フルスタックエンジニアに憧れる器用貧乏なIT社畜犬の遠吠え

2015.08.04 「運用フェーズになった自社サービスを抱えた会社のエンジニアってどうやってモチベ―ション維持してるの?」 参加してきました

unmochi.doorkeeper.jp

こちらのお話を聞いてまいりましたー。

簡単ですがまとめー。

「ぼくがかんがえたさいきょうのモチベーションを維持するための環境づくり」

ハイロウテック しおばらひろあき様

  • モチベーションがなぜ重要か?

    • 科学的管理法(能率学) -> 「生産性は報酬と環境で管理」 <= 本当にこれでいいのか?
    • ホーソン実験 エルトン・メイヨーら「心理的要素が生産性に大きな影響を与える」
  • リリースが完了するとなぜモチベーション維持が難しい?

    • 動機づけ要因 ⇔ 環境要因
    • リリース後 = 「達成」が完了された状態
    • 承認欲求の充足が別に必要になる(モチベーションの前段階)
  • なぜ「承認欲求」が満たされないのか?

    • 満たされた状態 = 褒められる
    • 満たされない状態 = 無視・無関心(個人・組織間・コミットメントへの)
      • 個人への無関心(例:○○さんと話したことない)
      • 組織間への無関心(例:サービスインしたからもうシステム部は関係ないよね?)
      • コミットへの無関心(安定運用させるための動きをしても企画側に見えない。企画側の内容もシステム側に見えない)
  • 融合的な対処法

    • タスク情報の共有(コミット・個人)
    • コミュニケーションの場の構築(個人・組織)
    • 「現状」と「成果」の把握(コミット・組織)
  • ツールへの落とし込み

    • タスク情報(タスク管理ツールの導入 -> これをシステム部だけで完結させない。企画・制作側も)
    • チャット・メッセージツール(相互の遊びも重要)
    • ダッシュボード・モニタリングツールの導入
      • ⇒ これらを「非エンジニア系スタッフ」に歩み寄る形で実施(全員が参加できなければ意味がない)
    • 情報のチャネルは「一つに集約」する。メール、タスク管理ツールwikiと分散させない
    • 日本語であること(日本人以外は?)
    • 単純であること
  • 実際のツール

    • redmine(チャネルの集約化、看板化はできる。しかし、導入が難しい、非エンジニアが使えるようになるまで時間がかかる)
    • Let's chat(無料・日本語あり)
    • Googleアナリティクス(わかりやすい・情報の一元化が難しい)
    • Liferay / Joomla!(ポータル用CMSjspとか書かないといけない)
    • Let's chatのbot
  • まとめ

    • redmine + Let's Chat が今のところはいいか
    • 非エンジニアも含めチームの人を巻き込んでいくこと
    • 最適解は異なる。モチベーションの定義を思い出して検討。これ自体がモチベーションをさげてはいけない

「運用にモチベを求めるのは間違っているだろうか 」

GMOくまポン システム部:伊藤大輔

  • 運用エンジニアとは?

    1. 自社サービスを提供し
    2. 新規開発をすでに終え
    3. 運用・保守・開発業務を行うエンジニア
  • 運用エンジニアの憂鬱

    • レガシーコードを運用でごまかす
    • 新しさのない永遠の日常が続く
  • モチベーションとは

    • 承認要求モチベーション:感謝されたい(他人の行動が原動力)
      • マクロの環境に依存
      • 供給が不安定
  • 自己完結モチベーション:好きなことをやりたい(自分の行動が原動力)

    • 自分だけで高めていける
    • 安定したモチベーションが可能
    • 自己コントロールが幸せを産む
  • とはいえチームで働くには、承認要求も必要

    • チームワークには尊敬と感謝とが必要
  • まとめ

    • 自己完結モチベーションを見つけること
    • 承認要求モチベーションの為、うまくチームなどと連携すること

「手段の目的化のために僕らがやるべきこと」

spice life 五十嵐邦明開発部長

  • 前提

blog.spicelife.jp

  • エンジニアのモチベーションと事業利益のベクトルを合わせる

    • 例1:AWS使ったよ -> 一気にお客さんきても大丈夫だよ!
    • 例2:gitにしたよ -> 開発スピード上がります!
  • セキュリティ対策はチャンス

    • これを理由にいろいろやれる
  • やっていること

    • 制度をハッカブルに保つ
    • コードを書いたことがない人は採用しない(企画含む)
    • 納得感を持って仕事に取り組める環境作り
    • 「余計な事をしないで!」ではなく「やるべきことをやって!」
    • 日報にポエム大事

「挑戦と安定と職人気質」

アニメイトラボ CTO こしばとしあき

  • 運用だって大事 でも、エンジニアの精神衛生も大事

  • 挑戦と安定と職人気質

    • 「理想と現実」を知る -> 言語化
    • 1人で全部やるのはワンオペ
    • 安定とは何か? 現状はどうか?
    • トップダウン・コラボレーション
    • 安定とは:揺れ動く事
  • 挑戦と安定とのトレードオフ。それを考え直す

    • しんどいけどたのしい -> たのしいことはモチベーションにつながる
    • モチベーションは上げていくもの
  • まとめ

    • トレードオフを捨ててモチベーションを上げる
    • 熟練職人に近づこう
感想

実際の運用技法というよりは、どちらかというともっと根本の理論から学ぶ会という印象でした。 実際長く運用していくのも人間ですので、 心理学、組織理論といった基本的なところから学んでいき、後は実際の現場に則して合わせていくのがいいのかと思いました。

後は、運用という長いフェイズを楽しめるような仕組みづくりが重要とも感じました。 適度に遊びの精神がないと、人間詰まっていくだけだと思いました。

今回は自社サービスの運用メインでしたが これが運用をアウトソーシングされた側になりますと、顧客側を巻き込んでいくことも必要になるのかなと思います。 そのような、人を巻き込んでいく方法というものももっと掘り下げて聞いてみたいなとも思いました。

運営の皆さま、貴重な機会を提供いただきまして、誠にありがとうございました。