はじめに

レバウェル開発部アドベントカレンダー13日目！

あれ？今日は金曜日…？

13日の金曜日、、なんとも不吉な日を担当することになりました。

そもそも何で「13日の金曜日」が不吉な日と言われているのだろうか。

wikipediaによると、イエス・キリストの磔刑の日であったり、元々13という数字が忌み数と呼ばれているからなど、さまざまな論説があるみたい。

多分、現在この説が有名なのはアメリカ映画の「13日の金曜日シリーズ」が大きく影響してるんだろうなーとか、、、考えてみたりして。

このような論説は(信じるか信じないかは置いといて)過去の人々の思考を追体験できる感じがして何か面白いと感じる。

びっくりしたのは、英語で「friggatriskaidekaphobia(13日の金曜日恐怖症)」という単語があるとかないとか。もう単語が作られるくらい一般的な論説なんだなーと。

wikipediaって読み物として面白いですよね！関連用語のページに簡単に跳べるし、、、と、早速脱線しまい、自己紹介を忘れてました。

レバウェル開発部、レバウェルグループでバックエンドエンジニアをしている恩賀です。

もうお分かりかと思いますが、真面目に話すのが苦手です。。。

普段はNestJS(TypeScript)を使ってスカウトサービスのバックエンドアプリケーションの開発を行っている私ですが、最近は社内ユーザーをターゲットにした「入稿システム」の開発に勤しんでおります。

今回はweb開発経験1年の私が「入稿システム」の開発を主導して得た気づきについて書こうと思います！

背景

レバウェルのスカウトサービスでは、実際のユーザーさん(採用担当者、求職者)だけでなく、弊社の人間もさまざまなデータを入稿しております。(求人情報を作成したり、事業所の魅力を取材して紹介文を掲載したりなどなど)

ありがたいことに利用者が増えてきており、(詳細は割愛しますが)既存の業務フロー改善の必要性が表れてきました。

そのために「入稿システム」を開発しよう！・・・と話が出ていたのが早一年前、、、

一度は要件定義を進めていたが、話が大きくなり、関係者が増え、がんじがらめになり。。。

気づいたら他の優先的な施策に押し潰されて霧散する形で開発停止、半年以上が経過した。

「誰かが動かなければいつまでも再開されない！」

この思いから周りの方に無理を言って、入稿システムの開発を主導させてもらい、再開することになりました。

現在も開発中でまだ運用するに至ってはいませんが、開発を通して得たものは多数ありました！

失敗した原因ってなんだろう？

背景に書いたように、「入稿システム」は一度失敗しております。

開発者の中には「やっぱり入稿システムが必要だよね」といった声も上がっていましたが、中々動き出すことができない雰囲気がありました。

それはふわっと「同じ失敗をまたするんではないか」という気持ちがあったからでしょう。

「同じ失敗」ってどんな失敗やねん！！！

具体的にしいひんから怖いんよ。「人は得体の知れないものに怯える」って言うし。

と言うことで過去の失敗を分析してみると、

関係者が多くなり、収集がつかなくなった。
なぜ→CMSという幅広く捉えられる名称を使っていたため、「この機能も入れて」「これができるようにして」「こっちの部署にも使わせて」と話が広がっていった。
優先度が他の施策よりも低く扱われていた。
なぜ→開発者と事業担当者で入稿システムを使って解決したい課題の認識が違った。

意外とシンプルで分かりやすい！？

これらを解消できたら同じ轍を踏むことはないのでは！と目の前の霧が晴れた気がしました。

今まで何に怯えていたんだろう、、、

気づき１：失敗が怖くなったら具体的に一つ一つ分析してみる。

分析してみると、怖がってたものが意外とそうでもないように思えてくる気がしました。

先人の事例があるってありがたいなと痛感！

線引きこそが成功の鍵？

過去の失敗の一つに「関係者が多すぎた」というのがあります。

ユーザーのターゲットとした部署が営業、CS、マーケティング、編集部といった多方に広がっており、もちろん部署が違えばシステムに求める機能も解決したい課題も違います。

これらを同じテーブルの上で話そうとしたら、それは散らかりますよね。

この時の問題は「関係者が多いこと」よりも「気づいたら関係者が増えていたこと」なんですよね。最初は数人で小さく始めていたはず、、、

そこで私は同じ失敗をしないように、「初期機能は編集部向けで作ります」と断言しました。

もちろん、「なんで編集部なのか」「将来的に他の部署も使えるように拡張ができるのか」などはきちんと説明をした上での断言です。

結果としてコミュニケーションが密に行えるようになり、スムーズな開発ができるように・・・なると思ったら障壁はもっと身近にも。

CMSは開発部内でも期待が膨らんだサービスになっていました。（実態もないのに期待だけ膨らむとかもうバブルだよバブル）

期待が膨らんでいるとどうなるか。

誰もが意見を言いたがるようになるんです。。。ほんと誰もが。

そうなると、インフラ構成をどうするか、言語やフレームワークは何を使うか、タスクの管理画面は？まず何から手をつける？・・・

