大手Sierがスタートアップでシステムリプレースしたら

  フリーランスCTO >     炎上のシステム現場 >  

前の案件ではエンジニアの経験がない人がCTO的な役割をして炎上して失敗していたので、やはり、エンジニアの経験とりわけSierの経験がある人がCTOを担った方がプロジェクト成功するのではと思ってたのですが、今回の案件は元SierがCTOを務めても炎上していたので、どうしたものかなぁって思いました。

改めてCTOの人選は超重要で且つ難しいなっと思いました。

• 1.QAチームの存在
• 2.PMOの存在と小松のポジション
• 3. 企画の要員
• 4.VueJSをこねくり回している
• 5.API, フロントエンドSPAの構成
• 6. レポジトリ一つで動かないシステム
• 7.開発環境
• 8.テストコード作りすぎ
• 案件を終えて

1.　QAチームの存在

アジャイルではなくて、ウォーターフォールになってしまう要因にQAチームの存在があるかと思います。

QAチームがテストをする時はどうしても仕様書を見て理解してからテストすることになるので精密で詳細な仕様書が必要になってきます。

QAチームがいない場合は要件をいう人（企画）が開発実装後に確認して終わりなので、自分の期待通りかどうかは少なくとも要件を出した人の頭の中にあるはずです。

なので、仕様書を書く必要がないです

開発側に向けて要件を伝える手段として仕様書を書くことはあります

しかし、QA用ではないので内容がわかればいい程度かと思います。

ややこしいところはチャットで補えばいいかと

QAチームがいることによってのでメリットはデグレを検知できる所にあります。

企画の人が自分の要件を満たした機能の確認は当然すると思いますが、その開発のせいで確認以外の機能がデグレしてしまうなどのケースでは企画の人の確認ではどうしても不十分になります。

QAチームがいた方がデグレのままリリースする可能性は少なくなります

というところがスピードとクオリティーのバランスかと思います。

でもやりようによってはデグレを防ぎつつ生産性を上げる方法はあります。

一つはプルリクエストを確認している時に開発者の勘所で気づく事もできます

しかし、確認する開発者のスキルに左右されます。

もう一つは、オブジェクト指向は古いの記事に取り上げたようにリクエスト・ページ単位で独立したクラス・機能を作れば、影響範囲が抑えられデグレのケースも減らせます。

なので、やはりオブジェクト指向は古いの記事どっからどう考えても正しいと思うのですが、世間一般的には受け入れられていない状況ではあります。😢

2. PMOの存在と小松のポジション

前述の理由でドキュメントを書く量が増えるためPMOの存在意義はありますが、QAチームをなくせば、必然的にPMOも不要になります。

QAチーム用の詳細な仕様書の作成も不要です。

それに、QAチームを効率よく回すためのスケジュール調整も不要になります。

そもそも「WEB系企業でPMOがあるのって珍しいですね」って言われた事もあります。

加えて、この時の小松のポジションは企画という対抗勢力の最前線に立たされるスケープゴート、かませ犬、トカゲの尻尾的なポジションに感じました。

前任者が２ヶ月で辞めて、その前の前任者も２ヶ月で辞めてる事実からも伺えます。

面談の時に把握しておけばよかったです。

面談の時に体制図を見せてもらった時は、フロントエンドチームとAPIチームを束ねるポジションでその上に統括の自分の上司（クライアント）というポジション

今思えば、じゃぁ、統括の人がフロントエンドチームとAPIチームを束ねればいいのにって思うような組織体制です。

その体制図から、フロントエンドチームとAPIチームにはマネージャー不在なので、今回お呼ばれしたのだと聞いていました。

ところが、参画して発覚したのは各チームに既に１年以上も在籍しているマネージャーがいました。

そのマネージャー達はコーディングの履歴がないですし、プルリクの承認履歴もほとんどなかったので、まさにPMOというポジションでした。

PMOの上にPMO？？？

となると、この両チームの連携がうまくいっていないからスーパーPMO的なポジションでAPI・フロントの連携をうまくいかせるってポジション？と推測しました

