update it, Inc.社長のブログ

今日もcrossnoteネタの、crossnoteの小さな工夫シリーズ、第3弾です。今日はシーケンス・パラグラフをご紹介します。

設計書を書いていると、手順を説明することってよくありませんか？　たとえば以下のようなものです。

ハンバーグの作り方
(1) 玉ねぎをいためる。
　このとき、茶色っぽくなるまでしっかりといためること。

(2) 他の材料とあわせる
　いためた玉ねぎをボウルに移動し、パン粉などと合わせます。

(3) 形を整える
　中の空気を抜くようにして…

この(1)、(2)、(3)と番号を振ってタイトルを書き、その下に説明文を書くというのは良く使う手法だと思いますが、例えば代表的なワープロであるWordでこのようなスタイルで書く際、中の説明文を書きたいところに勝手にナンバリングされてしまいます。いちいちナンバリングを外す操作をしなければなりません。また説明文をいじっているうちに、下の項目がまた1から始まるようになってしまったりすると最悪で、結局自動ナンバリングをやめて手で番号を振りなおしたことも何度となくあります。

crossnoteでは上記のような書き方をするために、シーケンス・パラグラフというものを用意しました。シーケンス・パラグラフとは順序を説明するためのパラグラフという意味で、ナンバリングしたタイトルと本文という組み合わせの文章を書きやすくしています。

シーケンスパラグラフのナンバリングはアウトラインの構造に従って行われるので、ナンバリングが思ったように行われずにいらつくこともなくなると思います。また開始番号を指定することもできるので、節をまたいで通し番号で説明するなどといったことも可能です。さらには通常のパラグラフとシーケンス・パラグラフで切り替えることも簡単です。

今日も引き続き、crossnoteネタです。

設計書の場合、全体はA4なんだけど、途中の図表だけA3にしたい、なんてことが良くあると思います。そんなときってどうしていますか？

あるワープロソフトの場合、ページ設定の用紙設定の機能を使うと、「これ以降」と指定したところのページ設定を切り替えることが可能です。でも使っているとわかるのですが、ドキュメントの構成を変更するためにコピー＆ペーストを繰り返していると、気がついたら「これ以降」の設定がぐちゃぐちゃになっていることがあります。つまりA3で出すべき図表がいつのまにかA4に戻っていたり、逆にA4で出したい本文がA3に出力されてしまっていたりする、という話です。

この現象は「これ以降」というページ設定方法のために発生します。A3で書いた表や図でも、これ以降がA4としているページに貼り付ければA4になってしまうのです。また「これ以降」の設定部分を誤ってBSキーなどで消してしまうこともあります。用紙が混在したドキュメントで構成変更をするたびに、私は何とかしたいと思っていました。

crossnoteではページ枠というのを用意しました。アウトラインを表示するView上で「A3横」などといったページ枠を挿入し、その中にパラグラフや本文、図表を入れると、その枠内はすべて「A3横」の設定になるのです。ちょっとした工夫なのですが、アウトライン上で、どの部分がA3で出るのかを簡単に指定・確認できることでかなり使い勝手がよくなっていると思います。

さらに「A3横」のページ枠上の図・表はコピーしてペーストすると、自動的に「A3横」のページ枠が差し込まれた上でペーストするようにしています。これによって構成変更をしていても勝手に用紙サイズが変更されることがなくなりました。

これでちょっと大き目の図や表が必要な場合に、気軽にA3のページを差し込むことが出来るようになったと思います。

今日は開発中のプロダクト、crossnoteについての小さな工夫の１つとして、アウトライン機能について書いてみます。

私はワープロを使って仕様書を書く場合、いつも章立てや段落設定がなかなか思ったとおりにならずに悩まされてきました。皆さんはどうでしょうか？　メジャーなワープロの場合、ENTERキーを押したときに自動的に対象のスタイルを自動的に判別して変更してくれたり、ナンバリングしてくれたりしますが、場合によってはこれがかえって余計なお世話で、なかなか意図した状態にならなかったり、空白行に章が設定されたり、変な改ページが行われたりして、よくイライラしています。

crossnoteではシンプルな使い勝手を目指して、文章の構成要素として大きく次の2つに分けています。

