業務ソフトウェアと業務の関係には、
１）業務に合わせてソフトウェアを作る
２）ソフトウェアに合わせて業務を行う
の２種類を考える必要があります。当然ながら SharePoint をはじめパッケージソフトを使う場合は 2 になります。
SharePointではお客の要求に合わせてカスタマイズ (開発) を行わなければならない場面が多々あるものの、パッケージソフトを扱う以上、開発やカスタマイズは最小限にとどめなければなりません。
同じプロジェクトにいた、とある SharePoint MVP の勘違いな話です。
カスタマイズの要望が発生
私の担当しているプロジェクトで、インターネット / イントラネット両方からアクセスできる SharePoint ポータルサイトで、アクセス元によって表示内容を変えたいという要望が上がりました。
外部からリバース プロキシＡを経由したアクセスの場合、リンクＡを表示し、内部用プロキシＢを経由したアクセスにはリンクＢを表示する、というものです。
開発部の責任者と私は実現案について相談しました。
実現案としては、
・SharePoint Designer を利用し、DataFormWeb パーツで実現する
・DLL を作成し、そのようなパーツを開発する
を上げていました。アクセスもとの違いによる表示変更の要望はトップページにとどまらず、様々な箇所で要求されるであろうことも想像できたので、なるべく移植性、保守性、拡張性を優先的に考えた形にすることが望ましいと考えて前者の案を推していました。
「開発すべきです」
このプロジェクトには SharePoint MVP 受賞者のエンジニア (Ｍ男) が居ました。彼は何というか、SharePoint の開発が自分のアイデンティティのように感じているところがあります。
彼は SharePoint でのカリスマとしての力を示したかったのでしょうか。暴走ともいうべき発言を始めます。
Ｍ男「コレ、開発ですよね」(注: Visual Studio を使用した DLL 作成の意)
私「この場合は SharePoint Designer を利用して実現できるので、DLL 開発の必要はないかと。」
Ｍ男「これくらいの開発は特に難しくないですよ。」
私「バイナリ開発以外の道があるのだから、保守性・移植性も考えてなるべく開発は避けたい。」
Ｍ男「難しくないですし、開発しちゃいましょうよ」
私「いや、開発以外の方法を採用します。」
彼は私をよそに、本プロジェクトの開発責任者に向かって、こういったのです。
Ｍ男「DLL 開発できるのなら、デザイナーではなく DLL 開発すべきです。」
私はあきれ返ってしまいました。
開発は「工数」だけではない
彼がしたかったことは、一般的な開発 Kiddy にありがちな、開発したがり病です。
彼は「SharePoint の専門家」として雇われており、その自負もあったのでしょう。彼自身も開発が好きで、彼のブログも主に開発系のネタが多数書かれていたくらいです。
確かに開発のほうが自由がきくし、工数もほぼ変わらないかもしれません。
しかしながら、ここが SharePoint アーキテクトとしての審美眼が問われるところです。
DLL で開発してしまうと、
・純粋な SharePoint フレームワークよりも変更弾性が小さいため、パッチ適用ごとに大きなリスクがある
・変更のたびに再コンパイルが必要で柔軟性に劣る
・変更が発生するたびに IIS 再起動が発生し、かつ、フロントエンド サーバーの数だけデプロイが必要
簡単にもこれだけのデメリットがあります。
トータルで考えれば、今回の開発という選択は、次善手はおろか、「悪手」とさえ言えます。
当然ながら、私としても彼の「遊戯」のために開発を OK するわけにはいきません。
私は抵抗しておりましたが、開発責任者は「SharePoint専門家」である彼の説明にやや押されていました。
しかし、運よくというべきか、ここでゴタゴタしているうちに、この要件を実現しなくてもよくなることが起きたため、お流れになりました。
ＩＴの基本原理を見失わない事
今回、私が強く抵抗していなければ、「開発しかない」の意見が通っていたかもしれません。彼が「SharePoint MVP」の名札の威光だけを使って開発を押し切っていた可能性は十分に考えられます。彼は ITの「解決力」が大きく欠けていたと言えます。
「MVP」がある種の専門家だとしても、単なる製品の専門家です。ＩＴの基本は変わらないので、少なくともシステム全体のアーキテクチャを頭に入れて、様々な観点で考えられるよう、その審美眼を持ってほしいと思いました。