技術と管理と標準化の悶々
Posted: Updated:
課題
昨今、感じている課題をゆるゆると。
he Only Problem... - Natalie Maynor
ここで自分が思いを馳せることができるのは、下記のようなトピックです。
- チーム構成・人材配置
- アーキテクチャやライブラリの標準化
- 開発効率の向上・環境整備
チーム構成・人材配置
ちょっと夢見すぎかなと感じている事案のひとつに「複数職能の人間（≒ゼネラリスト）を複数人組み合わせれば少数精鋭が成り立つ」があります。
少数精鋭がなぜ少数精鋭たるかといえば、単に「精鋭だから」ということに尽きると思っています。正味な話、平均的な能力の人間を浅く広くゼネラリスト化して少数集めたところで、生産力が高まるどころか品質が低下する恐れがあります。
組織であればこそ、環境と仕組みによって品質担保を行うことはできます。よって、品質担保の仕組みと合わせて議論すべきであることを前提としつつも、昨今のフルスタックエンジニア論に踊らされる過ぎるのはそれでも危うくないでしょうか。
一方、完全なスペシャリスト集団による分業も夢見がちです。平均的な分業においては、その場その場で足りないリソースを補い合う必要があります。それはある職能への瞬間的な負荷の高まりに起因するかもしれませんし、特定のメンバーの経験が浅いことに起因するかもしれません。
技術は発想やデザインの限界にならない で触れた事と関連していますが、この場合だと分業を保ちつつ、職能間で積極的に補い合うことが求めらるケースは多いのではないでしょうか。
ここまできて、いわゆる「銀の弾丸はない」というような話に戻ってきてしまいました。
- 全員がスペシャリストではない
- 全員がゼネラリストではない
- 全員が超優秀ではない
人材を配置する立場としては、これらの当たり前を受け入れて個別最適に励むべきであり、個々人の成長志向を尊重しつつ、組織としての理想状態を加味しつつ、本当の意味で精鋭に近づけるようサポートすべきなのではと感じます。
アーキテクチャやライブラリの標準化
エンジニアが集まると、特に自分含めてサービス開発よりも、ライブラリやフレームワークの作成に血道を挙げてしまう性分のエンジニアは、共通して使える道具・仕組みを作るべきという考えが強まります。
この考えは常に説得力があって、DRY（Don’t Repeat Yourself）繰り返しの手間を省くという原則に沿っているため、誰が見ても省力化できそうなイメージを初見で与えることができます。
反面、DRYのアンチパターンと同様に、過度の共通化は密結合や複雑な依存を招きやすいと言えます。不自由な制約を抱えた解決策をバラ撒いたところで、素直に亜種(fork)が発生すれば良い方で、悪い方で起こりうるのは制約と複雑性に苦しみ続ける技術的負債。
これら標準化の取り組みをトップダウンで叩き下ろしてしまうと、科学的管理法に通じる作業者の人権…というと大げさですが自由を奪ってしまう結果につながります。おさしみにタンポポをのせる作業に近づけるための標準化を、本来クリエイティブであるはずのプログラマー職能に押しつけるのは、少なからず反発ないし抑圧感を生み出してしまう可能性はゼロではありません。
きっと個人にあるのは、新しいモノを使いたい・自分で作ったモノを使いたい、そんな当たり前の欲求。同時に組織としては、そのケツモチを誰が行うのか、リスクを考えなければならない、などと悶々としてしまいます。
大成する前の未成熟なプロダクトに、ケツモチは本当に必要なのかという謎もあります。
個人の欲求は、標準化にコミットしている人間をなるべく増やすことで解決できるかもしれません。ただ使うだけではなく、自らのフィードバックが全体貢献に結びつく、みんなで育て上げている環境はモチベーションを支えます。そう考えると、世間のプロダクトをそのまま使うよりは、自社で何らかの形で内製プロダクトを持つほうが良さそうにも思えます。
ただし、大体数を満足させることができるレベルのプロダクトは中々生まれません。雨後の竹の子の如く内製プロダクトが乱立することは想像に難くありません。そのときは完全な標準化・一本化は妥協して、許容しうる限りの多様性を認めることが求められることもあるでしょう。
我々が標準化によって本当に管理すべきのは、一体何なのでしょうか。
開発効率の向上・環境整備
例えばチャットツールだとか、コラボレーションツールだとか、バグトラッカーだとか、色々なインフラ・ツールの面で整備を進めることができます。昨今のIT技術者は、自らさえも型に嵌めて自動化することを厭いません。
良いツールによって良いフローを生み出すというのは、技術者にとっても満足度が高く、生産性の向上にも素直に貢献することでしょう。組織から働きかけるにあたっても副作用の低い手段です。
このような取り組みでさえも、用意した道具を使いこなすことを強制したり、乗り換えを強制してしまえば、一変して個々のプロジェクト単位による自浄作用や個別最適化を阻害する要因になってしまいます。
エンジニアに快適な環境を与えることが生産性の向上につながるという旨の話はそこかしこで見かけます。今の自分は投資量とそれに対する回収率を示せるモデルケースを持ってはいませんので、確信はありません。 そういう面では、こういった取り組みが、投資に見合った効果が得られるかという説得力の醸し出し方は、自分にとってまだまだ未知の部分が多い印象です。
おしまい
ここに書いた内容は、自分自身が納得できておらず、今もなお課題感に溢れています。神の思し召し論に逃げすぎではという内省もあります。
いずれによせエンジニアの幸福論と、組織の成果をなるべくソフトに結びつけるということは、かくも骨が折れることなのだなぁと感じ入っている次第。
仕事人生上の貴重な経験ということで。
ではでは。
