過去に参加した炎上プロジェクトから学んだこと

事前面談の際に「あっこれあかんやつや・・・」と本能で感じたのですが、まとめサイトでよく見るSIer業界の実態が以前から気になっていたので、覚悟を決めて受けた時の話です。

面談時から怪しい空気が・・・

プロジェクトに参画する前に一度概要などを説明され、質疑応答などを行い、技術スタックや現状の進行状況に対するアプローチなどお互いの認識をすり合わせていく面談があるのですが、技術的な質問をいくつかしてみても「実装フローに携わってないのでわからない」という答えが返ってきました。

質疑応答が終わった時点で使用言語とFW、あとはとにかく期日が迫っていてやばい、ということしかわからない状況でしたが、妙に好奇心がでてきて参画を決めました。

経験しておいて本当に良かった

僕が参画したプロジェクトはネットの評判ほどではありませんでしたが、結果的に情報共有ツールや仕様の認識合わせ、加えて(実装ではなく要件定義のフェーズでの)API設計の大事さは改めて痛感しました。

短い期間でしたが改善を図るべく、「一週間試してみて微妙ならやめる」という条件でいろいろ導入させてもらったので、駄目だったものから効果的に作用したものまで項目別に挙げていきます。

やってみてよかったもの

Storybook

最初は「工数が延びるから非効率」「デザイナーがいないので使う意味がない」との声が挙がっていたのですが、クライアント→SE→PGと伝言ゲーム式に曖昧さゆえの齟齬が常態化していたので、クライアントの気に入らない箇所がパーツに依存したエフェクトを指しているのか、処理自体のフローを指しているのか、ステートの管理部分を指しているのか、などが明確化され、SEからは改善策や変更内容がだんだんと的確に伝えられるようになりました。

Docker

開発において一番つらかったのはコミュニケーションで、フロントエンドエンジニアとバックエンドエンジニア・SEが別会社の所属だったことでした。

フロントエンド側は実装を進め、仕様やAPIの不明点があれば逐一電話やメールで確認しなければならず、特に慣れないバックエンド開発環境の構築や管理パッケージの変更へ対応するのには流石に骨が折れました。

しかし幸いにもバックエンドエンジニアでDockerの知見がある方がいて、結果的にそれが僕にとって最大の助け舟となりました。

勉強不足であったことには変わりはありませんでしたが、おかげでフロントエンド側は環境統一が図れてコミット後に起こっていた依存関係のエラーを気にしなくても良くなりました。

その時初めてDocker使ったけど、本当にすごい。

すごさにピンとこない方は素晴らしい記事を拝見したので、こちらをご覧ください。

 

SRPというか共通レベルの認識

タスクの粒度は画面単位になっており、それだけだと問題はなかったのですが、例えば画面内のヘッダーやそこに表示されるボタンや時計などの他画面にも使用するようなパーツも各々で実装されていました。

それぞれで認識を合わせられていたのでソースコード自体はほぼ統一化されていたものの、ソースコードの重複がいくつも見受けられ、中には10000行を超えるソースファイルも存在しました。(おそらくコピペかな?)

また、完全に統一されていたわけではなく、やはり箇所に依っては多少のブレもありました。

したがってまずは共通化を図り、合間の時間にコンポーネントの作成を始めました。
Atomic Designも検討してみたのですが、今回はいくつかのパーツをまとめてWidgetっぽく切り分けることにしました。

処理やスタイルをコンポーネントに閉じ込めることで終盤の開発スピードがぐっと上がりました。

 

やってみてだめだったもの

Atomic Design

 

本家

 

Qiitaの記事をさらっと読み流す

上記でも軽く触れておりますが、検討した時点でアプリケーションに既にある程度のボリュームがあったため、流石にAtom単位から一つ一つ切り分けていくのは工数的にまずいという結論に至り、導入は断念しました。

ストア

アプリケーション的には導入した方がよかったものの、開発中盤からの導入はリソースが食われすぎるため、あえなく断念しました。(序盤に導入していなかった理由は不明)

さらにページのステートを遷移先に引き継ぐ方法がそれぞれバラバラでしたので、セッションやストレージへの保存ルールを決めることでひとまず落ち着きました。

Incoming Webhooks

