2010年10月6日水曜日

IT業界のネガティブ7K・ポジティブ7K

久々のブログ投稿です。

こちら長野県飯綱町はすっかり晩秋のような涼しさで、早朝は白い息が普通になってきました。


お隣の妙高では、既に窓ガラスが凍っている地域があるようです。
これって私が生まれ育った宮崎だと「冬」と呼ぶのですが・・・(笑)

っということで、本題に入って生きたいと思います。


先日、サポートさせていただいているファザーリングジャパン(FJ)が主催した、ITパパママ育休セミナーに参加してきました。


ちょうど東京出張と絡めることができ、久々にFJ活動を楽しんできました。


そこでIT業界にかれこれ20年いる私が始めて聞く言葉が出てきました。


どうもIT業界には「7K」というものがあるらしい。


その内訳を見てみると・・・・



  • きつい
  • きびしい
  • 帰れない
  • 給料が安い
  • 休暇が取れない
  • 結婚できない。
  • 子供がつくれない  



は、初めて聞いた・・・


正確にはなんとなく聞いたことはあったのですが、さして記憶にも残らずスルーしていた感じです。


なぜなら私はITの仕事が大好きなので、この全てが当てはまらないんですね。


会社員時代から、自分の仕事に対してこんな7Kな印象を持ったことは無かったですし、会社員を辞めてフリーランスになった今にいたっては、これとはまったく無縁の「IT業界ライフ」を送っています。

個人的なIT業界の新・ポジティブ7Kは・・・


  • 賢くなれる
  • 給料が高い
  • 個人で勝負できる
  • コミュニケーションが得意になる
  • 喰いっぱぐれがない
  • かっこいい
  • 高卒でも勝負できる:笑


っといったところでしょうか?
5分ぐらいで思いついたものをパッと書きましたが、これはもう少し検証の余地がありますね。


最後の1句は個人的なものですし・・・(笑)


しかし、なぜ同じIT業界にいながら、これほどまで差が出るのでしょうか?


やはり、その根本にあるのは、この仕事が「好きか・嫌いか」にあるのだと思います。


「いや、7Kだから嫌いなんだ!」なんて声も聞こえてきそうですが、ここはSEであれば冷静に考えて見ましょう(笑)


そもそもなぜまったく同じ職場環境や業界にいながら、その状況をネガティブ7Kで捕らえる人と、ポジティブ7Kで捕らえる人がいるのでしょうか?


もちろんどちらの要素にしても、複合的な要因があると思います。


個人の資質の問題、会社組織の問題、通勤条件、給与条件など様々な要因が重なってネガティブな7Kになってしまうのでしょう。


中でも私は、「個人の資質」が最も大きいウェイトを締めているのではないかと思います。


多分、IT業界に関わらず仕事で高いパフォーマンスを発揮する人は、例外なくその仕事が好きな人たちのはずです。仕事が嫌いで嫌いでしょうがないんだけど、なぜか仕事のパフォーマンスは高いという人はほとんどいないはずです。


私の言う「資質」とは、俗に言う定量的に測定されるような潜在能力、例えば論理思考能力やコミュニケーション能力、文章力などではなく、単純にその仕事が「好きか・嫌いか」というそれ一言に尽きると思っています。


好きであれば資質が高い、嫌いなら資質が低いというところです。


そういえば京セラを起業された稲盛さんが、仕事の能力というのは「熱意」×「能力」×「考え方」で決まるということをおっしゃられていますが、「好き・嫌い」という資質は、これらに直接起因する、1レイヤー上の概念であると思ってよいと思います。


その仕事が好きであれば、熱意はもちろん高いレベルに維持されるでしょう。

その仕事が好きであれば、上達欲も高くなるので一生懸命能力を高めようとするでしょう。

その仕事が好きであれば、その仕事で得られた能力を世の中の役に立たない、私利私欲だけを満たす道具として使うなんて悪どいことは考えないでしょう。


こう考えると、仕事こそ「好き・嫌い」で選ぶべきなのにと思います。


こと仕事になると「好き・嫌いで判断してはいけない」といった風潮があるのは、個人的にどうしても不思議でなりません。


仕事は「好き・嫌い」で選ぶべきなのです。


はい。


そして、ここで多くの人がぶつかるのが、「何が好きなのか解からない・・・」という壁ではないでしょうか?


この壁は相当高く、そう簡単に「自分が好きなものはこれだったんだ!」という天職の入った宝箱に出会える人はそうそういるものではありません。


大よそ最初のうちは、人食い箱やミミックに出会ってしまうものです(笑)



しかし、極めて合理的な方法でその宝箱にたどり着く方法論があることも、また事実です。


その方法は・・・


後日のお楽しみということで(笑)


_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
株式会社ライジングサン・システムコンサルティング
岩佐和紀
URL : http://www.risingsun-system.biz/
認定資格 :
 上級システムアドミニストレータ
 FileMaker認定デベロッパーVer10/11

2010年9月20日月曜日

FreeMindですいすいユースケース分析

今日は朝から雨の飯綱町です。
既に半そででは肌寒い感じで、あと1ヶ月もすればこたつと薪ストーブが恋しくなる季節になります。
今年は猛暑で早く涼しくならないかと思っていたのですが、いざ夏が過ぎるとあっという間に冬支度の北信州です。

さて、今日も上流工程ネタで行きたいと思います。

先日、上流工程の情報は全てFreeMindにまとめなさい的な記事を書きましたが、今日はその続編ということで、FreeMindをどのように上流工程で使うかについて書きたいと思います。


上流工程で記述するドキュメントは前回の投稿でも書いたとおりですが、FreeMindが活躍するのは何といってもユースケース分析の時です。

ユースケース分析で記述するドキュメントは、ユースケース図とユースケース記述書があります。


私はユースケース図をAstahProfessionalで、ユースケース記述書はFreeMind0.9.0で書いています。


もちろん統合開発ツールであるAstahProfessionalにもユースケース記述書を書く機能は搭載されているのですが、ユースケース記述書が8割以上完成するまでは、AstahProfessionalの機能は使わず、FreeMindを使っています。




FreeMindをつかう理由は主に3つあります。


ひとつめは、FreeMindのほうが情報をスピーディーに構造化しやすいことです。

確かにAstahのユースケース記述書機能は、下記のように構造化された記述フォームが用意されています。

しかし、エンドユーザからヒヤリングしたてで明確な構造が見えていない状況において、いきなり形式化されたフォームにイベントフローなどを記述するのは、記述の目的と効率化の観点からあまりお勧めできるものではないと思います。


それよりも、FreeMindのようなツールで「まず明確なところから」そして「書きやすいところから」書くほうが、仕事ははるかに分析しやすく、そして仕事も速くなります。


ユースケースは記述することが目的ではなく、業務とシステムの境界線、プロジェクトのスコープを明確にし、業務全体を構造化することが目的のはずです。


そういう目的に立ち返ると、ユースケース記述書はあくまでも分析結果・構造化の結果を書くものであり、分析・構造化の過程を記述するには向いていないことが解かります。


