動かないコンピュータ・フォーラム　第31回 ベンダーの技術力に異議あり 動かないコンピュータ・フォーラム　主宰者 中村　建助＝日経コンピュータ編集

日経コンピュータを読む理由No.1　「動かないコンピュータ」連載が単行本になりました。12月9日全国の書店で発売

　今回は予想外にたくさんのご意見を頂いた。記者として非常にやりがいを感じます。みなさん、有り難うございました。

　理由は様々ですが、本来プロであるべきベンダーに、技術を知らない技術者がいることは否定できないと思います。とはいえ、ベンダーは自らの利益を追求するもの。雇っている技術者をプロジェクトに参加させるのは当然のことでしょう。動かないコンピュータを減らそうと考えるのであれば、ユーザーはやはりベンダーのシステム開発力をきちんと評価して、問題があれば異議を唱えるべきではないでしょうか。

　今回は多くの書き込みを頂いたこともあり、普段の総括編と同じ書き方にすると、長大な原稿になってしまいそうなので、みなさんの書き込みに対する記者の感想を書き込む形でフォーラムを総括してみる。書き込みは時系列に沿って並べています。

日本の（おそらく）多くの企業の人事制度上、選択基準は“経験年数”であり、実態は“余っている人”である。ここでいう、“余っている人”とは、能力のない人という意味ではなく、ただ単にそのときに手が空いている人という意味である。企業運営上、手が空いている人に仕事を与えないわけには行かず、仕事を選択できるほど好景気でない以上、基準や建前がどうであれ、手が空いている人に仕事を割り当てざるを得ないのではないか。 （ちなみに私はISO9001の担当者であり、職種としては品質管理または開発プロセス設計者というのがあれば・・・と思います）。 (30代、システム・インテグレーター、システムエンジニア )

　ご指摘の面はその通りだと思います。ベンダーから見れば、プロジェクトに参加していない技術者は収益を生みません。ベンダーが利益を求める以上、「参加すべき技術者」ではなく「参加できる技術者」をプロジェクトに参加させるのはある意味で当然でしょう。弊誌はプロジェクトマネジメントに注目することが多いのですが、ソフトウエアの品質管理のあり方についても取材を進めていきたいと考え始めたところです。

フォーラムの議題から外れた意見で恐縮ですが、読者や識者からオープンソースである事が原因でないと指摘され、それを中村さんも肯定されているにも関らず、相変わらずオープンソースの問題として固執されている様ですね。それを象徴していると感じるのは次の２文です。［もちろん、これらの「常識」はオープンソースの開発に特に詳しい方々の意見である。］［早稲田大学の履修管理システムの場合であれば、オープンソースで開発することが決まった段階で、どういった対処をとればよかったのでしょうか。］ (30代、ユーザー企業、情報システム部門 )

　オープンソースの問題として固執したつもりはなかったのですが、誤解を与えたのなら申し訳ありません。ただし議論を提起した時点で、オープンソースを利用したシステムであれば、従来の商業ソフトにないトラブルの脱出法があるのではないか、と考えていた部分はあります。

今回の問題は、単純に通常のシステム構成設計やミドルウェアのアライメントを取り損ねただけの初心者クラスのミスである。こういったミスを犯す初級者にDB設計やPHPのツール設計と実装をさせた組織が悪い。また、初級技術者を上位の技術者として売り込んだベンダのモラル問題でもある。 　技術者には3通りいると思う。政治屋系、新物好き似非系、技術屋系の３つだ。1つ目は、ベンダ内の調整に長けているが、本来の技術屋ではない。2つ目は新しい技術に跳び付くが、その本質にたどり着けない似非エンジニア。3つ目が本来の技術屋だが、絶滅危惧種である。 　システム構成を決めていく段階で、2番目は確実に排除しないといけないだろう。1番目は1名いれば十分。3番目を如何に見つけるかだが、実は簡単である。システム上の技術は、汎用機だろうがオープン系だろうが、実はそんなに変わらない。彼らの領域の技術をわかりやすく汎用機系の技術で説明させれば、似非かどうかの判定は簡単に付く。だから、親爺族に云いたい。担当の若者と語れと。メッキは直ぐに剥げるのだから。 (30代、システム・インテグレーター、コンサルタント )

