月次で行なっていたある業務を日次化するかどうかの検討をしていました。この場合、

• 日次データが出る場合のメリット


• データを日次で蓄積する場合と月次で蓄積する場合の労力比較

• 日次化することで既存システムが被る影響


• 日次化するために発生する開発負担

こうした枝葉末節までよく吟味することは、決定された後の支障を予め取り除くことにつながるので、決定後のスピードに影響するし、決定後プロジェクトが頓挫するリスクが減るため、物事をうまく処理するためには必要なことです。

しかしながら、これらのことは吟味しておくに止め、判断材料とすることとは区分しておいた方が良いのかもしれません。

• 判断材料を目的と直接関係ないところまで含めると判断が鈍る


• 結局現状維持が一番という結論に陥りやすい

つまり、右を行くか左を行くかという判断はバイアスがかかりにくいわけですが、行くか行かないかという判断は行く場合のリスクばかりに焦点が行って、結局行かないことが多いわけで、これではなかなか変化・変革は成し遂げられません。

変化するばかりが能ではありませんが、先の例の場合、日次化した方が明らかに会社としてのメリットが高く、個人にもそのメリットが還元され、そこにかかる労力負担が問題になるほどでもなければ日次化するべきですが、付随する影響に目が行きがちで、時期尚早という結論に陥りやすいわけです。

さて、開発負担は考慮から外し、日次化することが決定されました。

それから二日の間に、フリーソフトで使えそうなものが見つかり、ほとんど開発しないですみそうな状況になったのです。システム間の連携やアクセス権の問題が多少残っていますが、その部分は先日相談した米長氏が力になってくれるだろうし、それらは後回しにしてとりあえず運用を開始するということもできる段階になりました。

日次化を選択した結果、本気で開発負担を低減させるためにサーチに力を入れ、結果良質なソフトを手に入れることができました。当初非常に頭を悩ませていた問題のほとんどは杞憂に終わったと言えるかもしれません。

そのためには非常にエネルギーをとられるし、徒労に終わるどころか、手を差し伸べたつもりが更に嫌われたり、憎まれたり、妬まれたりする可能性の方が高いかも知れません。

真意がなかなか伝わらない神経の鈍い人、被害者意識（誤った確信、思い込み）が強すぎてこちらの言っていることをなかなか理解できない人、こうした人達も理解させるには多大なエネルギーが必要です。

この問題に対して、自己啓発本を読み、二つの対応策が提示されました。

一つは効率を重視し、時間、エネルギーをとられる人は切る、というもの。これはこれで『営業』『成績』という観点では重要な考え方で、トップセールスマンになりたければ効率性を重視することも大事でしょう。

もう一つは、万人を信頼し、全ての者に救いの手を差し伸べる、というもの。これは言うはやすしで実際には非常に大変ですが、最終的に人を差別しないというか、区別しない生き方が認められて長い目で見れば結果的に大成功を収めるのかもしれません。

しかし後者の生き方をするには、次の点を注意する必要があると思います。

『時間、エネルギーをとられる人に時間もエネルギーも多大に費やすべきではない。あくまでも、平等に接するにとどめ、効率のいい人と同じ程度の時間とエネルギーを消費する。結果的に、時間、エネルギーをとられる人に理解させるのは随分先かもしれないが、切らない限りいつかは理解してもらえるだろう。』

例えば、多くの書籍では目標設定が大事だと教えますが、鵜呑みにすると常に目標を設定しなければと自分を追い立ててしまうでしょう。

本当に目標設定が大事かどうかをよく吟味すれば、夢の実現には目標設定が近道ではあっても、そのために日々自分を追い込むことが果たして自分の求めている行き方なのかどうかを検討することができます。そして、強く実現を望む夢に対しては目標を明確にしながらも、日々の人生を楽しむだけのゆとりを持つことができるでしょう。

また、お金は無駄に遣わず賢く遣えといった教え方もよく見かけますが、それぞれは『ふむふむ』と理解できても、一見対立するようなものを並列させて理解できるかどうかも、批判的態度で読んでいれば（聞いていれば）、そのバランスを自分なりに考えることができるでしょう。

しかし、最近自己啓発本をいろいろ読んで感じたことは、『人脈』と『戦友』とは異質なものではないということです。『戦友』ということになると、普通2、3人、せいぜい10人いれば多い方であり、どちらかというと『パートナー』に近く、一方で『人脈』はほとんど無限大に多くすることができる点で、『人脈』と『戦友』とは異なるわけですが、本物の『人脈』とは損得勘定が一切入り込まないものであり、その点では両者は本質的に同じということになります。

