社内開発チームでのプログラマーの生き方

正直であるためには、重い代償を払うことになる。

このサイトはいつもITに携わる人が経験する現実を記述しているので、今回は私が開発チームで働いた経験について見ていきたいと思います。以下は、私が各社で経験した一般的なことです。特定の企業に関連する経験はなく、必ずしも批判になるものではありません。

企業は勤勉で積極的な人材を求めない傾向がある

たくさんのアイデアをお持ちの方イノベーションを起こしたいですか？あなたのチームが解決している、会社の半分を悩ませている複雑な問題に対して、エレガントな解決策を見つけることが好きですか？セキュリティ、ソフトウェア設計、プロジェクトのボトルネックを見つけることの重要性を理解していますか？

開発チームではずっと不幸になるんだろうな。

チームワークは、私が最近よく悩んでいることです。つまり、具体的にはその中で泳ぎながら、自分にとってまったく直感的でない原則を理解しようと努めているのです。

• チームワークとは、チーム全体が理解できる解決策を開発することです。ベストではないことが多い。エレガントであることはほとんどない。実は、常に非効率なのです。しかし、チーム全体がそれを理解し、長期的に管理できるというクールな利点があります。これは非常に重要な考え方です。というのも、大きなプロジェクトでは、企業として人を使ってスケールアップできるし、資金も十分にあるので、効率的でなければならないというプレッシャーはそれほどないのです。部分的に壊れていても、これまで知られていなかった制約があっても、時間通りに納品することの方がずっと重要です。それは、たとえ不完全でも、明日提供するソリューションの方が、100％デバッグされた1年後のソリューションよりも、顧客にとってずっと価値があるという考えと関係がある。
• イノベーションを起こし、物事を押し進めることは、むしろ間違っている。それは、企業で働く人の中には、家庭を持ち、営業時間内しか働きたくないという人が現実にいることと関係があります。そのため、人が新しいことを学んだり、試したりする時間は限られています。本来、企業は人の労働時間の中に、将来の仕事に活かせる教育や育成を詰め込まなければならないのです。その結果、決断や新しいことを学ぶのが必要な時期に先延ばしになるのは興味深いことです。私としては、このやり方は理解できますし、とても納得できるものです。私も社員がいたら、大雑把でいいから転職したいという人よりも、例えば15年会社に残ってくれるような落ち着いた人がいいと思いますが、それはチームの犠牲になってしまいます。確かに集団的解決は個人的解決と同じにはなりませんが、だからといって悪くなるわけではありません。

私のような人間は、問題や対立の原因になる可能性があります。そう考えると、かっこいいですね。

コードレビューの際は、客観的なエラーを探すだけでよい。

どの会社にもコードスタイルのルールがあります。残念ながら。最初はとても腹立たしかった。

.NETのような成熟した言語を使用する場合、コードスタイルのルールはより類似している傾向があります。その時初めて、PHPやJavaScriptがまだ世の中に存在していることを知るのです。特にPHPの件は、ちょっとイライラすることがありますね。PHPは非常に成熟した言語で、多くの素晴らしい機能を備えていますが、私の経験では、企業ではそのポテンシャルの3分の1程度で使われています。理由はさまざまで、惰性でやっていることが多いようです。

この点で、私は長い間、コードレビューの手続き的な解決策を模索してきました。私は長い間PhpStanで遊び、その周辺のアイデアを追いかけてきました。PhpStanの基本的な考え方は、いつかは必ず発生する客観的なエラーのみを強調することです。PhpStanを探求し、次のレベルに持っていけばいくほど、それがいかに真実であるかを内部で検証することができます。

チェコの企業の半分くらいにPhpStanが導入されるといいんですけどね。実際には、レベル4やレベル5の企業が最も優れていると思います。

つい先日、私は、独自の開発チームを持っていて、レベル0（あらゆるアプリケーションで期待されることを制御するレベル）にさえ合格しない、実際に稼働しているプロダクションアプリケーションが存在し得るかどうかを考えていました。すべてのクラスと関数が存在すること、ファイルにパースエラーがないこと、などを確認します。そうそう、そういうアプリケーションもありますね。しかし、長い目で見れば状況は改善されつつあります。うまくいけば