なによりもきっちりと書式が整った書類に書くときのデメリットは、記述しながらわからないことや疑問点が出てきたら、そこで仕事が止まってしまうということです。


ここで仕事の生産性が落ちてしまいます。


もちろん、わからない部分をペンディングにして、それ以降を書き続けることもできるでしょう。


しかし、心理的にも人間の脳の特性的にも、完璧にフォーマットされた書類に、「中途半端」な状態で文書を保存しておくのは、なんだか気持ちの悪いものです。


その点、FreeMindでの記述だと、書式化されたものではないので、解からない部分はそのままにしておき、わかる部分からスイスイ書いていくことができます。

FreeMindで構造化したユースケース記述書


そしてわからない部分には、0.9.0から登場した強力な機能である「属性」機能でマーキングしておき、「フィルタ」を使って、漏れなく調査やヒヤリングすることができます。


そしてこの属性とフィルタ機能が使えることが、FreeMindをつかう2つ目の理由です。


FreeMindはバージョンが0.9.0になって「属性」と「フィルタ」という強力な機能が追加されました。


属性機能とは、ブランチに構造化されたタグをつける機能です。


ブランチに属性(タグ)を追加する。


例えば、経理部門に提供するサービスのユースケースを記述しているときに、ふと疑問点やヒヤリングが十分でない箇所が出てきたとします。


そういうときに、【要ヒヤリング / 経理部】という属性をブランチにつけておき、具体的な質問事項をブランチのノートとして記述しておきます。


そしてフィルタ機能で、全てのブランチから【要ヒヤリング="経理部"】という属性(タグ)のついたブランチのみをフィルタします。

フィルタの定義
ブランチをフィルタした結果







こうすることで、ヒヤリング項目を効率的に管理することができます。


ちなみにこれには副次的な効果があります。


フィルタ機能は、単純にそのブランチのみを抽出するのではなく、上位ブランチと下位ブランチを表示することができます。


この機能により、その質問・疑問がどういった関連性を持っているのかをひと目で確認することができるのです。


Excelなどでヒヤリング台帳や質問台帳を管理し、それをもとにヒヤリングを実施すると、時に「自分はなぜこんな疑問を持ったのだろう?」と質問・疑問の「意図」や「本質」を忘れることはありませんか?


こういった質問・疑問の意図や本質というのはなかなか言語化しずらく、多くは記憶にイメージとして残っています。


このイメージを如何に効率よく引っ張り出せるかで、ヒヤリングの質というのはまったく変わるのですが、FreeMindをつかうと、MindMapがもつフィードバック効果を得ることができるので、ヒヤリングの質が飛躍的に向上するのです。


いかがでしたでしょうか?


FreeMindの0.9.0から実装された属性とフィルタの機能を使うと、こういったメモ以外にも様々な使い道があります。


「属性」はブランチで関連付けられている関係性とは別の視点・評価基準における関係性をブランチに付与することができます。


そして何よりもこの属性がに階層構造を持たせることができるのがすばらしい。


今回の例では、以下のような構造を作りました。

▼要ヒヤリング

├→経理部

├→総務部
└→経理部





これで2次元構造であったマインドマップが、立体的・3次元的な構造になり、より複雑な情報を効率的に管理することができます。


できればこの機能は本家のiMindMapにも実装してほしいところですが、恐らくトニーのおじさんから「そんなもんはマインドマップじゃない!」と一喝されそうですね(笑)


しかし、この機能はシステム開発の現場、特に情報が抽象的な上流工程では、その抽象的な情報を構造化するにあたって極めて有益な機能です。


_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
株式会社ライジングサン・システムコンサルティング
岩佐和紀
URL : http://www.risingsun-system.biz/
認定資格 :
 上級システムアドミニストレータ
 FileMaker認定デベロッパーVer10/11

2010年9月12日日曜日

上流工程の生産性を上げるツール

おはようございます。

今朝の飯綱町はちょっと曇り気味で、時折小雨も降っています。


本日は、上流工程の生産性を上げるツールというテーマで書いてみたいと思います。


上流工程の仕事はひたすらドキュメンテーション!
私が主に書くドキュメントは次のようなものです。
  • 情報システム活動計画書  
  • RFP
  • 要件定義書
  • 業務フローチャート
  • 業務記述書
  • ユースケース図
  • ネットワーク構成図
  • システム概念図

これらのドキュメントを書いていく上で、いかに早く正確にドキュメントを記述できるかは、私にとっての死活問題です。

フリーランスの技術者という商売は、多くが自分の時間を切り売りして収入を得ているので、収入を上げようとすると時間当たりの単価を上げるか、長時間働くかの2社択一になります。

もちろんこれ以外にも、自分で開発したソフトウェアのライセンスフィー収入や、著作からの印税収入なども見込むことはできますが、これができる技術者はなかなかいないのではないでしょうか。

そうであれば、時間単価を上げるか、長時間労働をするかの2社択一になります。

個人的には両方必要だと思いますが、時間単価を上げるということはすなわち短時間で人よりも多くのアウトプットができることが絶対的な条件になります。

ちなみに日本のSE単価は、ほとんどが勤続年数や相場など、その技術者の実力とはかけ離れたところで決まる部分があるので、エンドユーザ的に「ババを引いた…」と思うのは、時間当たりのアウトプット能力が低い技術者に当たってしまったときですよね…

特に上流工程は、特に情報の抽象度が高い工程を相手にするので、抽象思考やイメージ能力が高い技術者と、そうでない技術者のパフォーマンスには雲泥の差が出ます。

短時間で多くのアウトプットができて、さらに長時間労働ができる集中力・体力・モチベーションがあることが、フリーランスの技術者が最も確実に自分の価値をあげることができる手段になります。

そういえば長時間労働は、ランチェスター経営・「弱者の戦略」でもありましたね。

さて、前置きが長くなりましたが、このような上流工程で作成するドキュメントをいかに効率よく作成する「ツール」について書きたいと思います。

私はこれまで数あるシステム開発プロジェクトを経験してきましたが、SEさんによってドキュメントを記述するソフトウェアは様々です。



上流工程で使うプロ仕様のツール


フローチャートをExcelやパワーポイントで書く人。

フローチャートだけでなく、ネットワーク構成をはじめとする上流工程全てのドキュメントをExcelだけで書く人。(Excelって偉大だなぁ~)

もちろん、こういったツールの選択が「悪い」というわけではないのですが、個人的に思うのが、プロなんだからプロが使う道具で仕事をしましょうということです。

例えばフローチャート。

特に上流工程で必要となる部門間連携を表現するレーン付きのフローチャートや、産能式事務工程図を書く場合、とてもExcelやPowerPointで書ききれるものではありません。

もちろん手間と時間をかければ書くことはできるのですが、追加・修正などのことを考えるときわめて効率が悪くなります。

フローチャートであれば、それ専用のツールを使うのもプロの条件のひとつだと思います。

プロであれば、他人より圧倒的に早く仕事ができることもプロたる条件。

であればフローチャートを描くにはVisioや、ちょっと値は張りますがXUpperやJUDE/Bizといった専用ツールを使うべきです。

