90 マジメな話 Archive

　先日、ソフトバンクによるVodafone日本法人の買収が報道されたが、日本でも近年、企業買収とりわけ敵対的買収やそれに関わる金融テクニック用語もよく耳にするようになってきた。

　企業向け統合ソフトウェアパッケージの業界では、Oracle社によるPeopleSoft社の買収劇がメディアを賑わしたことが記憶に新しいが、このOracle社、この約2年間で実に20社以上のソフトウェア会社の買収を行ってきている。

　特にPeopleSoftやその後買収したSiebelについては、ERP/CRM分野で高いシェアを誇る企業向けソフトウェアパッケージベンダであり、Oracle社の買収も「敵対的」買収としての色がより濃いものであった。同社は以前からこの分野に「E-Business Suite」という名のソフトウェア製品群を投入していたが、ライセンス販売高や顧客シェアにおいて劣勢と言わざるを得ない状況にあった。

　コンサルタントという立場ではあるが、企業のシステム開発の現場近くに身を置く立場として、このOracleによる買収・合併の行く末は非常に気にかかる。

　冒頭述べたOracle社による企業向けソフトウェアベンダ買収の目的は主に、「短期的な財務指標の改善」と「カスタマーベースの取得」が中心であるように見える。この2点については、「１＋１＝２」となる世界であり、買収先企業の顧客は自動的に自社の顧客となり、売上げも自社に連結される。そして勿論、有力な競合企業の排除による市場影響力も相対的に増大することになろう。 　一方で、同社のWebサイトや報道発表では「複数製品による機能補完」や「より広範囲な統合アプリケーションの提供」をその目的として提示しているが、実現には多くの困難が待ち受けているだろう。 　そもそも企業向けのソフトウェアパッケージとは何か。

　さまざまな定義があると思うが、一般的には、企業の業務プロセスを自動化・効率化するために作成された汎用的なアプリケーションソフトウェアのことであり、購入して最低限の設定を行えば、短期間でユーザが利用開始できる。
また、設定に留まらず、導入企業毎にカスタマイズにより独自仕様を追加して機能を拡張するためのツールや環境を具備しているものも多い。

　現在、ERP（財務会計や人事などの基幹業務）やSCM（サプライチェーン管理）、CRM（顧客関係管理）などのさまざまな業務分野に特化したパッケージソフトウェアが販売されており、あらゆる業務分野への対応をうたった「統合スウィートパッケージ」と呼ばれる製品も開発されている。SAP R/3やOracleのEBS、PeopleSoftなどは企業向け統合スウィートパッケージを提供する大手のベンダであると言える。

　これらソフトウェアパッケージだが、実際のモノとしては、次のような構成要素から成り立っている。

　(1)アーキテクチャ（アプリケーション実行・開発環境およびその設計思想）
　(2)データモデル（データベーススキーマ）
　(3)ビジネスプロセス定義とアプリケーション（GUI、ビジネスロジック）

　(1)はシステムの稼動基盤であり、性能・処理効率や拡張性などを考慮したハードウェア・ソフトウェアの構成またはそれに係る設計思想を指す。
　(2)はアプリケーションが登録・更新・照会を行うデータの具体的な格納の仕方・構造のことであり、RDBMS（リレーショナル・データベース管理システム）上に実装されるデータモデルとほぼ同義である。業務プロセスの特性を踏まえたデータ構造や、効率的なデータ格納方法などが考慮・定義される。
　(3)が最もユーザに馴染みやすい部分で、想定する業務プロセスの定義と、その実行のための具体的な画面と、その操作に伴って実行される各種ビジネス処理である。

　これらの3点があらかじめ定義・実現され、すぐに使えるように製品化されたものが企業向けソフトウェアパッケージであると言える。

　少々説明が長くなったが、このようなソフトウェアパッケージを製造するベンダ間で買収があった場合、製品はどうなるのか？「お互いのいい所を補完しあってより良いものに」と言うのは簡単だが、異なる製品同士の統合は非常に困難である。

　まずはアーキテクチャの観点。前述したパッケージの構成要素のうち、アーキテクチャ統合は、非常に困難を極めるケースが多い。そもそも2階層のC/S構造の製品と多階層Webアプリの統合などは限りなく無理が生じるであろうし、ソフトウェア構成が似通っていたとしても、機能や処理の分散・配置に関するポリシーが異なる場合、統合はやはり容易ではないだろう。