１．パラグラフ（章や節などを表すもの）
２．本文（テキスト枠、図形枠、表枠など）

そして、パラグラフとするのか、本文にするのかはユーザが自ら選択して決めるというスタンスをとっています。つまり予めパラグラフ枠を挿入すればパラグラフですし、テキスト枠を挿入すれば本文になります。ユーザが指定した「構造」に応じてナンバリングされていくので、意図しない番号が振られることはありません。

普通、仕様書や設計書などを書く場合、あらかじめ全体の構成を考え、章立てを最初に作ってしまうと思います。crossnoteにはアウトラインをいつも表示しておくためのViewがあり、この上でパラグラフを追加してはタイトルを入力、と繰り返すことで全体の構成を作ってしまい、それから本文を書き始めるということができます。さらには本文の枠にもタイトルを設定でき、そこに書くべき内容をメモしておくこともできます。

アウトラインを表示するViewでは、パラグラフや本文はドラッグ＆ドロップなどで簡単に位置を移動することができます。このあたりの動きはアウトライン・プロセッサに準じたものです。

「アウトライン機能っぽいもの」が付いたワープロも多いと思いますが、私の場合、この手の「アウトライン機能っぽいもの」では満足できません。crossnoteは基本はワープロの使い勝手を基本としつつ、誰でもアウトライン・プロセッサの良さを味わうことができるように設計しました。

まあ、百聞は一見にしかず、ですよね。いずれこのあたりを機能をよりわかりやすく説明する資料やデモ環境を用意する予定です。

Javaで組んだプログラムの場合、実行中に例外が発生したときに適切に処理していると、プログラムを中断することなしに簡単にStackTraceを見ることができます。私がJavaを使い出したときに、非常に良いなと思った仕組みのひとつが、この例外処理の仕組みです。Javaに限らずに、既に他の言語でもあったのかもしれませんが、少なくとも私がそのときまでやってきたC/C++の世界にはなかった仕組みでした。

もう10年以上も前の話ですが、金融商品の理論価格をリアルタイムで計算するシステムを開発したことがありました。UNIXマシン+C言語で計算エンジン（今でいうアプリケーションサーバ）を開発し、LAN上のPCに計算結果を配信するような仕組みです。計算ロジックにはだいぶ複雑な計算モデルが使われていました。

こいつは日中マーケットが動いている間、計算をし続けるのですが、複雑な仕組みを用いているがために、たまにバグのためにメモリアクセスエラーで落ちる（止まる）ことがありました。当然のことですが、落ちると大変です。いつどこにいても呼び出されて対応に追われることになります。このシステムを担当している間は、マーケットの開いている時間帯は気の休まることがありませんでした。

さらに、メモリアクセスエラーが発生すると作成されるcoreファイルを元に解析するのですが、この解析が大変です、strip（リンク時に使ったシンボル情報を消すこと）していたりすると、もうお手上げ、ほぼ解析不能になってしまいます。

Javaで本格的なシステムを作り始めたのはJDK1.1の時代(1998年頃)からになります。その当時、24時間動き続けるサーバサイドのアプリケーションを作ったことがあったのですが、Javaの例外処理の仕組の恩恵を十分に受けました。まず例外が発生してもアプリケーションがストップしないように作ることができます。さらに不具合時の状態をStackTraceとして簡単に見ることができる。問題のかなりの割合がこのStackTraceを見るだけで一目瞭然に原因がわかってしまいます。おかげでアプリケーションの品質を上げる作業が非常にやりやすかったのです。実際これらの仕組みのおかげで、その当時、何ヶ月もの間ノンストップで動き続けるアプリケーションを作れたときに、Javaってすごい、と感じました。

さて、現代のJavaプログラミングの鉄則のひとつに、例外を握りつぶすな、という言葉があります。なぜ重要かわかりますよね。握りつぶしてしまうということ、イコール、起こっている問題から目を背けるという行為です。これをやってしまうと、アプリケーションをきちんとした品質にするのに余計に大変な思いをすることになるのです。せっかくの優れた仕組みなのですから、最大限、その恩恵に預かりましょう。

さて、一連のSaaSシリーズの締めくくりは、SaaSと従来のパッケージとの対比をしてみたいと思います。

