☠️

SIerとベンチャーでの仕事の仕方の違いについて

2020/09/20に公開

主語大きすぎ案件ですみません。
SIerとベンチャー(スタートアップ)2社で働いたことのある人間が、それらの仕事の仕方についてまとめてみました。同じシステムを開発する仕事であっても、風土によってこのように違いがあるという事を知って頂く機会になれば幸いです。

ちなみに、この記事はQiitadonのトゥートが元になっています。
最近、チームラボエンジニアリングに聞く、受託開発で成長できるエンジニアとは?という記事がQiita:Zineで公開されていた事にも影響されています。

話のきっかけ - 元は要件定義の話から

要件定義などのいわゆる「上流」から順を追って、原則としては逆戻りなく進める、いわゆるウォーターフォール的な作業の進め方に関しての話題が発端でした。
なぜ要件定義が必要なのか?というような話のあたり。私のトゥートを引用します…

要件定義がないと動けないひとは結構いる…
というのも、(最低)2つパターンがあって、

・能力が乏しいので、何をするかを定型的な資料でまとめられないと実装ができない
・自分で要件を正しく決める能力はあるが、合意を得ておかないとリスク的な意味で実装ができない

要件定義は合意書としての意味を持つので、ユーザーがIT詳しくない場合などは、「こういうシステム作りますよ」という合意をユーザー部門・ユーザー企業と都度都度取っていかないと、乖離がひどい事になる場合がある
(都度都度合意を取っていても、きちんと詰まった要件定義になっていなければ「そんな事言ってない」とか「ふわふわしてわからん」とかなるんだけど)

これでミスると、後の工程で動く人の工数が全て無駄になる
間違った方向に誘導しても、作業ができない状況にしても
つまり、プロジェクト推進に対する「本当の責任」がすごく重い資料になる

まー、みんな前工程に責任逃れしている、という感じもするんだけど、実際要件定義ないと設計も実装も進まない人や、それらがないと勝手な事をして工数全て無駄にしたりもするので…結構たくさん

ここに書いた事自体は、必ずしもSIer/スタートアップの間に本質的な違いは無いはずなのですが、私はスタートアップで仕事をする時は、ある程度の要件に関する合意形成はするものの、SIerの頃に作っていたような資料についてはだいぶ作らなくなりました。

その理由は、私は以下のように受け止めています(過去のトゥートより):

SIer1社、ベンチャー(スタートアップ)2社経験している身としては、スタートアップはそもそも社内では合意を取らなくて良い場合が多い。
まあ人・会社にもよるんだろうけど、例えば、管理画面の(一般のエンドユーザーが使う画面ではない)画面遷移で確認画面を挟むかどうかとか、そんなのは合意を取らなくてもよい。
ただ、そういう無法地帯で許されるのは、メンバーが『合意を取らなくてもヘマをしない』という前提なので、人を増やしたりすると、能力や考え方にばらつきが出るので、合意を取らざるを得なくなると思う。

私がSIerと呼んでいる一社目(客観的には中小開発会社だけど、一部上場企業数社と直接口座を開いていてプライム案件が結構ある)では、昔話をきく限りは最初は何も合意を取っていなかったんだけど、色々トラブルが起こって自衛の為に合意を取るようになった。
例えば、相手側の担当者がいきなりドロンして案件消えたりとか、逆に自社側の担当者が宗教にハマって変な事を言い出してドロンしたりとか、創業当初から居る取締役がいきなり消えたりとか。
基本的には、傷の分だけ規則が増える、という事だと思う。

SIerであるかどうか、というよりは、開発を軸にして受託開発をした結果のバッドノウハウ(?)の積み重ねということかな、と思っています。
一般の事業会社でも、受託開発をしたことがなければ比較的ゆるい場合が多いのかと思うのですが、特にスタートアップでは普通は客に騙されるような経験も社員に裏切られるような経験も無く、厳しいルールは無いのかなと思います。

厳しいルールには、良い面も悪い面も両方あるので、一概にルールが複雑であることが悪いとは思っていません。ただ、仕事の仕方は大きく違うので、それを見極めた上で自分自身の適性などを検討するとよいのかな、と思っています。

他にも、いくつか仕事の進め方の違いを紹介します。ただし、個人的な経験に基づくものなので、あらゆる会社の仕事の仕方がそうである、というような話ではありません。なんとなくこんな感じかな、ぐらいで受け止めて頂ければと思います。

管理業務とか

どちらも、過去のトゥートからの引用です。

SIerでの管理業務・仕事のスタイル

最初の会社では、WBS引いてガントチャートも作って報告とかを(私も)沢山やってて、典型的なウォーターフォールがベースで、社内の標準成果物に相当するものをレールに乗りつつこなす仕事がメインだった。ただ、最後の12年では、R&Dとかアドバイザリみたいな仕事を何件か取れて、作業は基本自社だけど工数精算というものを回していた。
これらは標準成果物は無いんだけど、当然合意は取りながら、しかも決断は必ずお客様にしていただく、というやり方だった。必ず議事録も取るし、メールは送る。
この辺の業務は、私の、お客様の意図を汲み取る技術とかで失敗した事もあったけど、ある程度はうまくいった。