その想定で引き継ぎ中のスーパーPMO的な存在であるはずの前任者も入れてのマネージャーミーティングに初めて入った時、衝撃を受けました。

そのスーパーPMOであるはずの前任者がフルボッコのボコボコに詰められてました。

内容は
スケジュールの引き方
ミーティングの入れ方
ツールの使い方
などの理不尽な指摘を大人数のミーティングでされてました。

そのミーティングでAPI・フロントのマネージャーにサポートされて、そのミーティングは終わりました。

管理する人たちから管理されているというおかしな体制。。？？

その時点ではじめてわかったのですが、自分が想定していたポジションは

• 開発のサイクルを変更
• 組織体制の変更
• システム設計

などのポジションかと思ったのですが、なんて事ないただのスケープゴートでした。

そんなボコボコに叩かれていたので、案の定数週間後に前任者は離任することになりました。

その引き継ぎ先が小松となり、スーパーPMO（スケープゴートでフルボッコ）のポジションを引き継ぐ事になりました。

流石にフルボッコされるとストレスは溜まります。

「要求と要件の違いはわかってんの？」

みたいな詰められ方は「はぁ？」どうでもいいやんって思ってしまいます。

 

3. 企画の要員

企画は企画でスケープゴートのポジションを作って開発チームとの最前線に立たされていました。

自分も企画側の立場になった時があったので、開発チーム内で企画側の悪口を言って、公のミーティングでは企画のスケープゴートの指摘をして落とし所にされている事がかわいそうで仕方ありませんでしたね。

企画のスケープゴートさんが一生懸命に考えて作った申請ページの件でも、CTOが「Google Formでなぜ無理なのか？」って質問されたら、スケープゴートさんの立場では何も言えなくなってしまうのは当然かと思いました。

全ての要件を社長に聞くのではなく、末端の現場で細かい要件は各々自分で判断して決めてほしいというのはわかりますが、いきなり最前線に立たされていてスケープゴート感はいなめません。

開発チームと、企画やマーケティング、営業などと意見が合わない事ってどの現場でもよくある事ではあります。

この案件の生産スピードが遅い原因が後述する技術選定やシステム設計も原因だという事実があるのですが、それを認めたくはなかったのだと思います。

なので、なぜ遅いの？の回答としては「チーム間のコミュニケーション」で終わる事ばかりでした。

本当はそうじゃないんですけどねぇ。。

その案件の社長もWeb系企業でマーケターとして勤務した経験があるので肌感で遅いというのはビンビンに感じているらしく、常になんでそんなに遅くなるのかと怒っていました。

１ページの申請ページでエンジニア４人かけて１ヶ月かかっているので、そりゃ遅いって誰でもわかる話ではありますがw

4. VueJSをこねくり回している

Vue3なので、Reactみたいにコンポーネント化して管理するのがベストプラクティスと一般的には言われてますが、ただ複雑になってるだけのように思います。

コンポーネント化の仕組みだと、新規参入者がコンポーネントを知っている古株のエンジニアにお伺いをたてないといけなくなってしまいます。

どのコンポーネントを使ってどのように実装するのか、などなど、お伺いをたてないようにするにはstorybookなどのドキュメントが必要になってきちゃいます。

オブジェクト指向は古いの記事の中でのオブジェクト・クラスがここでいうコンポーネントで小松の設計思想とは相反して世間一般的なモダンな開発ではこのコンポーネントを作っていくという開発スタイルが流行っています。

オブジェクト指向古いの記事でも述べていますが、改めてメリット・デメリットを述べると

• メリット

コード量が少なくて済む

いい設計をした場合で且つ同じページで複雑な処理をする時にコールバック地獄に陥らなくてもいい

• デメリット

コンポーネント作ったもん勝ち、使う側は作った人に聞かないとわからない

既存改修の影響範囲が大きくなる

ハイスキルエンジニアしか参画できない

ある日の事、input typeがどこかの時点でtextからnumberに変わって

・いつそうなったのか教えてほしい
・textに戻してほしい

その要件がめちゃくちゃ難しいって話がありました。

<input type="number">
を
<input type="text">

