FEPを持ち歩く ( とある新製品案 )

MacBookに「かわせみ」をインストールした。「ことえり」に不満はないのだが、インプットメソッドを変えると生産性が上がるのではないかと思った次第。まだ長文を書いていないので自信はないのだが、変換効率がずいぶんと良いような気がする。

iPadやiPhone4は、BlueToothでキーボードを外付けできるようになった。長文を書く人にとっては朗報だと思うが、きっとFEPもATOKが使えたらなあ、と思っているのでは。

私も、この快適さをiPhoneやiPadで出来たら、もしかするとiPhone,iPadでプログラムのコーディングが出来るのではないかと期待している。そこで、こんな製品を考えてみました。

(図は、iPadの手書きソフトpenultmateで作成したもの。ひどい絵で申し訳ない）

このコンセプト製品の名称は、MobileFEPです。FEPは、昔はよく使われてた名称で、Front End Processor だったと思う。

MobileFEPは、日本語インプットメソッドが組み込まれたハードウエア製品で、キーボートとＰＣなどとの間に取り付けます。キーボードとはUSBでつなぎます。PCとはBrueToothでWirelessで繋げます。

MobileFEPのおかげで、ユーザは好みのキーボートを使うことが出来ます。また、好みのインプットメソッドがインストールされてないＰＣでも、大丈夫です。

大きさは、モバイルキーボードの6分の１程度。４０文字ぐらいを一行で表示出来るモノクロ液晶を２段持ちます。 一段目の液晶にはキーボートより入力されたひらがなや英数文字が表示されます。変換キーを打つと、変換候補が２段目の液晶に表示されます。このあたりは、普通の日本語変換ソフトですね。変換確定すると、MobileFEPから、返還後の文字がＰＣに送り込まれます。

このMobileFEPでは、外部メディア（ＳＤ）を利用できます。ユーザ辞書を持ち歩いたり、変換データを保存したり出来ます。そうです、この製品は、文章を作成するだけであれば、ＰＣは不要です。液晶を見ながらファイルに保存することができます。

また、その逆も可能です。外部から持ち込んだテキストファイルを、キーボードで入力したかのごとく、ＰＣに送り込むことが出来ます。

相手は、もちろん、ＰＣではなく、iPhoneやiPadなどBrueToothキーボードが使用できるデバイスであればOKです。

気になるお値段ですが、日本語変換ソフト込みで15000円。今なら１GBのSDメディアをお付けします。いかがでしょう？

# この記事をごらんになってしまったメーカ様、パテントは請求いたしませんので、ぜひ作ってもらえませんか？ moperaが売れる時代です。きっと需要があると思いますよ。

My Dear Life ( Style )

自分の生活スタイルは中々変えることは出来ない、と言うのは嘘だ。割と簡単に、例えばダイエット程度には変更出来るのではないか。ダイエットが難しいのは、変化を継続させる必要があること。生活も、良い方向に自分を向け続けさせることが必要だと思う。そして、そのためには目標（理想、最終形態）を描いておかなければならない。

最近の私の生活スタイルをメモっておこう。理想に近づくために。

裏紙

会社では裏紙をよく使う。思いついたら、図でも文字でもガンガン書く。時にtodoリストになり、時に企画書原稿になり、時にDFDやユースケースを書く。汚い字だが、誰に見せるわけでは無いので気にしない。しかし、たまに一枚企画書になってしまったら、コピーして人に見せてしまい、恥をかく。

iPhone

無くてはならない道具。最近、iPhone4を手に入れて、G３とのスピードの違いに後悔しきり。「GSにしておけば良かった」。ダイエット、帳簿、RSSリーダ、アイディアノート、Twitter、そしてゲーム。片道３時間の通勤時間が足りなくなったのは、iPhoneのおかげだ。

バインダ

裏紙を挟んで持ち歩くために買った。わざわざ無印良品で選んだ、クリア版のこだわり品。これがiPadに変わるようだとデジタル世界は明るいと思う。

手帳

Midoriの革製ノート Traveler's Notebookを、ここ２年使っている。使う機会は少ない。お客様を訪問したり、会議に出るときに活躍。本当は、裏紙バインダシステムかiPhoneで行きたいのだが、さすがに恥ずかしい。裏紙システムが捨てることを前提としている野に対し、手帳はしばらく記録が保管されることがポイントか？ でも、やはり最近出番が少なくて、困ったもんだと思う。

ウイルスバスター

会社のPCに入っている。重くて嫌いだ。また、システム開発の時に勝手にポートを塞いでいたりして困る。ファイルのチェックだけしておけば良いのに、セキュリティ強化と錦の美旗を上げて、開発を邪魔するのは勘弁してほしい。だれが、メールのフィルタリングまでしろと言った！

時間

通勤時間と会社時間と自宅での会社時間が殆ど。個人のビジネスを考えたり、学習したりする時間は、現在通勤時間に移行中（かな）。家庭の時間はどこにいったのか？

タスク管理

Remember The Milkと裏紙を使ったGTD。あまり、守れたことはないが、元々無理があるので気にしない事にしている。その点で、会社では納期に関する信用がない。

仕事

システム企画と基本設計、プログラミング。本当はプロジェクト管理や労務管理が期待されているのだろうが、知ったことかと思う。弾（たま）も金も質、量ともに不十分な状態では、知恵と自分の技術、体力に頼るしかない。ドラッカー様、すみません。

女性

癒しを求めているのに、好みはツンデレだと気づく。これは矛盾だ。もしかすると、理想はツンデレメイド？ 自分が恐ろしい。

睡眠

必要悪。結局寝なければならないとすれば、いかに短く、かつ効率的に寝るか？が課題だな。

通勤

必要悪。金持ちになったら、都内のホテルを点々としたいな。今は通勤時間を如何に有効活用するかが課題。

Apple

ColorClassic2以来のMac信者。しかし、Apple最悪の時に株を買えなかったことを後悔している。Newtonも大好きだった。ソフトウエア技術者の道を進み、Linuxを学習し、Open Source / Unix の素晴らしさを知り、Appleが Unix文化に入ってきたことも大変うれしい。Macは、そしてAppleの製品は、外（外観、UI)と中（アーキテクチャ）も美しいと感じる。そして何より今うれしいのは、Macを使っていれば、スマートに、Open Sourceな技術を勉強することが出来る事だ。