　次にデータモデル。データモデルの流用については、ある程度実現が可能かも知れないが、製品として販売されているPKGの場合は、アプリケーションの実装に即して物理構造が最適化されているケースが多く、そのままの流用は困難。論理設計レベルでの適用でどの程度のメリットが出るのかは要検討だ。
　また、製品同士で業務カバレージが重複するケースも多く、その場合はデータの保持についても重複が発生することになる。顧客や自社組織といったマスタデータの構造しかり、受発注などのトランザクションデータの構造しかり。ベースにあるデータとその関連の前提が異なる場合、モデル統合というよりは重複保持を前提とした連携・同期といったサブシステム間I/Fの実装へ寄ってしまうことも多いだろう。

　最後にアプリケーション部分。この部分については、上記2点の統合ができない場合、そのまま使うことはまず不可能。特にGUI部分については製品の独自色が出やすい（画面構成や遷移のクセなど）ため、異なるアプリケーションのつぎはぎはオペレーションの複雑化や不整合を生みやすい。せいぜい業務レベルでの機能・処理をどちらか一方に実装しなおすといった流用がいいところだろう。

　このように考えてくると、買収によって製品そのものがより良い統合された１つの製品に生まれ変わるということはほとんど期待できないのではないか、という思いが強くなる。まして、1社や2社でなく数十社の製品を統合するとなると尚更だ。買収された企業のソフトウェアを利用しているユーザにとっては我慢ならない話だろう。

　このような現実を受け、買収攻勢を続けるOracleが選択したのは、製品の再構成としての統合ではなかった。 「プロジェクト・フュージョン」と銘打ち発表された同社の製品統合のロードマップは、アーキテクチャ統合やデータベース統合をあきらめ、EAI/BPM領域に位置づけられるミドルウェアを利用し、相互接続性を担保していこうというソリューションだった。見方によっては「間に合わせ」的で根本から目をそらせたアプローチと言えない事もない。

　顧客の立場からすれば、同じ会社の製品をつなぐためにEAI/BPM製品が必要というのはどう考えてもばかばかしい話だ。

　そもそも最終消費者が「サービス」に対価を払う銀行や小売の合併と違い、ソフトウェア企業の場合はソフトウェアという「製品そのもの」に金を払っている感覚が強い。パッケージソフトの良いところは、必要なものから早期に導入でき、後から徐々に業務領域を拡張していけるところだったのに、買収の結果、その道が断たれたり、明らかに「合わない」製品にゴテゴテとアダプタをつけて購入しなければならないとなれば、容易には納得できないだろう。

　とはいえ、既に述べたように真っ向から製品に立ち向かい１つの統合製品をつくるにはあまりにも多くの企業を買収してしまっているのも事実。獲得した顧客ベースをつなぎ止め、同時にビジネスを継続していくための唯一現実的な方法がプロジェクト・フュージョンだったのかも知れない。 　折りしも「SOA」なんて言葉が流行っており、既存資産の有効活用とか、サービスを媒介にしたシステムの有機的な疎結合なんてこともまことしやかに語られている。しばらくはこれで良い、もしくは中継ぎ手段としてはこれで良いのかも知れない。

　ただし、システムの一般的な寿命を5年～10年とした時、10年後、15年後に同社のエンタープライズアプリケーションの姿が、買収してバラバラに作ったものの寄せ集めの域を出なかったとしたら、顧客はきっと離れていくだろう。

　かつてERPベンダだったPeopleSoft社がCRMで高い導入実績を誇ったVantive社を買収した際にも同じようなことが懸念された。しかし同社は、自社の既存製品のアーキテクチャ更改の際、VantiveのCRMアプリケーションを完全に新アーキテクチャ上に載せかえてみせた。継承されたのは、設計仕様とも言うべき「機能性」のみといっても良い。

　長期的な視野から真に統合されたエンタープライズパッケージを目指すのであれば、自社のコア製品（E-Business Suite）と買収した各製品について、真剣に、詳細な分析を行って欲しい。そしてあらゆる角度から再評価を行い、優れているところ、劣っているところをスコアリングする。それに基づいて、存続するアーキテクチャを選定、もしくは新しいアーキテクチャを検討する。
　また各アプリケーション機能やデータモデルについては注意深く統合を行い、効率が悪い部分については思い切って設計仕様のみを受け継いで実装はスクラッチで行うことも検討する。