にするだけなので、何が難しいのか？って思いながら小松がデバッグして5分くらいで直そうと思ったのですが、どのソースコードにもnumberにしている箇所が見当たらず挫折した時がありました。

たかだかinput typeの変更でさえも容易にできない状況にあると感じました。

上記のような状態が怖かったので小松がシステム設計をする立場の時はVueJSは仮想DOMのHTMLベースのテンプレートなので極力VueJSは使わずに済ますように指示していました。

それでもエンジニアからすればHTMLのタグ打ちとVueJSのコーディングをどちらがしたいのかというと明らかにVueJSのコーディングの方が楽しいですし、経歴的にも単価が上がるのでついついVueJSのコーディングをしがちになります。

これはCSSを使えばJSより速度も上がり難易度も下がるのでお得なのにJSでコーディングしたがるという記事と似てる内容だと思いました。

結果HTMLのコーダーであれば時給1200円で雇えばいいところをVueJSのSPAの設計開発ができるエンジニアになると月単価が80万円ぐらいに跳ね上がります。

エンジニアファーストだとそうなってしまいますが、社長の立場ではその内情がわからないです。なので

• お金がかかる
• 生産スピードが遅い
• 採用できない

ってなってしまい、社長にはかわいそうだなって思います。

このエンジニアがしたいもしくはキャリアのためにシステム設計がなされているってこれからの日本のIT企業の大きな課題かと思っています。

影響力のある人が今の方向性ではろくなシステムが作れないって訴えないと本当にヤバい事になりそうです。

小松がここ２年ネットで訴え続けても流れを変えるには至ってないです。😭

 

5. API, フロントエンドSPAの構成

最近の流行りであるこの構成ではどうしてもAPI,フロント間でAPIの定義をしないといけないためその仕様書が必要になってくる

API定義書がずれてたら、フロント、API双方に共有しないといけない

ある要件の追加、変更があっても結局フロント、API最低2名の共有が必要になってくる

他のデメリットとしては、エラー処理、リダイレクトなど、認証処理などはAPI側、フロントエンド側両方に実装を入れないといけないので、二度手間なところもデメリット

従来のMVC(Laravel,Rails,Django)ではControllerからViewに変数にして配列だろうがなんだろうが渡していて1人称で開発するのが当たり前なので、ViewとControllerの間の変数定義所みたいなドキュメントを書く必要性が全くない

要件が変わってても担当のエンジニア一人に共有するだけなので、従来のMVCの構成の方が変更には強い

とはいえこのAPI,フロントエンドの構成が今の流行り・主流ではあります。

分業して、各々の得意な分野、APIであればDB、キャッシュ、負荷対策が得意

フロントエンドであればUI、UXが得意などで最適化した人材配置ができるのがメリットと一般的には言われています。

他の理由としては、大企業で多くのエンジニアの人数でシステムを作るとなる場合も分業しないといけないので、こういった手法が向いていると言われています。

大企業の方が資金も多いので、大企業が作るような大規模なシステム設計が単価が高くなり、その大規模なシステムのフロントエンドであったり、バックエンド、インフラなどの各エキスパートとして雇われる方が単価が高くなります。

露骨に言うとお金がかかるシステム設計をした方が経歴的にプラスになるという事になります。

何度もしつこいかもですが、この現状は本当にヤバい事かと思います。

そうなると、不思議な事にフルスタックでシステムの全てを把握している人材よりも、フロントエンドしかできないエンジニアの方が単価が高くなってしまいます。

小松ももう１０年以上前から、一人でシステム構築できてインフラからフロントまでできてそれが売りではあるものReact + Typescriptのエキスパートと単価が同じくらいです。

なので、この流行りのSPA構成は会社の利益を考えた場合どうかなって思うのが正直なところです

 

6. レポジトリ一つで動かないシステム

クリーンアーキテクチャという名の下、一つのレポジトリで動く設計ではなく、複数のレポジトリに分けてそれを落としてきて初めて動くという構成

ブランチのバージョンも各レポジトリに合わせないといけないのと、何かあった時のデバッグも本人しかできない構成

前述した申請ページでも３つ以上のレポジトリを改修しないといけなくなります。