もう何も決まらない。

そのため私は、「CMSチームを作る」 or「関係者を限定して勝手に進める」のどちらかにさせてくれとチームリーダーに直談判。

結果としてチームとしては分かれませんでしたが、私ともう一人の二人だけで開発を進めることに決めました。

関係者を絞ってからはもう早かった！密なコミュニケーションが取りやすく、決め事もすぐに決まっていきました。

何かを決定するときに、確認する範囲が明確だと動きやすいなと実感しました！

気づき2：スムーズに話を進めるためには、関係者の立場を明確にする。

これで万事良かったかというとそうでもない。

後から聞くと、「本当は参加したかった」「壁作られたのは嫌だった」という声もあったらしい、、、

開発を早く進めたいという気持ちから、関係者を早く絞りたくなり、チームメンバーにバッサリと壁を作ってしまいました。

私自身は、関係者の立場を明確にして線引きすること自体、悪いことではなかったと思っています。ただ、方法や伝え方を間違えたかな、、、と

反感を買わずに、線引きをする上手い方法はこれから学びます。

アイデアの核となるものは...

私が入稿システムの開発を急いだ理由。

それは、プロダクトや事業全体のアイデアの幅を広げられると思ったため。

どういうことか。

存在しないものをイメージするのは難しいと言うことです。

先ほどCMSに対する期待が膨らんでいたと書きました。

期待が膨らみすぎるとなぜダメなのか。

各々の頭の中で想像上のCMSが出来上がってしまい、「話が噛み合わない」「期待通りじゃないと文句が出る」などなど、

実態に合わない期待は、際限なく膨らみ続けていつか人々を不幸に陥れるものだと思ってます。(バブル経済とかまさにそうですね。)

これが、少機能であっても「社内向けシステムがある」というだけで形のない妄想が、核をもった「アイデア」になるのではないかと考えました。

気づき3：小さくてもいいから形あるものを作る！！！

要求分析にプロトタイプを作る意義もこれですよね。

多機能か軽量か？

入稿システムを作るにあたって、使用する技術を選定しました。

Express.js × pug

様々なフルスタックフレームワークが台頭する現在に、軽量サーバーサイドフレームワークのexpressとテンプレートエンジンのpug？

これには理由があり、「関係者を絞る」「小さく早く作る」という二つの意見を通すために、「機能追加や拡張をするときには、仕様を踏襲した上で作り直します！」と言ってしまったからです。

つまりこの入稿システムは作り直すことが前提になっているわけです。

(要件定義が無駄になったりするわけではなく、ソースコード上の作り直しですが)

そうなった時、特有の機能がびっしり詰まったフレームワークを使用していたら、作り直しがしにくい。最悪な場合、作り直しにくいからそのまま行かない？みたいなマイナスな意思決定が生まれてしまうかもしれない。

そんなのは嫌なので、最低限の機能だけを持った軽量フレームワークを採用しました。

実際に使ってみて、私が思ったことは、

気づき4：軽量フレームワークは本質が分かって好き

元々、内部構造がどうなってるかを調べるのが好きな性格なのもあり、使用していて気持ちが良かったです。

何より「よくわからないけど動く」がないので、挙動を推測しやすく、意図しないバグを生みにくいなと思いました。(そんなバグが生まれるほど大きなサービスでもないが)

特に、NestJSではmiddlewareをデコレーターを使って実装することが多いですが、expressでは実際に自分で書いて適用する必要があります。

今までNestJSを使っていた私にとっては、サーバーサイドのmiddlewareの挙動を理解するいい機会になりました。

もちろんHTTPステータスの定義がなかったり、便利な機能がなかったりと開発には時間がかかってしまうので、「全員expressに今すぐ変えな？」とはならないが、いい経験にはなると思うのでおすすめです！

私はさらに内部を知りたくなり、「ハンズオンNode.js」を読み漁ったり、githubでexpressやnode.jsのコードを読みに行ったりするようになりました。

入稿システムは誰のシステム？

入稿システム開発を進めるにあたって、私が一番思ってきたこと。

気づき5：これは私のシステムだっ！

(これは気づきなのか？)

とにかく私は入稿システムの開発を始動(再開)するにあたって、この気持ちを常に持つようにしていました。

せっかく作るなら愛着を持ちたいし、

何より、このシステムで何か問題が起こったら、それは私が責任持って直します。何時間でも残業して、何徹してでも直します。と思っていたら、失敗が怖くなくなりました笑

もちろん、本音では徹夜とかしたくはないですが、これぐらいの気概と責任感があれば、他の人にとやかく言われんだろう。

正直、入稿システムの開発、楽しかった！！

今後の展望

ここまで入稿システムの開発を主導して気づいたことについて書いてきましたが、最初に書いた通り、まだ運用始まってません笑

これからは実運用に向けた準備と、このシステムを導入した業務フロー全体の改善に貢献していこうと考えています。

課題を解決し、価値を生んでこそのシステム開発です！

長々と拙い文章を読んでいただきありがとうございます。