morimorihogeです。集中豪雨がすごい。
今年も弊社開発チームの紹介ということで、2024年版を更新してご紹介します。弊社への採用応募をお考えの方やお仕事を依頼検討中の方に向けて、どんな感じの開発チーム・スタイルでやっているのかの参考にして頂ければ幸いです。
※去年の内容と被る部分も多々ありますが、その辺りは昨年と方針が変わっていない部分ということでご容赦下さい。
というわけで、僕がチームリーダーとして所属するWeb開発第1チームの紹介になります。他の各チームについても記事がありますので、TechRachoトップページから読んで頂けるとうれしいです。
どんな仕事をしているの？
主にWebアプリケーションやそのインフラの受託開発や開発を伴う運用保守を行っています。2024年現時点ではRailsが絡むシステムをメインとしつつ、最近はそれ以外のAWSインフラ中心のプロジェクトなどもやることがあるというところです。現状でのチームの技術スタックとしてはRails開発をベーススキルとし、その周辺技術（AWSやJavaScript関連）についても必要に応じて組み合わせて開発を行っています。
また、Rails以外でもお客様の要件に応じてWordPressやS3でのStatic Website Hosting＋Lambdaによるサーバレス構成など、その時の保有スキルの中で要件に応じて最適と思われる選択肢を選んでいくというポリシーです。
具体的な業務としては以下のようなことが挙げられます。
- お客様の新規サービスの立ち上げに伴うシステム・インフラ開発部分の請負（フルスクラッチ開発）
- （弊社開発でないものを含む）既存サービスのリニューアル・改修などの請負（改修・リニューアル開発）
- 既存サービスの運用に伴う継続的な小規模開発・保守運用対応（保守運用・継続開発）
- その他サービス開発業務に関連する業務一般（プロトタイピング、技術・セキュリティ調査、技術相談など）
お客様の業務については受託開発ということもあり、業種・規模を問わず様々な案件をこなしています。
内訳としては社内システム、B2B、B2C、B2B2Cなど様々ですが、Railsを得意としていることで比較的バックエンド系のご依頼を受けることが多いため全体としてはB2B寄りが多いでしょうか。
お客様の会社規模も案件によってベンチャーから上場企業・学校法人まで様々となります。商流の都合上2次請けになるケースもありますが、ほとんどのケースで仕様書が送られてきてそのまま実装するだけのようなレガシーな開発会社ではなく、仕様や要件決めにもなるべく切り込んでいって開発会社の立場から提案するといったポジション取りをすることが多いです。
開発会社としての役割分担についてはお客様によって色々ありますが、今現在では以下の様なタイプがあります。
- お客様の開発チームに参加するタイプ
- お客様側の開発チームにエンジニアの一員としてJOINさせていただくケース。
- 大まかな責任境界はありつつも、基本的にお客様側エンジニアと同じような動きをします。
- 基本的に1名だけの参加ということはせず、最低2名以上のアサインをお願いしています。
- 1名のみアサインだと有休取得時や負荷分散に対応できず、メンバー負荷も大きいためお断りしています（メンバー側としても一人フリーランスエンジニアみたいになってしまうため、組織で動くメリットが享受できなくなってしまう問題もあります）。
- 2名で分担して合計1人月/月などの調整は可能です。
- お客様と役割分担タイプ
- 要件定義はお客様サイド、開発（システム基本設計～実装）は弊社サイドのケース。
- 要件や業務レベルの仕様についてはお客様サイドでまとめて頂き、それをベースに開発を進めていく。お客様側に業務とシステムに詳しく、仕様を切ってディレクションできる方がいるとこのパターンになることが多い。
- プロジェクト管理（PM）についてはお客様側で行うケース、弊社側で行うケースどちらも対応可能です。
- 開発チームから提案を積極的にしていくタイプ
- 要件定義から弊社が入り、リリース及びその後の運用・追加開発までサポートしていくイメージ。
- 弊社サイドからヒアリングを積極的に行い、機能の洗い出しから参加する。最終決定はお客様にして頂くが、それに必要な判断材料や比較ケース出しなど、一部技術コンサルティングに近い内容も行う。
その他、お客様側のシステム・他部門や他社と連携して動いて欲しいといったケースについても条件調整の上でお請けしています。
例えば、
- デザイナは発注側で手配し、HTMLコーディングから先を弊社でお請けするケース
- 開発・構築は弊社で行うが、構築後の運用・保守はお客様側で行うため引継ぎ資料を用意するケース
- インフラ周りのみ構築や助言役として見て欲しいといったケース
- システムが連携する一部のAPIを他社が提供しているので、その接続周りについてはよしなにやり取りしてほしいというケース
などがあります。
おかげさまで新規開発のご相談も多数頂いておりますが、稼働メンバーやスケジュールの兼ね合いもあり、最近は既存のお客様との継続仕事の割合が増えています。現場レベルで対応している開発プロジェクトとしては、新規に立ち上げるプロジェクトと継続開発なもの半々程度の印象です。稼働ベースで少なくとも5割以上は新規開発系のプロジェクトをしていると思います。
※既存のお客様と新規プロジェクトを始めるケースなども多い
どんな技術やスキルがあるの？
どんな技術を使っているかですが、2023年現在の得意な技術としては、
- Ruby on Rails（会社全体として10年弱ほどの開発・運用経験あり）
- AWS環境構築・運用（EC2ベースの一般的なシステムからECS、Fargate等を組み合わせたものまで要件に応じて設計）
- Linuxシステム環境構築・運用（Ubuntu、Amazon Linux等を主に利用）
- Docker環境構築・運用（開発環境のDocker Compose化、本番のDockerコンテナ運用）
- PostgreSQL / MySQLを使った開発・運用（アプリケーションパフォーマンスチューニング等を含む）
- フルスクラッチからの環境構築・リリースまでの一環した対応
あたりとなります。
その他、案件の要件や担当メンバーの得意分野に応じて、
- ReactやVue.jsを使ったフロントエンド構築
- SCSSを使ったHTML/CSSコーディング
- BootstrapなどのCSSフレームワークを使ったよしな管理画面やラピッドプロトタイピング実装
- AWS Lambda等のサーバーレス技術を使った開発
- WordPressを組み合わせたサイト構築
などなど比較的自由度の高い技術選定を行っています。
チーム全体としてはRailsをベーススキルとしていますが、メンバーごとに得意分野があるので要件の求めるクオリティと工数のバランスに応じてその時のプロジェクトメンバーが持っている手札から最も良いものを選んでいこう、という感じで技術選定を行っています。
技術戦略としてはRails自体は今では良い意味で枯れた技術となってきたので、そこはチーム内共通言語として押さえつつ、各自興味のある分野で強味となるスキルを伸ばしていくといった方針を取っています。
＃ 参考までに、僕はインフラ寄りのスキルセットを持っていることからアーキテクチャ設計やインフラ構築に突っ込まれることが多いです
チームの方針や大事にしていること
本節はどちらかというと採用向けな内容となります。
※チームメンバー向け資料から抜き出しているので、書き方が一部外部向けでない部分はご容赦下さい
把握力、問題解決力、提案力についてを意識して動いています。
メンバーによって得意分野・苦手分野はありますが、プロジェクトチームを組んだ時にはチーム全体として力を発揮できるようなメンバー構成をするようにしています。
スライド版は以下の通りです。
把握力
お客様に「このチームは自分たちのやりたいことをしっかり理解してくれているので安心して任せられるな」と思ってもらえるために必要な力としています。
- 常にプロジェクト全体の目的を見失わないように、お客様のプロジェクト目的を開発チームで共有・同期する
- 割り当てられた機能開発にだけ注視するのではなく、その機能が最終的にどのようにお客様の価値に繋がるのかを想像・理解することで、常に改善提案に繋げていく
- 密な情報共有をするためにもお客様も含めたアジャイルプロジェクトチームが理想
- お客様のビジネスやプロジェクトの位置づけを理解し、プロジェクトにおけるQCDの重心を正しく把握し、対応していく
- 「新規サービスなのでまずはMVPから」「既存顧客が多くいるシステムなので安定性重視」「全体予算が決まっているのでその中でできることを」などの位置づけを把握する
- 要望に全て答えられない場合でも、代案を提案・相談するなどして我々としてできることをすり合わせしていく
- お客様側の担当者の性質・立場なども考慮して、使う言葉を選んだり、ヒアリングの切り口を選べる
- 営業系の担当者であれば、技術寄りよりはビジネスの価値に着目。技術系担当であれば技術面で多少詳しい話もする。現場・運用系担当者であればワークフローなどに着目
問題解決力
お客様が「このチームであれば作ったものに信頼がおけて、いいものを作ってくれるな」という気持ちになれるように必要な力としています。
- 求められた品質の期待値を超えるものを開発し、満足していただく
- 約束した機能が正しく動作することはもちろん、中間成果物や付随する成果物（ドキュメントやモック素材等）についてもお客様の期待値を確認して提示していく
- 開発チーム視点でないと気付かない問題について、先回りして提示・解決する
- 当該プロジェクトの目的から当然想定し得る非機能要件や隠れ機能要件について、開発チームから問題の発見・解決を率先して行っていく
- プロジェクト中途の課題に直面した場合にも解決のための全力を尽くす
- プロジェクト中に発生する技術的・想定漏れ等の困難に対し、お客様と問題を共有の上で解決する方法を検討・提案していく
- 馬力があってもゴールに向かっていないのは価値がないので、よく狙って撃つのが大事
提案力
お客様が「開発や技術に困ったらこのチームに相談してみよう」という気持ちになれるように必要な力としています。
- 開発チーム視点から提示できる改善提案を常に考え、発言・行動する
- 機能の共通化・統合による工数削減提案だけでなく、利用者視点から考えた場合の改善・仕様追加提案なども積極的に行う
- 「開発者が楽をするため」だけではなく、その結果プロジェクトが良くなる提案を行う
- お客様の「次の動き」を見据えた先読み提案を行う
- 現行プロジェクトでは開発スコープ外でも、プロジェクト成功時には当然拡張されるであろう方向性について、先を見越した仕様提案を行う
- 「作ったものを見てみないとわからない」といったお客様であれば、まずはモックアップから見せていくなどのマイルストーンを置くことで、プロジェクト自体の不確定要素を一つ一つ減らしていく提案を行う
- お客様の本来求めている価値につながる提案ができる
- すべてを技術や開発で解決するのではなく、一歩引いて本来のゴールに近づける提案も時には必要
チームメンバーに目指してもらっていること
先に挙げたものはチームとして動くときの集団としての力ですが、これは各チームメンバーに意識してもらっている動きになります。
技術・開発のプロフェッショナルとなる
- 自分の得意分野を一つ以上持ち、プロジェクトに貢献する
- 開発プロジェクトに必要なスキルはコードを書くことだけでなく、プロジェクト管理やドキュメント整理など様々なので、その中で自分の「できる」得意分野を持ち、育てる
- プロジェクト全体を俯瞰でき、足りていないところのフォローに回れる
- 自分の担当分の仕事だけがうまく回ればよいというのではなく、プロジェクト全体がうまく回っているかにもアンテナを立て、駄目なところがあれば積極的に声を上げ、必要ならフォローに回れるフットワークの軽さを持つ
- 全員がオールラウンダーになる必要はないが、それぞれの担当する仕事について理解し互いにリスペクトできることで、フォローしてほしいタイミングの把握やチームワークに繋がると考える
- 次の武器・業務改善に向けた爪を研ぐ
- 新しい技術やツールなど、自分やチーム、果ては会社の武器になるかもしれないものを追いかけ、試し、社内知として情報共有する
- 個人 -> チーム内 -> 全社と順番に良いものは取り入れていく改善サイクルを回していき、自分だけでなく周囲のアウトプット向上に貢献する
- ※1人前相当に達していない人はまずはプロジェクトに貢献するところに全力を投入することを優先する
「エンジニア」の仕事とは？
- 究極的にはプロジェクトの成功のためのあらゆることをやるのがBPSのエンジニア
- コードを書く、プログラマとしての仕事
- 作られたものが期待通り動作するかを確認する、テスター＆レビュアーとしての仕事
- お客様から何をやりたいかをヒアリングし、実現可能な形に落とし込むSEとしての仕事
- システムに必要な環境構築を行ったり運用の仕事
- 上記の仕事をタスク分割し、チームメンバーで手分けして作業できる様にする開発統括としての仕事
- プロジェクトに関わる他社（協力会社・お客様側の委託先）とのすり合わせなどを円滑にするための調整や認識合わせの仕事
- その他、プロジェクトが円滑に回る提案できそうなことがあれば提案していく
- お客様の体制や担当者の背景などを見ながら「どういう動きをすれば喜んでもらえるか」を考えられると良い
チームの一員としてpositive feedback chainを回していくために
- 情報共有し・問題とその認識を密に取り合って価値観を大事にする
- プロジェクトごとに求められる動きは変わってくるので、分からなければ聞く
- 重要なところとそうでないところをなるべく漏れなく共有することで、手戻りの機会を減らしたり、より良い提案ができるようになる
- チームメンバーの仕事を尊重し、自分自身もまた尊重される動きをする
- 人のことを大事にする人は、自分も大事にされる
- 悪い所を探すのではなく良い所を探すクセを付ける
- チーム内でもお客様向けでも、心地よいコミュニケーションをする
- 同じことを伝えるのでも、より気持ちよく感じられる・スムーズにやりとりできる伝え方をする
- 誤解を招くようなことはなるべく避け、重要なことはなるべく早めに認識合わせをする
- 自分が困っていれば声を上げ、困っている人がいたら手を貸す
- 自分の手が回る範囲で助け合いができる
その他、チーム内の雰囲気など
本チームはもともとF2Fのオフラインコミュニケーションが少ない代わりにSlackでのコミュニケーションの多いチームでした。
某感染症の流行後は全メンバーがフルリモートとなり、今は希望者がたまに顔見せ・気分転換のために出社するくらいの状況になっています。
最近では関東近県以外からの採用も行っています。
チームのムードとしては、よく言うなら
- 仕事モードとプライベートがきっちり切り離されている
- 作業中にいきなり声をかけられて作業が中断されることが少ない
- やり取りがSlackに文字ベースで残ることが多いので、後から振り返りやすい
悪く言うなら
- 仕事以外でのチーム内での交流が少ない
- ちょっとしたことで気軽に声をかけにくい、雑談しにくい（自分から声を上げられないタイプの人は抱え込みやすい）
という見方もできると思います。
年齢層や趣味もバラバラで、プライベートな時間でもプログラミングをしているタイプの人もいれば、そうでない人もいてそれなりに多様性があるチームかと思います。
また、チーム全般（というかチームリーダーである僕）のノリとして「誰かにXXをやってほしい」というのは好きではなく、できるだけ「自分がやりたいからXXをする」というのを歓迎しています。困ってる本人から声を挙げるスタイルといえば良いでしょうか。
Slackというpush型のチャネルを中心にコミュニケーションしていることもありますが、経験上「誰かがやってくれるだろう」「困ってれば自然と誰かが助けてくれるだろう」というタイプの人はあまり合わず、放置されてしまう傾向があります。そのため、「やりたい」「助けて」「これってその後どうなってる？」などある程度自分から声を上げられる人がノリとして合いやすいです。
その他、分かりやすく声を上げられるタイプでなくても、コツコツと良い仕事をしていて周りからの技術相談によく答えてくれる人は頼られたり信頼を得ている印象です。この辺りは一緒に仕事をしているとコードレビューのやり取りなどで信頼を積み重ねていけるので、F2Fなコミュニケーションが苦手な人でもコードや文章でやり取りができるなら大丈夫、という感じですね。
参考までに、最近はF2Fで会う機会がなくなってしまいましたが、チームメンバーの顔と声くらいは覚えておきたいよねということで毎朝顔見せする会をやっています。
※2-3分くらい。5分を超えることはない程度のもの
また、2023年度からは地方在住メンバーも含めて年に2回は東京の事務所に集まって集まる会を実施しています。普段はフルリモートで業務を進めるので問題ないですが、たまには会ってお互いの顔を見ておくという距離感も大事かなと思っています。
チームリーダーよりひとこと
受託開発を15年以上やってますが、色々な案件に触れられて、その中でお客様の色々なビジネスを知ることができるのが受託開発の最大のメリットだと思っています。
案件が変わるとお客様との進め方や役割も変わるため、状況によって色々な動き方を求められたり、時には必ずしも自分が得意とは限らないことをやらないといけないこともありますが、それを乗り越えたら乗り越えたで自分のスキルも成長するので、新しいことややったことないことでも「とりあえず調べてやってみよう」なマインドな人は向いているチームなのではないかなと思います。
採用については既存業務に即戦力（Rails開発、インフラ構築・運用、要件定義・設計、PMなど役割としてはどこでもOK）として入れるスキルのない方は原則業務未経験評価からのスタートとなってしまいますが、プロジェクトにアサインされて結果を出してもらえればそれに合わせて評価UPは行っていますので、興味がありましたらご相談いただければと思います。
※本チームに興味のある場合は採用応募時に「この記事を見た」と言って頂ければ僕に繋がるはずです。
