[Ateam Lifestyle x cyma Advent Calendar 2018]の5日目は、株式会社エイチームライフスタイルの@gonjyu121が担当します。

はじめに

最近のWEBサービス運営チームというと、事業運営や企画営業のチームと、エンジニアチームが一緒になって働く事が多いですよね。

そんな時、多くのエンジニアが、

「品質保持やリファクタリング、改善系のissue（タスク）の優先度がなかなか上がらず、着手できない・・・・・・」

といった悩みを抱えがちです。これなんですが、非エンジニアの皆さんからすると、

「エンジニアがすごいのは分かるんだけど、何をやってるか、なんでこんな時間がかかるのか、正直分からないんだよなー」

と思っていたりします。こんな話、あなたの周りでもぶっちゃけありますよね？
専門分野が違うのである程度は仕方ないと思うのですが、みんな一生懸命やってるんです。こうしたすれ違いを、少しでも解決できれば……。
そんな、エンジニアから見た「保守の重要性」を、わたしが日々あの手この手で伝えていく中で、

「なるほど、これは分かりやすいです！」

と、非エンジニアから太鼓判を押された説明方法が見つかったので、もしかしてニーズがあるんじゃないかなと思い、書き留めておく事にしました。

「最終的には事業／サービスも苦しむ事になるから、知っておいて欲しいんです」

あなたが同様の説明をする際に、この記事の内容や資料が一助となれば幸いです！
※非エンジニア向けの内容のため、エンジニアの方には回りくどい表現になっているかもしれませんが、ご了承ください。

Point1. 共通言語で話をしよう

まずは説明に入る前に、言葉の定義をしておきます。

登場人物は、分かりやすく２種類に分けます。
「エンジニア」と「依頼側」

見ての通り、「開発する人と、開発者に依頼する人」という関係性です。

依頼する人の例をあげると、事業部長、マーケッター、サイトディレクター、デザイナー、営業、企画、時にはエンジニア同士……、という感じで、あらゆる職種から依頼されissue（タスク）が発生します。
ただ、全パターンで説明するとわけがわからなくなるので、一旦今回の説明では分かりやすく２種類に分けました。

今回説明する「依頼側」は、エンジニアの事がよく分からなくて、KPIが売上利益に近い仕事をしている人、というイメージで説明していきます。
また、「issue」って何？ という人もいるかもしれませんが、「タスク」とか「案件」とか「チケット」の事だと思ってもらってＯＫです。
馴染みの無い方は置き換えて読んで下さい。

Point2. issueには “種類” があると伝えよう

さて、そのissueですが、事業やサービスを運営していると、とにかくいろんな種類のissueが発生します。挙げだすとキリが無いのですが、今回は説明がしやすいように、以下の3つに分類してみました。

詳しい説明は、これからしていきますので、ざっくりイメージだけ覚えておいて下さい。
そして、図解した時に分かりやすいように、それぞれのissueに色を付けますね。
事業系issue：青　保守系issue：黄色　改善系issue：緑

今回はこの前提を元に説明していきます。

Point3. エンジニアのキャパを伝える

エンジニアのことを魔法使いか何かだと思っている方もいるかもしれませんが、当然ながらエンジニアにも、キャパシティがあります。つまり、１日に開発できる量です。

リソースとも言いますが、今回は分かりやすくキャパシティ、あるいはキャパ、という表現で説明していきます。

通常、同じissueでも人によって開発工数が全然違いますが、ここでは分かりやすく 平均、1人あたり１日２ issueが可能な５人のチームがあったと仮定します。

つまり、今回の開発チームは、チームとして1日10issueこなせるキャパシティがあるということです。

これをマス目で表現しましょう。

今は空っぽなので、枠だけです。

Point4. 理想の状態を共有する

まずは筆者が理想と思うバランスを見て頂きますね。
なぜこれが理想か、というのは、説明の中でおいおい分かってきますが、一旦は「へー」と思っておいて下さい。

やはり事業が成り立たなければ、どれだけ保守や改善しても意味が無いので、ウエイトは高めです。

Point5. 溜まってるissueの見える化をする

エンジニアにアサインする前の、いわゆる溜まってる状態のissueを右に並べました。ストーリーボードとも言ったりしますね。

今回は分かりやすいように、事業系が6つと、保守系が2つと、改善系が2つ、合わせて丁度10issue溜まってます。

キャパシティも丁度10なので、1日で消化できそうですね。そのままアサインしましょう。

