読者です 読者をやめる 読者になる 読者になる

しゃなりしゃなりと

脳内にたまったモヤモヤを吐いていきます

上司からの"アジャイルがダメだと思う7つの理由"になんと答えれば良いか

昔のBOSSから示唆に富むブログエントリーがありFB上で話題になっています。

http://arclamp.hatenablog.com/entry/2013/03/21/233012

BOSSならびにBOSSの所属企業であるGxPさんは、独立系SIerの中ではよいタレントがそろっている希有な存在であります。第1次アジャイルムーブメントからしっかりキャッチアップ&実践されており、私も数年間お世話になった今でも尊敬しているBOSSならびに会社の1つです。

 

BOSSの書くブログや組織をうまく活用したリーダーシップは素晴らしく、ずっと近くにいると影響されすぎて、自分の色が出せなくなる恐れを感じるほどでした。だって、もやもやしていることを、ずばっと客観的&抽象的にブログで書くんですもの.... 当時の私はBOSSのあの抽象化能力を超すことは100年経っても無理だろうなぁと思い、このままではだめだと思い、RSSの購読を断腸の思いで辞めた苦い記憶があります。

 

そしてarclampというブログ活動を起点とした社外を越えたコラボレーションの妙。近くで見ていてほんとにすごかった。彼の周りにどんどん著名人&有名人&実力のある人が集まってき、そしてそれをオーガナイズしていく。当時まだ技術者丸出しの自分からするとそれはそれは宇宙人に見えました。最後の極めつけは、BOSSの名前が「ゆうすけ」であること。みんなに慕われて「ゆーすけさん」「ゆーすけさん」と呼ばれ、こりゃ叶わないと完全にあきらめモードに入っておりました。その後、現在に至るめざましいご活躍は周知の通りでございます。

 

昔話はさておき、今回は、特定のレイヤー向けのアジャイラー(成熟度モデル的にはレベル1とか2、つまり研修受けたての人やアジャイルでの壮大な勘違いフェーズから脱却できていない人)に対しての上司からツッコミだと思います。そこで、ちょっとだけ皆さんの先を行っている(経験量が多いってこと。別に天狗にはなってないですよ)私が、現場のいろんなステークホルダーに今回の7つの”ダメ”を言われ場合に、どう切り返すか?という形で意見を述べたいと思います。(但し、私のコンテキストの”アジャイル”とはScrumをベースにしたものになります。)

 

1.全体スケジュールにコミットできない

まず計画を僕らと策定するところから始めません?僕らはBOSSの計画作りからお手伝いすることが可能なんですよ。BOSSが思っている「やってみなきゃ分からない」というもやもや成分を最小限にすることが 「施策立案フェーズからチームを持っていること」で可能なんです。みんなは、BOSSが立案した施策から生み出される価値にコミットしたいと心から思っているし、価値があるからこそ、その価値を生み出すソリューションを期日までにデリバリーしたいんですよ。BOSSが一人で決めなくてもいいんですよ。スケジュールはチームで決めてチームでコミットしましょうよ。

 

2.アーキテクチャ上の無駄が生じる

アジャイルだからって、ソフトウェアアーキテクチャ上の無駄が生じると決めつけるのはちょっと乱暴かもしれませんよ。あくまで結果論として無駄だったかもしれないけれど、そもそも無駄のないアーキテクチャというのは理想論であって、未来の要求を事前に予想して、ソフトウェアアーキテクチャを決めていたら、スタート地点ではそのアーキテクチャは無駄って判断(やりすぎ)ってことになりませんか?BOSSはいつもスモールスタートって言っているじゃないですか、アーキテクチャもスモールスタートで問題ないんですよ。TOGAFのようなオープンなアーキテクチャ標準でも「Enterprise Continuum」と言って、企業の成長ステージに応じてアーキテクチャは進化していくようにとらえるのが大事みたいですよ。なので、あんまり目くじらたてる部分でないと思いますよ。Scrumやりはじめてから、ひどいアーキテクチャのシステムを僕たち作ってませんよね。価値判断でアーキテクチャを決定するようになったからなんですよ。

 