ではなぜ、これまで『人脈』の本質に気がつかなかったのでしょうか。それは、心が狭く、視野が狭かったからに他なりません。

私と同じくらい真剣に人生を行き、同じくらい苦労を味わい、同じくらい技能を磨いている者だけを、私は認めてきました。そうして得た者が『戦友』となり、私は『戦友』さえいればよいと思っていました。

しかし、『戦友』しか認めない生き方では、自分が与えられる幸せの数は非常に少なくなります。もし仮に、考え方を変えることで、もっともっとたくさんの幸せを与えることができるとしたら、その方が自分も幸せになれると思います。

そうして考えると、『人脈』とは、自分が心から応援してあげたいと思え、自分の得意なことで喜ばせてあげられる人、且つ、自分を応援してくれ、それぞれの持ち味を活かして自分の役に立つことを喜びとして感じてくれる人を指すのだと思います。

まあ、そんな定義などどうでもよく、要するに、

• いろんな人の役に立っていると実感できることがうれしい


• いろんな人に助けてもらっていると実感できることがうれしい

つい先だって、稟議、電子決裁、押捺申請、報告書決裁のシステムを構築したところで、この勢い及びそこで新たに獲得したノウハウで一気に乗り切るかとも考えていましが、稟議システム等のベータバージョン完成後のバグ取り、ユーザーの要望への対応等を行なっているうちに、やや食傷気味になり、当面システム構築はやりたくないな～という気分に陥っていたのです。

ということで、日次集計システムを作るかどうか決めかねている、というのが現状ですが、潜在意識の中では作ることになるだろうと感じていたので、思い切って行動に出ることにした。

二日ほど前にラフなシステム構成のスケッチを描いていたのですが、果たしてそれが適切なのかどうか判断に苦しんでおり、一人で悩んでいても解決できないし、時間が無駄だし、かといって先に行動を起こして、後で深みにはまったり、頓挫したり、中止となっても面白くないし、やはり設計段階で（どこまで造り込むかどうかも含めて）十分検討した方がいいと思ったので、他に助力を得ることにしました。

1年前、タイムカードを導入しました。もともとは非常に簡便なフリーソフトのタイムカードシステムをVectorから取ってきて、これにExcelVBAで機能を付加して出勤簿を作成していたのですが、タイムカードとしてはいくつかの致命的な問題を抱えており、それまでのラフな運用では耐えられましたが、きちんとタイムカードを運用するには向いていなかったのです。

そこで、去年の今頃も、自分たちが求めるタイムカードシステムを自ら開発するかどうか悩み、結局Vectorでいくつかのシェアウェアソフトを試し、今のTCardというタイムカードを導入することにしました。

当事、TCard自体が出来立てでもあったようで、いくつかのバグが見つかり、開発者の米長氏と10往復ぐらいメールのやり取りをしながらバグの修正を行なってもらいました。あれから1年、今回の日次でのプロジェクト別割当時間集計システムの開発にあたり、米長氏の意見を聞いてみたくなりました。

場合によっては、将来タイムカードとの連動も視野に入れることも可能になるかも知れず、彼を味方につけることはメリットが大きいだろうし、そもそも、この1年で成長した自分の力量を誰かに評価してもらいたいという気持ちもありました。

電話を手にしたとき、（まだ、やるかどうかも決まっていない段階だしかえって迷惑になるだけかもしれない）と僅かにためらったものの、（電話をかけたからって必ず仕事につながらなくても、正直に現状を説明すれば向こうも理解してくれるだろう）と思い直して番号を押しました。

どうやって名乗ればいいかなと思いながら名を名乗ると（実はこれまでメールだけのやり取りで電話はしたことがなかった）、予想に反してこちらのことを覚えていてくれたのです。それだけではなく、実は近々私の方に相談したいと思っていたところだといってくれました。

相談というのは、TCardを新しいシステムに乗せたバージョンを開発中であり、できたときにその運用テストを当社で引き受けてもらえないかどうかの相談で、もちろんお代は頂かなくても良い、というものです。しかし、今は非常に忙しく（昨年も忙しい様子だった）、すぐに完成するというわけには行かないのだがという但し書きが付いていました。

おそらく、米長氏も、新しいシステムに乗せたTCardを完成させたいが、ニーズにかなうのかどうか、うまく行くのかどうか多少の不安を抱え、業務も忙しいので後回しにし続けているのではなかったでしょうか。そして、なにか後押ししてくれるきっかけを待っていたのだと思います。そして、私の電話がトリガーになり、開発意欲に火が付きかけたのです。