そのままスライドでいけました。issue置き場が空っぽになりましたね。バンザイ！

そんな簡単にいくか！

そうです。実際の現場はそんな簡単ではありません。
実際の現場では、事業系issue（事業がやりたい事）がエンジニアのキャパを絶対に超えてますよね。
こんな感じです。（ひとまず、保守系、改善系issueは一旦2つのままとしましょう。）

この中で優先度をはかると、やはり目に見えやすい売上利益に直結するものが優先になりがちです。
高い目標や、予算があったりして、日々奮闘している依頼側としては、少しでも多く、早く、数字が改善しそうな施策を進めたいので、押しも強くなります。

そして、口下手な人が多い開発チームは、うまく保守と改善の必要性を説明できないまま、「後でいいよね！」と押し切られ、結果的に開発リソースのキャパシティいっぱいまで、事業系のissueで埋まってしまいました。
売上利益の説得力は相当強いので、これを覆すのは容易ではありません。

ハウッΣ(￣ロ￣lll)

決まったものは仕方ないので、エンジニアは、実際に事業系issueをフルパワーで開発していきます。

事業MAXなので、その分事業の 数字（売上利益）に跳ね返る可能性も当然上がります。

今回は、依頼側がとてもいい人で、施策に対して出た数字を、頑張ってくれたエンジニアにも共有してくれました。
自分の開発工数が数字に跳ね返ると、エンジニアも、楽しいと感じますよね。
すると、着手前にあった「保守系issueが出来なかった残念な気持ち」よりも、「事業やチームへの貢献感や達成感」の方が圧倒的に上回りました。
そうすると、もっとやってあげたい！と思うようになりました。

そういった気持ちは依頼側にも嬉しいので、相乗効果で依頼側とエンジニアの一体感が生まれました。
保守系をやりたい気持ちが小さいトゲみたい刺さってはいるものの、いつの間にかエンジニアも事業MAX！

一見、チームは良い状態に見えますが、問題はこれがどこまで続くのか？です。

ええい！事業部系issueは底なしか！

話は終わりません。
良いサービスや事業ほど、やりたい事はどんどん生まれます。とても良いことです。

良いことなのですが、エンジニアのキャパシティが増えるわけでは無い事が殆どで、どんどん溜まります。

10消化できるなら15くる、といった具合。
最初は事業貢献が嬉しいという気持ちでやってたエンジニアも、迫りくるタスクを処理する事に追われ、だんだん疲弊していきます。
「俺たち、受託みたいじゃない？」という不満がポツポツ上がるようになりました。

そのうち「うひゃー、どこまでいくんだー！エンジニア増やしてくれー！」と心の中で叫び出します。

しかし、エンジニアの採用は・・・様々な職種の中でも獲得難易度が高めです。なかなか進みません。
＿|￣|○ il||li 　< ｵﾚﾀﾁﾃﾞﾔﾙｼｶﾅｲﾉｶ

このような事業スピード優先な現場だと、ほとんどのケースでプログラムコードが汚くなりますし、保守系issueが入らないので更に悪化していきます。
そう、事業系のissueの数を多く実施すればするほど、比例して、保守系と改善系でやりたいissueも溜まっていくのです。

ということで、このような形になりました。

終わらない悪夢

更に悪循環が起こります。

コードが汚くなると、少し修正しただけで思いもよらないところの不具合が出るようになります。不具合が出たら、エンジニアは申し訳ない気持ちになります。

特に共通処理で不具合が出ると、それを使ってる全ての箇所に不具合が発生するので、共通処理に手を加えるのが怖くなり、コピペで同じ処理が量産されがちになります。

そうすると、同じ処理がいろいろなところに書いてあるので、修正や検証に時間がかかるようになり、結果的に、少しずつ少しずつ、1issue当たりの工数が増え、エンジニアのキャパシティが減っていくのです。

このチームは・・・いつの間にかキャパが７に減ってしまいました。

キャパの減り方は少しずつなので、エンジニアも気付きにくいです。また、同じ開発者が担当していれば、汚いコードも慣れながらやっているので、そこまで劇的に遅くならず、意外に依頼側も分かりにくいです。
じゃあいつ分かるのか。

よくある、かわいそうなパターンは、開発担当が変わった時に表面化するパターンです。

長期で運用しているシステムほど、エンジニアの代替わりが発生し、開発担当が変わりますよね。そのタイミングです。
そもそも汚いプログラムなので、読み解くのに時間がかかります。そして、読み解いたとしても読み解けてない部分があるんじゃないかという恐怖で、スピードは落ちます。