スタートアップでの管理業務・仕事のスタイル

ベンチャー行って最初は、そもそも私はただの作業者だったのでマネジメント作業から脱したんだけど、しばらくしてマネジメントが必要になった。
でも、そもそも社風が違いすぎて、石橋を叩いて渡るSIer時代と比べると、ほんとに社内交渉ほとんど無し。
カスタマイズとかOEM案件で、自分で直接お客様にスケジュールとか要件定義とか提出した事はあったけど、お客様もそれまでより緩い事が多いし、自社サービスなのでソースを渡さないどころか先方はほとんどテストしない、プロダクトの責任は良くも悪くも自社にあるし仕様も原則こちらで決めるものだから、最低限の要件さえ満たせば社内でも社外でも合意を積み重ねなくても許容された。

最近は小規模も中規模も、お客様からの改修要望に合わせて、営業の人と仕様を相談して、文字数行で書けるぐらいの範囲で合意を取ってからスタート。
それをいくつか細かいタスクに分割して、チケットを切る。
開発担当者は、私が適当にアサインしたチケットをその日のうちに片付ける。基本はその日で、大きい場合は最長二週間とか(でも細かく分割してもらって、コミットはなるべく毎日)
ソースは確認して、当日なるべく3日でマスターにマージ。

合意の部分は、総じて、みんな物分かり良くしてもらっていて、お互いの信用で回している感じ。
もし何かあったら私がその場ですぐに直す、その意味での絶対的な責任を自分で持つ、というので回ってる

最近はうちのチームの採用面接では、実際に利用しているCircleCIやBitbucketやslackの画面を出して、こんな感じで仕事してますというのを見せていますが、特にSIer系中心の方からは、やっぱり仕事の仕方が違うんだなーという感想を持たれる事が多いです。

余談:チームラボの記述との比較

冒頭にリンクを貼ったチームラボの記事ですが、個人的には一般的な受託開発(?)とは少し毛色が違うのかな、という印象を受けました。
一般も何もないだろ、と言われればそうなのかもしれませんが、あの形だけが受託開発ではないと思うので、その辺の比較・感想を少し述べます。決してチームラボさんの事ではなく、業界一般にこうではないかな、という印象についての話ですので、その辺りはご注意ください。

受託開発のイメージとしてよく抱かれるような、「この技術を使ってこのように作ってください」という案件は、実は少ない

これは、プライムで入ればその場合が多いですが、プライムが既に提案したあとで流れてくる案件などが世の中には多数存在しており、これはそのようには行きません。
また、既存システムの保守案件(を当初の開発元以外がやっている時点ですでに炎上案件の可能性がありますが…)の場合は指定は不可能です。

案件ごとにリーダーやメンバーといった役割もシャッフル

これは、ユーティリティ人材についてはそういう場合もあると思いますが、役割をシャッフルできない人もいます。多くの受託開発の会社では、中核人材は確かに何でもできるユーティリティソルジャーかなと思う一方で、末端(?)の作業員は、イメージ通りのシャッフルはできないと思います。
悪い意味でのシャッフルの事例は、いくつか聞いた事がありますが…(非エンジニアの業務にあてられるなど)

AWSを利用していて比較的自由に触ることができるため、エンジニアとしての幅が広がった

会社資産は、どちらかというと自由に利用することは難しく、また権限も一部の中核人材に限定されがちであると思います。(もちろん会社による差はありますが、ISMSやPマークなどを取得していると、運用上自由に使えない場合の方が多いと思います)

キャリアにSIerが含まれていることについての、自分自身の受け止め方

そもそも、私はあまりキャリアというものについてのこだわりはなく、自分が最前線でコードを書き続けられればそれでいいかなぐらいの思いですが、SIerで過ごした時代についてどう受け止めているか?という事について。
基本的には、SIerで働いていなければ今の自分はなく、いきなりスタートアップで仕事を始めたのでは決して身につかなかったであろう事が沢山あります。実際に起業をしたときも、SIer時代に見聞きしていた信じられない出来事が本当にたくさん起こって、様々な落とし穴の存在を聞いていてよかったという事が山程ありました。
また、私は非常に雑な人間なので、テストやまともなシステムの作り方などは、SIer時代にきちんと向き合っていなければ身につかなかった自信があります。総じて、今の自分を支える技術であり根幹であると思っているので、決してSIerがスタートアップに劣るとか、そういうような事は決してないと思います。
SIerの方はもっと自分の仕事に自信を持って欲しいです、ただ一方で、環境的に恵まれない部分が多くあることもわかるので、それは非常に同情します。

むすび

非常に断片的な情報ではありますが、SIerとベンチャーの間でこのような差がある、ということの一例として参考になれば幸いです。
ご質問・ご意見・その他何かあればコメントでお寄せください。

Discussion