スタートアップで働く上で重要なこと
こんにちは。
4ヶ月ほどスタートアップで働いていたので、そこで得た知見などの書いていきます。
今年の2月まで僕はとあるスタートアップでフリーランスのソフトウェアエンジニアとして働いていた。契約期間は４ヶ月と短かったけれども今までにないタイプの会社で働き、優秀な人とも会えたのでとても勉強になった。
スタートアップでの仕事は激動の日々だった。自分が担当する予定の仕事はたくさんあったし、それ以外の仕事もたくさんあった。
僕が関わっていたスタートアップもご多分に漏れず人手不足だったため、自分の担当範囲を超えて仕事をすることも多かった。人手不足という理由もそうだが、自分がCEOやバックオフィスの方々との距離が近い立ち位置にいたというのも大きな理由だったと思う。
スタートアップと聞くと、仕事が多くて大きな裁量を持って仕事をすることができる、と考えている人は多いと思うがまったくもってその通りだと思う。確かにスタートアップに身を置けば色々な経験はできる。
しかし、複数の仕事を同時にこなしていくことは難しく、単純に複数の仕事をこなすためのマルチスキルが必要になるだけでなく、「その組織に今何が必要か？」「一緒に仕事をしている人の能力はどのくらいか？」ということを意識しながら動かないと、自分がどのように立ち回ればいいか分からず上手く仕事が回らないことがある。
自分の場合はITエンジニアとして働いていたので、ビジネス要求を設計に落とし込み、実装、テストまでは一通りこなしつつ、インフラの構築やCI/CD設定の構築、データメンテナンスからバックオフィスでの運用フローの設計、実際のサービス運用まで担当してきた。
実際にやってきたタスクベースで見ればそこそこ貢献してきたとは思うものの、組織全体を俯瞰した上で最適な行動を選択できていたかというとそうとも言えない部分も多々あったというのが正直な所だ。自分の裁量権や仕事の幅が広かった分尚更自分の至らなさを感じることもできた。
前置きが長くなったが、この記事では実際にスタートアップで働いてみて、重要だと感じた点を書いていく。
また、記事内のアドバイスはITエンジニア向けになっている箇所もあるのでその点留意してください。
スタートアップでやってきたこと
主に週5で基本リモート稼働という契約でプロジェクトに参画。
開発初期はビジネス要件から設計の落とし込みやAPI仕様の設計、DB設計、バックエンドシステムの技術選定、開発環境構築、CI/CD設定などを担当やっていて、サービス開発が進んでいくにつれ、データメンテナンスフローの設計をしたり、非エンジニアの方がサービス運用に関われるようにツールの整備なども行っていた。
また、サービスの後半はそれまでフロントエンド、インフラを見てくれていたエンジニアが抜けたのでそれに伴いフロントエンドの開発やインフラ周りの構築、デプロイ作業なども担当した。
出社の回数や稼働日数は他のエンジニアの方と比べると多かった方なので、サービスに関わるステークホルダと会話をする機会が一番多かったはず。
スタートアップで重要なこと
前述したが、スタートアップでは人的、時間的なリソースが少なくその中で多くの仕事を捌いていく必要がある。そんな状況では必然的に個人の裁量は大きくなるが、重要なことはその組織の中で今何が足りていないかを見極めて行動ができることだと思っている。
実際にスタートアップで働いてきて特に注意すべき点というのがいくつか見受けられたのでそれらをいくつかここで挙げてみたい
ステークホルダーと対話を重ねる
自分はソフトウェアエンジニアであり、ビジネスの目標を達成するためのシステムを構築することが仕事だ。
そしてスタートアップではビジネス要求はステークホルダーから生まれてくる。ここでいうステークホルダーとはCEOだけでなく開発エンジニアやバックオフィスの人たちも含まれる。
システムを構築するにはステークホルダーの発言を実装可能な仕様に落とし込む必要があるがステークホルダーは仕様を作れるわけではないため、ただ話を聞いているだけでは上手くいかない。
もしかすると事実と異なるような適当なことを言うかもしれないし、以前と違うことも言うかもしれない。ステークホルダーがどんな目標を達成したいと思っているのかを知るためにはこちらから積極的に問いかける必要がある。
また、ステークホルダーは自分のようなITエンジニアとは違う文化の中で生きてきている。なので、自分とは違った言葉を使うし、物事に対する認識の仕方も違ってくる。そういった事を加味しながらステークホルダーとコミュニケーションを取ることが重要である。
ビジネス目標を達成する上でステークホルダーのやりたいことを理解することが最も重要なので、この点は重視して行動する必要がある。
ユビキタス言語を定義する
ユビキタス言語とはそのサービスのドメインで有効な用語集のこと。
メンバーとコミュニケーションを取っていると持っている文化や知識に違いがあるので、一つの概念に対して2つ以上の言葉が割り当てられることがある。
各々が自由に言葉を使って説明すると文章の意味を誤って解釈されることがあったので、そのドメインでの専門用語やサービスを作る中で生み出された概念には決まった言葉を割り当てて認識の齟齬を減らす工夫があるとよい。
ユビキタス言語に採用するのはWebで検索しやすく、非エンジニアでも親しみやすいような言葉が適切。
ユビキタス言語を決める際は定期的な開発MTGなどを使って新たに生まれた概念などについてメンバーで話し合って決めるとよい。また、認識の齟齬が出ないようユビキタス言語以外の言葉でその概念を表現しないように気を付ける必要がある。
仕様とタスクのスケジュールは明確にする
多人数で協力して仕事をするなら、みんなで決めたことや議論の内容はいつでも確認ができるように文書化してオンライン上で管理しておく。
記録がなければ過去に言われたことが無いようなことを急遽実装することになるかもしれない。また、一度話したことについて何度も他人の頭の中から仕様を引っ張り出す必要がなくなるので効率的だ。
また、これも当然やらないといけないがシステム開発のゴールを定義して、そこまでのスケジュールを引いておくこと。
いつまでに何ができるのか分からないというのは中々にスリリングな開発になる。それが資金力のないスタートアップならなおさら。
仕事を簡潔に説明する
自分の仕事や扱っているシステムは誰の仕事にも影響していないということはほとんどない。逆に誰かの仕事の結果が自分の仕事に影響する事もよくあることだ。
なので自分の仕事や実装したシステムを簡潔に説明できる図や説明を用意することはとても価値があると思っている。自分が立てたリポジトリに簡単な説明を入れるだけでなく、関わっている非エンジニアに説明できるような文章があるとなおよい。
簡単にすぐ行動に移せることとしては、参加するMTGで自分が説明したいことや、自分が行っているタスクについてSlackのチャンネルで説明してみると良い。
こういう言語化されてない所を説明していったりすると意外とありがたがられたりする。
システムを図にする
システムを理解したり、説明したりするのは難しい。
ITエンジニアならソースコードを読むのも仕事ではあるがシステムの全容を把握するのにいきなりソースコードの解読から始めるITエンジニアはほとんどいないと思う。それくらいにソースコードを読み解くのは難しい。
システムの全体像を簡単に説明する図があればエンジニアにも非エンジニアにも役に立つ。特に非エンジニアに対しては外部システムとの連携方法や、各ユースケース毎のシステムの動作を説明できるような図になっているとよい。
SEOならそれを見ることでシステムがビジネス目標を達成しているかを確認できるし、バックオフィスの方なら自分が関わる作業がシステムとどう関係しているのかを把握することができる。
また、図を作る理由は説明できるだけでなく自分が理解するためにも利用できる。テーブル設計をする際にER図を書いたことがある人なら分かると思う。こういった図はどんどんメンバーと共有しよう。
多少図が汚くても無いよりは全然マシなので、必要最低限の労力でさらっと書いてシステムのドキュメントとして公開してしまおう。
反省
一番足りなかった点といえば仕事に関わるメンバー全体を俯瞰した上で行動することが足りなかったと思う。もっと言うと「その状況に足りない部分を見極めて補っていく」ようなことをしていけばよりもっと上手く行ったなと感じる場面は多かった。
具体的に足りていなかったと思われる要素について列挙してみる。
- 仕様を作成、共有する人
- ドメインエキスパート
- システムを視覚化する人
それぞれについて軽く説明を書いてみる。
仕様を作成、共有する人
まず自分がサービスを開発していく中で、仕様を詰め切れていなかったりすることがあった。原因はいくつかあるが最もなものとしてはステークホルダとの対話が足りていなかったことだと思う。
開発初期からチームのメンバーをよく見て察すればよかったのだが、ビジネス上の重要な要求はなんなのかについてきちんとヒアリングできる人がプロジェクト内にいない状態があった。
自分がその役割を担っていればもう少し円滑にプロジェクトを進められたと思われる。
ドメインエキスパート
もう1つは開発しているサービスについてのドメイン理解が不足していたことが挙げられる。
ドメイン領域をちゃんと理解しないままデータ仕様の設計をしてしまった事で設計を１からやり直さなければならなくなってしまう事もあった。
こういったことを避けるためにも開発するサービスが属するドメインについて自分から学んで行ったり、ドメインエキスパートと思われる人たちとの会話をする機会を持つことが重要だと感じた。
もしチーム内にドメインエキスパートがいなければ、自分がドメインエキスパートになっていく必要があるかもしれない。
システムを視覚化する人
システムを視覚化してシステムのアーキテクチャをメンバーに共有する人もいなかったため、メンバーと協働する際に効率よく仕事を進められない時も多かった。
例えば、DBに投入するデータを作ってもらう際にこちらでエクセルシートを用意したが、データ入力者はデータがどう使われるか分からないので不適切なデータを入力してしまう、など。
開発初期はDBのER図を作ったりGithubリポジトリのREADMEを書いたりはしていたが、非エンジニアなどのステークホルダーにも理解できるようシステムを共有できる形にすればより事はスムーズに進んだと思われる。
おわりに
スタートアップでは大きな裁量権を持って割と自由に働けたので何かチャレンジしていきたいという方にはおすすめです。
また、少人数で仕事を行なっていくにあたり、人とのコミュニケーションは非常に重要になってきます。
特にビジネス上の意思決定権は社長などの上層の方がしていくと思うので、
自分と方との相性がマッチするかどうかで仕事の満足度は大きく変わると思います。
その他にスタートアップで意識すると良い点としては下記の通り。
・ステークホルダーと対話を重ねる
・ユビキタス言語を定義する
・仕様とタスクのスケジュールは明確にする
・仕事を簡潔に説明する
・システムを図にする
ほとんどエンジニア向けの説明になってしまいましたが、みなさんもスタートアップでサービス開発をする際は上記のポイントについて参考にしてみてください。
この記事が気に入ったらサポートをしてみませんか？