なんとかなるを支える技術
※一部の組織に不利益があるような内容を含む可能性があるため、個別の組織・事象を特定できないように曖昧な表現を用いていますが、突然消すかもしれません。
副業でとある炎上プロジェクトをお手伝いをしている。 NPO活動で、3年ぐらい一緒に活動していたエンジニアの友達から、短期間でヘルプどう？と声をかけられたのがきっかけである。 その彼もヘルプで参加している。 なおヘルプに入ってからの稼働でいうと2週間で土日中心の8日間稼働で、実働40時間ちょいぐらい。 まだプロジェクトは途中だが、勝手に普段のチームとの違いや、違和感を言語化してみる。
なおお手伝いしている会社/プロジェクトは以下のような特徴をもつ。
- 10人ぐらいの会社(うちエンジニアは3,4人ぐらい)
- フルタイムのエンジニアはたぶんいなさそう
- 受託開発を中心で行っている
- 自社のプロダクトがあるわけではなく、フルカスタマイズ開発
なお自分は本業で現在以下の特徴の会社に努めている
- 300人ぐらいの会社(エンジニア100人ぐらい)
- 自分は、自社サービスの運用を担当
- 会社全体でも、自社サービスの開発・運用がほとんど(レベニューシェアの協業モデルがたまにあるぐらい)
- 会社がエンジニアリングに対してとても理解がある
- スゴいエンジニアがいっぱいいる
- 定量的にはうまく言い表わせないが、人間的にも技術的にも尊敬出来る人がたくさんいる
本業の会社とは全く別のチーム・会社で働くことって、実は意外と学びがある。 もちろんもう1回学ぶ必要があるか？といえば今回のケースに限っては自信をもって、NOと言えるｗ
本業の会社で自分がふざけて言ってた炎上プロジェクトという言葉は、全然炎上なんかしてないなと本当に思った。 新卒のときに、日報で炎上とかネタで言ったら、本当の炎上みせてやんよって！って先輩が盛り上がったのも納得。
今回の学びを言語化すると、以下のような感じっぽい
- お客さん商売において炎上すると、お客さんのレビューというごく直近のマイルストーンをクリアすることだけに目がいってしまい、プロダクトの改善が対処療法的になり後手後手の対応になってしまう(とりあえず◯◯できれば今はいいから〜みたいのが増える)
- 炎上したプロジェクトには、いくら人を投下しても全く速度上がらない。バグ改修→エンバグのスパイラル
- 炎上させないチームメンバーにどこから教えていこうか悩む感じ
- javascriptの中でphpでDBアクセス(ORMライブラリ使ってるけど、さすがにねぇ・・・という気持ちw)
- 心理的安全超大事
- 炎上させた人は本当に自業自得としかいえないほど酷い仕事ぶりだが、フロントでお客さんから詰められてる人から、詰められてて10日間家に帰らずホテルとか本当に可哀想。
土台がグラグラの上に何を積み上げてもダメだなというのが、本当にダメなケースを見ることで、リアルケース見れてなるほどっと思えたw がっつり開発工数としてコミットしていく余力はないとは思うけど、長期的にみてエンジニアリングに関する部分でお手伝いできれば、自分としてはそれはそれで学びかも?とは思える部分もある。
本業で努めている会社だと、ヤバイにおいがすれば、PullReqeustの段階で協力潰してるなと思った。
なんとかならない プロジェクトを通して、 本業でこれまで意外と なんとなかなる と思っていることが多かったけど、実はそれはとても多くのものに支えられた上で成立しているんだなというのをとてもとてもとてもリアルに実感した。
本当に大変になると、なんとかならなくなるという経験を通じてw
