比較検討もてっとり早く

オープンソースや既存のソフトウェアを利用すれば、速く目的に近づくのはわかりますが、そういうものを利用するにあたっては「比較検討」というフェーズを避けては通れません。

  • そもそもどんな製品が世の中に存在するのか?
  • どういう点を評価して選んだらよいのか?
  • 自分たちのサービスや製品に合うのか?(ex:考え方や実装)

というところを考えて、製品やサービス・ソフトウェアを選ぶ必要があります。

これは実は導入して使う以上にやっかいな問題です。例えば候補の製品があるとして、そこのベンダーを呼んで話を聞いても、基本的によいことしか言ってくれないものです。また、基本的に自分たちにない部分というのは経験が不足している領域でもあるので、なかなか何を選んでよいかわからないものです。評価をするにしても、その製品を理解するのに四苦八苦する、なんてことになりがちです。

例えば、キーマンズネットなんかを見てみるのも、最初のステップとしてはよいでしょう。実際、私も利用して情報を得ています。

使ってみればわかりますが、キーマンズネットではそれぞれの製品の系統(ex:データベース、帳票システム)で、登録している製品の一覧を作ることができます。また、それっぽい切り口で、各製品のマトリクスを作ることもできます。

ただし、「どんな製品があるんだろう」と探すのにはよいですが、正直なところを言えば、マトリクスの切り口があまりにも表面的で、実際の評価の参考にはならないかなあというのが私の感想です。動作するためのハード条件や、ライセンス、概要、価格情報なんていうすぐ手に入れられる情報しかありません。

本当に欲しいのは、もっとコアな情報です。

  • 実際使ってみて、興味のある部分がどんな感じだったのか
  • 欲しているこんな機能って、あるのかないのか
  • 出来るのは分かってるけど、簡単なのか難易度が高いのか
  • そもそもどんな考えで作っているのか

なんてところが知りたいところだったりします。モノによるとは思いますが、こんなわがままな問いにもインターネットは応えてくれたりします。

今携わっているサービスでは、HPを作成して公開するCMSシステムをユーザに提供しています。サービスにバンドルするCMSシステムをどうやって選んだかというと、実はこんなページを利用していました。

The CMS Matrix

日本語ではないのですが、様々なCMSシステムのリストとマトリクス形式での評価表を作成してくれるサイトです。CMSは、オープンソース系(Xoops,Joomla)といったものや、ブログからの派生系(MovableType,Wordpress)、ベンダー系と様々な製品が存在します。このサイトにももちろんたくさんのCMSが登録されていますが、私たちが利用したのは、このサイトでマトリクスを作成すると出てくる評価項目です。

  • System Requirements
  • Security
  • Support
  • Ease of Use
  • Performance
  • Management
  • Interoperability
  • Flexibility
  • Built-in Applications
  • Commerce

と大項目があって、その中に各評価項目が記述されています。(そうそう、そういうことが知りたいんだよね)

オープンソース系はここで比較できるのですが、ベンダー系の製品については、デモ版などを通してこの切り口で評価を行いました。このように、はじめに評価項目と評価サンプルがあると、自分で調査する場合にも「ここを見ればよいのね」というポイントが分かり、評価にかかる手間も減ります。大事なのかそうでないのか、よくわからないところで四苦八苦するということもなくなります。こういう評価項目のフレームワークは、あるだけでとっても価値が高いです。他の系統の製品についても、世界中さがせば何かしら「評価項目のフレームワーク」が見つかりそうな気がしてきませんか?

この手は本当によく使います。自分たちでやっているサービスについても、探して評価したりしました。

でも、比較検討をすること自体は大事だと思うのですが、実は、

一目見て気に入ったから

とか、

説明してくれたエンジニアが気に入ったから

なんて理由で製品決めちゃうのもおおありだと実は思っているんですけどね。案外その方が正しい選択だったりして。

本当にアジャイルなプロジェクト

最近自分たちの周りを見ていて思うのですが、開発プロジェクトに現場感覚から遠くはなれた、とんでもない「スピード感」が求められるようになってきていませんか?

「えっ、そんな期間で本当にそれをやるの?」

と思うようなプロジェクトがあちこちで起こっています。中には、自分の身に降りかかってきそうなものもあって、「正直やばい」と思うこともあるんですけどね。

「世の中がせっかちになっている。」
「ビジネスニーズがスピードを求めている。」

なんて一口で言ってしまえば話は簡単なのですが、実はビジネスニーズ以上に、

「速く作ることが可能だと思っている技術者が存在している」

ことが、通常のスピード感を超えた、「超アジャイル」なプロジェクトを生んでいるのではないかと思うのです。

インターネットが普通のインフラになった現在、オープンソースソフトウェア・ミドルウェア・フレームワークといったものが、とても充実してきています。手持ちで不足している部分を既存の技術でうまく埋めていくことで「速くつくることが可能」だということが、分かる人には分かるようになってきています。

先日、とあるベンダーさんにEAIツールのデモをしてもらいました。そこでは、難しい「ファジー・マッチング」のアルゴリズムを、インターネットから探し当てて流用していました。また、それによって難易度の高いデータマッチングを簡単に実現していました。デモ中は涼しい顔で話を聞いていたのですが、実は、

「そうか、探せばそんなものまでインターネットにあるんだ」

とちょっと感心していました。

そんな難易度の高いものもインターネットを探せば発見できて、組み合わせられる世の中になってきています。個別にフォーカスした技術であれば、かなり難しいものでもうまく探せば手に入れられる。探し出せなくても、ベンダーにお金を払えば(払わなくても、うまくすればプリセールスで)、相談できるエンジニアが親身に相談に乗ってくれたりもする。いい時代になったものです。

かつては、アプリケーションで使うような共通的なライブラリは、企業・あるいはエンジニア個人が、「自分たちの武器」として個別に持っていたりしていたものです。また、開発チームも、自分たちの手持ちの武器を元に、まず自分たちでどう作るかを第一の選択にしていたように思います。

今はそうではなくて「いかに見つけて、いかに組み合わせる」ことができるか。結果、「いかに自分たちで作らないようにするか」が勝負の時代になってきているように思います。

「アジャイル開発」というと、XP(エクストリーム・プログラミング)やTDD(テスト駆動開発)といった、「開発手法」を指す場合が多いのですが、本当にアジャイルなプロジェクトを完遂するには、

  • 「見つけること」
  • 「組み合わせること」
  • 「作らないこと」

がとても重要なファクターを占めていると思っています。
また、system-enablersでは、そんなネタを、できれば実践例も含めて提供できればと思っています。

正しいモノづくりをする

新年あけましておめでとうございます。

今年もいろいろと大変な年になりそうですが、どうか皆様お付き合いいただけるよう、よろしくお願いします。

今日のタイトル「正しいモノづくりをする」ですが、

「本当に社会に必要なもの」

や、

「本当に社会のためになるもの」

を作っていきたいと常々思っています。冬休みの間いろいろ考えるところもあり、またその思いを強くしたので、このようなタイトルにしました。

システムやソフトウェアの場合は、最近の風潮として、どうしても技術先行になっている場合が多いように見受けられます。どのように役に立ち、どのように社会のためになるのか。そのあたりを置き去りにして走っている人たちがたくさんいるように私には思えるのです。

たとえユーザが望んでも、ユーザのため・社会のためにならないものはちゃんと説明して「作りません」といえる。また、それで納得させられる。そんなエンジニアを目指しています。また、それが「正しいものづくり」をする人の姿だと思っています。

なーんて書きましたが、実際なかなかそううまくはいかないものですよね。さて、今年も頑張りますか。