もし会社がそういったツールを買ってくれないというのであれば、そんな会社はさっさと三行半をたたきつけるべきです。(笑)

まぁ三行半というのは行き過ぎかもしれませんが、そこの経営者は、適切なツールの選択による生産性の向上と利益の増大よりも、目先数万円のキャッシュがもったいないという感覚なので、既に経営者としての視点は持っていないということでしょう。

そんな会社は遅かれ早かれ行き詰るのが目に見えています。



一番大変なのは、膨大な関連情報の整理と数百ページになるワープロ文書


先に書いたとおり、フローチャートをはじめとする特殊なドキュメントには、それを補完するためのプロ用ツールが出ているのでそれを使うことがプロとしての生産性を挙げてくれる重要なファクターであることは明白だと思います。

またこれ以外にも、ネットワーク構成やシステム概念図、ER図や簡単なGUI設計ツールもプロとしてしっかりと揃えておきたいところです。

さて、そんな上流工程の中で使用するツールでも、「プロ用」と分類できるようなツールが無いのがワープロです。

要件定義書やRFPは、最終的にワープロ打ちしてA4のドキュメントで納品するのが大体のパターンだと思います。

しかし、このワープロについてはプロ用と呼ばれるツールがありません。

要件定義書やRFPは、しっかりとやればやるほど、記述する内容は膨大になります。

技術要求・業務要求・非機能要求など、頭の中にぼんやりならイメージできるものでも、いざそれを正式な要求・要件として文字にしようとすると、膨大な量になります。

これを章立てして、論理的な構造で組み立て、さらにプロジェクトの利害関係者の誰が呼んでも一定のレベルで理解できる文言で書くのは、極めて手間のかかる作業です。

例えば一般的に3000万レベルの小規模プロジェクトでも、教科書どおりの要件定義やRFPを作成すれば、ドキュメントの記述量はA4用紙で直ぐに100ページを越えます。

こんな膨大な文書を書くのに、いきなりまっさらのWordを開いてゴリゴリ入力していくのは極めて非効率的です。

そこでは私は、この作業にFreeMindを使っています。



FreeMindは上流工程の乗り切るためのプロ用ツールになる。

FreeMindはいわずと知れた(?)、マインドマップ風アウトラインプロセッサ。

生粋の(?)マインドマッパーからいわせていただくと、これはマインドマッピングのツールではなく、アウトラインプロセッサです。

しかし、個人的にはこれが上流工程の作業で最も活躍するツールかも知れません。

先にも書いたとおり、上流工程で作成するドキュメントの特徴は、記載する項目が多岐にわたり、アウトラインが何階層にもわたって深くなるということです。

また、アウトラインごとに関連付けて記述したいことが多々あるのもこれらのドキュメントの特徴です。

例えばある業務要件と技術要件が密接に絡み合っている場合、できれば「○○を参照」と入れたいですし、書く側としては容易にその参照先にジャンプできること生産性があがります。

さらに、ある章の内容を書いているときに、ふと他の章の追加記述や、システム化のアイデアが浮かぶもありますし、エンドユーザへの質問事項が頭に浮かぶこともあります。

そういったものは忘れないうちに文字にしておくと、後から思い出す必要も無く、忘れてしまうというロスもなくなります。

こういった一連の作業を効率よくできるのがこのFreeMindです。

例えばエンドユーザに確認しなければならない事項が出てきたら、関連するブランチにノートとして記述し、[?]などのアイコンをつけておけば、次回のヒヤリングで漏れなくそれを訴求することができます。

また、ふとしたシステム化のアイデアも、関連するブランチにノートとして記述しておき、電球アイコンなどをつけておけば、エンドユーザに漏れなく提案することができます。

さらに、ドキュメントを記述中に出てきたToDoもすばやく記述して、チェックマークなどのアイコンをつけておけば、ToDoを漏らすことがありません。

ここでFreeMindの素晴らしいのが、アイデアでも質問事項でもToDoでも、何をしているとき、何を考えているときにそれが生まれてきたかを関連付けて記録することが可能なことです。

これが別のノートやToDoリストに書き出してしまうと、「これは何の作業をしているときに出てきた質問事項だ?」となってしまいます。

FreeMindを使うと、そういった「何を源泉にこのToDoや質問が湧いてきたのか?」が、直ぐにわかります。

さらに素晴らしいのが、これらの質問事項やToDoを数あるブランチから一瞬にしてソーティングして一覧化することができることです。

マインドマップの原則を守るとありえないことですが、RFPや要件定義をFreeMindで書いていると、A0サイズの紙で印刷してもまだ足りないぐらいの大きさになります。

それだけの文書から、あるところに記述したToDoや質問事項を見つけ出すことが、FreeMindでは簡単にできてしまうのです。

もちろん、これ以外にもFreeMindを使った「上流工程ハック」はたくさんあります。

外部ファイルへのリンク埋め込みやURLリンクの埋め込みを使えば、周辺資料のまとめも極めて効率的にできますし、ドキュメントの作成時にも、あらかじめ全てのアウトラインをブランチとして書き出しておけば、書ける所から書いていくという作業が可能です。

ワープロだとどうしても頭から書いていくので、あるところで躓くとその先がどうしても進まなくなります。

こういった躓きによる作業中断がFreeMindを使うとかなり解消できます。

これらFreeMindを使った「上流工程ハック(?)」は、それこそ相当な量のドキュメントを書く必要があるので、また別の機会に詳しく書きたいと思います。



情報は全てFreeMindにまとめなさい?
今回はFreeMindを使った上流工程作業について書いてみました。

FreeMindは別にプロ用のツールというわけではなく、価格もフリーです。

上流工程を「Excel」と「Word」だけでがんばっている技術者さんには、ぜひ知ってほしいツールになります。

上流工程では、とにかくMECE精神で関連する多くの情報をかき集め、論理的に整理して問題点を定義し、バラバラと出てくる改善点も同じく論理的にまとめて要求・要件を定義していく作業、そしてそのかき集めた情報を文字化していく作業がその大半になります。

この作業を極めて効率的に行えるのがFreeMindです。

ちょっと前に「情報は全て100円ノートにまとめなさい」という本が出版されていましたが、私の場合は全てFreeMindにまとめなさいといったところですね。


_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
株式会社ライジングサン・システムコンサルティング
岩佐和紀
URL : http://www.risingsun-system.biz/
認定資格 :
 上級システムアドミニストレータ
 FileMaker認定デベロッパーVer10/11

2010年9月7日火曜日

情報システム開発業における弱者の戦略

こちら長野県飯綱町は、朝夕に関してはすっかりすごしやすくなりました。

我が家周辺は治安が良いこともあり、夜寝るときは窓全開で寝ているのですが、朝方は寒くて目が覚めることがあります。

今年は記録的な猛暑で、寝苦しい夜が続いていたのですが、ようやく北信州らしい気候になってきました。


さて、今日は情報システム開発業における弱者の戦略ということで書いてみたいと思います。


情報システム産業は、長引く不況の影響で、経営が苦しくなるソフトウェアハウス・システムインテグレータが相当数に昇っているのは、業界の方であれば周知の事実であると思います。


