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