前置き
- 全ての会社、プロジェクトにおいて前提条件と置かれている状況は異なります。これはあくまでも自分が体験した1つの例ですので、自分の所はそうでは無いというのであれば、それはそうなのでしょう。
- あるベンチャーにおいては、ビジネスの速度こそが重要である。
ある組織において共通の目的を持っている場合、肩書きというのは何に重きを置いて問題解決していくかを示すものであり、ソフトウェアエンジニアはエンジニアリングに重きを置いて目的を達成するロールである。ただし、共通の目的を達成するというミッションが前提になっている事を忘れてはいけない。
時として「俺(私)は目的を達成するためにXXをやろうとしているのにそれを阻害する行動を取られる」と文句を垂れる人間が居ますが、それはその手段が相当な悪手か、そもそも共通の目的を共有出来ていないのが原因です。
本題
さて、タイトルに書いた、速度を優先する事で品質が疎かになるのは正か否か。これは端的に言えば程度問題なので正でもあって否でもある。
ベンチャーにおいて、スケジュールが十分に妥当であること（まだ何も決まっていないが明日までに〇〇を出したいとかいうアホな事案で無ければ）を前提にすれば、ビジネスの速度にスケジュールが間に合わないのは技術力不足であると私は考えています。
スケジュールがタイトな場合に取る選択肢は幾つかあります。
- スケジュールをずらす
- 機能を削ぎ落とし、段階的なリリースにする
- ソフトウェアの品質を落とす
最初に書いた前提より、1は無し。通常は2を選択する事が多いが、削ぎ落とすものが無い場合は3を選択する事になります。
ただし、こんな事をしなくても出来る人は出来てしまうものです。それはその人が超人だから出来ているのでは無く、日々の積み重ねがあるから実現できるのです。
日々の積み重ねとは、何かあった時に普段からモニタリングしていたり、ある程度予測して準備したり、仕組みを用意しておいたりする事です。何かの案件を小耳に挟んだときに、自分は関係無いと思わずに当事者意識を持って準備をする事です。
Productionに出しても良い品質を80点以上とします。
時として間に合わない時は管理職判断で60点でも良しとする事はあります、ビジネスを優先した結果そうする事もあるでしょう。ですが普段から60点や40点の仕事をする人間に対して40点でも良しとするのはナンセンスですし、絶対値基準として40点でリリースという事自体がナンセンスです。
良く着地優先なのでという理由でテストを一切書いていなかったり、そもそも筋が悪いプログラムのPullRequestがあります。普通にやっても人によっては余裕で着地出来る案件を、着地優先という理由で20点や40点で着地させようとするのは、ソフトウェアエンジニアとしての職務を全う出来ていない事になります。実力不足、技術力不足である事をスケジュールの問題に挿げ替えているだけです。
それを着地優先だったので良しとする文化は、ソフトウェアエンジニアとしての成長を妨げる事になり、能力の凹凸がより歪になり、延いてはエース/シニアエンジニアが尻拭いをする時間に追われ、組織としてスケールできなくなる構図が出来上がります。
これで辞めていった優秀な人材を何人も知っていますし、実際に見ています。
また、1カ所に権限を集中させるとミスジャッジが発生した時、議論の余地が無くなり、さらには議論をしても意味が無くなるので、そもそも議論をしなくなり、健全な体制にはなりません。能力と権限を対等に分散させれば上手くいくとは限りませんが、少なくとも同じ方向を向いている限りは上手くいかなかった例を知りませんし、集中させる事によって悪いことが起きた事例を何個も知っています。そして、また後者が発生したかと思う度に、権限が集中していると介入余地がないので改善する余地が無く、疲弊していくわけです。
リスクテイクについて
60点で出す時はリスクが存在します。そのリスクをどのように扱うのかは大事な事です。
レースを例に挙げると、各種モニタリング、ガードレールやタイヤバリア、医療チームや救急車の手配の準備が万端であるからリスクを冒せるのです。
エンジニアリングも同様で、こういった何かあったら分かるようにする、何か起きたらそれに対処できるように準備しておく、といった保険があるからリスクを取れるのであって、保険をかけないやり方はただの無謀である。
こういった日々の積み重ねによって品質は成り立っており、何かあった時になんとか出来るように準備を積み重ねているのです。
原則について
金曜日にデプロイするのは禁止という原則が多くの会社にはあります。正確には、休みの前に初めて動くコードが無いことにするです。
これに対して文句を言う人が居ます。それだと着地出来ないとか、新機能をガンガン投入出来ないとか。プロジェクトのフェーズにもよりますが、あくまでも原則なので別に守らなくても良いのです。
ただし何故このルールが必要なのか、原理を理解しないで文句を言うのは筋が悪いです。
ルールが出来るのには何かしらの事象が蔓延っているからです。
金曜日のデプロイをする人間が、いつも40点や60点のプログラムを出しておりリリースの度にトラブルが発生させ、普段からアラートを見ている訳では無く、週末にアラートが上がっても他の人が対応しており月曜日になっても特に言及する事は無い。きちんとしたポストモーテム(振り返り)はせずに何回も同じ事を繰り返し、場合によっては不具合が発生している事に数週間気が付いていない。
このように何かあっても率先して自力で対処する事は出来ない（しない）人間に、金曜日デプロイを許可できますか? という話なのです。
何かあったら真っ先に対処しますという言葉も、普段の行動により信用力が伴っていないので、全く信用する事が出来ませんし、事実何かあってもその人間が対応しているのを見たことは殆どありません。真っ先に対応するという言葉だけでオンコールのローテーションに加わったりしているわけでもないのですから。
この原理を破っても良い人間も居ます。上記に挙げた行動とは逆で、スケジュールを殆ど守っており、品質も高くそもそもトラブルが殆ど発生していない。普段から真っ先にトラブルシュートをこなしている人間であれば、「何かあったら自分が対処するのでリスクを承知で反映します」という言葉にも信用が持てます。
このようにルールが出来るのには理由があり、文句を言う人間というのはそのルールが出来た原因である事が多いのです。しかしながら原理を理解していないため、自分で自分の首を絞めている事に自ら気づいておらず、どうでも良いルールが追加され、真面目にやっている人に迷惑をかけるのです。
大事な事は
最初から上手く出来る人はいません。何回か失敗を繰り返しながら成長していくものです。
何回も失敗している人は、振り返りが出来ていないのです。振り返りをやっても形だけでやっており根本原因を精神論で片付けている事が殆どです。
この様な状況に遭遇したとき、次からはどうするかを考え、対策を講じる事が大切です。何か失敗をしたのであれば精神論ではなく仕組みを持って解決していく必要があります。単純に実力が足りていないのであれば実力を付けるしかありません。
次どうするかを考える事を蔑ろにする組織/人間は、同じ過ちをひたすら繰り返し、信用を無くすだけではなく、周りの人間を疲弊させます。
最終的には、意識の高い人間やエース/シニア級の人材を何人も流出させる事に繋がっているのです。
まとめ
集中した権力の暴走は、ある領域の今までの仕事/成果/信念を踏みにじる行為に捉えられ、完全にやる気を無くします。