3.コーチって何だよ

 BOSS〜いつも「3人の石切り工の話」をするくせに、コーチいらないってどういうことですか!!「君の仕事の目的は何かね?」って聞く人がいないと、だれも気づかなくなっちゃうじゃないですか。チームの自己組織化が閾値を超えるまでは、チームの外から「君の仕事の目的は何かね?」って聞く役割は必要だと思うんですよ。だって、まだ社内にはスクラムマスターが育ってないし、まだまだ自己組織化できてないと思うんですよね。もちろんチームがコーチを不要だと思ったら、コンサル契約は終了させますのでチームが必要と感じている内は、このままで行かせてください!

 

4.変化ヲ抱擁スルために固定化している

BOSS分かりますよ、要員を固定化することがアジャイルの恩恵を最大限に享受できるっていうのは分かるが、実際には要員をずっと固定化することなんて不可能だって思っているんですよね。 まぁ一番いいのは同じメンバーで3年以上なんですけど、結婚や育休やらでやっぱり欠けちゃいますよ。でも、せめて要員数は同じにするのはお勧めですよ。だって、要員数固定してしまえば、コストは固定化されて、チームの生産性とチーム同士の生産性の違いがトラッキングできるようになるんですよ。適切なチーム同士の競争は組織の中では必要だし、チームを飽きさせないようにチャレンジを作るのがBOSSの仕事ですよね。これからも楽しい仕事をお願いしますね。

 

5.実証主義的な説明に過ぎない

BOSSのおっしゃる通り。他の優れたチームプラクティスを実践しても自分たちがよいチームになるとは限らない。でも僕らがやっているのは、チームでの「守破離」。チームの勝ちパターンを盤石にするために、いろんなプラクティスをまずはTRYして、血肉にしてるんです。最初から良い人材なんていないでしょ。BOSSも子供が生まれてそのこと実感してますよね。最初から優秀な要員、優秀なチームなんてのはなくて、成長によって優秀になるんですよ。だから成長に必要な学習はお父さんの心とお母さんの心の2つを持って見守ってくだいね。

 

6.手段が目的になっている

目的達成のため、BOSSの施策を確実に実現するための手段としてアジャイルで開発したいんです。失敗の確率が最も少ない科学的な手法だったら、そっちを採用しますよね。僕らは成功したいんです。昔と違って本や研修もたくさんあるし、実はBOSSへのご報告がまだだったのですが、前回のプロジェクトは実はアジャイルでやっていたんですよ。うまくいったでしょ。うちでももうアジャイルの実績があるんですよ。だからももうアジャイルは目的じゃなくて、成功パターンとして社内標準として認めて欲しいんです。

 

7.アジリティはアジャイルだけのものではない

アジャイルって思想(プリンシプル)なので、今は、開発だけという訳ではないですよ。最近意味不明なプロジェクト減っているじゃないですか!それなぜだか分かります?企業活動全体がアジャイルになっているから、フィードバックループの切れ目がなくなって、システム企画段階で、企画品質のValidationとVerificationを行うことになって、本当に価値を生むプロジェクトだけが開発稟議で可決されるようになったんですって。無駄なプロジェクトから解放されて、最近はみんな残業もなく生き生きとしてますよね。アジャイルがこれだけブームになっているのは、企業価値が向上した企業が実際に存在しているからなんですよ。

 

という感じです。スクラムマスターとしていつも心がけているのは、相手を立てて気持ちよくさせておいて、正しい方向に持って行くこと。ネガティブ意見に対して、恐れたり、怒ったり、対決姿勢を取ったりしないことですね。マスターヨーダも言っているとおり、「恐れはダークサイドにつながる。恐れは怒りに、怒りは憎しみに、憎しみは苦痛へつながる。」です。

 

いやーしかし、雲の上の存在となったBOSSは、やはりすごい。業界のことを考え、こういう役回り&立ち回りをさらっと嫌み無くやるセンスはあいかわらず抜群。だからこそ雲の上にいったわけですが..... やはり「ゆうすけ界」で超えられない壁の一人だw

 

 

 

 

 

 

 

 

 

 

Scrum Alliance Regional Gathering Tokyo 2013に参加して

2013年1月15日、16日に開催された「Scrum Alliance Regional Gathering Tokyo 2013」に実行委員という関わり方で参加してきました。この機会を与えてくれた高橋さん、川口さんを初め、その他の関係各位にはとても感謝しております。

 

私のコミュニティの関わり方は明確で、いわゆる「フリーライド型」です。現在の自分のコンテキストにおいて必要な情報/知見の調達先として、いろんな勉強会やカンファレンスなどのイベントに参加しています。

 