　ちょっと面白く読ませていただきました。記者は、汎用機系の技術すら知らないユーザー側の担当者が、システムを開発することになった場合の打開策を考えてみたいと思っています。

オープンソース云々ではなく、システムをちゃんと作れる人がいなかっただけである。メーカ製品を使ってシステム構成を組んだとしても、使いこなせなければ同じ結果になる。早稲田の場合は、開発メンバーが必要な素養・経験を持っているかどうか確かめる必要があったと思う。 (30代、ハード・ソフトベンダー、システムエンジニア )

　ご指摘の通りだと思います。早稲田大学は、開発メンバーの素養を確認する必要があったと思います。

オープンソースが原因であると無理やり解釈しても、「コネクションプールを有効にする方法が直ぐに分からなかった」程度のことです。さらにRDBMSでWHERE句に文字列関数を入れれば索引が無効になることも知らないなんて考えられないのですが。どちらも技術力以前の低レベルな話ですよね？恥かしいので技術者を自称しないで頂きたい。 　こんなベンダーを見抜く方法◆「オフショアで安くできます」は国内で技術が空洞化している可能性大。これでは看板貸しの人頭仲介屋。中間マージン取るだけで存在意味なし◆途中で技術者をベンダー都合で入れ替える。代わりに来る人は技術力が下がる◆雑誌に載っているような専門用語を連発するのは分かっていない証拠。本質を理解している人は流行語でなく自分の言葉で話す... 　他にも有る？でもこれだけの観点でも相当数のベンダーが除外されるでしょうね。逆に頼めるところが無くなるか... (30代、システム・インテグレーター、システムエンジニア )

　このご意見も楽しく読ませていただきました。ところでこのエンジニアの方は、技術力のないベンダーを見抜く方法として、「◆雑誌に載っているような専門用語を連発するのは分かっていない証拠。本質を理解している人は流行語でなく自分の言葉で話す」と書き込んでいらっしゃいます。記者は、本質を理解せず流行語ばかりで雑誌を作っている人間の一人かもしれません。反省させられました。

別にオープンソースだからといって、システム開発に特別な考慮があるとは思えない。早稲田の件で言えば、サービスインする前の段階で、実際の予想負荷に安全率を見込んだストレステストをきっちり実施するべきであったし、その結果性能が出ないということが判明すれば、解決策をWebで検索するなり(記事にもあるようにWebシステムを開発する上ではしごく初歩的なミスだった)、識者にコンサルタントに入ってもらうなり、いくらでも方策はあった筈だ。 　仮にオープンソースプロダクトでないからといって、上記のプロセスが無効になるわけでもないし、むしろオープンソースプロダクトの方がWebから得られる情報は多いと思うのだが、あまり生かされなかったようだ。 おそらく件のシステムは、これまで通りの業務システム開発経験しかない開発者が、はじめて見よう見真似でなれぬシステムを用いて開発した故のトラブルだったのではないだろうか。おそらく商用製品ならば、メーカーに泣きつくことで大事に至らなかっただけのことかもしれない。 (30代、ハード・ソフトベンダー、研究・開発部門 )

　商用製品ならば、メーカーに泣きつくことで大事に至らなかったかもしれない、というご指摘の部分は興味深く読みました。逆の見方をすると、オープンソースの利用が広がりは、技術者の底上げに有用なのかもしれません。

記事のタイトルについて、同じ事を感じた人がいたのだなというのがまずひとつ（私はフィードバックなどしなかったが…）。そして、その反論から考えるといっておきながら、なぜあのようなタイトル付けになったのかが何一つ示されてない。議論を交わすつもりがあるのか、無いのか？読者の意見を求めるなら、あの記事のタイトルに対してだろう。 (20代、システム・インテグレーター、営業部門 )

