iPod selection ビジネス書～有名な本15冊が要約して把握できるソフト

iPod selection ビジネス書（ソースネクスト）
http://www.sourcenext.com/titles/sel/79480/

いわゆる邪道ですが（笑）、結構いいです、これ。15冊全部今まで読んだことなくて、そのうち5冊ぐらいは読んでみたいなって思っていた本です。一般的なネタを題材にしたビジネス書ってのは何十冊か読んでいくと大体同じことを言っているので、一冊あたりから得るものが少なくなってしまいます。そういう境地に入っている人にとっては重要なポイントだけ抜き出していてくれるので時間・コストとも効率良いです。
＃今をトキメク勝間さんは、「本は新品を買いなさい」と印税が減らないように主張してますが、それに真っ向から対立するソリューションなので怒られちゃいそうですね～（笑）。

一冊あたり20分弱程度です。ちなみに要約してあるので集中して聞かないとすぐ終わってしまいます（--;。2回聞くと頭に入りそうです。ちなみにどの本もいいこと言っていますが、ちゃんと読んでみたいなと思ったのはコトラー入門ぐらいでした。

・金持ち父さん貧乏父さん
・ウェブ進化論
・マーケティングを学ぶ人のためのコトラー入門
・リッツ・カールトンが大切にするサービスを超える瞬間
・チームリーダーの教科書
・「キャバクラ」の経済学
・会社はこれからどうなるのか
・相手の心を絶対に離さない心理術
・部下をやる気にさせる100の方法
・日本のもの造り哲学
・なぜ、「できる人」は「できる人」を育てられないのか?
・パワー・ブランドの本質
・企業とステークホルダーを結合させる「第五の経営資源」
・ウケる技術
・一冊の手帳で夢は必ずかなう
・なりたい自分になるシンプルな方法
・2分以内で仕事は決断しなさい

タグ：ビジネス書 iPod ソースネクスト

Foxit Reader 3.1のメニュー日本語化

Foxit Reader はA*とくらべて軽量なことが定評のPDFリーダーです。