今回縁があって初めていわゆる裏方として特定コミュニティにコミットしたのですが、最後までコツというか、自分のプレゼンスを出すとこまではいけませんでした。皆さんがよく言われる「素振り重要」というのは、裏方としての素振りもそうだなぁというのが開催直前に気づいた最大の気づきでした。コミットしたからには、イベントへの参加を控え、他の実行委員の方としっかりやっていくという気持ちは十分あったものの(その考えも結局間違っていたわけですが)、スキル/経験ともに不足していたことは否めず、また、コミュニティの手練も多いことから、最終的には締め切りに近づくと、わーっと自己組織化&ドライブがかかり、私はその流れに乗る形でなんちゃって実行委員をしていたというのが客観的な見方だと思います。

 

コミュニティに深く参加する価値については、体験から理解することができました。つまり、ゴールデンサークルのWHYーWHATーHOWのトレーニングに最適だということです。もっとScrumを広めたいという想いにコミットしてバスに乗り込んだ実行委員がいて、POがハンドルを持ち、SMから適宜フォローが入り、全員で期日までにゴールに辿り着くという1つのプロジェクトを行えることは、とても価値があると思います。今回、それなりに高い有料イベントだったのもコンテキストとしてよかったと感じています。

 

実行委員の方からは、実行委員の運営はScrumではなくWaterFallだという意見が大多数なのですが、もう少しこなして行けば、お金回り以外はもっとScrumで回るだろうなというのが自分の意見で、お金に振り回されなくても、それ以外の準備は行えて、最後にどうリリースするかのときに制約条件としてお金回りが絡んでくるスキームに変えてもいいのかなぁと思っています。

 

個人的にも得る物があったので、次回の機会もあれば是非同じ立ち位置で参画したいと思っています。それまでには、

 

  • CSCになるための努力をする
  • Scrum Masterのためのツールを作る
  • Product Ownerのためのツールを作る
  • Scrumの場をもっと作る
こういうった個人努力をScrumのコミュニティにフィードバックできればよいかなぁと
 今は思っています。
 
最後にKPT
 
Keep
  • 今回の実行委員メンバーで同様のサイズのイベントを実施する
  • コンテンツに占めるワークショップ比率
Problem
  • 「ギャザリング」が弱かった。ギャザリング委員のような格上げをして、戦略戦術ともに洗練させていかないといけない。「場」にいる価値を高め、スライド資料や音声/映像はフリーにするぐらいでいきたい
  • ワークショップの参加方法(整理券配布)に少なからず問題があった
  • 実行委員のコミュニケーション設計/基盤。MLに替わる何かにしたい
  • イベントとして参加者との継続的関係性が気づけないこと(個人情報関連)
Try
  • OpenJam/アンカンファレンスの濃度を高める
  • アフターカンファレンスの実施(そこまで含めたタテツケ)
  • 前夜祭(そこまで含めたタテツケ)
  • (Scrumに関係なく)事業者側の課題を共有しネクストアクションを一緒に考えるコンテンツ。キーワード的には「フューチャーセンター」か
  • プラクティス/ワークショップの展示会。ポスター発表等
  • 誰かと会って話をしたい!を確実にコーディネートして、個人と個人の「場」を創り出すこと
  • 商談色の強いパーテションに区切られた部屋の提供
 
以上。
 
#sgt2014が開催される可能性は高いので、みなさんまた会場でお会いしましょう!
 

 

 

 

 

アジャイルがキャズムを超えるとは

新年あけましておめでとうございます。本年も宜しくお願いいたします。

仕事始めの最初としてアジャイルに関して、私の今の所感を述べたいと思います。

 

私がCSM(Scrum Masterの認定資格)を取得したのは2010年の3月ですから、今度の3月で3年立つ事になります。Scrumの洗礼を受けた時の事(マスターBasセンセイのリスバーガーの話)は今でも強烈に覚えています。私はエンジニアとしては比較的恵まれており、技術スキルが高いチームで新しい技術やアジャイルのプラクティスに挑戦することが許される環境に身を置いていました。これからの10年(当時29歳)をどうするかを考えたとき、別の環境で自分をさらに磨くことを選択し、ユーザー企業内の現場へと自分の環境を変えました。

 