ただでさえ、少しずつ減ってきているエンジニアのキャパが、担当者変更のタイミングで、一気に目に見えて落ちます。

半分の５になってしまいました。

依頼側からすると、その変化が、担当者変更のタイミングで一気にきたように見えます。

なので、「前の人は10issueできたのに、なんで今の人は5issueしかできないの！？」と、恐ろしい一言を言ってしまいました。

それを言われたエンジニアは、10issueできた頃を知らないので、過去のスピード感に答えようとして、更に保守系issueや改善系issueの優先度を落とし、事業系issueをぶちこみ、すごいことになります。

これが俗に言う、炎上プロジェクトです

これはさすがにやばいぞ、ということで、エンジニアが思い切って「昔と違って今は保守性が悪くて・・・」と伝えてみました。
保守性がよく分かってない依頼側は、それがネガティブな言い訳に聞こえてしまい、
「昔のエンジニアは事業に向かって一体感持ってやってくれたのに・・・」と思われてしまいました。
当時がいい思い出であればあるほど、それが仇となって溝が深まります。

お互い、理解してもらえない状況となり、チームはどんどん険悪なムードになっていきます・・・

最後の切り札「リプレイス」

最後の最後で、担当エンジニアが「こんなシステム、もう無理（怒）」と言い、クーデター的にリプレイス（移管）が勃発。

さすがに聞き入れて貰えて、リプレイス作業開始。

しかし、このリプレイス作業というのは、保守性の悪いビジネスロジックを読み解かねばならなく、更に今まで積み上げてきた機能要件を全てキレイに設計し直して実装する必要があり、かなり高度なスキルと時間を要求されます。

つまり、エース級エンジニアを長期的に投下する必要があります。1年間なんてのはざらです。

事業から見たら、「1年間もエースエンジニアが付けば一体どれだけの施策ができたか！」ですよね。逆に言えば、どれだけのチャンスを逃すことになるのか・・・勿体無い。

更に、リプレイスが成功しても、依頼側の人達に理解されにくいという現実があります。

今回も、エンジニアのクーデターのような形でリプレイスに踏み切ったため、悪くなった関係性が修復されていないままでした。
なんとか苦労してリプレイスをやり切ったのですが、「喜んでるのはエンジニアだけだね」と思われてしまうという悲しい事態になってしまいました。

では、どうしたら良かったのか。

解決策は、冒頭に言った、理想の状態の維持だと思うわけです。

例えば、issueがエンジニアのキャパを超えていても・・・

溜まってるissueを、各issue毎に分類して、それ毎の優先度を設定して、

各issueの比率に応じて割り当てる事ができれば、

一見、最初は6しかできないので遅いように見えますが、長期的に見ると、保守系issueが必ず入っている事により、6を維持できます！
キャパを維持できるんです！なんと素晴らしい。これで、あの悪夢の再現は防げるわけです。そして何より、リプレイスも発生しない！
「徐々に減っていくキャパ　＆　最終的にリプレイス」という先程の運用よりも、長期的に見るとかなりプラスになるのはおわかりになると思います。

いいことは続く

更に、それだけではありません。
改善系issueが毎回入ることで、エンジニアの開発しやすさが向上したり、検証工数が削減されたり、などなど、キャパが増える現象が起こります。

これを維持できると好循環となり、システムもより洗練され、あの、エース級エンジニアを長期的に投下するリプレイス作業をする必要がなくなる（または頻度を減らせる）のです。

エンジニアのスイッチングコストも下げられるので、別のシステムを担当する時に、ビクビクしなくて済みます。
かわいそうなエンジニアが産まれなくて済みます！
事業も進み、みんなHAPPY！

まとめ

今回の物語はフィクションです（笑）が、とはいえ、ありがちな現場なのではないでしょうか。
こんな悲劇を繰り返さないために、まとめです！

ということで、エイチームグループでは、事業系も、保守系も、改善系も、みんなで一緒に作っていける仲間を募集しています。興味を持たれた方はぜひエイチームグループ採用サイトを御覧ください。
http://www.a-tm.co.jp/recruit/

そして、[Ateam Lifestyle x cyma Advent Calendar 2018]　明日は@yutaroud に書いてもらう予定です。お楽しみに！

※ 他にも記事を書いてますので良かったらどうぞ🙇‍♂↓