　このようなアプローチによって、全プロダクトを一貫性のある作りにして真の意味での「統合アプリケーションスウィート」を作るためのロードマップをユーザに公開すべきではないだろうか。場合によっては、旧Apps、EBSのアーキテクチャを捨てて買収した中の1社のアーキテクチャに合わせるとか、そんな大胆な選択も有効かも知れない。
　それができないというのならば、結局はマネーゲーム、顧客に対して高い価値を提供し続けていた企業を、自らの存続や利益拡大のために潰し、結果として最終消費者にそのつけを払わせたと言われても仕方がないのではなかろうか。

　キャッシュに物を言わせて企業向けソフトウェアパッケージ市場の再編を無理やり加速させたOracleは、その責任を重く受け止めて、最も広いカバレージを持った最も良い製品を提供してもらいたいものだ。

先日、会社のコーチング研修というのを受講して来た。本来2日間でやるコースを1日間に短縮したもので、ロールプレイ形式のエクササイズを中心に進めながら、コミュニケーションスキルの伸張とコーチングの基礎を学ぶのが目的。この研修の中で、「コーチングのためのタイプ分け」というのが面白かったのでちょいとご紹介。

授業の中では、参加者全員が簡単なテストによってコミュニケーションタイプを判定される。
タイプは次の４つ。

• 人や物事を支配していく「コントローラー」
• 人や物事を促進していく「プロモーター」
• 分析や戦略を立てていく「アナライザー」
• 全体を支持していく「サポーター」

テストは40個の質問で構成され、その回答により上記の４タイプ毎のスコアが算出される。最も高い数値が現れたところが自分のタイプとなる。
（あなた自身のタイプもTest.ne.jpのWebサイトでチェックできる。是非お試しあれ）
授業で使用するテキストには、各タイプのコミュニケーション上の特徴や重きを置く価値、異なるタイプに対峙した時の留意事項などが示されているのだが、４つの違いを大まかに知るには、「自己主張」と「感情表出」の2軸により4象限で分割するのが良いのだとか。

自己主張が強く感情表出も大きいプロモーターは、「自由」と「影響」に価値を見出す。つまりアイディアの斬新さや、どれだけ他人へ影響を与えられるかが一番の関心事となる。

自己主張が強く感情表出が少ないコントローラーは、「判断」と「スピード」重視。重要な決断を下すことに躊躇しないが、合意形成に時間をかけることを退屈に感じることもある。

自己主張、感情表出ともに少ないアナライザーは「正確さ」と「ペース」が重要であるため、自分で立てた計画に基づいて着実に物事をこなして行くことを好む。そのため外的要因などで計画が変更を余儀なくされ、ペースを崩されることを嫌う。

最後に主張は弱いが感情豊かなサポーターは「合意形成」と「安心」を大事にする。頼まれれば嫌と言えない性格で、他者との関わりや強調による安心が感じられる時に充実感を得られる。

授業では、それぞれのタイプ別にグループを作り、同じタイプの人間同士でディスカッションをしたり、特定タイプの人間と質疑を繰り返して傾向を確認したりというアクティビティを行う。
占いや心理テストのような要素があり、アクティビティもゲーム性があるので大いに盛り上がるのだが、結局は人とのコミュニケーションを取る際に、自分と相手のタイプを認識することで不要な衝突や誤解を回避しようというのが趣旨となる。

正直、この手のタイプ分割は目新しいものではなく、エゴグラムやその他さまざまな分割方法があるし、このようなタイプ分割に基づいて技巧的な対話を行うことには違和感を感じる。

ただ、このアクティビティを通して再認識すべきと感じたのは、人間の「多様性」とそれに基づく「価値感の相対性」ということ。上記のような簡単なテストでも人の傾向は大きく異なることがわかるし、自分が何よりも大切にしているものが他人にはどうでも良いものかも知れないし、その逆も然り。人からされて嬉しいこと・嫌なこと、受入れ易いこと・難いこと、人それぞれだ。

このような認識はコミュニケーションの基礎だと思うし、友人関係の中では当然のように意識していることかも知れないが、上司－部下という関係になった途端に忘れてしまいがちな点かも知れない。
相手との間に絶対的な差異（スキル、経験、年齢・・・etc）がある場合のコミュニケーションでは、上位にある者が自分の流儀や経験を相手に押し付けてしまったり、自分が欲しい、もしくは欲しかったサポートを与えて指導した気になってしまいがちである。