最初のうちは今まで通りのやり方でうまく成果を出す事ができていました。しかし、自分のチームメイトを呼んでから事態は悪化していきます。チームメイトが今まで通りのパフォーマンスを発揮してもらうための地ならしがまったくうまくいかないのです。価値観の違うエンジニアとの不協和音にはじまり、企画部門とのコミュニケーション不全と、今までいたSIerのコンテキストやプロトコルが全く通用しません。その中で特に一番凹んだのは、企画の様々な要求に柔軟に応える事がむずかしくなってきたレガシーシステムをどうにかしたいというビジネスオーナーからの要望に腹落ち出来る答えを用意し説得できなかった事です。今までの蓄積した知見をすべて総動員してプレゼン資料を作り、役員にプレゼンしましたが、呼び寄せたチームメイトと一緒にチームを組んで成果を出すことが出来る最後のチャンスは訪れませんでした。技術があっても使う機会を与えてもらえなければ、なす術もありません。私は失意のどん底でした。「任せてもらえさえすれば、最高のチームメンバーで最高の成果を出せたはず、なぜそんな判断をするんだ….orz」 

 

そんな中、日本でScrum Masterの研修が2009年12月に開かれて、そのすばらしさに関するブログ記事が盛り上がっていました。当時の私は、「アジャイルでシステム再構築をさせてくれ」というプレゼンの敗北感と、XPに慣れ親しんでいたことから、たいして意識はしていませんでした。「自分はアジャイルの経験者。そんな研修は今更不要。むしろ今の現場の人たちこそが行くべきだ。」そんな思いでした。

 

ところが、事態は急変します。会社としてその研修にコミットすることが決定され、大量に現場のリーダーたちがその研修に参加するという話になっていました。空いた口が塞がらないとはこの事で、「あれだけやってもだめだったのに、なんなんだ?」という気持ちと共に「これだけの人数が参加してアジャイルの理解をしてくるのにアジャイルアジャイル言っていた自分が研修未受講はさすがにマズい」という気持ちになり、研修に参加する事にしました。

 

研修はカルチャーショックでした。今までの自分の中で確立されていた物がすべて崩れました。そしてプリンシプルを得ました。自分の中でアジャイルがきれいに腹落ちしました。そこから今に至る約3年間はサーバントリーダーシップの実践でした。専任のScrum MasterでフルスタックのScrumの運営経験もしました。うまくいかなかったScrumの経験もしました。どんな状況であっても、Scrumというフレームワークがある限りチームメンバーにアジャイルの原理原則を理解してもらい、自己組織化されたチームを作るのは難しくない。そう思えるところまでやっと到達しました。

 

でもね、Scrumはソフトウェア開発チーム/ソフトウェア開発組織に閉じた世界ではうまくいくんだけど、会社運営フレームワークとしてはScrumは使えない。なぜならScrumにおいてソフトウェア開発プロジェクトは所与の条件であり、その条件を作り、維持するためのところ、つまり「キャッシュフロー」の部分はサポート範囲外のフレームワークだから。よって、経営者に対して「アジャイルの必然性」の回答にScrumを担ぎだしてすべてうまく伝えて相手に腹落ちしてもらっても、まったく刺さらない。金の話ができないフレームワークに価値はないというわけ。

 

会社は、損益計算書、貸借対照表キャッシュフロー計算書を必ず作る。ここに並ぶ新しいモノサシ(基準)が必要で、そのフレームワークがScrumを内包する事で初めてアジャイルの必然性を経営に対して納得させられるものと信じている。Lean Startupやビジネスモデルキャンバス/リーンキャンバスなど新しいモノサシの候補が出てはいるが、まだ弱い。数理モデルでかつ、万人が腹落ちするモノサシが必要で、それまでは、新たなモノサシが作られては、キャズムの谷底に投げ捨てらる状況が続くのである。

 

つまり、アジャイルキャズムを超えるとは、ソフトウェア開発部門(機能組織)の外のフィードバックループも完結した状態になるということを意味しており、単一企業さらにはホールディングスレベルで統一的に利用出来るモノサシができるかどうか?そしてそれを使って企業経営ができるか?そういったレベルに到達して、はじめてアジャイルキャズムを超え、これからの時代を生き抜く能力を身につけた企業になる。よって、日本中のソフトウェア開発現場がアジャイルな現場になっても、キャズムを超えたと私は思っていない。

 

自分自身、あと30年以上はビジネスパーソンとして生き続けて行く必要があり、今までの延長線上に幸せな未来があるとは思えないので、これからの時代を生き抜くマネジメントフレームワークをなんとか構築していかなければならない。自分達が先人のバトンを継ぎ経営を革新する時が来ているのである。

 