そういうわけで、話がとんとん拍子に進み、来週たまたま仕事で東京に来る予定があるので、会社に立ち寄ってもらえることになりました。こちらの依頼に関しては、米長氏が多忙であること、当方も開発ノウハウは有していること、予算の問題もあることなどから、とりあえずは、最初の設計段階で間違えないよう、また、随時問題にぶつかってもすぐに解決策を見つけられるようコンサルテーションをお願いするということでラフに合意が形成されました（実は今、もう少し別のことも検討しています）。

ということで、片思いが両思いになったような、不思議な感覚になって、とてもうれしく、今日はとてもいい一日でした。

ただし、演出＝演技ではなく、演出≧演技であるわけで、普段の生活における伏線（自己表現）、感情表現すべきときに一緒に共鳴すべき人物に対する根回し、感情を表に出す舞台製作、感情にふさわしい言葉（セリフ）等々、よく準備して行なわなければただの茶番劇になってしまうか、演技しすぎてしらけさせてしまいます。

重要なことは演出も本物で無ければならないということです。偽物の演出はただの学芸会にすぎず、リアルそのものでなければなりません。

そのためには真剣に伏線し（普段の生活を送り）、仲間（＝同志、戦友）のことを常に思い（第一に考え）、ここぞといった節目節目に向かって全力を出し、達成したときに素直に感情（感謝の気持ち）を言葉で表現する、そうすれば、自然に体全体で表現したくなるだろうし（喜びのダンスも含めて）、男泣きもするだろうし、仲間とハグもしたくなるでしょう。

ということで、今後は仲間を思うことをより強め、来るべき時の感動を毎日イメージしながら、節目に向かって全力で走ろうと思います。

色：
万物、様々な現象、様々な人格、様々な状態、要すれば世の中の存在全て（現在に限定せず、過去の存在も未来の存在も含む）

空：
固定的な実体・絶対的な実態は無く、全ては移り変わるもの、相対的なもの、他との関係の下で成り立つものという存在に関する真理、もしくはそうした状態

色不異空　空不異色：
色と空は異質なものではない。世の中のあらゆること（色）は、一見すると実態があるようであり、定義付けることができそうであるが、全ては相対的なものであり、常に（その形、性質、意味、意義、作用、価値等が）変化する空という真理で捉えることができ、本質的に異質なものではない。

色即是空　空即是色：
色はすなわち空である。だからといって無力を感じるのは早計である。空はすなわち色なのだから。

観音菩薩が言っている（と思われる）こと：
物事にとらわれずありのままを受け入れなさい。全ては空なのだから何かにとらわれても仕方の無いことです。しかし、何ことにも虚無を感じてはいけません。全ては空なのだから様々に変化していくのです。また、今このときの様々な違いはたまたま今違いが見えるだけで絶対ではありません。未来は様々に変わっていきます。また、過去さえも変わりえます。過去というのは人間の記憶の強弱・解釈です。過去をどう捉えるかで過去も変わりえるのです。繰り返しになりますが、何事にもとらわれてはなりません。ありのままを受け入れ、そして物事に向かい合い、未来に向かい合い、過去に向かい合うのです。

タグ（キーワード）:

• 仏教

（続き）

とにかく夢はかなったわけです。それも数日で。本田さんにメールを出したときは、まさかこんなに早く会いに行くことになるとは思っていなかったし、どういう形で会おうかもイメージが明確になっていなかったのですが、彼には会いたいと強く思うので、なんとなく直感的に近々会えると信じることができました。

後で思い直した夫婦でという表現は付け足した願望に近く、今思えば、そこに込めた思いが少し弱かったと思います。思いが強ければ、そしてその思いに自分自身が疑いを持たなければ、必ず実現するというのは普段から実感することですが、こうもうまく行くと人生の妙味にあらためて感嘆することしきりです。

また、データ収集は好きで、情報収集は得意と書いたのですが、この違いはなんでしょうか？

情報というのはそれだけで価値があるものであり、データはそこから情報を見つけ出すものというのが違いとしてあると思います。情報収集が好きというのはいかにも情報を活用していなさそうで嫌なので好きの項目に挙げなかったわけですが、やはり、情報収集というのは好き嫌いの話ではなく得意不得意の話なのでしょう。

システム構築は得意なことであり、また好きなことです。

これは完全に一致しています。このことは自分はシステム構築を専門に行なう仕事が向いているのではという暗示にもつながると思いますが、それは早計かもしれません。

