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