　なぜあのようなタイトルになったか議論すべきではないかということですが、編集部内の力不足で誤解を与えたとしか説明できません。申し訳ありません。「動かないコンピュータ・フォーラム」は、動かないコンピュータにまつわる様々なテーマを幅広く議論し、考えることを目的とするフォーラムですので、早稲田大学の履修管理システムで起きたトラブルについて議論すべきだと考えて、前回の提起を執筆しました。

オープンソース系のシステムは、開発環境にコストがかからないため、トータルの予算規模を従来の仕事と合わせようと、機能要件を必要以上に膨らましているのでは？まずは、最低限の機能である程度運用してみて、それから少しずつ機能を満たしていけばよろしいかと。 　また、Perlについていえば、サーバ構築が非常に簡単であり、メンテナンス性も良い。Perlを使うことに疑問を感じた、その理由こそ、明確にしていただきたい。おそらく、開発側の(企業の)都合が大半で、本当に顧客の立場になって、システムを運用していくことを考えれば、Perlの可能性もあるのでは。 (40代、その他、研究・開発部門 )

　Perlについてのご指摘ですが、少し説明してみます。統合医療システムは、診察料金の計算などを実行するシステムであり、演算機能を優先して考えればPerlを選ぶケースは減るのではないでしょうか。また開発規模の大きなシステムに、プログラムの可読性が低いPerlを使うとテストの手間が大きくなってしまうという問題もあると思います。こういった点が、Perlを利用したことについての疑問につながったのではないかと思います。

プロジェクトに参加する技術者の選択基準ということだが、多くの場合は技術者のプロフィールシートに該当の技術の経験があると書いてあるかどうか程度ではないでしょうか？（私は凄くその考えは嫌いですが）最近よく感じるのですが、「技術」というのは非常に軽視されているように思います。技術はどうでもいい。重要なのは「プロジェクトマネージメント」と「業務知識」であると。 　私はそれらも重要と思いますが、「技術」なくしてはプロジェクトの成功はないと思います。多くのプロジェクトでは新しい技術を知っている技術者がプロジェクトの企画段階でアサインされることはまれで、新しい技術に精通している技術を持っている技術者がアサインされるころには「間抜け」なアーキテクチャが既に決定されていて、どうしようもないと知りながらもそれを今から変えるには遅すぎる・・・という状態がよく見受けられると思います。 (30代、システム・インテグレーター、システムエンジニア )

　おっしゃる通りです。IT業界の特質に技術の進歩の速さがありますが。新しく登場した技術を理解しながら、実際のシステム開発にいかに取り込んでいくか。言い古されたことかもしれませんが、これは重要な問題だと思います。

最近強く思い始めたことがある。情報システムも千差万別。動けばいいようなものや中には「ある」だけが目的であるようなシステムだってある。全てが同じような信頼性を持ち、同じような正確さで構築されなくたっていいのだ。 　早稲田大学の履修管理システムの場合、おそらく安く、アンチョコ（中村注：安直の入力ミスでしょうか？）に作れることが大切なのであって、粛々と作って一発で動くことなどはアテにもしていないことだろう。だとすれば、結局、このままでいいのではないか？ 　本来、一発で動くようなシステムの開発には、OSやハードまで含めたシステムの全容を押さえられる技術者が不可欠だ。しかも、いろいろな失敗事例や成功事例なども教え込んでおく必要がある。もちろん、オブジェクト指向だけできる技術者よりはお高い賃金を払っている。そういう技術者が必要なら必然と構築費用は高くなる。それだけである。全てが成功できるわけではないのだ。 (40代、システム・インテグレーター、システムエンジニア )

　ご指摘に理解できる部分もありますが、やっぱり大学で履修申告を全面的に電子化するなら、履修管理システムはきちんと動くべきシステムではないかと思います。一応、学生は授業を受けることになっていますし、履修できなければ授業を受けることはできません。違うでしょうか。