自社内ライブラリ、再利用、聞こえはいいですが、そう簡単な話ではありません。ですが、これを手軽に「あれを使い回せばいいじゃないか」→「ライブラリのできあがり」なんて思う老害が結構多いのもこのジャンル。油断できませんよね。挙げ句の果てに「フレームワーク」なんて名前つけちゃったりして。フレームワークに謝れ！って感じですよ。
で、こんなものが周囲にあって、それに関する会話が漏れ聞こえてくるわけですが、それに対して思った事を書き殴っておきます。
ただし、ここに書いたのは「しっかりした設計ポリシーを持った設計者と彼を中心とするチームによって作られた、ある程度の品質を持ったライブラリ」の場合です。残念ながらウチの会社のそれは適用外かもしれません。
結論
やりたくないなら止めなさい。イヤイヤやられると周囲は迷惑します。
管理とは？
管理ってのは「禁止」「制約」「縛る」とか「すべてを手中に収める」とかじゃありません。適切な状態を保ち続けること、この場合だと、対象物を適切な状態に維持し、その利用者が楽をできる、気持ちよく仕事できる環境を保つこと、です。もちろん、その結果、何かしらの制約を設けたりすることは当然ありますが、「制約すること」が管理の目的ではありませんから。そのところをはき違えないようにしてもらいたい。
ソース管理とは？
ソース管理ってのは「決められた人以外が勝手にいじれないようにする」が目的ではありません。
- 何があるかを把握する。
- 有る物を適切に保管する。
- 誰が何を変えたかを把握する。
- 過去のバージョンを把握する（最悪、過去のバージョンを取り出したりという要望にも対応する）
です。いじれないようにするなんてのは上記の目的を果たすための一手段に過ぎません。そしてなにより、「開発者の邪魔にならない仕組みでないといけません」。もうね、SourceForge.JPとか使って勉強しろっての。
- SourceForge.JP/オープンソフトウェアの開発＆ダウンロード
- http://sourceforge.jp/
バージョンの決め方
- そんなのは最初に決めなさい。どうするかなんて定石はありません。どう決めるかです。
- リリース方法などを考えれば自然とできあがるはず。バージョン番号は管理対象を特定するために必要なものだから、それが決まってないということは管理体制ができていないということ。
- 「バージョン番号は必要」ではなく「対象物の集合体を特定する方法の1つとして、バージョン番号というものがある」です。目的を忘れない。
修正作業や改変作業
- 修正するかどうかはライブラリの担当チームが主幹で行う決定事項。コストや期限といった政治的要素は組織の上長もふくめて考えないといけない。
- 責任を負うというレベルで仕事をするには、専属のチームが必要。ある程度の規模になると片手間での管理は不可能と思った方がいい。
- チームとしての方針をきちんと定め、それを貫く覚悟が必要。その判断や責任を個人に負わせるのは間違いだし、そんなことをしたら判断できなくなる（前に進めなくなる）。
- 出す/出さない/やる/やらないといった判断を適切に行うことがライブラリ管理や担当チームの指揮をとる醍醐味。それがいやならやめちまえ。
- 事の重大さを知れば知るほど慎重に動かざるを得なくなる、結果、慎重な設計や実装を強いられることになり、品質は自ずとあがる。
リリース
- 修正版や新しいバージョンのリリースは、そのライブラリを使っているチームへの影響なども考える必要があるが、「誰が使っているか」までで良い。どう使っているかまでを事細かに把握することは間違い無くパンクへ一直線になるからやめるべき。
- 逆に、エネルギーは「いちいち説明に張り付かなくても使ってもらえるライブラリ作り、資料作り」に注ぐべきである。
- 社内での利用チームは把握しなければならないし、利用の際にはライブラリ担当チームに申請してもらうといった仕組みは必要。
- また、試用が簡単にできる環境は必要。たとえば、試用版はダウンロードして自由に使える、など。
不具合管理
- なるべく自動化すべき。特に社内なら、Webを使った不具合管理に利用者を強制参加させて、不具合レポートを自動的に収集する仕組みを構築するのが良い。
- 修正結果などのアナウンスもWebを通して行うことで、関心のある人には自動的なアナウンスとなる。
- こんなところに力を掛けるなら、バグをなおしたり次のバージョンを作ったり親切なヘルプやマニュアルを作るのに注力した方がよい。
こんなところでしょうか。多分に私見が入ってますが。