慣れればいいだけかもですが、domainレポジトリがSQL中心で〜〜とか新規参入者からすればその分時間はかかってしまいます。

 

7.開発環境

開発環境はDockerでローカル開発して自分自身で確認してデフォルトブランチであるdevelopにマージして、誰かが手動でステージングに上げるといった流れです。

ステージングに上がった状態で要件を出した企画スタッフ、QAチームが確認するという流れ

要件を出した人が確認するまでに本流であるdefaultブランチにマージしないといけないって流れがあまりにもウォーターフォールすぎるかと思います。

本流にマージするくらいなので、その時点でかなりの精度を求めないといけなくなります。

要件を出す人とちょっとした文言やUIを開発サーバーに上げて確認して、すぐ修正っていう事ができなくなります。

サーバーはdevelop, staging, productionとあり、各々にDBが用意されて贅沢に使っているのにちょっとした確認ができないのがあまりにも勿体無いです。

AWSの持ち前のサーバレスなので、WEBサーバー上で.envを切り替えてこの機能の場合は本番データでテストしてみたいって事もできないです。

そもそもネットワークで分かれているためです。AWSでいうVPC

当然のごとく確認したいためにDevelopを増やしてほしいという議論があったときはもう一つdevelop1,2など一つ追加するだけで、月30万円かかるそうです。

それで、developサーバーの追加は途切れました。

さすがクラウド界のメルセデスベンツ、高すぎます。

自分がよく作る開発環境はVPSで環境を作って、各開発者ごとにポートとディレクトリ、nginxのconfigファイルを作成します。

そうすればgitのマージをする前から要件を出した人にそのポートのURLを渡せば確認ができるので、とても便利がよくで生産性が高いです。

そして、無料です。

インフラ担当の手間も不要です。

環境構築も既にサーバーがあるので不要です。

しかし、AWSでもなければサーバレスでもないので、人気はないです。

みなさんに合理的に考えてもらいたいです。😭

8.テストコード作りすぎ

テストコードは作った方がいいけど、なかなかてをつけれてないって現場が多いかと思います。

テストコードを書くとテスト自動化ができて、バグが発生しづらくなると言われています。

実際ここまでテストコードに徹底した現場は初めてですが、再修正が少なくなったかというとそのようには見受けられません。

システム的なバグ自体は少なくなったかもですが、再修正が必要な条件って単純なバグはむしろ少なく要件変更であったり、SQLやDB設計のミスの方が多いのではと思います。

そんな限定的な部分をカバーするだけのために工数を増やす必要があるのかが疑問です。

テストコードを書かなくてもコードレビューでほぼ補えるのではと思います。

実際にゴッドクラスの修正が入ったり、そのクラスを使わずに違うクラスを使うような場合があって、相当数の時間がその修正に費やされました。

テストコード効果を発揮するケースは新規参入者が間違いやすい部分をテストコードにしてCIで引っ掛けて気づかせるというケース

コードレビューするその現場のチームリーダー的存在の人が休みの時でもそのミスに気づかせるっていうメリットはあるかと思います。

それでも効果は限定的なのは否めないかと思います。

 

案件を終えて

今回の案件は元大手Sier出身の方がCTOで人柄はよかったのですが、規模の大きいリプレース案件を経験もないモダンな構築をして失敗したいるように見えました。

モダンな環境が流行っているので、技術選定としては間違いではないのかもしれませんが、現場社長の「なんでこんなに遅いの？」の原因が元Sierが無理してWEBでこのモダンな環境を作ったからというのは皮肉だなと思いました。

リプレース前がLaravelのMVCでシンプルなので、元々の目的はリプレース後に開発スピードを上げるためっという目的だったと思いますが、リプレース前に戻した方がいいんじゃないかってぐらいの生産性なので、現場の社長はかわいそうだなって思いました。

それに加えてSierならではの組織体制だったので、より遅くなってしまったのではと思います。

QAチームないし、PMOチームが存在しててお金を贅沢に使う事に慣れてる人がスタートアップでは炎上してしまうのかって思いました。

by プログラマーこまつ