willcom

長年のwillcom使い。DDIポケットの時代から使っている。シンプルさととんがった精神を持った良い会社だ。H"（エッジ）や zero3シリーズ製品を経て、今は Honey Bee。すっきりして、ポップなデザインも良く、何よりカメラがついていない点が重宝している。お客様によっては、カメラ付き携帯を禁じているところもあるので。iPhoneを販売しているSoftBankが救済にはいったのも、何かの縁かな。どのような形でも良いので、ぜひ復活してほしいな。

Analyst

昔、理想としていた職種。普通の会社に、そんな職種があるわけはないのだが。分析、問題解決は、今の自分の重要なスキルの一つ。しばらく、学習とトレーニングを怠っていたような気もするので、「ロジカル・シンキング」をキーワードに、最近の技術を身につけたいと計画中。

Manager

いつも求められる職能だが、成功した体験はない。理論だけは完璧なんだけどね :-p ビジネスシステムがしっかりしていない限り、キッチリ定義されていない限り、ルーティングワークが主体となるマネジャーは成り立たないのでは。しくみがハッキリしないので適した部下も集まらない。ワインズバーク氏が提示した技術リーダシップが、今まで学習したなかでは、最良の選択かな。

consultant

以前、小さなコンサルティング・ファームに所属したことがある。そのときに、コンサルタントには２種類あると教わった。コーディネイト型とコンテンツ型。コーディネイト型のスタイル、あるいは武器はコミュニケーション技術だと、そしてコンテンツ型は最良の業務知識だと。しかし今、それは間違った考え方だと思っている。コンサルタントには一つのスタイルしかない。業務のベストプラクティスを熟知し、問題解決技術を駆使出来る人、それがコンサルタントだと理解している。