自分よりもスキル、経験の乏しい部下と対峙し、彼or彼女が自主的に考え、行動して自らのゴールを達成するのをサポートするのが「コーチング」であるならば、
　・自分が他者と比して様々な傾向・特性を持った存在であること
　・相手もまた、自分と比して異なる傾向・特性を持った存在であること
この両方を忘れてはならないのだろう。

自分のノウハウや経験のみから部下を指導・強制するのではなく、上司としての責任を持って部下の傾向や特性を理解し、質問や承認（ほめる）行為を通して相手の自主的な思考・行動を促していくというアプローチ。
それが自然にできるようになるのが、コーチングにおいて最も大事なことなのだろう。

なんだか難しいね。
あなたは後輩や部下に対してどんな風に接してますか？

最近、髪を切りに行く度に思うのが、大手美容室のサービスの良さ。
1年くらい前から通っているところがあるんだけれど、ホント、ちゃんとしている。
顧客との良好な関係を継続的に築くことでロイヤルティを高め、収益向上につなげていくというCRM（Customer Relationship Management）の発想が、美容業界へも徐々に浸透してきていることを感じさせられる。

まず、電話での予約受付。
店に直接ではなくて、受付専用番号に電話。すると、発信者番号を検知して自動的に顧客情報（氏名や通っている店舗、担当者情報など）が表示される（と思われる）。こちらから名前や担当者を告げなくても、「○○様ですね、ご担当者は××でよろしかったでしょうか」と言って来る。毎回の予約の度に名乗ったり、担当者を告げるのは何気に面倒なので、結構嬉しい。

店に行くと、カードを提示してロッカーに荷物を預ける。ロッカーもスペースを有効活用しながらも上着やかばんを無理なく入れられるようなつくりになっている。

またこの店では、1人の美容師が多くの顧客を相手にしなければならないため、洗髪→カット→カラーリング→洗髪→ブローといった一連のプロセスにおいても徹底した分業が図られている。俗人的な要素の低い洗髪やカラーリングなどの作業はアシスタントが担当し、カットや仕上げのブローは専属の美容師が担当するといった具合だ。こうした分業は、客の立場からすれば「ぞんざいな扱いを受けた」という印象を受けやすいのだが、そこにも配慮が見られ、アシスタントはよく教育されており、皆にこやかに話しかけてきて態度が良い。

毎回のカットの履歴やカラーリングで使用した薬品の調合などに関する情報も、カルテとして残されている（と思われる）。そのため、たまたま担当者が休暇の日に別の店舗に行ったとしても、以前やったカラーリングと同じカラーをオーダーすることも簡単にできる。
実際、以前は代官山店に通っていたが、あるとき原宿店の別の担当者に切ってもらったときも全く面倒がなかった。以降、原宿店に通っている。

また、カットやカラーリング、ブローに至るまで、美容師は細かにその手順の内容を説明してくれる。ワックスを使った手ぐしの入れ方なども丁寧に教えてくれる。また、使っている整髪料なども、希望すれば店頭で販売してくれるようになっている。

このようなサービスの発想は、まさにCRMではないか。

よく「CRMの原点は駄菓子屋のおばちゃんである」ということが言われるが、いわゆる個人経営の駄菓子屋においては、店主たるおばちゃんが、顧客である子供たち一人一人の顔や好みなどを全て把握してサービスを行なうことが可能だ。この当たり前のサービスが、事業活動の大規模化と顧客チャネルの多様化により実行困難になるところにテクノロジーの出番がやってくる。

この美容室も、個人経営の1店舗経営から、多くの美容師を擁する複数店舗経営という拡大路線の中で、無理なく適正規模での技術を導入し、顧客満足度を高めている良い例だと思う。

視点を変えて美容室という事業の特性に着目してみる。

（１）加入者型に近いビジネスモデル
言うまでもなくサービス業であるが、この店のような大手美容室の場合は、いわゆる「加入者型（Subscribe型）」に近いモデルとも言える。不特定の顧客に対してサービスの売り切りを行なうのではなく、会員登録を行った特定顧客に対して定期的にサービスを提供することで、継続的に対価をもらう形態である。

（２）特定従業員（美容師）への依存度が高い
消費者は「美容室」ではなく「特定の美容師」を選んで髪を切っており、その美容師が持つ技術に対して金を払っている。そのため、美容師が転籍した場合には顧客も一緒に移動してしまう場合が多い。

