OnSheet
オンライン表計算アプリ「OnSheet」
インフォテリアは7月25日、Webブラウザから利用できる表計算アプリケーション「OnSheet」を開発、ベータ版の公開を開始した。法人向けにSaaS形式で10月から提供する。料金は未定。また個人向けには無料でサービスを提供する。
同社のデータ連係技術と香港のTeam and Conceptsが開発したブラウザベースの表計算技術を組み合わせた。Excelなどのデータを読み込むことができ、表計算のほか36種類のグラフ描画機能も備える。500種類以上の関数のほか、罫線を引くことも可能だ。シートは自動的に保存され、編集ごとに履歴も保存され、遡って過去のシートを閲覧することもできる。
ワークシートやグラフには固定のURLが与えられ、パーマリンクとして利用できる。
また表の一部やグラフなどをブログに貼り付けることもできる。iFrameまたはJavascriptを使い、表の変更は動的に反映される。
＊ITMediaから転載＊
JavaSpeechAPI
Java Speech APIとは
Java Speech API(以下、JSAPI)はJavaアプリケーションに音声認識や音声合成の機能を組み込むためのAPIである。Java Speech API自身はJCPがスタートする前に発表されたのでJSRは存在せず、Sun Microsystemsのサイト上でその仕様が公開されている。
JSAPIを使用することで、Javaプログラムで音声の認識や合成を行うことができるようになる。たとえば、合成音声によってテキストを読み上げるというような処理の実装が容易に行える。
JSAPIの代表的な実装としてはオープンソースで開発されているFreeTTSがある。商用の音声認識/合成ツールのような高度な機能は有していないが、JSAPIを試すには十分な機能を提供してくれる。
企画とマネジャー
ITMediaから転載
「企画を出せ！」そのとき試されるマネジャーの能力
「企画をつくる仕事」というのは本来楽しいもののはず。しかし、部下がピンとこないのはあなたに問題があるのかもしれない。マネジャーのあなたは、部下にハッパを掛けるだけではもちろんダメだ。マネジメント能力が求められているのだ。
役員から命令を受け、画期的な商品企画や営業企画を策定することを任されたあなたは、部下たちに対して「とにかく企画を出せ」と命じた。部下たちは「頑張ります」とは言ったものの、本当は途方に暮れている。そして、あなたの知らないところで、こんなセリフが深夜の会社でささやかれる。
「この間も突然企画を出せと言い出したけど、あのときの企画はどうなったんだろう」「企画力でマネジャーになったの？ あの人」「数を出せば、何とかなるだろうなんて、付き合いきれないよ」
そう、あなたが役員に対して感じたことを部下たちも感じてる。「また始まった。前回出した企画はどうなったんだ。何時間残業して企画をねったと思っているんだ」――。
しかし、あなたはどうしようもない間違いをおかしたわけではない。部下がピンとこないのは、あなた自信が良い提案をしていないか、あなたのチームが企画による成功体験を持っていないからだ。
「とにかく企画を出せ」という命令はマネジメントとは言えない。あなたは上役から何を求められ、企画を必要としているのか、理解して指示を出したかが問題だ。
ダメ企画はすべてマネジャーの責任
「企画が成功しない原因は、それをマネジメントする側にある」というのは、外資系企業で数々の商品企画を成功に導いてきた経営コンサルタントの長谷川和廣氏だ。
昨年まで同氏がCEOを務めていた眼鏡レンズメーカーのニコン・エシロールはデフレの値引き合戦による赤字経営に苦しんでいた。同氏のCEO就任以降、見事、黒字に転換しているが、その原動力になったのは、新商品企画だった。世界的にも有名な同社の「バリラックス」ブランドで、高機能の遠近両用レンズの新製品を開発。当時の業界の常識では考えられない高めの価格設定で市場に投入したが、消費者に受け入れられた。商品は売れても利益が出ないという厳しい市場環境の中、勝ち組へと転換した。
実はこの高機能の商品企画は、現場のR＆D部門のシーズや、営業やマーケティング部門が読み取った消費者のニーズから発想したものではなかった。低価格路線を続けても利益は出ないため、付加価値のある高機能商品で利益率を高めたいという経営上の戦略が第一にあり、その目的に向かって商品企画を立案したのだ。
「シーズやニーズは、企画のもとになる重要な要素です。だから、R＆D部門はシーズにこだわって発想しようとするし、営業はニーズから発想を組み立てる。それ自体は間違っていませんが、目的を設定しないままシーズやニーズから企画を立てていくと、的外れな企画になりがちです」と長谷川氏。
いくら画期的だったり、消費者心理を満たす企画であっても、目的を達成できなければ意味がない。部下に企画の提案を求めるときは、目的を明確にして企画の到達点をしっかり示すことが先決だ。
チームの目指す方向を示せ
シーズやニーズをもとにギリギリ知恵を絞っているマネジャー層は多いだろう。しかし、そもそもその発想が企画力を弱めているかもしれないのだ。
企画はまず数を集めるということは大前提だが、目的を明確にしないまま「数を出せ」と言っても、部下たちはすぐに息切れしてしまう。マネジャーは一呼吸置いて、経営課題を再確認して、何が求められるかを明確にしたい。統括するチームのメンバーは、あなたの指差す方向を探しているものだ。
マネジャーというのは、チームにとってオーケストラの指揮者のような存在だ。演奏者としての経歴は必要ない。バラバラの個人プレーではない、チームを基礎にした企画を実現するには、その方向を示さなければならない。マネジャーは、ハッとする企画をひねり出す部下を育てればいいのだ。
ハッとする企画が備える7つの条件
マネジャーが方向性を示さないまま集められた企画は、ハズレ企画の山になることが多い。「いい加減にしろ」と部下を怒鳴っても時すでに遅し。部下に企画を立てさせるときは、7つのポイントを押さえさせるようにしたい。
方向性を示すことなく「出せ出せ」と部下に企画を要求するだけでは、マネジャーとは言えない。具体的にどう企画マネジメントしたらよいのだろうか。眼鏡レンズメーカーのニコン・エシロールの元CEOで、経営コンサルタントとして活動している長谷川和廣氏に企画マネジメントの心構えを聞いた。
企画立案に必要な7つのプロセス
部下に企画を立てさせるときは、7つのポイントを押さえさせるようにしたい。
（1）背景・経緯
（2）現状の課題
（3）課題改善の可能性
（4）目標
（5）目標達成のためのアクションプラン
（6）経済性
（7）ほかに与える影響
この7つは、企画を立案するときのプロセス順に並んでいる。まず情報収集して現状を把握、そこから課題と改善可能性を洗い出す。数ある改善可能性の中からターゲットを絞り、それを実現するための企画を立てる。さらに、それが会社にどんな利益をもたらし、どんなリスクをはらんでいるかを検証する――というわけだ。
企画立案というと、このうちの（5）のアクションプランだけを考えようとする部下は多い。しかし、前後のプロセスが抜けた企画は、ただの思いつきにすぎない。商品企画にしろ、営業企画にしろ、7つの手順が順番にそろってこそ、はじめて企画として価値を持つことを部下に徹底させるべきだ。
例えばヒットの可能性を秘めた商品企画があっても、自社がすでにその類似製品で圧倒的なシェアを取っているなら、新しい商品を投入する意味はない。にもかかわらず、そんな企画を上げてくるのは、（1）背景・経緯の把握と（2）現状の課題の洗い出しというプロセスが抜けているからだ。
あるいはヒット確実な企画でも、多大な投資が必要で豊富な資金力がある企業にしかできないものもある。自社が中小企業なのにそういった企画を部下が提案してくるのは（6）経済性の検証ができていないからだ。
では、部下にどうやってこの企画立案プロセスを徹底させるか。もっとも簡単なのは、このプロセスに応じたフォーマットで、企画書を作らせることだ。最初から（1）～（7）を書きこませるようなフォーマットを作っておけば、どこかが抜け落ちるようなことはない。
会計知識がなければ企画はできない
部下から上がってきた企画を、どのように判断すべきか。これも企画をマネジメントする上で大切なポイントだ。
判断基準はさまざまだが、長谷川氏が特に重視していたと言うのは提案者の質だ。過去に企画の成功体験を持ち、その経験を自分の中でメソッドになるまで消化させている部下なら、ほぼゴーサインを出す。また、詳細を突っ込んで質問したときに即座に答えられる部下の企画も、承認を出しやすい。「次までに調べてきます」と答える部下は、企画に対する熱意が足りないと判断していい。単なる精神論ではなく、熱意が足りない部下が持ってくる企画は、たいてい生煮えで、どこかに落とし穴があるものなのだ。
もちろん人だけではなく、企画の中身の精査も必要だ。そのためには、（1）～（7）の企画プロセスを、マネジャー自身も自然に使いこなせるレベルまで身につけておかなくてはいけない。当たり前だが、企画を精査するには、自身が優秀な企画マンであることが前提条件になる。
中でもマネジャーが重視すべきは、（6）経済性の検証ではないだろうか。かうての日本企業では、企画の着眼点が良く、なおかつ前例があれば、案外簡単に承認が下りるケースが多かった。しかし、外国企業は企画事にP／L（損益計算書）の計画書の提出が必要であり、マネジャーは発想の目新しさよりも、その部分を何度もチェックする。企画を提案する側も、それを承認する側も、論点になるのはいつも「いつまでにいくら利益が出るのか」ということだ。
いまや日本企業も変わりつつあり、厳密なP／Lまでいかずとも、利益という視点なくしては、企画の提出、承認が難しくなってきた。今後、その傾向がますます強くなれば、当然マネジャーにはより深い会計の知識が求められるようになるだろう。
例えば部下の企画書では売上1億円の見込みになっているが、本当にそれが可能なのか。あるいは販促費500万円という計算になっているが、それだけで済むのか。別に会計のエキスパートになる必要はないが、少なくともそういった数字を関係部署や関係者に確認して精査できるコーディネート力が必須になるはずだ。
突き詰めていけば、企画マネジメントは事業をマネジメントするのとあまり変わらない。企画となると、アイデアの質を問いたくなるマネジャーもいるかもしれないが、あくまでも「ビジネスとしていくら利益が出るのか」という視点が大切なのである。
「良いダメ出し」が10倍知恵を絞る部下を育てる
部下を褒めるのは難しいが、ダメ出しはもっと難しい――マネジャー自身が普段から企画についての明確な判断基準を持っているかどうかが、企画に対する部下のやる気を左右する。
部下に企画を出すよう命じるときには「何を求めているか」方向性を明示しないと、後の企画会議が空中分解する。部下たちの間に「どうせ企画を出してもどうせボツなんだろう」という空気がまん延したらおしまいだ。
「どうしてボツなのか」を説明できるか
7つのチェックポイントを提案する眼鏡レンズメーカーのニコン・エシロールの元CEOで経営コンサルタントの長谷川和廣氏によれば、人材が豊富な大企業でもこのようなチェックポイントを精査せずに、企画提案をしているケースが多いという。
長谷川氏は「できるだけ自由な発想をさせたいという狙いがあるのかもしれませんが、どの方向にいけばいいのかを示さずに提案をさせても、結局はハズレ企画の山になってしまいます。自由な発想というのは、ある程度制限がなければ出てきません。制限があると、それをクリアさえすれば、自分の提案が受け入れられるかもしれないというリアリティが生まれます」と語る。
企画マネジメントにおいて最初に大切なのは方向を示すことだが、付け加えるなら「どうしてボツなのか」を説明することも同じぐらい重要だといえる。
「緊急企画会議」で議題にされる企画
そもそも、企画は2種類に大別できる。
従来から取り組んでいる仕事の延長線上にあり、その仕事に対する改善案的な意味を持つ企画と、延長線上にはあるもが新機軸を含んだ企画の2種類である。
前者は、部下からも求めている方向性を比較的理解されやすい。「この間、だれかこんなグチをいっていたな」というようなところから、具体的なプランが出てきたりする。
しかし後者は異なる。「いつもの報告は聞いているけど、キミのところは毎回、同じことを繰り返しているだけじゃないか。もっと新しいアイデアはないのか」などと上役から突然言われるようなケースである。
上役の言葉の裏には「当然、新しい取り組みぐらい普段から考えているんだろうね」というニュアンスが込められている。そこで、チームメンバーに緊急呼び出しを掛けるわけだ。
慌てている上司を見透かす部下
もちろん部下が1人か2人であろうと、マネジャー1人で「新機軸」をひねり出すよりは協力があった方がいい。
長谷川氏は「たった1人で何か新しいことをしようというのは、土台無理なことです。本人がどんなにすばらしいアイデアマンでも、複数の人の協力を仰ぎながら企画を練るべきです」と語る。
ここで、普段からのマネジメント力が問われてくる。
緊急企画会議を招集して、メンバーに自分が言われたことを告げる。しかしそれだけでは漠然としているので、やおら雑談モードで場を和らげながら「自由闊達な議論」を展開しようとする。しかし、メンバーはマネジャーの置かれた状況を瞬時に把握している場合が多い。
「また、だれかに言われて慌てているな」という具合である。
そこから、何とかメンバーが知恵を絞ってくれるかどうか。これには、普段からのマネジメント力、もっと言えば「ダメ出し力」ともいうべき力をマネジャーが発揮していたかどうかに掛かる。
日常のダメ出しが熱い部下を生む
「良い企画が部下からどんどん出てくることはめったにありません。特に新機軸が求められるような企画の場合には、なかなか出てこないはずです。当然メンバーが必死になって知恵を絞る必要があります。そこまでの意欲を引き出せるかどうかは、日常の中で『ダメ出し』がしっかりできているかに掛かっています」 (長谷川氏)
7つのチェックポイントなどを活用して、マネジャー自身が企画に対し明確な基準を持って判断しているかどうかなのだ。メンバーから、ぶれのない判断をしていると評価されていれば、彼らが知恵を絞るモチベーションも高まる。
あいまいな判断基準では、メンバーの企画に対する情熱もなくなる。企画マンとして将来独立できるぐらいの力量を持ったメンバーがそろっていれば話は別だが、そうでなければ、ダメ出しには最も神経を使うべきだ。
「なぜ、その企画がダメなのかを7つのポイントで判断すると、企画を出した方も不満はたまりにくい。このポイントは（1）～（7）まで順番にチェックしていくことです。背景・経緯という最初の段階でつまずいているのか、最後の段階で考えが甘いのか、説明もしやすいはずです」(長谷川氏)
褒めることも難しいが、ダメ出しはもっと難しい。しかし、これを意識して普段からマネジメントしていると、あなたが率いるチームに粘り強い積極性が生まれてくるはずだ。
MG4J
MG4J (Managing Gigabytes for Java) is a free full-text search engine for large document collections written in Java. As a by-product, it offers several general-purpose optimised classes, including fast & compact mutable strings, bit-level I/O, (possibly signed) minimal perfect hashing for very large strings collections, etc.
With release 1.1, MG4J becomes a highly customisable, high-performance, full-fledged search engine providing state-of-the-art features (such as BM25 scoring) and new research algorithms. Release 2.0 significantly improved performance and introduced several new features.
The main points of MG4J are:
* Powerful indexing. Support for document collections and factories makes it possible to analyse, index and query consistently large document collections, providing easy-to-understand snippets that highlight relevant passages in the retrieved documents.
* Efficiency. We do not provide meaningless data such as "we index x GiB per second" (with which configuration? which language? which data source?)—we invite you to try it. MG4J can index without effort the TREC GOV2 collection (document factories are provided to this purpose) and scales to hundreds of millions of documents.
* Multi-index interval semantics. When you submit a query, MG4J returns, for each index, a list of intervals satisfying the query. This provides the base for several high-precision scorers and for very efficient implementation of sophisticated operators. The intervals are built in linear time using new research algorithms.
* Expressive operators. MG4J goes far beyond the bag-of-words model, providing efficient implementation of phrase queries, proximity restrictions, ordered conjunction, and combined multiple-index queries. Each operator is represented internally by an abstract object, so you can easily plug in your favourite syntax.
* Virtual fields. MG4J supports virtual fields—fields containing text for a different, virtual document; the typical example is anchor text, which must be attributed to the target document.
* Flexibility. You can build much smaller indices by dropping term positions, or even term counts. It's up to you. Several different types of codes can be chosen to balance efficiency and index size. Documents coming from a collection can be renumbered (e.g., to match a static rank or experiment with indexing techniques).
* Openness. The document collection/factory interfaces provide an easy way to present your own data representation to MG4J, making it a breeze to set up a web-based search engine accessing directly your data. Every element along the path of query resolution (parsers, document-iterator builders, query engines, etc.) can be substituted with your own versions.
* Distributed processing. Indices can be built for a collection split in several parts, and combined later. Combination of indices allows non-contiguous indices and even the same document can be split across different collections (e.g., when indexing anchor text).
* Multithreading. Indices can be queried and scored concurrently.
* Clustering. Indices can be clustered both lexically and documentally (possibly after a partitioning). The clustering system is completely open, and user-defined strategies decide how to combine documents from different sources. This architecture makes it possible, for instance, to load in RAM the part of an index that contains terms appearing more frequently in user queries.
The starting point for understanding MG4J is a look at the tutorial, which explains how to index a sample collection and query the newly constructed index from the command line or using a browser. Then, the Javadoc class documentation can provide more insights.