英語

苦手だ。今までの英語の学習方法は完璧に間違っていたと思う。英会話ばかり始めては挫折していた。違う。自分はソフトウエア技術者であり、必要な能力は、英語の読み書きだ。今からでも決して遅くはない。少しづつでも始めようとしている。

JAZZ

ソニー ロリンズ、マイルス デイビス、チャールズ ミンガス、ワールド サクソフォン カルテット、スタンダーズ トリオ etc 。引退したら、大きなスピーカーで心行くまま、時間を気にせずに、タップリ聴くぞ。それまで、iPodで我慢。

藤沢周平

何回も読む。読めば読むほど、その美しさ、切なさ、切れ味、暖かさがにじみ出てくる。隠し剣秋風抄、隠し剣弧影抄、よろずや平四郎活人剣、三屋清左衛門残日録、用心棒日月抄シリーズ 等々。疲れた時には、藤沢周平を紐解く、仕事に飽きたら、藤沢周平を紐解く。

Sherlock Holmes

尊敬すべき師。思想の原点であり、読書の原点。全作品 4長編、56短編を小学校時代に読み終わったのは自慢。ストイックで変人、何よりも論理を愛する姿勢は、大きな影響を受けた。イギリス グラナダTV版のシャーロック ホームズ 映像は、殆ど完璧の出来映え。ビックリしました。

小さいSIerの差別化戦略

SSIer (Small System Integrator)ビジネスの成功の鍵(KSF)は、CS（顧客満足）だ。成果による差別化ではなく、工程による差別化が有効。CS獲得の重要な手法はプロトタイピングだが、その功罪も大きい。

--------------------------

　ソフトハウスと言う呼び名は嫌いだ。その言葉には下請け体質の匂いがする。顧客と直接に話し、企画を提案し、アプリケーションソフトウエアを提供するビジネスを考えているが、それを小さなシステムインテグレーションと呼びたい。

小規模のSIが成立する市場で成功するための戦略はどのようなものかを考えてみた。

　システム構築の提出物は、もちろんアプリケーションソフトウエアだ。その評価は、品質・コスト・納期で成される。要求される機能を満足し、適切な価格で、決められた期日に納めることが良いSIの条件だ。最近はドキュメントにもうるさい。しかし、品質・コスト・納期で、SSIerは差別化できるだろうか？ これは下請けの最低条件でしかないような気がする。

　納期品質コスト主義には、いくつかの欠点がある。システムの要求仕様は発注者の技量と経験に依存する。しかし、彼らは業務のプロであっても、ITのプロではない。今まで使っていたシステムの範囲でしか、機能を考えられない。そのシステムは熟れた技術をベースにするので、見積は、難度を考慮せず、最低単価による工数ベースになる。納期は、構築工数とは関係なく、発注者のイベントに依存している。例えば、○月までに完成していないと新センタの開始に間に合わないとか。結果、スケジュールに無理が入りやすい。これらの欠点の原因は、発注者と制作者が主従関係にあることだと思う。発注者が絶対神なのだ。

　もう一つ大きな問題がある。システム構築工程での問題だ。Waterfall型で開発が進められるが、進捗報告の会議の席上で、仕様の変更や追加が多くはいる。これは品質を混乱させ、納期を無理なものにし、コストアップとなる。本来、進捗報告のはずだったのに、検討会議に様変わりするのをずいぶんと経験してきた。このようなプロジェクトでは、たとえ成果物が守られたとしても、発注者も受注者もヘトヘトに疲れてしまい、しばらくはシステム開発プロジェクトはコリゴリとなるだろう。私はそうだった。

