最近は、小さい規模の開発(大企業に関わらない)が多いですが、数年前は、大企業のプロジェクトに関わったことがあります。

大企業の大規模開発には、ほぼ共通チームと呼ばれる技術者集団がいました。そしてそれ以外の開発者は、実際の業務の各機能を実現するチームに振り分けられていました。これらのプロジェクトでは業務チームの一員として参加していました。

共通チーム VS 業務チーム(フレームワーク提供者 VS フレームワークユーザ)

あるプロジェクトではデスマーチ化してくると、共通チームは業務に関わる問題が発生した場合、「業務的なことは知らんから、そっちで顧客に確認してくれ」という態度を取るようになりました。本来理想としては、共通チームが業務を把握した上で業務チームをサポートできるようなフレームワークなりを各チームに提供すると思うのですが。その結果、業務チームは共通チームを頼りにしながらも嫌っているような状況となっていました。

フレームワークを作るのってキモチー「Playing God」

なぜ、共通チームが傲慢に見えるようになってしまうかの理由の一つには、大袈裟なフレームワークを生み出すのは、本来の業務とは無関係なある種の快感を感じられるからだと思います。同時にフレームワークユーザに対して傲慢な気持ちを持つようになりがちです。(実際私も大袈裟なフレームワークを作る快感は、感じたこともあります。そのせいで痛い目にも会って学習しましたが)

フレームワークを作る側の人間が気を付けたいこと

上で書いたような業務チームのモヤモヤは、共通チーム側の人間になると忘れてしまうことなのかもしれません。

「Lisp設計者は、自分より言語ユーザの方が、そして現在のユーザより未来のユーザの方が、賢いと考えている」。

Lisp:S式の理由

引用元はLispの話ですが、引用部分はフレームワークに置き換えると良い共通チームのための教訓に見えてきます。

できの良くないフレームワークを提供しておいて「超便利なフレームワーク作ってやったよ! さあ使え」という態度は、プログラマーの第三の美徳が傲慢だとしても、傲慢すぎます。共通チームのような役割に立つ場合には、第一に顧客、第二にフレームワークユーザを尊重する気持ちを忘れないようにしたいものです。

なんかまとまってないので、後で修正するかもしれません。