このところの[業務日誌.NET]系の記事は、詳しい方にはつっこみどころ満載なのかもしれない。が、正しい手法をしかるべき手順で学ぶ機会をもてなかった人間が四苦八苦しながら情報を集めていく過程をあえて晒すことは、多分他の同類エンジニアの役に立つだろうという考えに基づいての記述。突っ込むべき所は適切に突っ込んでほしい。
ところで本題。今やっている作業の成果物を、他のプロジェクトで流用できないかという話が挙がった。現在やっている作業で作っている共通ライブラリの基本コンセプトは、
- オフショア開発がベースにあるため、本拠からのコントロールが無くとも、基本仕様から逸脱しづらいような機能と枠組みを開発者に提供する。
そのために採用されたのが、Application Context。この仕事をやるまでは、Application Contextなるものを全く知らなかったのだが、そもそも.NET Frameworkにも同名のオブジェクトが存在する。J2EEなんかではよく使われているようだ。今回も、基本コンセプトを考えた技術者は、JAVA系だった（各所でBeanという言葉が使われていて、Java系に触れていない技術者を混乱させていたのはちょっと考え物だが...やはり用語は各ジャンルで使い分けてほしいところ）。
これを用いた場合、アプリケーション起動時にContextを生成、基本的に、様々なクラスのインスタンスや情報は、このContextにお願いして作って（渡して）もらうという作りになるようだ。また、アプリケーションはこのContextを核にして動くため、起動や終了にまつわる諸処理をココに集約することで、作業漏れなどを防ぐ事もできる。このあたりは、今回の「Out of ControlでもNP」という路線にマッチする。
残念ながら、あらゆる業務用オブジェクトのFactoryとして働かせるという設計には完全には至らなかった。理由は、
- 事前に十分な設計が出来なかった。
- 共通ライブラリに対する用件が明確になりきれていなかった。
- いくつかの基幹オブジェクトがContextとは別系統で設計された。
- 実装中に、既に設計中の業務開発チームが成果物を試用していた。
などなど。事前にどのようなものを作るかという規模感をしっかり把握し、何をどこに依存させるかということを十分検討すべきだったが、それが出来なかったため、Contextを中心に据える作業が中途半端になってしまった。また、本来のApplication Contextのあるべき姿である（らしい）、Singletonで設計するというのも挫折している*1。が、DB接続オブジェクトだけはContextに「GetDBConnectionManager」などというメソッドを用意して、Contextが自主的に採取したアカウント情報などを元に接続を管理するようにした。Context自体はGetInstanceメソッドを用意し、自らへの参照を外部に提供できる。これにより、アプリケーション内のすべてのオブジェクトからContextへの参照が可能になる。ここで問題になるのが、Singletonで作られていないことだが、これについては、少々みっともないが、GetInstance用にShared宣言された（Staticな）自インスタンスが存在する時点で例外を発生させ、開発者に「本来の用法から逸脱している」ことを認識させるようにした。これで、少なくともテストの段階で利用法に過ちがあることは判明するはず（例外には、「用法間違いだよ」というメッセージも込めた。完全に開発者向けのメッセージ）。
というようなものを含めたライブラリを2時間で説明せよ、と言われ、スキルセットが判らない相手に、
- アプリケーション内のロジックが情報その他を共有できるように、ApplicationContextというものを下地に置いて動作する方針を採っています。
- アプリケーションのすべてのオブジェクトやロジックは、そこに依頼して共有情報を取得できるので、フォーム間での情報共有などにも便利です。
というような説明をまず行った。その時点で、そのあたりに詳しいと思われるマネージャーから「そもそも設計やってないでしょ。構成がぐちゃぐちゃだ」という指摘が。
この長文のキッカケはその指摘。なんで？確かに脳内設計＆二人だけの「共通チーム」による開発の成果なので、現時点では設計書と呼べる資料は揃っていない。だって元々が「共通関数やクラス*2の一覧でしかなく、そこに書いてあるのは軽い一文だけ。そんなものをベースに、2ヶ月でのライブラリ作成を要求され、一人でスタート。1ヶ月後に二人に増え...というような状態（それももう一人は社外の人。本来は社員の仕事だとおもう。それでも、よりよい姿を目指して指摘やアドバイス、提案をしてもらえるので人材には今回恵まれたと思う）。
で、指摘ときた。それも、これからモノを使ってもらおうと思っている相手の技術者とマネージャ、それから自分の部署の部長の前で。たしかに設計が出来ていないのは言い訳のしようが無い。また、その場で何がおかしいのですか？という問を出せるほど、自分が扱っているモノに対する理解が足りなかった（そのため、時間をかけて考えてここで書いている）のも確か。だが、その指摘は正しいのか？どこをみて「設計ができていない」と言われたのだろうか？タイミング的には、Contextの（利用上の）概念について、アプリのフォームと、その下にあるContextをレイヤーっぽくホワイトボードに描いたところで指摘された。Contextがすべてのオブジェクトからアクセスできるところが気に入らなかったんだろうか？でもこれはそういうもの。そういう方針に基づいたもので、それはそれで「間違い」では無いと思う。何だろう？
いずれにしても、ああいう形で否定されると、この先この路線は使いづらい。また、今やっている作業、それなりに「今後の下地になりうること」というミッションをアンオフィシャルに掲げていたのだが...。これが主流にはなり得ないだろうが、選択肢の一つとして間違ってはいないだろうし、できあがったものを下地に、設計を書き起こし、まずい部分を見直す作業をやろうとおもっていたのだが...。なんかやりづらくなってしまった。
指摘は誰にでもできる、問題は適切な訂正案を自ら提示して、実践に移せるかどうかだと思う。このことは指揮者をやったときに痛いほどわかった、学生時代に得た数少ない教訓の一つ。学生に宿題を出すのではないのだから、指摘して「考えてこい」というのは仕事ではやってほしくない。新人の教育ならあり得るが...。
まずいのなら、自分を降板させて適切な人材を充てるか、今、それなりに流れているものを堰き止めることが無いように、とりあえずは黙っておいてほしかった。ただでさえ下り調子なモチベーションに、激しい急制動をかけるようなのは勘弁してほしい。