まず（１）を考えた場合、重要となってくるのは顧客のリテンション活動である。店先で呼び込みをかけ、たった1回髪を切ってもらっただけでは儲からない。定期的に来店してもらい、継続的に出費してもらうことが収益向上のキーとなる。特に客層の多くを占める女性客は意外にドライであり、ちょっとした不満やトラブルですぐに他の美容室へ乗り換えてしまうため、ロイヤルティ形成は非常に困難であると思われる。

（２）については、従業員満足度の向上と離職率の低減が課題となってくるだろう。高い技術を持ち、多くの顧客をつかまえた美容師を他店に次々と奪われていては、全く意味がない。インセンティブの導入や職場環境の改善などを通して優秀な従業員が好んで留まる職場を形成することが重要となるだろう。

前半で自分の体験を紹介したが、この他にも、この美容室ではいくつかの顧客リテンション活動を実行している。例えば会員カード。初回来店時に発行されるのだが、来店を続けるうちにランクが上がる。僕は現在「SILVER」カードだが、奥さんは既に「GOLD」カードになっている。ランクが上がると毎回の料金が10%OFFになったり、トリートメント無料などのさまざまな特典が用意されている。こうした取り組みは、個々の美容師を向き勝ちな顧客の目を「美容室」自体に向けさせ、ロイヤルティを高めるために非常に有効な施策である。

こうして褒めちぎってきたが、まだまだ課題が多いことも事実。やはり情報化が遅れている業界のためか、IT関連のサービスはまだ一歩遅れた感が否めない。以下に奥さんの意見もとり入れた上でいくつか提言をば。

・Webサイトでの情報提供
意外としっかりとしたWebサイトを持っている美容室はまだ少ないとか。
はじめていく美容室であれば、美容師の情報（顔写真・性別・得意なカット・略歴など）などをあらかじめ確認した上で来店できると良い（らしい）。

・インターネット予約の仕組み構築
CTI（Computer Telephony Integration）を活用した受付の仕組みに加えて、インターネットから予約する仕組みが是非欲しいところだ。顧客の多くは日中仕事場でPCを使っており、インターネットに常時接続されているはずだ。これにより利便性は更に向上する。

・顧客情報の更なる整備
個人としての顧客情報だけでなく、顧客同士の関係などの情報なども美容師任せでなく、集中的に管理できると良いのではないか。特に女性客などは、友人の紹介などを頻繁に行なうらしいし、うちのように夫婦で同じ美容室に通っている場合もある。そうした部分を加味した応対やサービスなどがあると、一層良いと思われる。

・特定顧客層への定額制の導入
これはやり過ぎか？ただ、月に何度も来店して金を落としていくような優良顧客については、年間契約などを取り付けて定額料にてサービスを提供することも良いのではないか。

これまで中規模以上の企業を中心に語られることが多かったCRMであるが、美容室を始めとした小規模サービス業界でも今後は更なる進展があるだろう。
システムで飯を食う側から言えば、こうした仕組みを低いコストで導入してもらうためには、共同利用型プラットフォームの構築や、アウトソーシングビジネスの立ち上げが考えられるかも知れない。

翔ソフトウェアというサイトで、スラップスティック アジャイル プロセス導入記という記事を読み、「パターンランゲージ」という概念を知った。

「パターンランゲージ（Pattern Language）」とは、元々建築家のChristopher Alexanderにより提唱された市民参加型の建築・都市デザインプロセスに端を発する。合意形成とデザイン、施工などから成る一連の建築プロセスにおいて、個々の局面での問題解決シーンをあらかじめパターン化しておくことで効率よく質の高い建築を実現しようという手法を指す。
最近ではこの考えが汎用化され、あらゆる知識エリア・活動エリアにおける効果的な合意形成や創造行為をサポートする共通言語として捉えられることも多い。IT分野においては、このパターンに基づく思考整理や合意形成の手法を用いて、要求仕様の整理から機能の抽出、開発までのソフトウェア開発プロセスを効率化しようとする動きもある。XP（eXtreme Programming）に代表されるようなアジル（Agile：アジャイル）開発などとも親和性の高い概念となっている。

ここで言う「パターン」とは、問題の典型的な解決法をある定められたフォーマットで記述したものであり、「パターンランゲージ」は、相互に関連した「パターン」の集合帯で、より体系的に問題解決を行うためのもである。