　Waterfall型は、大規模でトラディショナルなシステム開発には有効かも知れないが、SSIerがターゲットとする市場では欠点が目立ってしまう。また、このモデルをとると、SIerの競争戦略はコストや効率になる。それは大量生産による原価低減がとれないSSIerにとって身を削る行為だ。SSIerは別の競争戦略をとらなければ生き残れない。そのポイントは開発工程での顧客満足（CS）向上にあると思う。開発工程を進捗会議のような、一方的な報告ではなく、顧客との間のコミュニケーションと満足向上のための場として積極的に利用する場として、捉えることが出来たら、CSの向上に効果的ではないだろうか。

　最近終了したのだが、特殊な事情で海外のお客様からのシステム開発案件を受注した。出張できないこともあり、Requirementを受け取った後、評価版を急いで作成し、プロトタイピング手法で進めた。具体的には、Webアプリケーションにて構築し、テストサーバに公開し、ユーザに見てもらいながら、Skypeで仕様の詳細化とソフトウエアの改良を進めた。このスタイルはおおよそ上手くいったようだ。顧客は実際に動くものを触りながら、疑問点や新たなリクエストを提供し、また間違いを指摘することが出来た。また結果として進捗も、つまり完成度も判り、安心できたのではないかと思う。プロトタイピングを通じて、様々な提案も具体的に出来た。顧客満足度は、結構高かったのではないか。ただ、この方法は反省すべき点もある。一番問題だったのは納期だ。「親の願い」状態となった要求仕様は、終わることがない。どこかでフリーズする必要があったのだが、そのタイミングを見失った。どのように仕様に、けじめをつければ良かったかの手法も不明だ。また、プロトタイプ手法では表面の仕様（画面遷移、デザイン、ビジネスロジック）しか決定できず、内部処理(セキュリティ、データベース、アーキテクチャ、負荷への対処）については何も決定できなかった。

　SSIerは、成果物(納期、品質、コスト)では差別化することが出来ない。納期品質コスト主義のKSFは、コストにあるのだから。私の経験からすれば、SSIerは工程で他社との差別化を図るべきだと思う。工程重視主義のKSFはCS（顧客満足）にある、そしてCSを実現する手法の最有力候補がプロトタイピングだと確信している。

しかし、CS向上の点でプロトタイピング手法には改善・補完しなければならないこともある。以下にその課題を提示しておきたい。

- 納期厳守への対策

プロタイピングは活発になればなるほど、納期遅れになる。もっともWaterfall型も進捗会議の旅に納期遅れになるが :-p

- 最終ドキュメント

中間ドキュメント、メモ、TICKETが異常に多くなる。成果物の書類を作るタイミングがない。

- アーキテクチャが制限される

今のところ、Webアプリケーションが一番向いていると思う。

- 大規模開発には向かない

これは課題と言うより、制限だろう。大規模開発では使うべきではない。

これらを解決することがプロトタイピングによるCS向上戦略をとるSSIerのプロジェクト毎の課題となる。

クラウド時代の問題解決

最近のビジネスシステムの世界では、原因分析や予測は決して難しいことではない。必要な問題解決プロセスは、予測結果を元に対策を図るプロセスを実施することだ。

　AppleがiTunesStoreを中心に作り上げたエコシステムは、現在大成功している。クラウドの時代に入り、ビジネスはエントロピーの法則とうまく折り合いをつけながら規模を拡大し、クローズドなシステムの世界で成功をおさめようとしている。その理論的な解説は、LongTailだったり、ネットワーク理論だったりする訳だが、ここで注目したいのは、今ビジネスは秩序をもった大規模なシステムだということだ。

　当たり前だが、システムの中では、ロジカルな思考、技法は通じやすい。私は、KT法の社内講師の資格を持っていた時期もあり、問題解決の技法には割と熟練していると思う。システマティングな問題解決法が通じる世界が広がったことは喜ばしいことだ。仕事はソフトウエアエンジニアなので、当然、情報システムでは問題解決技法を多いに活用しているし、役に立っている。そして、最近、経営企画の活動に参画する機会もあり、同様の姿勢で事にのぞんだ。

　何年も前からロジカルシンキングが重要だと提唱されていた経営の世界で、問題解決手法は十分に通用するだろうと考えたのだが、現実は随分と違うようだ。参加した会議では割と感情的な「かん」とか自分の想いとか、あるいはトップが発言した仮説（これも想いに近いと思うが）を全面的に肯定する前提での企画・計画が進められた。たまに古い時代の自慢話が計画の裏付けとして発言される。私が冷たく批評し根拠を求めたり意見を述べると（これは、私の態度も悪いと反省しているが）無視されたり怒ったりとリーダは忙しい。結局、タイムリミットとなり、原因と対策らしきモノが用意される。つまり、当初の社長の仮説を根拠なく肯定することになった。

　気に入らないのは、社長の仮説が通ったことではない。むしろ、社長の仮説は正しいと思われる。問題は２つある。誰も検証しようとしないのだ。都合の悪いデータを提出すると、それは統計が間違っていると批判されるのだ。もう一つの問題は、原因となる現象が将来に渡り継続すると仮定した時の状態と、対策の効果を比較しないこと。つまり、対策の修正、あるいは見直しを行わないことだ。原因を追求しようとせず、対策をより良いものにしようとしないこと、社長の仮説に血や肉を注ぎ込まないことだ。第一の問題への解決の方向は、原因分析することだが、なぜ私たちのチームが原因分析行動をとれないのかと言う問題は分析すべき価値のある重要なテーマだが、一般敵なビジネスにインプリメントできることではないので書かない。第二の問題「対策をより良いものに出来ない」ことに対する技術的な点について書きたい。

　ビジネスは、非常にシステマティングな構造をもつようになったと思う。数々のコンサルティング会社のフレームワークな手法、ビジネスモデルと言う考え方、そしてクラウドベースのエコシステム。このような世界では、ロジカルにものを検討することが出来る。その前提で現在のトラブル、つまりあるべき姿と現実のギャップの原因を分析することは、手法的には奇抜なことではない。トラブルの傾向を把握し、変化点を見極め、想定原因を検討する。伝統的だ。

　その後、通常の手法では評価の物差しを用意し、複数の案を出し、その比較評価を行い選択する。また他の案の良いところを、選ばれた案に付加して、さらに良いものにする。しかし、ビジネスシステムは、コンピュータシステムと異なり、その構成要素は人が中心で、人は動かすのに時間がかかる。つまりシステムの変更に時間がかかる。折角、選ばれた案も実現する間にさらに現状が悪くなり、システム変更ができなかったり、もはや遅かったりする可能性が大きい。

　そこで、ビジネスシステムの問題解決に対しては、いくつか伝統的な手法に改良をくわえたい。

1. あるべき姿、その比較の現在の姿の時間ポイントを将来の結果を得たい時点に置き換えること。
2. 評価の物差しに時間による影響を加えること。例えば、資金繰りの悪化を招かないとか。

　未来時点にあるべき姿と成り行きの現実を置くためには、原因を分析したあと、その原因を放置していた場合の予測（成り行き予測）を行う必要がある。これが対策立案のスタートだ。ところが、ここでへこたれてしまうケースが多い。私の例もそうだった。チームは、成り行きの予想の酷さに怖じ気づき、その解決は営業現場や親会社の支援にぶん投げてしまったのだ。ここで逃げるか立ち向かうかが、経営者とそれ以外の人の違いだろう。ビジネスシステムのトラブルに対しては、時間軸への考慮が大きな比重を閉める。

　これからも原因分析は重要な問題解決プロセスであることは変わらない。原因分析の目的は、対策の立案（原因の裏返しが対策）に加え、成り行き予測（期待効果決定のためのベースライン）となる。正しい現状把握とは、正しい成り行き予測を得ることだ。