実は先日も、複数のソフトウェア開発会社の営業さんや経営者さんから、仕事が無くて困っている、案件が決まらずに困っているという話をお伺いしました。


2008年のリーマンショック以降、「真水キャッシュフローの源泉」である常駐技術者を返されたり、1000万円を越える案件の受注率が極めて悪くなったりと、中堅・中小規模のソフトウェア開発分野における経営環境は極めて悪くなっているようです。


翻って、私がお付き合いをさせていただいている開発会社さんの中には、仕事を断らなければならないほど活況な会社もあります。


双方ともに規模としては数十名規模、同じソフトウェア開発会社を生業としているのに、この差はどこから出てくるのでしょう。


今日はこんなことを考えてみたいと思います。

考えるベースになっている世界観は、弱者の戦略・ランチェスター経営です。


現在の日本におけるソフトウェア開発会社は、メーカー系の大手を除いてその99%が「弱者」と考えてよろしいでしょう。


例えばこの地域では一番の・・・という会社でも、ここ数年の技術動向から考えると「弱者」であると考えるべきです。


それが数十名から数百名規模の中堅・中小レベルであれば、圧倒的な番外弱者と考えたほうが良いでしょう。


このランク付けのキーとなっている技術動向・技術トレンドというのはズバリ「クラウド」です。


この技術トレンドのおかげで、地方の小さな開発会社であろうが、都内の数百名規模の会社であろうが、世界的なクラウド技術プロバイダーであろうが、同じ競争空間に放り込まれてしまうのです。


クラウド化の本質は紛れも無く仮想化・バーチャルかであり、これを経営戦略という視点からみると、競争の優位性が物理空間(リアル)から情報空間(バーチャル)に移ることにあります。


情報空間とは限界効用逓減の法則が働かない世界なので、独占した人たちが圧倒的に優位な競争空間です。

世界的企業と数名・数十名規模でシステム開発している会社が、バーチャル空間上で同じ土俵に上げられて、いつの間にか競争させられているんですね。


地方で数名規模でソリューション開発をしている会社と、SalesForce.comのような世界規模で商売をしている会社が比較されてしまうのが「情報空間」における競争の本質です。

例えば、「いつも付き合いのあるあの会社に開発をお願いするのと、セールスフォースを使うのはどっちが得だろう?」

ソフトウェアを発注する側であれば、こういった考慮は必ずされるでしょう。


実はこの時点で、数十名規模の会社と世界規模のクラウド屋さんが比較されてしまっているのです。



だからこそ、一般的な開発会社は弱者の戦略を徹底的に研究し、それを実践するしか生き残る道が無いのです。


冒頭に上げた、経営が汲々としている会社さんと、仕事を断るぐらいお客さんから問合せが来ている会社の違い。


これは、意識的にか無意識的にか解かりませんが、後者の会社さんはしっかりと「弱者の戦略」を実行されているように思えます。


顧客・商品の絞込み、そして「接近戦」といったことをしっかりされているんですね。


さらに戦略ではなく戦術レベルの話をすると、ソフトウェア開発業で極めて重要なのが、自社で取り組む技術分野の絞込み。

これは「武器の選択」といっても良いでしょう。


弱者が採用すべきは、接近戦に優位な武器。

自社が絞り込んだ業界・客層に優位な武器は何なのかをしっかりと見据える必要があります。

ここで明らかなのは、強者が使う武器を使って戦ってもダメだということ。


弱者には弱者にふさわしい武器があるし、その武器が通用しないところには出て行ってはいけない、そういった土俵に登ってはいけないということになります。


ちなみに、私はこの弱者の武器としてFileMakerテクノロジーを選択しています。

私は「実装能力のあるITコンサルタント」なので、システム企画や要件定義の仕事がメイン名のですが、実装フェーズに自らが動くこともあります。


その時に使うのがFileMakerテクノロジーです。


これは、私のような弱者にはぴったりの武器です。


これを使うことで、強者の武器を使って戦っている中小規模のソフトウェア会社の技術者数人分の仕事を、私1人でこなすことができます。


結果、お客さまからは喜ばれるし、自分自身の仕事にも誇りと自信を持つことができます。


注意しなければならないのが、世の中に出回っている技術情報は、そのほとんどが強者が使うべき武器の情報で、弱者が使うべき武器の情報はまったくといっていいほどメジャーなメディアでは取り上げられないということ。


情報システム開発業における弱者の戦略は、メジャーメディアでは絶対に取り上げられないので、自らが研究し、実践し、トライアンドエラーで見出す以外に方法はありません。


また、弱者の戦略を勉強するのであれば、ランチェスター経営の竹田先生が作られている教材、そして神田昌典さんのダントツ企業オーディオセミナーをはじめとする各種教材はすごく勉強になります。


ランチェスター経営:http://www.lanchest.com/
神田昌典さん:http://www.kandamasanori.com/


弱者の戦略、勉強しましょう!

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
株式会社ライジングサン・システムコンサルティング
岩佐和紀
URL : http://www.risingsun-system.biz/
認定資格 :
 上級システムアドミニストレータ
 FileMaker認定デベロッパーVer10/11

2010年8月30日月曜日

情報システム戦略に関する考察 ~記述の粒度について~

昨日は娘が通う幼稚園の行事で、根子岳に登ってきました。


去年の根子岳登山で、ウチの娘はベソかき・ケツ持ち部隊で、最後はオンブしながらの下山だったのですが、今年は出発前からガンガンに気合いが入っており、出発時には初代隊長に任命されました。


その隊長任命でさらに気合いが入ったのか、出発直後から隊列の先頭をビシビシ登っていきます。


去年までの弱々しさはまったく無く、気合いの入った表情で隊列を引っ張っていく4歳の娘には感動すら覚えました。


7時に登山口を出発して、数回の休憩を挟み、11時30分には山頂に。
そこには北アルプスまで見渡せる素晴らしい景色が待ち受けていました。


我が家は山頂で、炭焼きのスペアリブを楽しみ、手作りのメダル授与式などのセレモニーを経て13時30分ごろ下山開始。

予定通り、15時には無事登山口に到着しました。


驚愕したのはその後。
登山口に到着後、ほかの家族の到着を待っている間に、友達と走り回っていました。


子どもの成長というのは本当に素晴らしい。


子どもにゴチャゴチャと小言を言う前に、親自身も、もっともっと成長しなければということを痛感した一日でした。

─────────────────────

さて、本日は情報システム戦略に関する情報の粒度について書きたいと思います。


情報システム戦略を文書化するときに、どういった情報の粒度(抽象レベル)で書いてよいのか迷うことはありませんか?


何を書かなければならないのかを迷うのはもちろんのこと、どの粒度で情報を書けばよいのかがよく解からない方というのは、意外に多いのではないかと思います。


情報システム戦略を文書化する上での粒度を知るためには、まず戦略と戦術の違いについて知っておくことが重要だと思います。


戦略と戦術の違いは、その語源をたどるとわかりやすい。


戦略とは、その語源がラテン語の「ストラテジア」にあり、英語の「ストラテジー」の語源になっています。