こうした取組みは、「暗黙知」を「形式知」に変換しようだとか、SECIモデル （セキモデル）のように循環させようだとかという議論や、組織全体のパフォーマンス向上のための標準化への取組みなどがベースとなっているのだろう。
※リンク先の記事ではこれらの概念が若干煩雑になっている気がするが。。

個人的には、このようなチャレンジングな取組みが大好きだし、「暗黙知」を「形式知」に変換するナレッジ・マネジメントや、圧倒的な効果と生産性をもたらす「パターンランゲージ」の整備に携わってみたいとも思う。ただ、気をつけなければならないのが、こうしたパターン化・標準化の取組みというのは、元来知的探究心の旺盛な人間にとって「危険な果実」であり、他者の創造的思考やマイノリティの可能性を奪ってしまいかねないということだ。
友人のabe++は、自身のblogにおいて、「標準化する人・される人」「仕組む人・仕組まれる人」の関係を取り挙げ、仕組む側に立つ人間がしばしば自身の視点を見失い、個別最適に走る危険性を指摘している。

加えて、事象のパターン化に代表される「暗黙知」の「形式知」化には常にオーバーヘッドが伴うことを認識しなければならない。その道10年ベテランが書いた本を読んだからといって、すぐに同じような仕事ができるわけはない（形式化された知は目減りしている）し、そんな本を読んでしまったばかりに、読まなければ行っていたであろう試行錯誤や工夫をしなくなることもあるだろう（形式化された知が、暗黙知発達の阻害要因となる）。

こうした点に配慮することなく、不用意にパターンランゲージと称して他者の創造的活動を妨げるようなコンテンツを放出することは避けなければならないだろう。

以下に対の概念を挙げる。本当に大事なのは常に後者かも知れない。
しかし、混沌とし、ともすれば無気力な相対論に陥ってしまいがちな人間にとって、理想的・普遍的なルールがあると信じて標準化・パターン化に取組むことは決して悪いことではないと思う。

• 戦略と実践
• 標準化と遵守
• 汎化と特化
• 理想と現実
• 普遍と混沌
• 静的と動的
• 共通の限定と個別の自由
• 知的探究心と無気力な相対論

重要なのは、本末を混同しないこと、傲慢な標準化論者・パターン化論者となって他者の反感を買わないようにすることだろう。

流転の世界である感覚物に対して、学問知識の成立を問うたイデアをめぐる議論も、そんなところにあったのだろうか。なんつって。（笑）

【参考】
Biztech special - 形式知／暗黙知、SECIモデル
技術系メーリングリストで質問するときのパターン・ランゲージ
要求獲得と合意形成のためのパターンランゲージ入門 ※PDF、あんまりオススメじゃない

哲学というにはショボイのだが、自分なりのスジ。

「人間は何のために生きているのか」という問いには、
「幸せになるため」と答えたい。

「じゃあ、幸せって何さ？」と問われるならば、
「自分が必要としている誰かに、自分が必要とされていること」と答えよう。

幸せを定義しようとした時、他者との関係抜きには考えられないし、考えてはいけないと思う。他の動物と人間とを隔てる大きな違いの一つは、「自分以外の他者との関わりにおいて幸福を捉えられる」ことではないかと思う。故に人間はより充実した生を享受できるとともに、弱さも併せ持つことになったのだと思う。
「自分なんていなくてもいいんだ」と思ったら、幸せではないだろうし、生きていくのも辛くなりそうだ。逆に例え1人でも、自分を本当に必要としてくれる人間がいれば、人は生きていける。
「自分がいなきゃいけない」と思えることで力が沸いてくるし、満ち足りた充足感を味わうこともできる。他者が不在の一時の快楽は、自慰行為と一緒で結局は空虚感を伴うもの。幸せのイメージとはちょっと違う。

産まれて最初に、そして無条件に自分を愛し、必要としてくれるのは親だろう。
その後は、様々な人と出会いながら、より多くの人と「必要とし・される関係」を築きながら自己の存在価値を確認し、充足を求めるようになる。

そして、幸せに貪欲で積極的な人間は、自ら他者を求め、より多くの人から強く必要とされるために知識・知恵・力を身につけ、いくつもの関わりを持っていく。慎ましく消極的な人間は、今自分を必要としてくれる人間を大事にしようと日々心を配り、さらに強い関係を築いていくかもしれない。
どちらにせよ、幸せは他者との関係の中に存在する。昔、「新世紀エヴァンゲリオン」というアニメが流行ったことがあったが、アレのメインテーマというのも、そのような話だったと思う。