SaaSとパッケージを比較した場合、どちらも「既製品を提供する」という部分は同じです。どちらも受託開発ではなく、自社のノウハウをベースに自社がリスクをとる形で開発を進め、売るという部分は同じです。そういった提供者側の経済的な効果ではSaaSはパッケージ開発・販売の1形態と考えることができると思います。パッケージソフトは提供者側の立場で見た場合、自分でリスクを負う分、粗利を大きく稼げる可能性があるというメリットがありますが、その部分に関してはパッケージもSaaSも同じといえます。

ではサービスの提供形態の違いという点ではどうでしょうか？　最近ではパッケージ型についても売り切りではなく、期間契約型のものがでてきています。例えばアンチウィルスソフトなどでは1年毎に契約を更新しないと利用し続けることができないものがありますが、こういった形態の場合、実質的にユーザ側の経済的な効果の違いはないと言えます。

そのような場合には、SaaSとパッケージの違いは単に技術的な違いだけなのでしょうか？　いや、１つ忘れてはならない部分があります。それはSaaSではシステムの運用の大部分をシステム提供会社が行う、という点です。

つまり各種インフラ（通信環境、設置場所、バックアップの仕組みなど）およびハードウェア、ソフトウェア一式をすべてシステム提供会社側が提供するという点が大きく異なります。こういった設備をマルチテナント方式（複数のユーザが相乗りして利用すること）で利用することにより、コストの最適化が図れることになります。

まとめると、SaaSは期間契約タイプのパッケージソフトと似ていて、さらにその運用をマルチテナント方式でアウトソースしている形態、ということができます。

SaaSというと従来との技術的な違いばかりが強調されがちですが、サービスという視点で考えたときに、実はたとえ従来の技術をベースにしたとしても同じような効果を出せることがわかると思います。重要なのは利用する技術の違いではなく、システムの提供者、ユーザそれぞれにどのようなメリットを提供できるか、です。私がSaaSが優れていると感じるのは、技術的な面の違いよりも提供できるメリットの違いです。単なる技術論で終わることなく、その優れたメリット・可能性を考え、このモデルに移行する時期が来たのではないかと考えています。

連日すごい暑さですね。

夜にせみに襲われるとちょっとびびりますよね。

せみが毎夜、会社の窓に捨て身のタックルをしています。びっくりするような音です。また、会社の窓から洩れる明かりに反応してか、昼間と同じくらいの大きな音で鳴いています。

昨日までは技術者の立場から見たSaaSというテーマで書いていましたが、今日は自分が経営者になったつもりで見てください。以降では受託開発をベースとしたシステム開発型モデルとSaaSを利用したシステム提供型モデルの対比として話を進めます。

昨日の技術者の立場から見たSaaS その２で「改善」という観点の話を書いたのですが、このことは経営者の立場から見た場合、大きな強みになります。

例えば今、Salesforce.comに対抗するようなシステムを受託によるシステム開発型モデルで作り上げることができるでしょうか？　SaaSを利用したシステム提供型モデルのシステムはマーケットの要求に応じてどんどん改善＝進化していきます。一方でシステムが進化しても価格が上昇するわけではありません。それらはすべて、サービス料の中に含まれているのです。最初は受託でもあまり差がなかったとしても、システム提供型モデルのシステムは徐々に改善を続けた結果、いずれ受託開発では追いつけない高みにいってしまうことになります。

こういうとERPの例を出して否定する人もいるかもしれません。つまり、ERP導入がさかんだったころ、パッケージをベースにしても対象顧客向けの作りこみ（アドイン）が大量に必要になることが多く、かつそのアドインを開発するにはそのERPの専門の技術者でないと対応できないということがありました。このためパッケージを導入してもあまりメリットがなかったじゃないか、SaaSにしてもこれは同じではないの？という意見です。

しかしSaaS時代のシステムの場合、システム間連携のためのインターフェース（API）はWebサービスという標準的な技術で提供されます。これは対象のシステムの専門の技術者でなくてもシステムへのアドインが開発できることを意味し、システムのコンポーネント化、すなわち水平分業化が可能になることを意味します。