Slackを使用していたので、メールの確認代わりにさり気なく取り入れてみましたが、報連相がしっかりしているところでは普段の業務連絡にアプリケーションの監視が加わり、通知の見落としが目立つようになったのですぐに撤退しました。

カオス化した原因と考えたもの

意思疎通不足

今回挙げた取り入れてよかったもの、微妙だったものなどはあくまで実装者側の周辺環境も含めた改善策でしかなかったので、改善を行った後でも目立ったもどかしさやストレスというのは、昔からの習慣に起因するものがほとんどでした。

例えば、

  • なんでもかんでもエクセルを使用する
  • できない理由やしてはいけない理由を技術的に理解する時間をとれないせいか、クライアントからの代替案への対応がその場でできず、変更が一箇所でも確定まで時間がかかりすぎる
  • スタイルは適当で大丈夫といっていても、後からなんだかんだイメージしているUIがあるのではという内容の修正が入る
  • 優先順位が仕様と認識の同期 <<< 超えられない壁 <<< 上層部への報告なため、最悪な場合、変更が決まってから共有されるまでの間にもう一段階変更が入る

こういった問題点はチーム内で少しやり方を変えたぐらいでは改善されません。

結局はプロジェクトに関わる人全員の意識改善が必要になるので、大変難しいところです。
「上流工程の方が少しでも実装者側に歩み寄ればもっと大きな改善ができただろう」と後で本音を漏らす方もいました。
僕の参画したプロジェクトではこのような形で終わりを迎えましたが、「理屈に合っている≠ユーザビリティということをもう少し理解してほしい、FWの選定論争に時間をかけないでくれ」というような逆のパターンもあると思います。

コーディング規約の緩さ

これは自戒も含めてですが、「ここまでコードサイズを縮めてやったぜ」とか「イカしたロジックができたぜ」と快感を抱くような書き方ができた時、それが単なる自身のひとり歩きでないかを再確認する必要があります。

レビューの習慣があるところだと、しっかりフィルタリングされているはずなのでかえって自信に繋がることにもなり得ますが、ないところだと可読性が低くても気づけずに後で他の人が苦しむことになります。

OSSフレームワークには必ずドキュメントが存在するので、自分の書いたコードが規約と乖離していないかを確かめましょう。

参画した開発では、おそらくセットアップから既に大きく違っており、それを力技で軌道修正したであろうオレオレ環境ができあがっていたので、フレームワークにも周辺ライブラリにも知見があったのに標準APIや関数さえ使えないといった問題がありました。

僕の事例はコーディング規約とは少し異なりますが、出来る限り公式に従うべきという教訓が得られました。

引き継ぎの粗さ

炎上プロジェクトは引き継ぎの問題も大きく関係があると思いました。

単なる主観でしかありませんが、自社開発ではないリプレイス案件などはドキュメントがないとスタートから出鼻をくじかれる流れになってしまうなと。

正直なところ、実際ドキュメントを作る時にはわかりやすく丁寧に作りたくなりますが、実装者側に経つと、どれだけ書式が乱雑であってもないよりは数段マシなので、後に自身が無関係の立場になるとしても作ったほうが良いと思います。

ただ「そんなもの作成する時間があるなら遅れを取り戻す時間に当ててくれ」という真っ向からの反対意見が上がることもあると思うのでそもそも作る時間がないところも多いと思います。

僕のところもそんな感じでしたが、タスク分担には寛容だったので、後から責任は取れないこと、どれだけ綺麗に仕上げていても、何もない状態からのコードリーディングはあるときと比べてコストが確実に大きくなるので、結果的にリソース節約に繋がること、責任の所在や原因の明確化を図れるようになることをしっかり伝えると、すんなり書類の作成を引き受けてもらえました。

作成書類は最後に拝見しましたが、「何故毎回しないのだろう」と少し疑問を抱くほど見易く仕上がってました。

最後に

実際終えてみると技術的な知識だけではなく、開発に付随する周辺知識も身についたので、結果オーライとなりました。

今まで一度も経験したことがなければ、どこかで思い切って参加してみても良いと思います。
もしかすると気持ちの持ちようで意外にも視界が更に開けるかも知れません。
(あくまでフリーランスの意見です。)

思い出したら追加していきます。