確かにシステム構築は好きですが、システム構築のプロセスを良く考えてみると、それを商売として専門に行なう場合、バグ取り、とんでもない使い方をするユーザーの対応、ヘルプファイルの作成、エラーハンドル等に多くの時間が割かれ、あまり効率的とはいえない仕事になるだろうし、あれやこれやと無理な注文に応じるあまり整合性が取れなくなったりして、嫌いなことを仕事にしていることにつながってしまう可能性が大です。

【得意なこと】
・データ分析、情報収集、検索
・システム構築
・人を説得すること、法律を引用すること
・はったりをかますこと
・年配の人を魅了する、感服させること
・体力勝負、気力勝負
・スノーボード、野球
・シミュレーション、いろんなことを想定し、予め準備しておくこと

【好きなこと】
・データ収集
・システム構築
・効率化
・ゲーム、歌を歌う
・キャンプ、ハイキング、スノーボード
・本を読む、勉強をする
・哲学する、空想する
・筋が通っていること

【苦手なこと】
・童心に返る
・人の名前を覚えること
・整理整頓、ファイリング
・英会話

【嫌いなこと】
・整合性が取れていないこと
・非効率なこと
・エレガントさに欠ける業務
・テレビを無駄に見る
・言っていることとやっていることとが食い違っている人と一緒にいること

Excelの特徴を列挙すると、

• 印刷が比較的得意


• 計算式を入力できる


• インタプリタ形式でのプログラム処理できる


• データをテーブル形式で持つことができる


• 集計機能・表作成機能・フィルタ機能・収束演算機能・回帰分析機能等便利な機能が装備されている


• マクロ記録機能がある


• 普及している


• ADOによりAccessで作成したデータベースにアクセスできる

こうした特長を持っているため、『プロトタイプが早くできる』というのが一番大きな利点であると思います。

• 最初から使いやすい機能が充実しているため一から開発する必要が無い
• 印刷シートの作成⇒入力シートの作成⇒データシートの作成⇒自動化のためのプログラム開発という風に段階的に開発でき、かつ印刷シートさえできればとりあえず使うことができる
• マクロ記録機能があるので全てのメソッド・プロパティ・関数等を覚えていなくてもサクサク開発できる
• プログラムを書く場合でもインタプリタなのでいちいちコンパイルしないでよい

しかしながら、プログラムとデータと入出力が一つになりがちなため、同時使用、複数配布、グループ開発等が難しい。これは克服できないのかというと、とりあえず取り急ぎ必要なものを上記の要領で作ったうえで、

①データ部分を切り離し、mdbファイル・csvファイル等で保管してADOやOpenステートメントでアクセスする
②プログラム部分を切り離し、アドインにする

という方法により、ユーザーインターフェイス（入出力）がデータから切り離され、同時使用が可能になり、またプログラムからも切り離されることでインターフェイスを複数に配布してもプログラム変更が１箇所で済むため運用管理が楽になり、更にコードの記述に関する規則をきちんと作りさえすればアドインするファイルを複数に分けてグループで開発することもやりやすくなります。

①の手法については３年前から取り組んでおり、随分と洗練されてきた（バリエーションが充実してきた）と思えます。②については、何を隠そう昨日紹介した井上治氏からのアドバイスをきっかけに実現できたばかりであり、まだまだ改善の余地は残っています。しかし両者の手法を自分のものとしたことで、今後の開発に大いに役立つと思います。

VBAの達人は多くいると思うが、これまで個人的に尊敬している人として、大村あつし氏（この人を知らない人はVBAのもぐり）、S氏（以前勤めていた会社の先輩、VBA専門ではないがとにかくすごすぎる）、そして井上治氏が挙げられる。

なぜ井上治氏が３番目なのかはあまり良く分からない（考えていない）が、かなり理解しやすいVBAの解説と良質なアプリケーションを配布している点、そして自分のサイトには掲示板を置かないというこだわりを持っている点などがポイントとして高く、その辺からなんとなく縁を感じていたのだろう。

これまで、井上氏のサイトはそのボリュームに圧倒されて全てを読破しようという気がなかなか沸かず、効率よく興味のある部分だけつまみ食いしよう、という接し方であったが、こうして掲示板とメールを通して意思の疎通ができたことが原動力となって、一応それなりに隅から隅まで読破することができた。

隅々まで読破することで、新しい50の発見をすることができ、また、自分も一角のVBAプログラマーである（に近づいている）ことを再確認できたし、とにかく非常に良かった。