継続的な改善は大きな力となります。継続的な改善が可能なSaaSを利用したシステム提供型モデルは受託開発をベースとしたシステム開発型モデルを徐々に駆逐していくことになると考えます。

さて今日は昨日の「技術者の立場から見たSaaS」の続きです。

技術者の立場で考えた場合、SaaSにはもうひとつの大きな違いがあります。それは1度作ったら終わりなのか、何度も改善を積み重ねていくものなのか、という違いです。

システム開発会社の受託したシステムの場合、基本的には作って納品してしまえばおしまいです。もちろん保守もあるにはありますが、エンハンスが続く場合は別として、通常の保守の場合システムの障害対応がメインであり、中身を改善して作りかえるということはあまりしないと思います。

一方のSaaSによるシステム提供会社の場合には、そのシステムは大切な商売道具であり、絶えず改善が求められることになります。作ったらおしまいではなく、中身をどんどん改善していかなければ他の競合他社に負けてしまうのです。

この特徴はパッケージ製品を提供している場合でも同じはずです。つまりパッケージ製品の場合でも、通常は何度も改訂を重ねて改善していきます。ただしパッケージ製品の場合には見た目を華やかにする「売る」ための機能追加がメインになっているとおもいます。一方のSaaSの場合、自社で運用するために実際に「使える」製品にすることにも自然と注力せざるをえません。つまりセールストークのための機能追加よりはシステムの安定性や通常の使いやすさの改善に力をいれなければならないということです。

システムを受託開発するとき、きちんと動きはするものの技術者としては納得のいかないレベルでの納品が必要になる場合があります。そして一旦納めてしまうとそのシステムはそうそう改善するチャンスはありません。しかしシステム提供会社の場合には保守をしやすくするための改善をやるチャンスがあります。もちろんマーケットの要求に応じることが最重要ですが、それをやりつつ、既存のコードのリファクタリングも行うことが当たり前になるのです。

さて、あなたはどちらの技術者のほうが幸せだと思いますか？

すごい暑さですね。

今日も自転車で出社したのですが、車が少なくて快適でした。

最近、日経新聞とかにもSaaSという言葉が踊っていて驚かされることがあります。NBOnlineでもつい先日、SaaSでもっとも成功している企業の例としてSalesforce.comの話を取り上げていますね。

以前のブログでシステム開発会社とシステム提供会社というテーマでSaaSの進展に従ってシステム会社の「製造業」から「サービス業」への転換が始まるという話を書きました。SaaSの本質は、技術的な面よりもむしろ、今までオーダーメイドで作っていたのを止めて、既製品を提供する商売へ転換するということだと思います。

その意味ではパッケージ商売と近い部分があります。ただしパッケージ商売の場合、ソフトウェアだけを売り物（正確には使用許諾権ですが）にしていたのに対し、SaaSではもっと広く、利用するためのバックエンドの仕組みを含めて全体をサービスとして提供します。つまり、作っては売る「製造業」の世界から、継続して様々なサポートを提供するサービス業への転換を意味することになります。

システム開発会社の世界では製造力、すなわち技術力（と体力？）の勝負ですが、システム提供会社の世界では技術力もさることながら、他にも企画力や運営能力など、総合的な能力が問われるようになります。

ではシステム開発会社の技術者とシステム提供会社の技術者では違いがあるのでしょうか？　技術者という立場からみれば、作るのは同じじゃんと思うかもしれませんが、実は大きな違いがあります。それは顧客との関係という点です。

オーダーメイドでシステムを作る場合、顧客と開発会社の関係は主従の関係になります。つまり顧客のほうが開発会社よりも圧倒的に強い立場になります。顧客の言うことには従わなければなりません。

一方のシステムを提供する立場の場合、システム・オーナは自分自身（の会社）なのです。もちろん多くの顧客に使ってもらうために様々なサービスを顧客に提供していかなければなりませんが、システムがどうあるべきかは自分達が決めることになるのです。もちろん会社の内側を見ると企画側と開発側での綱引きとなるのですが、そうは言っても自分の会社自身がシステム・オーナであり、どういうシステムとすべきかという部分に技術者がより主体的に関与できるという点で、大きな違いがあるといえます。

自分達のシステムであれば、作るシステムへの愛着も格別かもしれませんね。