1864年に山口県の大村益次郎がこの「ストラテジア」を「将帥の術」と翻訳し、「見えざるもの」との解説を加えました。


そして、明治のはじめヨーロッパで兵学の研究をしていた軍人が、これを「戦略」と翻訳し直しました。





次に戦術ですが、これはその語源がラテン語の「タクティコース」にあり、英語の「タクティクス」の語源になっています。

これも同じく大村益次郎が「兵士の術」と翻訳し、「見えるものと」と解説しました。そして、兵学を研究していた軍人が「戦術」と訳したといわれています。


つまりシンプルに解釈すると

「戦略は大将の術であり見えざるもの

「戦術は兵士の術であり見えるもの」

といえます。



これが戦略と戦術の基本的な違いになります。




では次に、これを「情報システム戦略」に当てはめてみましょう。




まず、情報システムそのものが「見えざるもの」的な部分が大きいので、混乱してしまいがちですが、私はこれを解かりやすく解釈するために、オブジェクト指向の考え方を取り入れています。




そしてオブジェクト指向の考え方をどう取り入れているかについてですが、私は、戦略=クラス、戦術=オブジェクト(インスタンス)という階層構造で捉えています。




こう捕らえると、「戦略」は、その下位概念である「戦術」に一定の規則性・法則性を持たせるものともいえますね。




いくら屈強な兵士をたくさん揃えたとしても、その兵士が適材適所で配置され、タイムリーにそのタスクを遂行できる状態でなければ、その能力は十分に発揮することができません。




情報システム戦略も同じで、いくら優れいたインフラ・プロダクト・ソリューション、そして人材を揃えたとしても、それが適切に機能する状態でなければ、ガラクタ以外の何物でもなくなります。




適切な兵士の配置には、一定の規則性・法則性を見出して、それらが適切に機能するように再拝する必要があります。




オブジェクト指向では、下位概念のクラスやオブジェクトの規則性・法則性をまとめた抽象概念をクラスと表現しますが、戦略と戦術の関係はまさにこの階層構造に当てはめることができる関係性を持っています。






そこで本題の情報システム分野における戦略と戦術ですが、これはズバリ具体的な製品・プロダクト・ソリューション等、固有名詞が明確なものに関しては戦術レベルの記述であり、それらの上位概念で記述されているものは戦略レベルの記述であると考えます。






つまり情報システム戦略を文書化したものに、具体的なプロダクト名やベンダー名等が記述されているものに関しては、情報システム戦略を表現する文書として具体的過ぎる、抽象度が低すぎるということです。




これは、「木を見て森を見ず」状態の戦略構築の危険性があります。




情報システム戦略の文書化における情報の粒度に関する留意点としては、その情報粒度がクラスレベル、つまりその下位概念に別のクラスやインスタンスが存在するかどうかを意識して文書化することが望まれます。




例えば、情報システム戦略を記述する上で、RDBMSやデータベースという単語ははクラスレベルの記述となるでしょう。


なぜなら、その下位概念には、MS-SQLServerやOracle、FileMakerProといった下位概念のクラス(インスタンス)が存在するからです。




また、SFAやCRMという記述も抽象的だといえます。これに具体的なSalesForce等といったプロダクト名・製品名が入るのは戦術レベルの情報粒度といえます。




もちろん、これだけが戦略と戦術を分ける決定的な要素ではなく、今回はあくまでも情報システム戦略を文書化する局面における情報の粒度にフォーカスして書いているので、ご了承ください。


いかがでしたでしょうか?




今回は、情報システム戦略を文書化する局面にあたっての情報粒度について書いてみました。




これはあくまでも私個人が勉強して、ビジネスの現場で「使っている」考え方でありテクニックです。




世の中には、MBA的なアカデミックな解説・解釈はいくらでもあると思いますし、Google検索するとそういった解説は山のように出てくると思います。




ただ、私の実力や知識が伴わないせいか、こういった解説を読んでも、いざ具体的に文書化するとなると、とたんにペンが進まなくなる。(キーボード入力ですけど・・・)




こういった局面に陥ってだいたい次にやることが、どこかの会社の事例を探したり、テンプレートを探したりというのが多くの人の行動パターンだと思います。




十分な時間を与えられず、形ばかりのアウトプットばかりを要求される現代においては、それも仕方が無いと思う反面、やはりその本質だけはしっかりと理解しておくことは極めて重要なことだと思います。




また注意事項として、ここに書いてあることが「ITストラテジスト」等の「知識」を問う試験対策にはお役立ていただけません(笑)




試験対策には、上記に書いたようなアカデミックな知識を身につける必要があります。




次回は、戦略を構築する上で重要な「予見力」について書いてみたいと思います。




_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
株式会社ライジングサン・システムコンサルティング
岩佐和紀
URL : http://www.risingsun-system.biz/
認定資格 :
 上級システムアドミニストレータ
 FileMaker認定デベロッパーVer10/11

2010年8月28日土曜日

昨日、一昨日と東京に出張してきました。

実は一昨日の26日は37回目の誕生日だったのですが、私の誕生日には必ず出張が入るというジンクスがここ10年近く続いています。

そして必ずなんらかのギフトがもたらされるというジンクスも・・・

37回目の誕生日も、新たな仕事の展開を予感させる素晴らしいオファーをいただきました。

最近自分がフリーランスであるが故に悩んでいたことが、まさに氷が解けるかのごとく、すっと溶解するようなオファーです。

それもこれも、当面はフリーランスで行くとハラに決めたこと、そしてそれを決めるにあたって的確なアドバイスをしてくれたたくさんの友人がいたことが本当にありがたいことです。


──────────────────


さて、今日も情報システム戦略について書いてみたいと思います。


情報システム戦略を含めて○○戦略って昔からビジネスの現場で使われていますが、頻繁に使われる割には、「戦略とは何か?」と問われたときに、ぱっと答えることはできないのではないでしょうか?

経営戦略・顧客戦略・PR戦略・IT戦略・・・


いろんな○○戦略はありますが、この「戦略」について紐解いてみたいと思います。


世の中に戦略に関して難解な説明をしている本はたくさんありますが、正直ビジネスの現場でそれを生かそうと思ってもなかなか難しい・・・


農業高校卒でMBAでもなんでもない私には、ピッカピカのアカデミックな知識よりも、即現場で使える知識のほうが重要です。


そこで参考になるのが、「神田昌典先生の60分・企業ダントツ化プロジェクト」で有名なスター戦略構築法、そしてランチェスター経営・竹田陽一先生の一連の書籍やオーディオ教材です。


これらの書籍・教材を勉強することで、これまで霧にかかっていた「戦略」というものが、より鮮明で立体的にわかるようになります。


さて、前置きが長くなりましたが、「戦略」を理解するうえで大切なことその1.


「戦略とは目的を達成するための順番を定義したものである。」


これが戦略を理解する上で、最も最初に意識しておくべきことです。


順番をほかの言葉に置き換えると、「優先順位」や「計画」として良いかも知れませんね。


