misc.log

日常茶飯事とお仕事と

ライブラリ的なものを作る要件定義レビューで書きかけてやめた文章

従来製品と次期製品のつなぎとして、「従来品のフリをさせるラッパーライブラリ群」を作るという話のレビュー指摘を書いていたのですが、長すぎるので削除しました…。
備忘録もかねてここにメモっておきます。

元々、このライブラリは自社の命を受けて我々が作った物を「今までと違うからと否定した上で始まったプロジェクト」。そもそも作った物を否定された我々がレビューに参加して向上に寄与するなんてのはお門違い(ってか願い下げ)なんですが…まぁ同じ会社としてはね。つぶし合ってもしょうがないし。一番の元凶は、「新しい物を取り入れるが、大きな変化はいやだ」というアホな指針を掲げた経営や開発集団のトップなんですけどね。

以下、書きかけた文章を切り出しながら補足します。

フレームワークの内部や目的を隠蔽しようとすることについて

初回のWGでも指摘しましたが、使わない機能を「隠す」ことは本件の主眼ではないと思います。「使いやすく、被せる」を目指し、使う人は「被せられている」ことを意識できても良いかと。むしろ、被せた下に素の***があり、それは****とは全く異質であることを使い手は意識すべきです(どうせサーバー側は丸見えなんですから)。

フレームワークを「どうせわからない君たちには使いこなせない機能だから、大半を隠し、君たちが使いやすい機能だけに絞ってわかりやすくまとめてあげるよ」というスタンスで作る人たちの発想をまずはなんとかしたいと思いました。

このスタンスを取りたくなる気持ちはわからなくも無いです。ただ、一時的にはそうして「できない人たち」を封じ込める事ができたとしても、いつまでもそのままでは済まされません。いずれは組織全体がそういう風土になり、立ちゆかなくなるときが来ます。

向上や学習を阻害するフレームワークで良いのか?ということ

そうすれば、従来のやりかたをこのライブラリが実現出来なかったとき、壁にぶち当たった人達が納得でき、自発的に「仕方ない。作り込むか、回避するか考えよう」という流れに持ち込めるのではないでしょうか。

完全に隠されていたり、隠すという意図が露見した時、隠された側は部外者として振る舞い、こちら側には入ってきてくれません。そうすると、「不足分や拡張は各プロジェクトで」という方針は実現されないまま、「機能が足りないから使えない」という評価を受ける可能性があります。

それは避けた方がよいのではないでしょうか。適度に中身をチラ見させて、自分達でもいじれるんじゃないか?と使い手に思わせるのも共用
ライブラリ的なものを作る上でのコツだと思います。

自社内で使う自社向けのフレームワーク、それも開発費や大量の時間を費やして作った物であれば、それを通して開発者がさらなる拡張を目指したり、それによって浮いた時間を次の何かに費やすような風土を作っていく道具にすべきなのではないでしょうか?

また、機能や内部を隠蔽された側は「自分たちは信頼されていない」と言うことを感じるようになり、どんどん組織から離れていきますし、向上しません。

さらに、フレームワークを作ったりメンテする側だってリソースは有限です。なので、最終的には利用者の一部は作り手側に回ったり、さらに継続的な改善、機能追加に協力してもらえる余地を見せておくことが長期的な開発には必要です。その発想を織り込んだ方針や作りにして、最終的には自律的に変化しつつ使い続けられるものを目指すべきなのでは無いでしょうか?

ただ、残念ながらこの組織に関して言えば、フレームワークや再利用可能なライブラリ等については以下の発想をベースに作る傾向が非常に強いことがわかりました。

  • 継続的な改良や変更は行うべきでは無い。
  • 最初に良い物を作れば、そもそも機能追加等は不要なはずである。

これは理想論です。この理屈が実現するならば、世の中にソフトウェアのバグなんてものは存在しません。

実際、社内での情報共有などにしても、wiki的なものを利用してとりあえず共有ゼロではない環境を作ろうという提案に対して「そんな、不確かかもしれないものを共有することは罷り成らん。確実かつ完全な情報以外は共有してはいけない」とか言い出す人たちがトップですから……まぁそうなりますよね。

というわけで、私は何かを変えることもアピールする事も面倒になったので、最終的にこうした指摘も行いませんでした(そして、この2年後に見切りをつけて転職します)。

Webアプリケーション設計・実装のためのフレームワーク活用の技術

Webアプリケーション設計・実装のためのフレームワーク活用の技術