だから、codereviewでも同じようなアプローチをとっています。客観的に見て必ず間違っているものしか報道しない。何かが間違っている、でもやはり対処が必要なほど大きな問題ではない、という程度の誤判断によく遭遇します。多くの問題は、慣習で解決されたり、「リスクは小さいから治療しても意味がない」と断言されたりします。

私は、データ型（複合型も）の欠落は致命的なバグだと考えています。そして、テストとダンプがあることを理解しました。

この部分については、具体的な結論は出ていないと思います。ただ、主観的な意見が多く、お互いの誤解の元になる可能性が高いので、掲載は見合わせます。長期的に見ると、私はコードレビューができないという結論に傾いています。私が厳しすぎるのか、それとも慈悲深すぎるのか。何が本当に重要で、何がそれほど重要でないのか、一般的なレベルではわからないのです。他の人がどのようにやっているのか、かなり興味がありますね。私も使える答えはまだ誰も教えてくれません。

カスタム開発にはお金がかからない

代理店を持っていて、カスタムウェブ開発をしているのでしょうか？他の企業のために大きなプロジェクトをしているような規模でなければ、おそらくいつか存在しなくなるでしょう。

こうなってしまうのは、カスタムプロジェクトに対する資金繰りが悪いからです。買い手の方が得をする契約内容になっていることが関係しているのでしょう。実際、ほとんどの代理店は残酷なまでに資金不足で、オーナーの実益だけを考えている。

社内で自分の会社として開発する場合、1ヶ月の納期遅れはそれほど問題ではないでしょう。代理店としては、1ヶ月までに仕事を納めないと、その言った月は仕事でゆっくり寝ていることが保証され、一貫して健康を害し、クライアントは電話やチケットに向かって悪態をつき、もっと早くならないかといつも言われ、報酬としてやはり契約上のペナルティを支払うことになります。そうしないと、クライアントはあなたに信頼できない請負業者というレッテルを貼り、どうせこれ以上良くならないのだからと、他所へ行くことを考えるかもしれません。

しかし、それは私が実際に知っているゲームのルールであり、私の予算に穴をあけることになったのです。

請負は、おそらくITの中で最も複雑なビジネス形態である。請負はしたくないんですね。請負は身を滅ぼす。週末も、夜も、クリスマスも、電話がかかってくる。仕事の半分は、給料をもらわない。できもしないミスを謝ることになる。今年3回目の休暇に行った友人たちのストーリーテリングをInstagramで見ている一方で、土曜日の午前3時にオフィスでクライアントのプロジェクトを仕上げ、どうせ月曜日には契約内容が多くてやりきれないと叱られるのだろうと思っている。人は休暇や病欠を取り、あなたはその人の代わりに働くことになるのです。あるいは解雇される。そうすれば、家賃を払うのが楽しくなりますよ。

でも、また、いろいろと勉強になるんですよね。というのも、ちょうどプレッシャーのかかる時期で、次回は同じ時間で少しでも多くの仕事をこなせるように、学習と効率化を図らなければならないからです。悪い点は、企業が興味を示さないため、その知識や経験を他の場所で本当に生かすことができないことです（上記で説明しました）。

幸いなことに、これは2019年の話なので、まだまだ先の話です。

理想郷はありえない

自分が楽しいと思うことをやっていれば？そうなんですか？:D

割合の問題なんでしょうけど。100％充実した仕事というのは、おそらくないでしょう。10年間、強引に学んできたことを、内心では「できる」とわかっていても、「できない」と説明する人が必ずいるはずです。

一方で、自分の個性をある程度否定する分、それ以上のものを持つゆとりを得ることができます。週末の時間、健康、自分のための時間、安定した環境、などなど。長い目で見れば、それが維持できないことも明らかです。

いろいろなことを試して、他の人がどのように持っているかを直接体験できるのがいいですね。開発チームでの仕事は、カスタムの仕事と比べると非常に退屈なものです。

もはや、最良で最速の解決策を見つけることではなく、コラボレーションが重要なのです。コミュニケーションや感情の向上、そして何より人間らしさを身につけることです。それも、大きな価値です。