ありがたいことに、これから応援させて頂く現場は、まさにこの課題に真っ正面からがっつり取り組むことになり、どういう結果になるかは別としてそういう機会を頂けた事はScrumさまさまだったりします。1月15〜16日には秋葉原でScrumに関するイベントが開催されます。Scrumの実践者が集まり、最新の知見と事例を聞く事ができます(私も2日間参加します)。2013年は日本におけるプロダクトオーナー元年ではないかと個人的には思っております。自己組織化されたチームを作るのは当たり前の話として、プロダクトオーナーがチームと対話するためのプラクティスと、プロダクトオーナーが自身をドライブするためのプラクティス、ツール、フレームワークについての話題が活発になっていくものと思います。

 

"Quality of programming life"の実現を目指して今の自分がいます。おじいちゃんになってもプログラミングしていられるように、急がば回れで今年もがんばって行きます。(ちなみに今年は年男です)

 

 

 

理不尽なことが最も少ないことがフリーランスのよさですかね

http://togetter.com/li/236971を読んで最初に脳裏をかすめたのは、

「1対1もオフェンスの選択肢の 一つにすぎねぇ それが わからねぇうちは おめーには負ける気がしねえ」

という仙道の言葉。それは置いておいて、、、

シューカツしたことないし、勤め人やったことないので個人の経験談でしかないけど、世の中、何かしらの思惑によってルールが出来上がっているわけで、そのルールに乗らないように乗らないように注意して現在に至っているのが自分の状況。ルールメーカー側に立ったほうが何かとお得だしね。まぁすっごいルールを作るところまでは至ってないけど。

自分が本物だったら、フリーランスだろうが勤め人だろうが、特に違いはないと思う。自社に組織能力がなければ、外から調達するのがまっとうな経営者だからね。

世の中の仕組みや動向を知ってそのルールやうねりをうまく使うと、そんなにお金に困ることはないし、その仕事が本当に自分がやるべき仕事なのかどうかを判断することができる。

プロジェクトの立ち上げ以前のフェーズ(経営企画系)に参画するほどの立ち位置にいるわけでもないし/人脈を持っているわけではないので、原則プロジェクト化されたところに参画することが多いわけですが、なんでそんなプロジェクトを立ち上げたの?っていうのは多々あり、得てしてそういうプロジェクトは政治色の強く、ステークホルダマネジメントに四苦八苦するものです。人間が出来ていない自分としては、プロジェクトメンバと一緒に仕事をしたいか?が最初の問いになったりします。昔よりはうまく立ち回っているつもりだけど。

仕事が成功するのも失敗するのも人次第だと思っているので、理不尽極まりない成分が多いと撤収すること考えます。ただ最近は、理不尽極まりない成分をなんとかするスキルがついてきたので、撤収しないでよしなにやることが多くなってきています。

仕事が一番面白いのは、仕事を作ることで、すでに出来上がった仕事をImplするのはJenkinsにやらせたほうがよいですw

 

設計に上流も下流もない

http://d.hatena.ne.jp/ryoasai/20120103/1325591098を読んでの個人的感想。

設計のOUTPUTが顧客にデリバリする価値と一致しないのであれば、その流れは何か別の思惑によって形成された流れなんだだろうと思う。そして流れがあるところには必ず摩擦があり、そこでのエネルギー消費量によって顧客へ届く価値の大小が決まるのだと思う。だから、

  1. 自分が流れの最上流にいて、そのまま価値をデリバリする
  2. 流れを意識させないで、後工程の方に価値をデリバリする(この価値は顧客の価値とは違う半製品の価値)
  3. 流れを標準化しておいて、標準の枠内で価値を後工程の方にデリバリする

こういうのがよいんじゃないかと思う(1のほうが摩擦が少ない)

2と3は似ているようで、大分違うと自分は認識していて、”自己組織化”が進んでないと2は実践できない。

1は本当にそうなれば素晴らしいんだけど、なったらなったで別の課題が浮上することが想像に浮かぶ。

流れを作るって、一言で片づけると”フィードバックの設計”だと最近は思っていて、設計っていうフェーズ内でフィードバックのポイントを設置するのは悪くないんだけど、もっと上位の全体に対する設計がおざなりにされていることが多い。さらに言うと、その部分の本質を整理すると、そもそもその流れって必要なの?もっと他に作るべき流れがあるんじゃないの?っていう話になったりすることがあって、私たちは何をやっているんだろう?ってことになる。