また、井上氏がどうやら自分と同じような業務を担っているらしいこともわかり、更に（勝手な）親近感が増した。

胆力を練ることと想定範囲を広げることとは似ているようで同じではないように思う。もちろん想定範囲を広げる努力は重要だけど、想定外の、身の危険を感じるほどの本当にどうしようもない窮地に陥ったとき、そこを切り抜けられるかどうかは、それと同等かそれ以上の窮地に自分の身を置き、そこから脱した経験があるかないかにかかっているのではないだろうか。

つまりハングリーに生きているかどうか、確たる原理原則を持っているかどうかだ。想定範囲を広げることはあたかも暗記事項を増やすことに等しい。暗記した箇所がテストで出れば高得点が取れるが、覚えていない事項が出ればたちまち成績は見るも無残な結果になる。

原理原則を重視した学習をしていれば、最高点は取れないかもしれないけど、どんなときも一定レベルの得点はでき、難問中の難問に出くわしても解決できる可能性が高い。

胆力を練るためにはどうしたらいいか。それは、ずばり失敗を恐れず、何事もチャレンジすることであり、特に苦手と感じる分野に対して意欲的に挑戦することではないだろうか。

（追記）
そういえば、昔、数千人規模の銀行から、当事数人だった今のベンチャーに転職する際、親父から内定をもらう前に辞表を提出するよう助言された。僅か5日ほどの期間だったが、職を失うかもしれないという緊張感が脳裏を走ったことを思い出した。

当時は『なるほど、それが筋だ』ということで、親父の助言に従ったわけだけど、今思えば、このことが僅かにでも己の胆力を練ることにつながっているように思い、親父に対する感謝の気持ちが沸いた。

というのもアプリケーションを１本構築したためである。昨日の帰り際にラフな構想が持ち上がり、『今日はアプリケーション構築以外何もせん！』と心に決めて、やる気のなさを暗にアピールするために１０時過ぎに出社。以後６時間ほどかけてアプリケーションが１本完成した。

ユーザーの利便性や習慣、セキュリティ、整合性等に細心の注意を払いながら、持てる知識を総動員し、頭脳をフル回転させて行なうこの作業は、疲労すればするほど、できたときの達成感たるや語り尽くせないほどのものがある。そのおかげで昨日の虚無感はどこへやら、完成以後はその他の業務もやる気が沸いて、毎度のように一人居残っての仕事に没頭できた。

企業内ユースのアプリケーション構築というのは、非常にスリリングだ。もちろん不特定多数のユーザー向け、対価を取っての販売アプリケーションはユーザーのクレームという緊張感と常に隣り合わせであるため、こちらの方がスリルが高いといえなくもないが、思うに販売アプリケーションというのは非常に細かいバグとりやヘルプファイルの作成に膨大な時間と労力を割かされるため、空しさと紙一重ではないだろうか。

その点、企業内ユースの場合、使用方法についてはマニュアルという形である程度こちらで指定でき、親切丁寧なヘルプファイルを作る暇があれば直に説明しに行く、説明会を開催するという方法で乗り切れるし、ユーザーのITスキルが非常に高い当社の場合、レベルの極端に低いユーザーを想定しないで開発できるので非常にストレスが少ない。

もちろん、そうはいっても個人ユース、部門ユース（自分と部下のみ）に比べると、企業ユースの場合には、ネットワークの構成、アプリケーションのバージョン、Excelの得意不得意等を考慮して開発するため、それなりにではあるが手間隙がかかる。

それでは何が非常にスリリングなのかというと、時間との戦いであるからだ。企業ユースのアプリケーション構築に与えられる予算は少ない。現金での予算などそもそも無い。あるのは時間だが、その時間も非常に限られる。

時間がかかるようだと、「何もそこまでする必要は無い」「紙（アナログ）でやればいい」「もっと他にやることがあるのではないか」「そんなに時間をかけて得られる効果はどれだけのものか疑問だ」「アプリケーションは買えば（外注すれば）いい」などといった声が聞こえてくることになる。

つまり、企業ユースの場合、時間をかけると全く報われないわけだ。ということで、片手間で、業務の合間に作らざるを得ないわけだけど、そうした片手間で作る習慣が身に付くと、『いつの間にそんなものを作ったのだ』という驚きで迎えられ、『コストもほとんどかかっていないし、便利なのは確かだから使ってみよう』ということになり、受け入れられる。

この、低予算（短時間）で作る（らねばならない）という点が、非常にスリル感を高めていると思う。