自分は、このような幸せに対して積極的・貪欲にアプローチをしていきたい。
「皆に好かれたい」とは思わないが、今自分を必要としくれる家族や友人を大事にしていきたいし、仕事においてはより多くの人間に影響を与えられるだけの能力を身につけ、できるだけ多くの局面・組織・場所において必要とされる人間でありたい。

WEBにこんなこと書いてんのも幸せ探求の１つなんだろな。

以前に類似した仕事をやったことのある人間と、全く経験のない人間とでは、前者の方がより効率的にうまく遂行できると考えるのは自然である。だが、実際には、期待通りの結果にならないことが多いのも事実である。何故か。できる人とできない人がいるだけと言えばそこまでだが、もう一つ突っ込んで考えてみたい。

前に同様の仕事をやったことがあるのに、初めてやる人間より効率的に仕事ができない、または期待されたほどの圧倒的な違いを発揮できないことの理由は、その人が「経験を能力に昇華できていない」ことが原因であると思う。

基本的に経験というものは、「やったことがある」という単なる事実であり、「次に同じようなことができる」ということに対して何の保障にもならない。「やったことがある、うまくやっていた」ことが「次もうまくやれる」とイコールになるのは、2つの仕事が全ての点（ゴール・成果物内容・作業項目とその内容・スケジュール・コスト・・・）で酷似していた場合のみである。だが、そんな事は実際にはほとんどないだろう。
にも関わらず、実務の世界においては、明確な能力評価の物差しが未発達であることもあってか、あいまいな「経験」というものを元にしたジョブアサインや責任委譲が行われるケースが多く、結果としてプロジェクト遂行上の障害となったり、働く個々人にとっても不幸な結果を招くことが多くなっている。

それでは「やったことがある」と「次は人よりうまくやれる」との間に介在するものは何であろうか。僕は個人の「汎化/分化フィルタリング能力（造語）」であると考える。
何かを経験する際に、常にその内容を汎部（多くのケースで適用可能な共通的な部分）と個別部（今回のみに適用可能な特殊な部分）に分けながら物事を進めていく人間は、経験から確実に能力を醸造することができる。これを経験のフィルタリングと呼びたい。
このフィルターが機能していない人間は、新しい仕事に直面した時に、
・短絡的に前回と同じだと考えて盲目的に同じやり方で臨む
・前回との違いにばかり固執するあまり、せっかく培ったノウハウを適用できない
のどちらかとなってしまうケースが多い。いずれにせよ、大きな見落としや、判断ミスを誘発するため失敗する可能性が高い。
よく、物事を教わり理解することを「消化する」と表現するが、まさにその通り、要らないもの・要るものを一瞬一瞬で選り分け、整理して身につけていくことが重要なのだと思う。個人的には、汎化と分化にも更にレベル分けができると、より効果的に能力伸張がはかれると考えている。
例えば、システム構築という仕事に携わるのであれば、ある１つのプロジェクトでの経験の中には、「システム構築全般」に通用する真理や「CRMパッケージソフトウェアを活用したSI」共通のノウハウ、そして「地域系通信事業者の顧客管理全般」に共通するコツなどが散在しているハズである。同様に、今回限りの「個別」として分化したものの中でも、一生活用の用途がないようなものもあれば、イレギュラーケースとして他業者から見て面白いネタとなるものもあったりもする。

仕事をする人間としてこれから経験を積んでいく中で、より高い効率で能力を向上させ、仕事においてより大きな責任と権限を獲得していくためには、この汎化/分化フィルタをフル稼働させていかなければならないと考えている。高度なフィルタを持った吸収力の高い人間であれば、カレーパンを作っていてもパンとカレー全般を意識するだろうし、クリームパンを作れと言われても戸惑わないだろう。また、カレーとパンを本格的に学ぶことになれば料理や食文化を考え出すだろう。

最後に、ジョブアサインをする側、人をマネジメントする側の方々に言いたいのは、こうしたフィルタ能力ないしはフィルタリング後に残ったものをみて評価する方法を見つけて欲しいということ。プロジェクト終了後に論文を1本書かせるなり何なり、方法はあるだろう。
事実としての経験をデータベース化してスキルマッチを行ったり、人事評価に組み入れたりしてもあまり良い結果は生まない気がしますが。