自分がその流れの真ん中にいるなら、どんなに天候が悪くなろうがそこに腰を据えて踏ん張るだけの”何か”があるか?だよね。それがなくなったらもうその流れはいらない。止まるまでに時間がかかるのが流れの特徴だけど.....

 

 

2011年総括

久々のエンタープライズソフトウェア開発

2010年の終わりから約5年ぶりのエンタープライズなソフトウェア開発の現場に参画しました。しかも、どー考えてもフルスタックすぎるアホみたいに豪華なプロジェクト体制。最初から失敗臭がプンプンしてました。テクノロジースタックも5年前とほとんど変わらない構成で、これがレイトマジョリティなエンタープライズな現場の最前線なのか!って愕然としたのを覚えています。いろいろのらりくらりとやりつつ、引き際を探っていたのですが、ひょんなことから、ゼロベースでチームの立ち上げ支援をする機会を得、そのまま今に至って2012年を迎えてしまいました。あー朱に交わると怖いですね。

小規模チームの立ち上げは何度もやっているので、まぁ今回も及第点はもらえるかと思っています。今回のポイントはScrumのフレームワークをフルセットでやってみたことです。自分の立ち位置はScrum Masterだったのですが、チームを生かすも殺すもProduct Owner次第ってことがよく実感できました。Product Ownerの能力以上にチームのスループットが上がることがなく、Product Ownerのパフォーマンスが重要だなぁと感じました。次は自分がProduct Ownerとして振る舞い、知見を蓄積したいなぁと...(どこかに事業部門のポストありませんかねぇw)

飯の種的な話をすると、”ビジネスアナリシスのスキル構築支援”、”プロダクトオーナーのスキル構築支援”、この辺りはこれから(自分的)マーケットが作られる感じで、”アジャイル開発支援”、”継続的○○”はコモディティ化が激しくなってきそうなので、パッケージにして....な感じですかね。

テクノロジー的には、ソリューションの実装が大分簡単になった感じがします。自分で抽象構文木もどきを作ってごにょごにょできちゃうぐらいですからね。便利な世の中です。ただ手のひらを返すと、ソリューションの実装は誰にでも出来るから、そこに存在価値を出していくのは無理ゲーです。子供4人養えませんw

日本のSIの縮図のようなところで1年過ごしたわけですが、オナニストが多くてつい最近までの自分を見ているようで微笑ましかったです。ソフトウェア開発は目的ではないし、人は使い捨ての機械ではありませんw

法人にして3年目を迎えました

 個人事業主時代よりは確実に売上・利益ともに上がっているのですが、法人としては体をなしていない状態でテコ入れしないとまずい状況です。やはり一人では限度があり、番頭さんよろしく一緒にやってくれる人を見つけないと何も世に残せないなぁと痛感しています。このまま内部留保しっぱなしってもよくないと思いつつ、手ごろなサイズのビジネスモデルは何かないか?と模索している状況です。チーム支援では”紙飛行機”、”紙飛行機”言っているのに、自分は紙飛行機を一度も折っていないダメダメな子です。

家族計画はこれで打ち止め?

4人目にして待望の長男が生まれ、次女も長女と同じ小学校にお受験で合格して、プライベートは充実した1年でした。本当はもう一人、男の子が欲しいのですが、まぁそろそろ次のステージに入るころなのかもしれません。まぁ何も考えずに子供作って、なるがままでここまで来た感じです。つい先日、結婚10周年を迎えてしまいました。入籍したときは卒論前の大学生だったのが懐かしいです。お互いだいぶ肉体が劣化してきましたが、これからもよろしくです。

最後に

はたから見たら幸せなのかもしれませんが、自分はまったく満たされていないし、死ぬまで満たされないんだと思う。上には上がいるし、横見てもすごい人ばかりだし、、、、 とくに”若くない”っていうのが最近じわじわ来ています。年齢相応っていうのが痛々しく、自分への投資が大分減っているのか?それとも投資対効果が下がって来ていて年連相応になってきているのか?情報社会において自分への投資は他者との優位性を生まなくなっているのか?よくわからないけれど、普通の”ただのおっさん”になってきている感が強くあります。(まぁそもそも、生まれながらにして普通の人だった説が濃厚ですがw)

まぁ、このブログもすぐに飽きてしまうような気もするのですが、何かを変えたい気持ちと新年というイベントが相まってこのような形で昨年のふりかえりをしてみた次第です。