【Webアプリ】課題ぶっちゃけ座談会
こんにちは！採用広報チームの恵川です。
オープンワークではエンジニアを絶賛採用強化中なのですが、今や日本は、いや世界は未曽有のエンジニア不足…！大企業からスタートアップまで、皆さんエンジニア採用にしのぎを削っています。
優秀なエンジニアにとっての超売り手市場において、オープンワークを選んでもらうために伝えたい事。働く環境とかスクラム開発とかももちろんお伝えしたいのですが、今回の記事ではあえて、Webアプリ開発における「課題」を共有したいと思います！
本来ならイケてないと思われてしまうかも、、と隠したくなる社内の課題をなぜあえて出すのか。それは、私たちが運営するOpenWorkというサービスが、社員クチコミで会社の良いところも課題も確認することで「入社後のミスマッチを減らす」ことを目指しているから。完璧な組織なんてない！……とはいえ書くのはちょっとドキドキしてるんですが…最後まで読んでいただけたら嬉しいです！
メンバー紹介
この場所が集合写真の定番になりつつある。お洒落だしね。
（こっちは右から）
平田（ひらた）：2021年新卒入社だが、その前に2年間学生アルバイトとして勤務していたため実は社歴は中堅。OpenWorkは転職だけでなく就活生にも信頼を置かれているサービスで、機能改善のやりがいがあり、アーキテクチャ再考や改善タスクが面白かった。
永田（ながた）：2020年新卒入社。自身が利用しているサービスの開発をしたいと考えており、OpenWorkを利用していたことが志望した理由。OpenWorkリクルーティングの開発を担当。
濱田（はまだ）：2016年入社。地方のIT企業にプログラミング未経験で入社後、さらなる成長を求めて東京で転職。オープンワークの事業内容に社会的意義を見出したこと、自分よりも若い世代に役立てられるサービスであった点を魅力に感じて入社。
【聞き手】西川（にしかわ）：2020年入社。田が付く3人の優しいマネージャー。最近引っ越した。
今回もカメラマンはインフラの小川。書き手は恵川なので、苗字に田と川がつくメンバーによる記事でございます。
会社の成長と課題と。レガシー問題
メンバーには事前にどんな課題を感じているのかを書いてもらい、それについて話し合いました！在籍期間はそれぞれ違うメンバーでも、課題に感じているのは、組織の拡大に伴って変化をしていかなきゃならない部分でした。
「改善」が個人の裁量になりがち
西川：はい、今日はWebアプリ開発についての課題を話し合えればと思うんですが、まずは濱田さん、「技術的な改善を行うための時間が取りづらい」と。
濱田：今自分がインナープロジェクトという、OpenWorkサイトの各種機能追加等を行うチームに居るんですが、社内の内注先のようなポジションというか、色々な社内からのオーダーを引き受けて対応しているんですね。今だとフレームワークのアップグレードに向けた準備もしているところなので、生産性向上の改善タスクまで手が回らないのが実情です。
永田：それでも、改善タスクって課題にあがると「インナーにやってもらおう」ってなりますもんね（汗）。機能開発も行ってる中だとどうしても優先度下がって取り掛かれなくなっちゃいますよね。
西川：僕もそこは課題に感じていて、「何でもやるプロジェクト」としてインナーにばかり色んなタスクが集中してしまうのは良くないなと感じています。もっと適材適所な配置ができるといいですよね。
永田：僕も、生産性向上のためのプロジェクトがあるといいなと思っているんです。今の、機能開発に優先度を置きながら、個人の裁量だけで改善を行っていくのは限界があると思っていて、改善したいものはたくさんあるのだから、それ専門に取り組むプロジェクトがあってもいいんじゃないかなって思ってます。
濱田：改善提案をすると受け入れられやすいのはとてもいいことだと思っているんですが、今はそれを提案するだけじゃなく最後まで巻き取らないと解決されないのが課題になってしまってますね。テスト周りの改善も、本当はみんな何とかしたいはずなんですが、目の前の優先タスクに追われてしまって「誰かがやってくれる／くれているだろう」という状態になってしまう。また、時間が経ってプログラムが大きくなってしまうと新しい技術や全体に関わる改善を入れるコストも高くなってるなぁと。。
西川：改善を提案するチャンネルやBacklogにチケットは作れるんですが、旗振りまで自分でやる、という状態にはなっていますね。
濱田：そうなんですよね。自分で手を動かせればいいんですが、全ては無理だし、そうしている内に挙げた改善提案がそのまま放置されてしまったりする。もっとスピードを上げてリアルタイムに改善をしていくべきだと思うんですよね。全員が課題の当事者になる文化作りや、放置されてしまっている課題に気付けるような仕組み作りが必要だと思っています。
永田：全員が課題の当事者、だと、問題に気づいたら自分でやるしかない、って感じしませんか？（笑）
濱田：いや、なんというか、改善をひたすら頑張る人と、我関せずな人とで分かれてしまうと、それは組織として良くないと思うんですよね。
平田：課題を見つけられるかどうかは結構個人によると思っていて、でも、課題を定義して「これを解決しよう！やろう！」ってなったら手は挙がると思います。そういうのを広げていけるといいですよね。
永田：自分の空き時間で改善！だと強靭な精神力を要するので（笑）、改善も目標立ててリソース確保してやっていくしかないのかなって思いますね。
濱田：そうなんですよ、、、1人で改善頑張ってると、たまに、何のためにやってるんだっけ…？ってなることもあって。。。
（一同ざわつく）
西川：今の状態は、Googleも実践している「20％ルール」（業務時間の20％を好きな事に充てて良い）が続いてきているものだと思うんですが、今の話を聞いて悩み始めました。コスト度外視でも自由にやれる方が良いし面白いようにも思っていたんですが、どっちが良いのか、ちょっと考えたいですね。
濱田：そこは良い部分だと思っていて、自分は技術が好きなので、プロジェクトをやる合間で、触っていない技術に自由に触れられるのは楽しいんです。が…
西川：でも、それだけだと解消しきれなくなってきた、ってとこですかね。平田さんはどうですか？
平田：最近はElasticsearchの開発・リリースやABテスト周りを担当することが多いんですが、Elasticsearchの同期がうまく行かなくてリリースを何回かやり直したりとか、ABテストは自作フレームワークを使ってるんですが、ドキュメントが古かったり情報が不足していてミスが多くなってしまっています。新しい人が入るたびに同じような問題が起きて、そのたびにみんなで話し合う、というのを繰り返しているような状況ですね。
濱田：ABテストは、慣れているデザイナーさんでもミスを起こしてしまう印象があります。
平田：ABテストは、昔作ったものをずっとそのまま使っているような状態なので、直感的に使いやすいインターフェースではないんですよね。ドキュメントを整理して、みんなにとってよりわかりやすいインターフェース（ライブラリ）を実装出来たらいいなと思います。僕は作りたがりなので何でも実装したくなるんですが、色々ツールもあるので、そういったものも含めて検討できるといいなと。
西川：Elasticsearchは、どういうところが課題だと思いますか？
平田：例えば新しいメンバーがプロジェクトで新しくElasticsearch系のリリースをする際は、僕と藤原さん（ベテラン）がペアプロをしたり相談を受けるんですが、新しいメンバーが入るたびに口頭伝承の繰り返しになっているので、スケールしない感じがしてるんですよね。ドキュメントをちゃんと書こうとしても、現状をこのままドキュメント化するのも何か違う気がしていて、、、インフラチームと連携して、アーキテクチャやリリースのフローそのものを自動化したり改善していく必要があるように思っています。
永田：ふと思ったんですけど、改善を個人の裁量に任せるなら、やる気のある人たちや改善ができる人たちはそっちに注力する、というのはダメなんですかね？
西川：いやいや、機能開発の方も大事だし（笑）そこはバランスよく人材配置をしないと。
濱田：特に新卒入社の人や、新しく入った人たちをきちんと育てていかなきゃですしね。
永田：そっか、そうですね（笑）
濱田：でもまぁ、自分でやりたい！ってよく思っちゃうんですけどね（汗）
もっと色々平準化したい
永田：Webアプリ全般の課題としては、期待されているものを継続的にデリバリーするためのプロジェクト運営についてですかね。コミュニケーション、タスク管理、見積もりなどのやり方を工夫して改善していかなければならないなと思います。オープンワークではスクラム方式を採用しているんですが、スクラム自体は素晴らしいものの、人によってやり方が違ったりするので、上手く回してるチームの知見やフォーマットを共有して、ある程度平準化していけるといいなと。
濱田：わかります。クオーターごとにやり方変わったりするので…＞＜
永田：スクラムをうまく回せると、いつまでにこれが出来るという見積もりがある程度正確に見積もれるようになる。それが出来ると、サービス開発のロードマップが立てられるんですよね。今全プロジェクトでスクラムを導入してますが、試行錯誤している部分もあるので、全プロジェクトがうまく回せるようになると良いなと思います。フォーマットの統一とか…
濱田：フォーマットの統一、したいですね。今プロジェクトのリーダーによってフォーマットが違うんですよね（苦笑）
平田：この規模の組織で、チームも10人以下だったりするのに、なんで全部違うんだ～！ってなります。揃えようと思えば揃えられそうなのに。
西川：この辺は、メンバーの裁量に任せてきた部分が大きいからでしょうね。
濱田：Backlogがスクラムに合ってないんですよね。それを解決するために各自やり方を考えた結果バラバラになってしまった。
永田：各プロジェクトが柔軟性を持って出来るように、という背景もあると思うんですが、フォーマットが不揃いなのは意図してそうなってるわけではない気がするので、フォーマットを決めて揃えた方が効率良いと思いますね。
濱田：人の入れ替わりもある中で、色んな側面で様式を統一したり、平準化は必要になってきてますよね。古い機能とかになると誰も詳しくなかったり…、今プロジェクトとして行われているリファクタ活動でそのあたりが解決出来るといいなと。
平田：人の入れ替わりで言うと、新しい人が入社するたびに開発環境で同じような問題が起きてますよね（苦笑）もっと、コマンドとかボタン一つで立ち上げられるようにしなきゃな、って思ってます。
フロントエンド、もっと色々やりたい
西川：皆さんそれぞれ、フロントエンドに課題を感じているようですね。
永田：最近、入社して初めてちゃんとフロントエンドを書いてるんですが、コードのカオス感がまずい気がしてます（苦笑）。バックエンド（php）は設計パターンとしてDDDを採用しているんですが、現状フロントエンド（Vue.js, js）はそういうものが無く、自動テストも無いので、壊れていてもそれを検知できないのが心配です。Typescript, Jestを導入したり、設計についても、現状を整理して、ルールや指針を考えたいですね。
平田：僕は今ジョブマッチング促進プロジェクトに居て、永田さんが担当してるOpenWorkリクルーティング側と違ってインタラクティブではないので、そこまで苦労はしてないと思うんですが、それでも、テンプレートが読みにくいですし、ソースコードはカオス化してるし、HTMLやJavaScript以前に、プレゼンテーション層（参照系）の実装が求人検索周りではすごく複雑で悩まされていますね。
西川：今までどうしても、バックエンドを優先してきたところがあるので、フロントエンドに課題は多いですね。
濱田：あ、Typescriptは今度のバージョンアップで頑張ろうとしてるので待っててください。出来なかったらごめんなさい。
永田：ありがとうございます。いや、でもこういうところが改善が個人に任されている部分の怖いところで、濱田さんがやらなかったら、Typescript使えないかもしれない、っていう（笑）
濱田：いやぁ、バージョンアップのチャンネルで「やります！」って宣言したので（苦笑）でも確かに手を挙げなかったら何年でもこのままになっていた可能性はあるのかな…、手を挙げたらやらせてもらえる環境はとても良いと思っているんですけどね。
平田：フロントエンドの中でも、OpenWorkリクルーティングの方はOpenWorkサイトに比べると新しめのフレームワークでインタラクティブなUIを入れてるんですが、OpenWorkサイトは古いままなんですよね。開発者全員がそれに慣れてしまってるので、そこの枠から出ないんです。変える必要性が議論されないので、「こういうもの」という前提で機能やUIを開発している状態かなと。コードはカオス化してても開発はやり切れるので、改善も優先度下がっちゃうんですよね。
濱田：この辺はデザイナーにも聞いてみたいなって思いますね。現状のままで開発しているから今のUIなのか、もっとモダンになったらもっとリッチなUIにしたいのか。
永田：いきなりめっちゃインタラクティブなUIになったら浮きそうですけどね（笑）
西川：でもやってみたいけどね～
濱田：やってみたいですね～
平田：確かにデザイナーさんに聞いてみたいですね。もちろんデザイナーさんだけではなくプロダクトの方針としての部分にもなりますが、OpenWorkとして提供したいUI／UXが現状のままである限り、フロントエンドの課題はクリティカルじゃない状態で残り続ける気がしているんですよね。改善を進めるためだけに機能や仕様を変更していくのは何か違う気もするので…。
永田：そこって双方向な気もしています。フロントエンドの優先度を上げてこなかったから裏側がカオス化してるのもあると思うんですが、裏側がカオス化しているからこだわりたくてもこだわれない部分もあるのかな、と。裏側からよくしていくというアプローチもありだと思いますけどね。
西川：マーケチームで作っているLPとかは色々かっこいいの作ったり新しいことにトライしている気がしますね。そういう意味では、諸々のしがらみで制約されてる部分はありそうですね。
永田：LPとか「働きがい研究所」とか、ある程度本体と独立した実験できるような場所があるといいですね。
恵川：研究所インタラクティブにしてほしい～！！（突然登場する恵川）
濱田：「実験」でユーザーに迷惑が掛からないよう、社内の管理画面（メール配信など様々な機能を管理しているページ）ならSPAとかにしやすそうですね。
平田：そういう意味では、管理画面ってダッシュボード的に使うから、インタラクティブになってる方が良かったりもしますね。ABテストでもそうなんですが、今ページ遷移してるものも、APIでやった方が効率的だよね、という話はプロジェクトでも出ています。優先度が現状低いので何ともですが、実験的にトライできなくはない気がします。
濱田：管理画面は社内向けな分自由度も高いので、色々やれるといいですよね。
もっとAWSのサービスを触りたい
永田：AWSのサービスを活用した設計開発があると楽しいし、需要の高い技術を覚えられていいと思うんですが、そういった案件は現状少ないのでちょっと残念です。もしもOpenWorkのマイクロサービス化のような分割ができたら、機能ごとに最適なインフラを考えることができるので、そういった新しい技術を使った面白い取り組みが増やせるんじゃないかなと思ってます。
西川：マイクロサービスの基盤は用意されてて、濱田さんも以前ある機能をマイクロサービスで実装してもらったので、個人次第ですけど、やろうと思えばできる、というのが現状ですかね。
濱田：だいぶ昔すぎて忘れちゃいました（笑）うちのWebチームは、インフラ面をインフラチームに頼りすぎてるところがあるので、もっとエンジニアとしてみんながインフラに慣れていかないといけないなと思ってます。
平田：インフラ側も変わっていけるといいですよね。インフラは一定の知識を必要とされるのでなかなか新しい人が入れない分、メンバーが固定されてしまうところがあって。そうすると、その中で当たり前になっている知識が外に出てきづらくなってしまう。今インフラチームが手動でやっているリリースも、メンバー内で問題が無いかぎり自動化されないのかなとか。信頼できる範囲で、適切な権限を開発者に付与していけると良いんじゃないかなって思いますね。
濱田：全員がAWSコンソールは見られるようにならなきゃいけないなって思います。
西川：平田さんが言うように権限を付与できると理想ではあるんですが、ちょっとまだ難しい部分もあって。実は自分は来期からインフラチームに行くので、Webアプリ視点からの改善を色々できたらなと思ってます。
でも、オープンワークのここが好きだ！
西川：課題、たくさんありがとうございました（汗）でも皆さんオープンワークが好きで働いてくれてるはずなので（笑）、是非ここから「オープンワークのここが好き！」というお話をしましょう。
濱田：課題の裏返しでもあるんですが、改善作業やコードのリファクタを行うことを個人の裁量で出来るのはすごくいいと思っています。改善提案も受け入れられやすいですし、その改善に工数を使うべきかも自分の判断でできるのは良いところです。
永田：労働時間の融通が利くところです。眠ければ遅く始業できますし、集中できなければ早めに終業して、逆に集中できている時は遅くまで働ける。現状フルリモートなのも良いですね。
濱田：永田さん遅くからって何時からですか…？11時…？（オープンワークのコアタイムは現在11時～16時）
永田：じゅ、10時半です、最近は（笑）
西川：あとは、プロジェクト運営がスクラム方式なのも良いところに挙げてますね。
永田：そうですね。タスクの見積もりをして、プロジェクトのベロシティ（チームが作業を進める速度）を測定することで、出来るだけ現実的なスケジュールを臨機応変に組もうとしているのは良いと思います。期日決めてとりあえずここまでに絶対終わらせる！みたいなのではないので、過度な残業とかが生まれにくいのかなとも。
西川：池内さん（CTO）残業厳しいですしね。結構言われます。
恵川：そんなこと言いながらあの人趣味仕事だよね。（突然登場する恵川②）
平田：学びや改善に向けた意見を全体共有すると、建設的にフィードバックをもらえるのがいいですね。Web開発グループに限らず、フラットな組織で、改善にも比較的積極的なので、課題提起や相談がしやすいと思います。あと、AWSの勉強会に今年の新人君が行っていたので、そういう機会ももっと増やしていけるといいなと思いますね。
西川：確かに確かに。どんな人にオープンワークに来てもらいたいって思いますか？あと、自分がやりがいを感じるところとか。
濱田：今、何よりもリソースが足りないので、改善の経験が豊富で、リーダーシップを持って力技でどんどん改善していってくれるようなアグレッシブな人、が来てくれたら嬉しいですね。
永田：スキルがあって実績が欲しい方には合っていると思います。組織の改善をしたり、大幅な設計の見直しをしたり、そういった課題に挑戦したい人に、今のオープンワークの状況はマッチしているんじゃないかな。コードの設計について考えられるのもいいなって思います。いいコードって何だろう？どうしたら、わかりやすくて壊れなくて変更もしやすいコードができるんだろう？って考えて実行できるのは素晴らしいと思います。世の中ままならないことが多いので（笑）、コードを作ってる時は理想を追求できる気がするんですよね。オープンワークは、ただリリースするだけじゃなくて、より良いものを作ろうっていう空気感があるからこそだと思います。
平田：改善もやりがいありますが、まだまだ機能として不十分なものを違うアーキテクチャや全く新しい作り方でトライできるのは、サービスとして面白いと思います。自分は技術が好きなので、ツール開発が楽しかったりするんですが、やりがいがあると思うのは、友達が「使ってる」って言ってくれるし、実際に本当にたくさんの人が使ってくれてて、最近出したエージェント求人機能とかも知ってくれてたりするんですよね。そういう時に、ちゃんと届いてる気がして楽しいですね。
編集後記
いやぁ、、、こんなにさらけ出していいのだろうかと採用広報担当としては思ってしまうのですが、普段寡黙なエンジニア達の「熱さ」を垣間見ることができた座談会でした！
「これ、オフレコで…」「いや、録画してるがな！」というやり取りも実はあったんですが（笑）、座談会の録画をCTOも見る前提でも皆臆せず課題をぶつけてくれるところに、開発への情熱やプロダクトへの愛情を感じた次第です…（じーん）
組織が拡大するにつれて、昔ながらのやり方では無理が出てきたり、平準化を進めなければならないのはどんな組織でも同じ。「今」のオープンワークだからこそ取り組める課題解決や、働きがいがあります。是非是非、ご興味のある方はカジュアル面談からでも話を聞きに来てくださいね！
オープンワークではエンジニアを絶賛募集中です！
☞エンジニアの募集一覧
今回も記事内写真を撮影してくれたインフラエンジニアの小川が所属するインフラチームも絶賛募集中です！（カメラスキル不問）
☞SREエンジニア
オープンワークでは一緒に働く仲間を募集しています。
☞求人一覧はこちら
ご応募、ご連絡お待ちしています！！^^