経営とはなんらかの目的を達成するために行われる商活動であり、その目的へ早く・効率的に・そして正確に到達するための手段として「情報システム」を用います。


そして、どういった順番で情報システムを自社に投入していくか、それが情報システム戦略になります。


世の中に出回る技術トレンドに直ぐ振り回される・・・

ベンダーの提案に乗っかってしまい、自社に導入しても効果の薄いシステムを買ってしまった・・・・


こういう「なんでも重要症候群」にはまっているのが、戦略の無い情報システム投資です。


戦略とは自社の強み・弱み・業界動向・成熟度などを複合的に判断した上で、必要なアクションを優先順位をつけて時系列にマッピングしていくことです。


この戦略がないと、「なんでも重要症候群」に陥ります。


常に目の前にある仕事が常に「最優先」であり、その仕事が何につながっていくのかについては何も考えられていない。仕事に意味が見出せず、仕事へのモチベーションが下がってしまう。


情報システム戦略が構築されているということは、現在情報システム部門として第一に取り組んでいるのは○○、次に○○。来年は○○がテーマで・・・


というように、優先順位がはっきり決まっているということです。


また当然ですが、情報システム戦略は、経営目的を達成するための戦略なので、当然経営戦略とシンクロしている必要があります。


経営戦略無しに情報システム戦略を構築するなんてことはありえません。


うちの会社の経営戦略なんて知らないけど、経営層から情報システム戦略の構築を指示されたなんてことはあってはいけないわけですね。


そういった意味でも、情報システム部門は常に会社の経営戦略を意識しておかなければならないわけです。


順番・優先順位・計画が定義されていない「情報システム戦略」は戦略ではありません。


情報システム戦略を構築する上で、まず意識しなければならないのは順番・優先順位・計画です。


これをしっかりと頭に刻み込みましょう。


戦略を持つというのは、地図・羅針盤を持つということ。


自分達がどこにどういった経路で、どれぐらいの時間をかけて旅をしようとしているのか。


これを定義することです。


次回は、情報システム戦略を構築する時の「粒度」について書きたいと思います。



_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
株式会社ライジングサン・システムコンサルティング
岩佐和紀
URL : http://www.risingsun-system.biz/
認定資格 :
 上級システムアドミニストレータ
 FileMaker認定デベロッパーVer10/11

2010年8月25日水曜日

情報システム戦略に関する考察

連日の猛暑ですね。

こちら長野県飯綱町は、朝夕はずいぶんと涼しくなったのですが、日中はまだ相当暑くエアコンの無い事務所の室温は30度を越えてしまいます。

幸いにして湿度が低いので、扇風機を回せばまだ思考力が落ちるほどのダメージが無いので助かっていますが、こういった猛暑が続くようだと思わず窓用エアコンでも購入しようかと思ってしまいます。

さて、本日は情報システム戦略について書いてみたいと思います。

・・・っと、いつものような文章を書きたかったのですが、実は明日からの東京出張でその準備があるため、本日の投稿は考えをまとめるために書いたマインドマップの掲載にとどめておきたいと思います。


私は手書きのマインドマップと、タブレットPCを使ってのiMindMapを併用しています。

使い分けのポイントは、右脳処理優先のマインドマップか、左脳処理優のマインドマップかによります。

前者はアイデア出しや新しい発想を得たいとき、平たく言うと「手に考えさせたいとき」に用い、後者は考えをまとめたり、カオスな状況を構造的に整理したりといった「頭で考えたいとき」に使っています。


明日以降、このマインドマップの中身について書いていきたいと思います。


_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
株式会社ライジングサン・システムコンサルティング
岩佐和紀
URL : http://www.risingsun-system.biz/
認定資格 :
 上級システムアドミニストレータ
 FileMaker認定デベロッパーVer10/11

2010年8月23日月曜日

情報システム化の本質は省力化であり効率化である。

昨日は夏休み最後の週末ということで、家族で海水浴に行ってきました。

長野県に引っ越してきて始めての海水浴です。

場所は、谷浜海水浴場という新潟県の海水浴場。

初めて日本海で泳いだのですが、水の透明度が高くす晴らし海水浴場でした。

この夏は娘とプール・川を含めてガッツリと泳いだので、二人とも日焼けで真っ黒になってしまいました。



2010年8月22日日曜日

iPad with FileMakerGoの生かし方 ~コンテンツマネジメント編~

iPadの発売から約3ヶ月が経過し、企業においてもiPadの大規模な導入事例が紹介され始めました。

企業におけるiPadの導入目的はいくつかにセグメントできると思いますが、中でも大きいのがペーパーレスを目的とした導入。

先日もベスト電器が、社内資料の電子化を目的としてiPadを導入し、まずは役員クラスの会議で私用を開始するニュースが流れました。


社内会議すべてiPad ベスト電器、資料流出も防止


今後こういった利用は、ますます進んでいくと思います。

企業におけるペーパードキュメントは、コンピュータの導入で減るどころか増える一方。

毎月のデジタル複合機の利用料に頭を悩ませている企業もかなりあるのではないでしょうか?

ベスト電器の事例も恐らくそういった事情が背後にあるのではないかと推測できます。

しかし、ペーパーレスを目的にドキュメントをiPadで閲覧しようとしたとき、何らかの方法でiPadから社内ドキュメントにアクセスする手段を考えなければなりません。

まず考えられるケースとしては、ドキュメントはPDF化し、サイボウズ等のWebベース・グループウェアが持つファイル管理機能を用いて、それらのPDFデータをiPadから閲覧するという方法です。

導入初期の段階では、この方法でも十分に利用可能だと思います。

しかし、iPadの導入が進むにつれて、大量のPDFコンテンツをフォルダレベルで階層化し、適切なセキュリティコントロールを保ちながら管理をするのは、システム運用負荷が極めて高くなる可能性があります。

このあたりは、社内のファイルサーバの運用を考えれば良くご理解いただけるでしょう。

現在、ファイルサーバはほぼ全ての企業に導入されているといっても過言ではないと思いますが、このファイルサーバを適切に運用できている会社は極めて限られていると思います。

それもこれも、ファイルサーバはコンテンツを適切に管理するために機能しているものではないことに起因していると思います。

そもそもコンテンツ管理は、アクセス権もさることながら、ドキュメント検索、保存期間や廃棄時期の管理、そしてアクセス履歴・頻度などまで含めた複合的な管理ができないことには、データがたまる一方であり、サーバ資源をムダに消費し、またシステム運用にも大きな負荷を与えることになります。

こういった問題を解決するためのコンテンツ管理システムが存在するのですが、現時点でiPadに対応した製品は極めて限られていることと、使いこなすのが難しい機能(不必要な機能)がてんこ盛りの高価なパッケージソフトを購入するのに二の足を踏んでいる企業も多々あることだと思います。

そこでお勧めするのがFileMakerGoを使ったカスタムソリューションの開発です。

ちょうど先日SuperContainerというFMプラグイン+JavaServletで構成されるキットがFileMakerGoに対応しました。

