私個人から見たチームの変化について

今年の1月15日に現在の会社に入社して、もうすぐ1年が経ちます。

フリーランスを卒業して「会社員」というステータスが久しぶりだったので、入社当初は色々戸惑うことが多かったのですが、今では立派な不良社員になりました。

そんな私個人の今年の振り返りは別途書くとして、チームや担当サービスがこの1年でどのように変わったか？を少し振り返ってみたいと思います。

f:id:haru_skywalker:20171220163608p:plain

ミーティングについて

週次ミーティングの在り方の見直し

アサインされた当時、定例のミーティングは以下の2つでした。

朝会（毎朝、今日何をするかを報告する会）
週1回の週次ミーティング（一週間何をしたか、次週何をするかの報告）

アサイン当初は右も左も分からない状態で、ミーティングもただ参加するような状態でしたが、会社にも慣れてきた頃、ミーティングの在り方をもう少し見直したほうがいいと思うようになりました。

というのも、当時の週次ミーティングは朝会の延長なような状態で、全員が集まる価値が生かされていないと感じたのです。そこで上長に相談して週次ミーティングの在り方を大幅に見直しました。その後も何度か内容の見直しが入り、最終的に現在はこのような内容に落ち着きました。

各チーム担当分の進捗状況の報告
次回リリースに関する報告
技術的課題の共有
発生した障害の共有
技術的ナレッジの共有
ユーザからの要望の共有
売上・成長率の報告
新規Issueの確認、およびマイルストーンの設定
未解決Issueの棚卸し（月1回）

内容は今後も少しずつ変化していくと思いますが、その時々で最適な会議体を検討する風潮が根付いたことが、良い変化だったと思います。

おそらく入社直後だったから、第三者的な視点で長年の慣習に疑問を持てたのでは？という気もするので、転職直後の「曇りなき眼」のうちに、思い切って既存の体制に斬り込む勇気も時には大切だと思います。

ミーティング開催日の見直し

しばらくずっと、週次ミーティングは金曜の夕方に行われていました。でもこれにもちょっと不満がありました。

ミーティング内容の見直しの結果、せっかく様々な議論が出来る場になったのですが、金曜夕方に密度の濃い話をしても、具体的なアクションを起こせるのは週末を挟んだ月曜になってしまうのですよね。打合せで何かが決まったら、さっさと動いたほうが良いことって多いのですが、週末を挟むと残念ながら忘れちゃったりするんですよね・・・

ということで、週次ミーティングは火曜の午前中に行うよう開催日の見直しをしました。体感的に月曜って何かと忙しかったりするのと、ハッピーマンデーや振替休日などの影響を受けやすいので、週の前半、特に火曜は個人的にちょうど良いと思ってます。定時近くは避けて可能な限り午前中にやるのもポイントで、熱量のあるうちにアクションが起こせるため、午前中に行うのはなかなか良いと感じています。

技術的負債への取り組み

負債返済の日を作る

これはつい最近決まったことですが、「月に1日だけ技術的負債を返済する日」というのを設けることになりました。

なかなか手を付けられていない技術的負債が蓄積しており、しかし他タスクとの優先度を考えると、いつまでも放置されてしまうのが現状でしたが「月1日であれば通常業務への影響度も少なく済む」ということで、試験運用的に月に1日行うことで始まりました。

これはまだ始めたばかりなので、効果がどの程度出るかは未知数ですが、個人的には「負債が溜まり続けることへの精神的負担」の軽減効果は大きいと思っています。稼働ベースで言えば全体の5%程度しか負債返済に充てられないのですが、それでも「負債を返済する機会がある」ということ自体が、エンジニアの精神衛生には大切なことだと思っています。

全体に関わる技術的負債について

現在、サービスの根幹部分で、インフラコスト/開発効率/学習コスト共に負担の大きなアーキテクチャが採用されたままの状態にあります。

サービス開始当時はそれしか選択肢が無かったのですが、現在は他にも代替となるものが出てきました。しかし、今から変更するのは大きな労力を伴うが、このまま突き進めばデメリットも膨らみ続ける、という悩ましい問題にぶち当たっていました。

そこで、新しいアーキテクチャへ乗り換えをチームで慎重に検討したものの、最終的には「今はサービスのグロースが最優先」という結論になったため、乗り換え自体は見送りになってしまいました。しかし、ただ見送るというだけでなく、「売上目標が達成されたらアーキテクチャ変更を再検討する」という結論になったのは個人的にとても良かったと思っています。

今回のような「新しいアーキテクチャへのチャレンジ」が見送られるようなケースは、往々にしてエンジニアのモチベーションをポッキリ折りやすいものです。しかし条件付きでも可能性があるのと無いのでは話は大きく違うし、今度はその条件をクリアしようという別のモチベーションにも繋がります。また、このような議論および結論が出せたこと自体が、チームにとって意義のある結果だったと思っています。

開発以外のタスクについて

マーケティングや営業活動

残念ながら、現在サービス専用のマーケティング部隊や営業が不在なため、チームとしても開発だけに専念していれば良い状態ではないのですが、アサイン当初はその辺がかなり手薄な状態にありました。

そこでチーム内で話し合った結果、直接的な営業活動は引き続き営業部門をはじめ他部署に依存するものの、社内の情報連携や、整っていなかったマニュアルを充実させていくなど、他部署との強化を図ることになりました。またマーケティングについては、サービスサイトや販促パンフレットの見直しから始め、外部メディアへの露出、開発ロードマップの公開などを行いました。

まだ十分とは言えないものの、この1年間で開発以外の部分については、以前より大幅に改善されたと思っています。

ユーザーヒアリングの実施

本来であれば定期的にユーザーヒアリングは実施すべきなのですが、慢性的なリソース不足でなかなか実施出来ないでいました。

現在、サポートページから要望等を投稿してもらう仕組み自体はあるのですが、表面的な要望しか分からず、もっと踏み込んで「具体的にどのように利用され、顧客の業務のどこに影響し、どのような不便を強いているのか」といったことを詳細に把握するために、ユーザーヒアリングを実施しました。

このヒアリングは、この1年で一番効果が大きい部分であったと個人的には感じています。

インタビューからは非常に多くの収穫があり、その結果として現在大きな仕様追加の開発を行っている真っ最中です。一般利用者向けのサービスとは違い、企業ユースのエンタープライズサービスの場合、顧客の業務に関する部分はヒアリングでしか把握出来ない、ということを改めて感じた次第です。

また、顧客だけでなく社内の各部署にヒアリングを実施したのも非常に良かったと思っています。弊サービスは社内でも多く使われているため、日々の業務効率に繋がるために必要機能や、どうすればもっとセールスに繋がるか、といった視点でもヒアリングを実施しました。これは代表から「売り上げを伸ばすことだけが利益ではなく、社内の業務効率を改善することも利益に繋がる」と言われたことが大きいのですが、それが結果として営業やサポートといった多方面からの意見の収集に繋がり、顧客だけではなく社内に目を向ける良いキッカケになり、そこから多くの課題も見えてきました。

現在はこれらヒアリングの結果から、必要な機能の開発中です。リリースされてからが本番ではありますが、以前よりは確実に効果が高い方向に舵を切れている感覚があります。