で、ver3.1で日本語メニューが準備されていません。翻訳途中のものを拾ってきたら中身が中途半端だったので、翻訳にregistrationして直そうと思ったんですが、Web翻訳ツールがバグってて上手くいかないので、生ファイルを修正してしまいました(--##

ということで我慢ならない部分だけ修正したものをアップしました。（使用は自己責任でお願いします）
せっかくいいソフトなんだからちゃんとしてほしーなあ。MOTTAINAI。

使用法
(1)ファイルを保存して、lang_jp_jp.xmlにリネームしてFoxit.exeと同じフォルダに置いてください。
(2)tool->preference->languageでjapaneseを選択すると日本語表示になります。
http://komlog2.blog.so-net.ne.jp/_images/blog/_f2e/komlog2/lang_jp_jp.jpg

タグ：foxit PDF

Googleドキュメント 自動アンケート集計フォームの実験

正月で時間のある時に何かやってみよう企画です。

Googleドキュメントに「フォーム」という機能があります。これはアンケートなどの集計をいちいち自分でやらずに、Webフォームの形で自動的に集計する機能です。母数が数十になるとアンケートの集計の手間もバカにならないので、これを活用すると便利かもしれません。

・公開フォームのサンプル（ページで表示）
https://spreadsheets.google.com/viewform?formkey=dEUwWDIzbkRXVEdDQXFDOTZtQ0Znd3c6MA

・公開フォームのサンプル（ブログに埋め込んでみたバージョン）


・集計結果
フォームの集計は、Google ドキュメントのページから見えます。以下は詳細ページ（表計算ドキュメント）の画像です。


・メリット・デメリット
・作る手間は慣れると約5分（上記サンプルの場合）
・フォームはメールで送信することもできます。
・アクセス制限、回数制限は今のところできないっぽい。そのうちできるかもしれませんが。


幹事が多い方とか利用してみてはいかがでしょうか？

タグ：Google ドキュメント フォーム

OpenOffice.orgのスクリプト（マクロ）にJava(BeanShell)を使用するためのメモ（３）

挫折したので最終回です（笑）。やはり最低限のIDEがないとDebugができないので厳しいです(;o;。とりあえず調べたところまで書いておきます。

○Calcのサンプルコード

//クラスをインポートします。おまじない（・人・）

import com.sun.star.uno.UnoRuntime;

import com.sun.star.uno.AnyConverter;

import com.sun.star.uno.Type;

import com.sun.star.lang.XComponent;

import com.sun.star.lang.XMultiServiceFactory;

import com.sun.star.frame.XComponentLoader;

import com.sun.star.document.XEmbeddedObjectSupplier;

import com.sun.star.beans.XPropertySet;

import com.sun.star.beans.PropertyValue;

import com.sun.star.container.*;

import com.sun.star.chart.*;

import com.sun.star.table.*;

import com.sun.star.sheet.*;

import com.sun.star.script.provider.XScriptContext;

loader = (XComponentLoader) UnoRuntime.queryInterface(

XComponentLoader.class, XSCRIPTCONTEXT.getDesktop());

//既に存在するファイルに対しての処理は以下のように行います。Windowsの場合は引数1のようなファイルパスの書き方をしてください。

comp = loader.loadComponentFromURL(

"file:///c:/test.ods", "_default", 4, new PropertyValue[0]);

//文書

doc = (XSpreadsheetDocument)

UnoRuntime.queryInterface(XSpreadsheetDocument.class, comp);

//文書構造

index = (XIndexAccess)

UnoRuntime.queryInterface(XIndexAccess.class, doc.getSheets());

//シートの選択、一番左のシートが"0"です。ここらへんVBAとは異なります。おそらく名前で指定することも可能。

sheet = (XSpreadsheet) AnyConverter.toObject(

new Type(com.sun.star.sheet.XSpreadsheet.class), index.getByIndex(0));

//文字列などの挿入、セルのアクセスもA1->(0,0)のように0から始まります。あとVBAと異なり(行、列)の順番なので注意してください。

sheet.getCellByPosition(0, 0).setFormula("Test" + 1);

//ループしながら数字の代入

for(int i=0;i<200;i++) {
sheet.getCellByPosition(0,i).setValue(i);
}
こんな感じのイメージです。


○なんとかjEditからBeanShellを叩けるようにする道のりの途中
BeanShellを作成、クラスを読み込んでいるところまではソースを追いました。BeanShellのデバッグウィンドウはswingで書いてあるようです。

・ソースのパス：OOE680_m6\scripting\java\com\sun\star\script\framework\provider\beanshell\

・ファイル：ScriptEditorForBeanShell.java
　　public void actionPerformed(ActionEvent e) {
　　で execute();
　　が実行される
public Object execute() throws Exception {
　　で
return model.execute( context, cl );
　　が実行される。クラス、メソッドはそれぞれ以下の定義。
private ScriptSourceModel model;
private XScriptContext context;
private ClassLoader cl = null;
　　ScriptSourceModel はScriptSourceModel.javaの内容を参照。つまりここに何を渡しているかが重要です。

・ファイル：ScriptSourceModel.java 要約すると以下のようになっています。
public Object execute(final XScriptContext context, ClassLoader cl ) throws Exception
{
Object result = null;
if ( cl != null ) {
Thread.currentThread().setContextClassLoader(cl);
}
bsh.Interpreter interpreter = new bsh.Interpreter();
if ( cl != null ) {
interpreter.getNameSpace().clear();
}
interpreter.set("XSCRIPTCONTEXT", context);
interpreter.set("ARGUMENTS", new Object[0]);
if (view.isModified()) {
result = interpreter.eval(view.getText());
}
else
{
result = interpreter.eval(getText());
}
return result;
}
んー、どこでclが定義されるんだろう。nullのままの気が。。。

OpenOffice.orgのスクリプト（マクロ）にJava(BeanShell)を使用するためのメモ（２）

○序文～開発環境を整える

ほんとーはこれを書く頃までには解決しているはずだったのですがドはまりしてUnsolvedです(;o;。1日探して解決策が無いのでとりあえず状況だけ残しておきます。

○外部のエディタをIntegrate

本当はBasic並みのエディタが起動してくれれば一番うれしいのですが、OOoのソースコードに戻って構築するだけのスキルはありません(;o;。設定項目にも無さそう。

○外部のエディタから叩く

多分これが手っ取り早いです。で、これをやろうとしたとき以下のサイトに当たると思います

（１）http://framework.openoffice.org/scripting/scriptingf1/developer-guide.html（古）…コーディングの方法は参考になると思います。ただしリンク先にある「Developing Scripts in NetBeans 」等はモジュールやバージョンが古いです。つまり外部のエディタから叩くという目的では情報不足。

（２）http://wiki.services.openoffice.org/wiki/OpenOffice_NetBeans_Integration…NetBeansでOOoのアドイン・アドオンを開発できます。上記のWikiに"OpenOffice.org Scripting Project Type"とありますが、現時点では使用できないようです。しかも"currently the support is planned for Java scripts only"とまで書かれているのでやはりBeanShellは少数派か(;o;

（ちなみにアドイン・アドオンとスクリプトの差は（a）コンパイルが必要か、と（b）使い捨てレベルかという定義でいいと思います）

（３）煮詰まり具合が伝わったでしょうか？f（^^;）。かなり割り切りが入ってきたところでエディタで飛ばせばいいじゃんということでjEditです。BeanShellのコーディング機能があります。http://www.jedit.org

現時点でのベストはjEditで編集してDebugWindowにスクリプトを貼り付けるというやり方です。実はｊEditからBeanShellを制御する方法があってスクリプトの実行までできると貼り付けたりする手間がなくなるのですが、現時点でOOoの制御までうまくいってません（クラスパスにそれっぽいものを与えても×）。なのでとりあえず以下にスクリプトを実行するところまで記しておきます。

。。。まずjEditをインストールします。もともとjEditはBeanShellをマクロ言語として使用していますが、BeanShellの開発・実行環境とするにはひと手間かかります。

・インストール後"Plugins"->"Plugin Maneger"の"install"タブで"SuperScript"にチェックを入れて"install"ボタンを押すと、プラグインがインストールされます。

・"Plugins"->"Plugin Options"で"beanShell"にチェックを入れて"Apply"をクリック。これで準備が完了です。

・最後にもうひとつ。ホームディレクトリ（Windowsの場合はc:\Documents And Settings\ユーザ名 以下）にある.jedit/jarsフォルダにbsh.jar（http://www.beanshell.org/からダウンロード、バージョン名がファイル名になっているのでbsh.jarにリネーム）をコピー

・jEdit再起動

これでメニューからPlugin->SuperScriptを選択するとjEditから直接BeanShellが叩けるドックウィンドウが現れます。

○リソース

・言語はどれがいいか？のDiscussion

http://www.oooforum.org/forum/viewtopic.phtml?p=207906

OpenOffice.orgのスクリプト（マクロ）にJava(BeanShell)を使用するためのメモ（１）

突然ですが掲題の作業を始めました。随時更新します。

○動機

・「いやぁ、そろそろデータはサーバで作らないと」と言って、職場で堂々とJavaの勉強をするため（笑）。

・BasicだとOpenOffice.org(以下OOo)内部で呼び出す必要があるが、Javaで書いておけば後でオフィスドキュメントサーバとして動かすときに移植が楽そう（多分）

○前置き

職場ではバリバリのVBA使いな私ですが、本格的にJavaを勉強するにあたり教材として実益も兼ねそうなOOo＋Java(BeanShell)を選びました。OOoはスクリプトとしてBasic/Java(Beanshell)/JavaScript/C++/Phytonを使用できます。この中でBasicはVBAを意識したものになっており、比較的日本語の紹介ページも増え始めたり、製品版のStarSuiteでは移植ツールも用意されていたりとこれからの発展が期待できます。しかしそれ以外の言語に関しては原典をたどる必要があったりしてあまり普及しているとは言えません。そんなイバラの道状態のOOo+Javaですが、この記事がとりあえず興味を持った人のための参考になったらうれしいです。

○使用バージョン

OOo-2.1.0, OOo_SDK-2.1.0, JDK-1.5_11 with NetBeans

○とりあえず使ってみる方法

（１）Writerを開く

（２）メニューの「ツール」→「マクロ」→「マクロの管理」→「BeanShell」を選択

（３）ダイアログが開くので「OpenOffice.orgのマクロ」→「HelloWorld」→「helloworld.bsh」を選択

（４）テキストエディタ風のものが出てきます。ここで「Run」をクリックするとコードが実行され、Writerウィンドウに文字が入力されます。とりあえず雰囲気はこんな感じです。

さて、コードを書いていく以前の問題として開発支援ツールがありません。このテキストエディタですが機能はRun（実行）、Clear（全消去）、Save（保存）、Close(閉じる)の４つしかありません。Undoとか無いです。この環境はデフォルトで使用できる4言語のうち最下位です（普通ここであきらめますよね（笑））。ということでまず開発環境をマトモにすることにします。

○開発環境に関するリソース（次回詳しく解説します）

http://www.jedit.org

http://wiki.services.openoffice.org/wiki/OpenOffice_NetBeans_Integration

http://framework.openoffice.org/scripting/scriptingf1/developer-guide.html（古い）

大規模開発プロジェクトのドライビング（７）～集団ヒステリー前編

このテーマも第七回になりました。かなり一般化したつもりで書いていますが、実はそれぞれのテーマは常に自分が仕事をする上で困っていることです。こういったテーマに関していわゆるマニュアルのようなものはよく売られており、それを使用して飯を食っている人もいます。いままでのテーマに関してはわりと一般的だと思われますが、今回の集団ヒステリーはあまり知られていません（多分）。しかし結構簡単に陥りやすいので集団ヒステリーは注意が必要だと思われます。集団ヒステリーは内部だけで直すのが非常に困難です。経営のように外部から手を入れることが可能な場合は例えばカルロス・ゴーン氏を連れてくるという技もありますが、失敗が多くかつ最終的な結果を求められる研究開発などにおいては内部で集団ヒステリーに打ち勝っていくことが必要です。とりあえず好き放題書いてみるのでよかったらいろいろご意見ください。

○集団ヒステリーの例とヒステリー要因の分析１：経営難の会社

上でカルロス・ゴーン氏が出てきたので日産の例を挙げましょう。ご存知のように日産はどん底からV字回復をしました。さて、なぜV字回復ができたのでしょうか？リストラやコスト削減、ライン管理などいろいろな分析がされていますが、根底にあるのは集団ヒステリーです。

・リストラ→人を切るのは経営者として行ってはいけない（いや、正しいのですが…）

・コスト削減→いままでの仕入れシステムを変えるのは理由があるに違いない

・ライン管理→管理システムを変更すると何かトラブルが出たときの責任が取れない！

多少強引ですが共通して言えるのは既成観念への執着と変化への恐怖です。ただしこのケースが割りと楽なのは、改善していける正攻法が見えていること・会社にその体力があったことです。そして「救世主」として現れたカルロス・ゴーン氏が優秀だったのは重要なポイントです。

○集団ヒステリーの例とヒステリー要因の分析２：研究開発

研究開発が同じマネージメントでも難しいのは正攻法がない、厳しい場合には道筋も見えないということです。そして一般的なマネージメントでは対応が出来ないため内部のみでヒステリーに打ち勝っていかなくてはいけません。以下に陥りがちな状況を挙げます。

・うまく行かないので新しい方法を試そう…救世主頼みの無茶な計画

・ここはこうあるべきだ、○○がダメだとうまく行くはずがない…現実点と到達点の混同

・批判体質…実作業がうまくいかないと口だけ動かす人が増える

さて、３つ挙げましたがよく考えるとそれぞれtradeoffの関係になっていることが分かります。例えば新しい方法を試すのと固執するのは逆、また３つめの批判に関しても何も考えないでとりあえず試そうという姿勢はそれぞれ強弱の問題です。つまり集団ヒステリーとは「思考のバランスを欠いている」状態です。このような状態での客観的な解析は鞍点をさがしてくれないのでさらにどちらかに吹き飛んでいってしまう危険性もあります。さあ困った、どうやって抜け出そう…。

後編では集団ヒステリーに打ち勝つ方法を議論します。ポイントはスパイラルがポジティブかネガティブの見極めです。

大規模開発プロジェクトのドライビング（６）～Knowledge Management後編

実はGW中です。日々忙殺されていると本業以外に眼が行かなくなるもの。寝るのとゴルフは十分やったので今度はお勉強。ちなみに休む・遊ぶ・勉強を同じぐらいの割合でできるのが自分の理想の休日～。ってことでKM後編です。

○Context（文脈）付きDB

本当はもっとたくさん種類があるのかもしれませんが自分の知っている範囲でとりあえず挙げます。

・WSS,SPS

Microsoftの製品です。それぞれWindows Sharepoint Service, Sharepoint Portal Serverの略です。これらはMicrosoftが進めるWindows server強化の一環（多分）で、WSSのほうはWindows Server2003の無料アドイン、SPSはWSSの上位互換になっています。基本としては単層のポータルならWSSで済みますが、WSS同士をノードを作成して繋いだり、SQL serverを使って検索機能をつける場合はSPSが必要になります。基本的にまだ歴史の浅いソフトなので使い勝手の面で劣ることがありますが強力なメリットとしては、Microsoftの有り余る開発力を使って開発が継続されていくことと、Microsoft Officeファイルに対しインデックス付きの検索をかけられること※です。

※自分では試してないです。

※NamazuでOfficeファイル検索ができますが、日本語の文法解析やファイル構造解析がそれぞれ別ソフトなのでそこで限界が決まってしまうところがあると思われます。

現在のオフィス環境においてはMicrosoft Officeファイルを高効率で処理できることが重要なポイントの１つなので、（独占的で好きになれないという感情は置いといて）非常に魅力的な製品であるといえます。デメリットとしてはやはり歴史の浅いソフトなので拡張性、可用性、堅牢性の実績が未知数というのがあります。

・Lotus Notes

現在はIBMの製品です。ポータル・DBとしては歴史が長く、IBMで全社的に使われているので実績は十分です。したいことは大体出来ますがそれはサポート部隊の能力に寄ります。

以上が大規模プロジェクトにおけるKMとしてのDBの紹介です。

・Wiki

小・中規模までならWikiぐらいがちょうどいいかもしれません。メンテナンスコストが抑えられます。

http://pukiwiki.sourceforge.jp/

○Officeファイル検索

インデックスを作らない検索ならばOffice2003からOfficeアプリケーション上から検索を行うことが可能です。今手元に環境がないので詳細は書きませんが、「ファイル」のメニューから検索でそれが可能です。検索範囲はローカルからファイルサーバ上まで可能、検索はファイル名からファイル内まで選択できます。インデックスを作らず一つ一つのファイルを解析していくので検索対象が大規模な場合は注意してください。

○移行に関して

大抵いままでの仕組みを変えようとすると文句を言われます。なので一番楽なのは新しくDBを作る際に変えてしまうこと。途中から変える場合はなるべく最終的に負荷が増えない方法をとるのが好ましいです。人と場合によりますが、自分が好む方法は1から2に移行する場合は1.9ぐらいの移行技術を使用します。中途半端に1.5ぐらいのものを使用すると移行しない人がいたり、もう一段波が来るので最終的に二度手間になるケースが多いです。

以上KM関連でした。

次回は集団ヒステリーに打ち勝つ方法を考察します。

大規模開発プロジェクトのドライビング（５）～Knowledge Management前編

人が増えアウトプットが増えれば増えるほど、知識の共有の困難度は急上昇します。前回の標準化はいわば知識を共有化するための下準備です。最終目的として位置するのが、知識の適切な共有、すまわちKnowledge Management…KMです。

あなたの組織はどれだけKMできてる？チェックリスト！

ちょっとノリを軽くしました（笑）。質問に途切れたところがあなたの組織のレベルです。

Q1　ファイル（知識）が…

A1 そもそも何もない→ある意味何もする必要ないです(-"-;;

A2 何かある→Q2へ

Q2　自分に関連するファイル（知識）の置き場

A1　どこに何があるか分からない→DBの整理が必要

A2　どこに何があるか分かる→Q3へ

ここから難易度上がります。

Q3　自分に関連しないファイル（知識）の置き場

A1　どこに何があるか分からない→DBの整理とインデックスが必要

A2　どこに何があるか分かる→Q4へ

Q4　自分に関連しないファイル（知識）の思考の軌跡（context、文脈)

A1　分からない→インデックスとチームポータルが必要

A2　分かる→最強の組織です！

Q2までは常識で考えて分かる範囲です。整理整頓してあれば少なくとも自分が手を出す範囲に関してはすぐにアクセスが可能になります。仕事する上で自分の手を出す範囲さえ整理されていないのは問題なので早急に直しましょう。

問題となるのは組織が大きくなったときに発生するQ3以降のケースです。「知らないことは知っている人に聞けばよい」はある程度有効ですが、これは中規模までしか通用しません。アクセスだらけになります。これを防ぐには他の人にもファイルの場所が分かるようなインデックスやポインタを作ることが必要です。手法としてはWebシステム、Officeファイルなどのリンクつきの文書がお手軽です。

「ファイルをDBに置くにはトップレベルまでたどれるリンクでつながっていること」をファイルを置く上でのCriteriaにすればこれが実現可能になります。

さらにQ4というのは非常に難しく、人が考えた軌跡を追える、つまり情報にcontextが付属している状態です。これを実現するためには莫大なリソースが必要です。リソースと言っているのはユーザがそのシステムを使用するリソースと、そのシステムをメンテする管理者リソースの２つです。どの程度のシステムにするかはトータルコストで決まるはずです。ここで求めるシステムに必要なものは情報にアクセスしたときにcontextが付属したDB、ポータルが作成できるものです。いわゆるグループウェアと呼ぶものにはポータル機能がついているはずです。これはＱ３でのインデックス機能はそれに値しないのか？という疑問があるかもしれませんが、インデックスの作成とＤＢの作成作業が別のものはユーザが全てその作業を行うという性善説に立っているので不可能です。ここで目指すポータルとは性悪説に立ち、ユーザは楽な方法があれば手を抜くという考えからＤＢを作る前にポータルを作る必要があるというシステムになっている必要があると考えています。

次回は具体的なシステムについて議論します。

予定

WSS,SPS,Notes,Wiki

大規模開発プロジェクトのドライビング（４）～標準化

１人の人が１のアウトプットを出すとします。では１０人いるあなたの組織は１０の結果を出してますか？

人数が増えるほどアウトプットは線形から崩れてきます。人数が増えただけ強大なアウトプットを出さないと厳しい競争には勝てません。アウトプットが線形から崩れる理由としてはところどころに発生するミスコミュニケーション、質の悪い仕事が混じることによる損失（Cost Of Poor Quality）が挙げられます。小手先の修正では一瞬直ったりもしますが社会人の年齢になるとなかなか性格は変わらないもの、個人差を消すのは至難の業です。そんな時は標準化を進めましょう。標準化というと個性をつぶすようなイメージがありますが、これもうまくメリットを生かせばかならずやプラスに働きます。

例：＞実験データを見て解釈をするというプロセス

データ取得→まとめる→プレゼン→次のプランの考察

実はこの中で本当に頭を使わなくてはならないのは一番最後の次のプランの考察であって、途中のワークに個性は必要ありません。むしろデータ取得の段階から個性があると他の人がその結果を利用しようとした時に上記のプロセスを上から下って行って最初までたどらないといけないので非常に無駄です。

改善例：＞VBAの徹底活用

データ数が６万超える場合は専用ソフトが必要ですが、通常はOfficeがあれば十分です。ExcelにまとめたデータはVBAを使って処理できるのは有名です。定型的な作業は全てマクロ化してしまいます。さらに提示するグラフが決まっている場合PowerPointに貼り付ける作業までVBAでやりきることが可能です。シーケンスを読み込んで定型的な作業を行う仕組みを作ってしまえば主観を排除したレベルの高いデータをどんな人でも作れるようになります。