SuperContainerがFileMakerGoに対応したことで具体的にに何ができるかというと、PDFドキュメントやWord/ExcelといったOfficeドキュメント、さらにはiPadで閲覧可能な動画ファイルをデータベース化して管理し、それを直接iPadからアプローチできるシステムが簡単で安価に開発できるようになったのです。

具体的にはこちらのYouTubeを見てください。


ご覧のとおり、FileMakerGoの中でPDF/Word/Excel/動画コンテンツが閲覧可能になっています。

この仕組みを使うことで、各々の会社独自のコンテンツ管理ソリューションを安価に開発することが可能になります。

ファイルサーバの最大の欠点は、コンテンツがデータベース化されていないことあります。

データベース化されていないがために、登録・保存期間管理・検索・更新・閲覧頻度管理・廃棄といった、コンテンツ管理のライフサイクルを効率的にマネジメントできないのです。

また、コンテンツ管理に関しては、様々な社内ルール(ローカルルール)があり、パッケージ商品では対応しきれないことが多々あると思います。

こういったローカルルールは、社内業務を変えてパッケージ製品に社内運用を合わせるというのがこれまでの「王道」とされる対応方法でした。

しかし、このようにパッケージ製品に社内運用を合わせるといった方法でうまくいった事例がどれほどあるでしょうか?

私が知る限り、この方法でうまくいった事例はほとんどありません。

確かに理屈では、この「王道」が正しいのですが、この対応方法に実際に使う人間のメンタリティ・感情はまったく考慮されていません。

これまでコンテンツ管理システムは、自社開発しようとすると高コストだったのですが、FileMakerとSuperContainerの組み合わせで、極めて安価で早く独自のソリューション開発が可能になります。

iPadを社内資料の電子化が目的で導入される予定の企業は、ぜひFileMaker+SuperContaienrによるカスタムソリューションの開発をご検討してみてはいかがでしょうか。

2010年8月21日土曜日

アメリカでも育児休暇や家族休暇を取ることは評価にマイナスと捕らえられている。

久々の翻訳書、フリーエージェント時代の到来:ダニエル・ピンク著を読んでいます。

単なるノウハウ本やそこの浅いビジネス書と違って、翻訳されるような本は骨太で読み応えがありますね。

もちろん最初はフォトリーディングでアプローチするのですが、この手の骨太本は、その後何度も読み返してしまいます。

それぐらい、味わい深い本ですね。

さて、今日の話題はタイトルにも書いたとおり、「アメリカでも育児休暇や家族休暇を取ることは評価にマイナスと捕らえられている」件です。

アメリカでは1990年以降、仕事と家庭のバランスを取ることに国を挙げて取り組み、様々な法整備がなされたようです。

例えば、アメリカには家族休暇・医療休暇法という法律があるそうです。(現存するかどうかは未確認)

これは、一定規模以上の企業の従業員に、新生児や病気の家族の世話をするために、年間12週までの休暇を認めるという法律らしいです。(休暇中は無給)。

しかし、この法律に基づいた休暇の利用率は全体の4%に過ぎず、また休暇を取った人も、大多数は2週間に満たない短期間だったということです。

この休暇制度が積極的に利用されない背景には、"オーガニゼーション・マン(組織人)"のあるメンタリティが隠されているようです。

それは、育児休暇・介護休暇・フレックスタイム製などの「家族に優しい」制度を利用すると、出世にマイナスになると考えている人が、全体の41%もいるということです。

約半数弱の人が、家族に優しい制度が出世にマイナスと考えているのです。

これは個人的にイメージしていたアメリカのビジネスパーソンとはずいぶんとかけ離れたものでした。

こういった考えは日本や東アジア特有のものと思っていたのですが、これだけ法制度が進んだアメリカで働くビジネスパーソンも、同じようなメンタリティを持っていたのですね。

なんとなく「会社員」、この本でいうオーガニゼーション・マンという枠組みの中で仕事をするということの本質が垣間見えるような内容です。

著者のダニエル・ピンクさんは、この法制度に2つの大きな欠陥があると言っています。

ひとつは「自分サイズの服」を求める人に、「共通サイズの服」で解決を押付けていること。

もうひとつは、「仕事と家庭のバランスをとらなくてはならないと決め付けていること」と書いています。

ふたつ目の欠陥については、個人的にすごく共感できるものです。

私は子どもが生まれたタイミングでフリーランスとして独立をしましたが、そのきっかけは、「会社という枠組みでは、仕事と家庭のバランスを取るのは無理」だという結論に達したことです。

その時は別に会社が悪いとも、社会が悪いとも思いませんでした。

単純に自分がこう生きたいというライフスタイルに、会社というフィールドが適応できないので、別のフィールドに引越しをしたという感覚です。

私にとっての仕事は生活や家庭の一部であり、まったく別の毛色のものではありません。

何よりも仕事をしているときは楽しいですし、ワクワクして取り組んでいます。

それと同じく、家族とキャンプをしたり日曜大工をしたりという時間も私にとっては楽しくワクワクした時間です。

これがいい具合にブレンドされた24時間が、自分にとっては極めて心地の良いライフスタイルです。

著書の中では、「実際に、ほとんどの人に本当に必要なのは、それぞれのやり方で仕事と家庭をブレンドさせることなのだ」とあります。

まさに「我が意を得たり!」ですね。

2010年8月20日金曜日

企業に溶け込むiPad

今週一週間、夏休みをいただいています。

月曜日から今日まで、白馬~安曇野で4泊5日のキャンプを楽しんできて、ちょうど先ほど、キャンプから帰ってきました。

キャンプの荷物を家に運び込む途中で郵便受けを確認したところ、8月18日発行の日経コンピュータが届いていました。

ちらっと表紙を見ると、企業に"溶け込む"iPadという特集記事が組まれているではありませんか!

、妻の無言のプレッシャーを感じながらもキャンプの後片付けをちょっと中断して、しばし内容を読んでみました。

記事によると、iPadの本格的な業務利用が始まったということで、居酒屋チェーンの注文端末や、銀行での接客時に使用するプレゼンテーションツール、そしてベテランの技術ノウハウを伝承するためのナレッジベースとしての利用例、さらには医療現場での利用例が掲載されていました。

そして最後に、ではこのiPadで動くアプリケーションは、どのようなテクノロジーで動いているのかに関する解説が書かれているのですが、やはりというか次のような行がありました。

引用開始
企業がiPadやiPhoneを様々な用途で使い始めている一方で、情報システム部門にとっては不安材料もある。
アプリケーションの開発や管理方法が、使い慣れたWindowsや従来の携帯電話とは異なるからだ。
iPadやiPhoneのアプリケーションは、アップルが配布しているSDKを使って開発するのが一般的だ。
このSDKはMacOS上でしか動作せず、Objective-Cと呼ばれる開発言語を使う必要がある。
引用終了

こちらの記事にあるとおり、確かにiPad/iPhoneで動くプログラムを作る唯一の方法は、Objective-Cになります。

しかし、iPad/iPhoneで動く「業務アプリケーション」であれば、FileMaker/FileMakerGoで開発することが可能です。

