それは縦社会崩壊の一つの課題かと

全てのRubyエンジニアはだいたい糞である

カバレッジが100%で打鍵でエラーがでるってことは、実装者半分、全体の指揮をしている人間が半分の責任ではある。が、同じ事はPHPでもPythonでもおきてる。なので、CTOが本当に文化を創らないといけないんだよね。

2016/06/20 13:28

よんだ。

主語が大きくはあるけども、それを除くと現実に起きていることで、特にウェブ系では顕著になっている課題ではあります。

理由は単純で、昨今アプリケーションを作る事自体はそれほど資源の確保も言語の習得難易度も低く、作るだけであれば正直自分ひとりの組織から開発チームとして開始できるという状況で、そのため、組織に『文化』がないところも多くあります。

昔の開発は、そもそも資源の確保のコストが高く、それはリリース側の環境であっても、開発用のリソースであっても同様で、単純に『ちょっと作るか』のようなのりは不可能でした。

COBOLでいえば、一般的にコンパイル可能な時間はチームで決まっている事が当時は多く、ディスクやテープのリソースも、極論言えば「利用不可」な事すらあります。

そのため、結合テスト前までにあげておくべき品質は相当高くなければなく、一度結合試験のタイミングを逃すと、再度それだけのリソースの確保を行うという事を実現するため、コストも時間も負担が大きいという現実があり、結果、結合試験までの品質向上は実機上のテストだけでなく、コードレビューや、仕様全体の確認もウォークスルーなどさまざまな手法を使い、あげるという事が求められていました。

さらに、この手法や取り組みは、組織の中で仕様化されており、新人技術者は、チームに配属されると、まずコードを書くという行為よりも、それ以外の部分のお手伝いから入る事が多かったため、結果、コードを自分がくみ上げる前に文化を知り、学ぶという事も可能でした。

COBOLに関してもっといえば、あの言語では紙ベースでコードを整理する事も少なくありませんでした。

今では考えられないでしょうが、専用の紙もあり、そこにコーディングを行い、そのコードをタイピングするという事が別な方に依頼される事も普通にありました。

この文化の影響で、コードのノウハウ、つまり、何を行う際はどのようにコーディングするべきか、がわかりやすく、継承も容易でした。

特にソートについての記述でいえば、定石が明らかなので、コードとフローチャートを比較しながら、なぜこのケースではバブルソートなのか？のような疑問を先輩に確認したり、自分で研究したりする事も容易でした。

当然これらは近年の開発環境でも実現できるのですが、近年は技術の移り変わりも早く、結果、言語としても、フレームワークとしても十分な経験者は限定され、且つ、多くの場合で、ある程度の評価のみで採用し、そのままプロダクションの環境変更や採用をしてしまう事も事実として少なくありません。

これは、悪い事ではありません。

が、本来は例えば、スクラムのような手法を採用する際、同時にこういった課題についてどのように対処するかをチームや組織で検討し、段階的に解消する事を試みるのですが、私が知る限り、そこまで万全の体制で環境を整備できているところはおそらく数えるほどしかないでしょう。

本来はCTOであったり、開発責任者を頂点に置き、チームや組織内での「文化」を共通言語として、その中でフレームワークや開発言語の採用、部分適用などを調整し、前述の課題も解消するべきです。

しかし、昨今のチーム構成は、多くの場合で並列関係であり、役割的にリーダーとなる人間はいたとして、その事と、文化を取り仕切る事は別である事が大きく、極論言えば、リーダーよりも特定の技術に深い知識を持つ人間の方針で文化のほうをあわせる事もあります。

結果、プロダクトのもとめる「結果」に対して、より影響をおよぼす方向に文化がゆがむ傾向が強く、その影響で、品質管理や技術の整理といったところを軽んじる結果になりがちです。

「カバレッジ」と一言でいいますが、単体テストのカバレッジと、結合テストのカバレッジは異なります。

この意味がわからないというチームはテストの本質が理解できていません。

もっといえば「100%」である事は重要でもありませんし、「100%」になったとしても、それはテストの完了を意味するわけではありません。

この意味もわからないというならばそのチームは同様にテストの本質が理解できていません。

言語やフレームワークを書籍で学んだり、ネットで知識を得るという事は本当に簡単になりました。経験がなくともそれなりのアプリケーションやシステムは構築できる時代です。

が、言語の仕様不備、フレームワークの課題、導入したモジュールの癖、実機となるクラウドの特性、など、コーディング以外でも実装に対して影響をおよぼす事は多く、これらも含め影響を図り、適切な品質を確保する事が重要となります。

これを誰がどのように指揮を執り、どのように維持するか、または上げていくのか、この方針自体が文化ですから、新しい文化を作る事は非常によい事ですが、もしそれだけの労力を避けないのであれば、新しい手法や新しい言語を使う事よりも、まずは文化を少し改善したり、トレンドを追い過ぎないということも重要になるでしょう。

Rubyに限らず、PHPでも、Pythonでも同様で、どちらかというと言語よりもチームの規模や発足の仕方の方が影響をおよぼしやすいと感じます。

もし自身のチームや組織やそういった課題を抱えているようであれば、臆することなく、一度外部の技術者やCTOを採用するなどして、第三者の視点で問題点や改善策の検討など行う事をお勧めします。

本当にあなたのいう「スクラム」は「スクラム」として機能しているのか、そういった基本的な点からおそらくは新しい発見があるかと思います。