私はObjective-Cでの開発を知らないので、一般論でしかお話できませんが、常識的に考えて業務アプリケーションをFileMakerで開発するのと、C言語がベースになっているObjective-Cで開発するのとでは、どちらがコスト・時間的に有利なのか、想像に難しくないと思います。

また、記事の中に、「iPad用アプリケーションの開発に当たっては、人脈を作って、iPadやiPhone向けの亜プロケーション開発で実績があるベンダーを探さなければならず苦労した。」という情報システム部門の方の話が掲載されていました。

こちらについては、まだiPad/iPhoneを用いた本格的な業務アプリケーションを開発しているベンダーが極めて少数であることから、想像以上に大変だったと思われます。

しかし、この選択肢の中にFileMaker/FileMakerGoがあれば、開発ベンダーを探すという苦労も、そして開発コスト・開発期間も、極小化することができたと想像できます。

これからiPad/iPhoneの業務利用を想定されているのであれば、ぜひ一度、FileMaker/FileMakerGoをご検討されることをお勧めいたします。

2010年8月13日金曜日

フリーランスSEとして生きるという決断

今日はWebサイトリニューアルのきっかけとなったもうひとつの出来事、「フリーランスSE」であることをしっかりと明示するということについて書きたいと思います。


結果から書くと、やっとここにきて「フリーランスSEとして生きるという決断」ができたことがきっかけです。


まぁ、いまでもフリーランスSEでやっているのですが、今後も当分はフリーランスSEで生きるということを自分の中で決断したということになります。


私は、娘が生まれてちょうど1年が経とうとしていた2006年、それまでのサラリーマン生活にピリオドをうち、株式会社ライジングサン・システムコンサルティングという会社をつくりました。


独立したいと思ったきっかけはたくさんあるのですが、大きく上げると次の3つになります。

・通勤電車に乗りたくない。

・もっと子どもと過ごす時間を持ちたい。

・将来は会社組織にして、経営者として仕事をしたい。


最初は子どもが小さいうちは、フリーランスとして仕事をし、ある程度子どもが大きくなったら、会社を大きくしてチームで仕事ができるような人生のシナリオを想定していました。


そして娘は今4歳。


日常ではずいぶんと手が離れるようになり、仕事に没頭できる時間も増えてきたところで、これからの自分の仕事についていろいろと考えてみました。


・そもそもなぜ自分がサラリーマンを辞めたのか?

・なぜ個人事業主ではなく法人にしたのか?

・この先、何の仕事を、どのようなスタイルで、どういった人たちとやりたいのか?


こういったことを考える中で、この先当分はフリーランスというスタイルでやっていこう、やって生きたいと思ったことが、今回のリニューアルのきっかけになります。


それではなぜ「フリーランス」というスタイルなのか。

理由は3つあります。


ひとつは、フリーランスというスタイルが、自分の人生観、自分自身の性格にに最もマッチしたワークスタイルであること。


ふたつめは、SEという自分の生業と「フリーランス」というワークスタイルの親和性が極めて良好なこと。


そして最後に、数十年の世の中の流れを想定して、一番リスクが少ないワークスタイルであること。


この3つが「フリーランス」を選んだ理由です。


この3つの詳細については、このブログで少しずつ書いていきたいと思います。

2010年8月11日水曜日

ホームページをリニューアルしました。

長年中途半端なままだった会社のホームページをリニューアルしました。

リニューアルの目的は主に2つあります。

ひとつはFileMakerを使ったソリューション開発を全面にアピールすること。

そしてもうひとつが、「フリーランス」であることを明確に示すことです。

本日は、前者の「FileMakerを使ったソリューション開発を全面にアピールすること。



こう考えるようになった背景について書きたいと思います。


まずFileMakerを使ったソリューションというのは、この2年程度で、自分自身がFileMakerプラットフォームでの開発に、かなりの自信と可能性を見出せたことが一番のきっかけです。

恐らく3~4年ほど前だったと記憶していますが、はじめてFileMakerを触ったときの感想としては、FileMakerではプロが提供する商用レベルのアプリケーションは作れないと思っていました。

ただ、その生産性の高さは直感的に察知していましたので、私はこれを業務システムのシミュレータツールとして使う判断をしました。

業務シミュレータとは、「業務設計・RFP・要件定義の"天動説"(木ノ下勝郎氏著)」の書籍に出てくる言葉です。

後日業務シミュレータについては詳しく書きますが、既存概念として「プロトタイピングモデル」によるシステム開発プロジェクトの弱点を埋めるため、そして何よりも「要件定義の正確性」を極限まで高めるために同氏が考えられた手法のひとつです。

冒頭にも書いたとおり、FileMakerは業務シミュレータとしての活用を考えて勉強を開始したのですが、勉強を進めていくうちに、これは確実に商用アプリケーションを開発・運用できるだけのポテンシャルがあるソフトウェアであることを認識しました。

そこからさらにFileMakerに関する技術習得を続けた結果、世界で唯一FileMakerのハイスキルな技術者であることを証明する資格であるFileMaker認定デベロッパーのVer10/11に合格することができました。

この認定デベロッパー合格に向けた勉強をしている中で、FileMakerに関するその秘められたポテンシャルをだんだんと感じてくるようになったのです。

最近では、数十人規模から数百人規模の業務システムにおいては、ほとんどのケースでFileMakerがベストな選択肢ではないかと思っております。

また、極めて少ない労力で高度なアプリケーションを高速に構築できるRAD(Rapid Application Development)ツールとしては、今のところこのソフトウェアの右に出るものはないのではないかとも思っております。

これまで3000万円かかっていた新システムの調達が、条件さえ整えば500万円程度で可能になるかもしれない。そんな可能性をもった開発プラットフォーム。

それがFileMakerです。

そしてこのFileMakerが、私のようなフリーランスSEにと極めて親和性のある開発プラットフォームなのです。

では、どう親和性がよいのか。

それは、システムの上流から下流まで、通常であればチームで動いて初めて完成するシステムが、条件さえ整えば1人でできてしまうということです。

通常、「フリーランスのコンピュータ技術者」となると、おおむねその仕事は、情報システム戦略の策定サポートや、大規模なシステム導入プロジェクトの企画といった「超上流工程」を担う「ITコンサルタント」か、もしくは高度なプログラミング能力を売り物とする「スーパープログラマー」といった仕事になるでしょう。

極端な話をすると、最上流か最下流の仕事であり、超ゼネラリストか超スペシャリストの仕事です。

自分にその能力と知識とやる気があれば、ある程度の規模のシステムであれば上流から下流工程までの仕事を1人で担うことができます。

確かに、FileMakerにも「スクリプト」という独自のロジックを組み込む機能があるので、バグが内在する可能性はありますし、それを防ぐためには1人で開発するのではなく、複数人でレビューを重ねながら開発するというのが、正しいスタイルではあると思います。

しかし、それを差し引いてもいくつかの前提条件が整っていれば、1人で開発が可能であると考えています。

このいくつかの条件については、このブログでおいおい書いていきたいと思います。

さて、ちょっと長くなってきたので、今回はこの辺で・・・

明日は、もうひとつのフリーランスについて書きたいと思います。