今年を振り返ると、過去にないほど年初の想定外だらけの一年でした。今年の10大ニュース、とか書きたい気持ちもあるのですが、もう何というか「厄年恐るべし」の一言に集約されそうな感じです。 こういうことは書く方がいいのかどうか迷うのですが、将来につなげるためには書いておいたほうが良いように感じるので少しだけ書いておきます。 敗北宣言します。偉そうに何だかんだと言ってきました。言行不一致にならないように自分なりに色々と取り組んできました。ですが、ひとえに自分自身の力不足・器不足で、残念ながら今年の6月でSI屋さんとして会社を継続していくことが出来なくなりました。第一回戦は負けましたが、いずれ再戦を期したいと考えてはおります。 会社にまつわる全ての責任は私にあります。一切は私の至らなさによるものです。その責任から逃げるつもりはないですし、また逃げようとして逃げ切れるものでもありません。これを踏まえて

人生というのは何かを得るのと引き替えに何かを諦めることの繰り返しなのかもしれない。そんなことを感じたりしています。 例えば私はプログラミングの経験があります。これは「プログラミングを知らない人の感覚が理解出来ない」ということでもあります。つまり「何も知らないユーザの気持ちがわからない」ということなのかも知れません。 進学、就職、転職、結婚、出産、育児、その他あれやこれや。人生の至る場面で分岐点があり、進める道はいつもひとつだけです。そしてその道を選ぶが故のメリットやデメリットがありますし、コインの裏表のように選ばなかった道にあったであろう可能性と危険性というのも存在するのでしょう。 例えば大きな病いに遭う人もいれば健康に格別気を遣うこともなく人生を送る人もいるでしょう。健康の有り難みというものへの実感にはやはりそれぞれに違いがあるかと思います。あるいはまた例えば子供がいる人には子供がいない

賢者は歴史に学び愚者は経験に学ぶと言われたりします。賢者でありたいと願いながらも愚者に過ぎない身としては、せめて経験からの学びくらいは適切でありたいと思ったりしています。 この試練から何を学ぶかとか失敗って何だろうなんてことを過去に書いたりしています。最近もまた色々とあって凹んだりということがあるのですが、苦しい中それでも止まることなく無理矢理にでも進んでいると、あぁそういうことか！　という学びを得られることが多いことに気付きます。 何というか、そうやって試練を乗り越え続けていると、もちろん大変ではあるのですが、それでも得たものの貴重さを後に実感したときに、あぁやって良かったなぁと思ったりするのです。その経験がまた新たなチャレンジへと向かわせるのですから、ある種成功は次なる失敗というか試練の種なのかもしれません。 やらなければ未練、やれば試練。試練がないことというのは、やれば出来て当たり前

人間誰しも時には誰かに甘えたくなるものではないかと思います。一方で、誰かに甘えたいのであれば、逆に誰かに対して甘えさせてあげる気持ちも必要なのではないかと考えるのです。 他人に甘えられたくなければ、まず自分が他人に決して甘えないという覚悟が必要です。一方的に自分だけが甘えても許されるのは、本当に幼い頃に親に対してだけでしょう。生物として未熟なうちにだけ許されることです。成長に従ってまずは小さな範囲から、そして徐々に大きな責任を背負うに従って、一方的に他人に甘えられるものではなくなっていきます。 ですが一方で、どこまでいっても人間というのはお互いに持ちつ持たれつだと思うのです。他人が全くいないところでは生きていくのは非常に難しいでしょう。責任を背負うというのは、他人の甘えを受け容れるということなのかもしれません。自分では自覚していなくても結果として他人に甘えてしまっていることも多々あるでしょ

人それぞれの感じ方もあるのでしょうし辞書的な定義もあるのでしょうけど、私としては謙虚と卑屈は違うし、一方で傲慢は卑屈の形を変えたものであるとも感じます。 例えば、ものの言い回し・表現を簡潔明瞭にするのは受け手に対する配慮の発露であって、必ずしも簡潔明瞭な言い回しが適切でないと感じるなら、冗長な言い回しを使うのも当然必要です。そのような配慮もなく闇雲に「簡潔明瞭に！」とこだわるなら、それは結局のところ「相手に伝わらない」という自分の過ちを受け容れずに自分の一方的な思いを押しつけるということであって、それが正に傲慢であると周囲に感じられることにつながるのでしょう。 そもそも「謙虚でありたい」「傲慢に生きよう」と思うのは個々人の勝手ですが、実際のところはその人が謙虚か傲慢か卑屈かなどというのは、周囲の評価で決まります。いくら本人が「俺は傲慢だ」と思っていても周囲がそうは思ってないことも多く、そし

先週、問題構造分析という手法についてセミナーを行いました。これは今感じている問題を解きほぐして原因を明確にすることで、同じ問題を繰り返さない未来を考えるというものです。一方で、そもそも自分はどんな未来を欲しているのか。今これをやりたいという気持ちはそもそも本当なのか。そういうことを明確にする方法があります。 これらの希望・願望というのは、実は分析をしていくと数少ない幾つかの本質的な自分の「こうなりたい・こうありたい」というものに辿り着きます。逆に言うと、その数少ない幾つかの未来を達成したいと思う自分が、今持っているボキャブラリの中で当座の目標・願望として数多くの欲求を表現しているのです。そのことをきちんと理解していないと目標達成は難しいですし、もっと苦しいのは目標が達成できても自分自身の心が満たされない、つまり「こんなはずじゃなかったのに」と感じてしまう結果に陥ってしまいます。 では「そも

…というほどのものでもないのですが、新年に向けて幾つかのインターネット上のサービスを退会しました。例えばTwitterやWassrなどです。登録したっきりで存在すら忘れているものもあったりするのですが、それらは引き続き放置ということにしたいと思っています。 何度かここにも書きましたが、私どものような業務システムを作っている会社というのは正直何をやってる会社なのかわかってもらえていません。一方で、インターネットというのは私どもの業界と近しいため、どういうことをやってるのかということについて了解が存在する世界でもあります。少なくとも私が見知っているサイトなどはそうです。 一方で、私がお近付きになりたい、あるいはもっと私どもを知って頂きたいと感じている方々にとってはインターネットというのはまだまだあまり日常的な存在ではないように感じます。もちろん楽天やアマゾンのようなサービスは活用されています。

「やります」と「やってます」と「やりました」では、過去形になるほど具体的です。具体的になるということは、厳しい評価に晒されるということでもあります。 先日、「要件定義の高速化をやります」と書きました。これがどう評価されるかは正直わかりませんが、一部の方からは期待もしていただけるのではないかと感じます。そして今後あれこれとトライしていく（といいながら既にあれこれとやってはいますが）中で、中間経過が見えてくるとそれなりに評価も頂けるでしょう。「まだまだだね」とか「結構いいんじゃないか」などと感じてもらえることかと思います。 この「やってます」の時点ではあくまでも中間の過程に過ぎないので、評価も甘めなのが正直なところでしょう。ところが「やりました。これが完成形です」となったら、突然厳しく評価されます。 ソフトウェアの場合は、RC（リリース候補版）などというもはや完了と同等の状態でも、まだ甘めに見

ギョイゾー！の実装における開発生産性の高さには自負があります。一方で、そのキャパシティを活かしきれない状況になってきました。別の工程がボトルネックになってきたのです。 ところが今では製造自体には1時間もかかりません。もちろんカスタマイズ部分や完成品の検品作業などに時間は必要ですが、圧倒的に製造工程のサイクルタイムが短縮された一方で、要件定義工程は従来どおりの時間がかかっているため、非常に目立つようになってきました。 また、この要件定義という作業が出来る人間を育成するのも、まだまだ結構大変なので人数を増やすことでスケールさせるということも難しかったりします。また、以前にも書きましたが相手あってのことですし、お客様の側の納得形成までの時間が必要というのもあって、なかなか一筋縄ではいかない課題です。 そういうわけで今はこの要件定義のキャパシティ改善を考えています。要件定義の量産化と呼んでもいいの

こんなことを書くと自己否定のようにも感じたりしますが、一方で私は経営コンサルタントとしての側面もあるので、色々と考え込んでしまったりします。 あるお店の改善をするとして、ポップ一枚で業績が改善することも現実にあります。IT化以前にやれること・やるべきことが山積みの会社さんも非常に多かったりします。ところが、そういう会社さんに限って「IT化によって一気に会社を良くしたい」と考えがちだったりします。 一方でどうみてもそろそろIT化しないと辛いでしょう、と感じるような状況の会社さんに限って「いや、うちはずっとこうやってきたから」とIT化にはあまり関心を示しません。もちろん業績の改善には当然前向きなのですが、IT化ということについては興味がないのです。 業務システムを導入するというのはソリューションです。商売の基本としてソリューションありきではいかんというのがあります。お客様は、例えば在庫の山をし

順調に物事が進むと、色々と引きがあります。会社もそうですし、それ以外のことでもよくあります。そのような引きに乗っかって勢いを増していくと、気がつけば本業が疎かになってしまっていることがあります。 そうこうしているうちに、段々と本業の方が手薄になっていき次第に結果をきちんと出せなくなってしまってることがあります。不思議なもので、自分ではちゃんと出来ているつもりでも実際には以前ほど時間を割いているわけではないので、やはり微妙に衰えが生じていたりします。勘が鈍って読み違えを起こしていたりということもあります。 結果が出なくなってくると周囲の評価も僅かずつですが下がり始めます。そこで何とか挽回しようと無茶をして結果として空回りしたりします。そうこう繰り返しているうちに、順調に回っていたはずのあれこれが見事なくらいに逆回転をしはじめます。そして気がつけば周囲にいたはずの人たちが離れてしまっています。

先週からイベントに出展など色々としてきました。その合間に来客が続いたりなど、空き時間が全くなく、PCに向かうのもままならない状態でした。そんな中で、色々と感じたりしたことがあります。 となりのブースは老夫妻による「かんきりくん」というものの展示だったのですが、そのあまりのなめらかな切り口に小さな子供からお年寄りまで、正に老若男女問わず「すごいねー」と感嘆して人だかりの山が続いていました。その横でスタロジのブースはずっと閑古鳥です。途中からパソコン無料相談という趣に変えたところ、数人の年配の方が筆王のバックアップはどうすればいいかなどを聞きに来られました。 夜の出展者同士の交流会ではメリヤス屋さんの社長さんに「御社（スタロジのことです）と違ってうちはものづくりの会社だから」と言われて、あーそうだよなー、と改めて痛感させられました。ソフトウェアはものづくりとは感じられないのだろうと思うのです。

先日、小室哲哉さんが逮捕されたという記事を見ました。自作の曲の権利を売るということでありながら、その権利を有していなかったということが問題になっているようです。この著作権に絡む問題は、実は私どものような業務システムを作っている商売でも非常に重要なことだったりします。 この契約書の内容ですが、基本的には「いつ・誰が・誰に・何を・どこに・どのように・何個・いくらで」納品するかということを明記しています。この「何を」が役務なのか具体的なブツ（成果物）なのかによって多少変わってきますが、大筋は納品に関することです。それに連動する形で対価のお支払い方法が記載されています。納品できなかった場合のペナルティなども併記されます。 さて、この契約書の中で役務ではない場合に、その成果物の取り扱いにおいて非常に重要なセクションがあります。それが「著作権に関すること」です。著作権者が誰になるのか。どのタイミングで

もうすぐ、とはいっても来年の春ですが、娘が小学校を卒業します。人間というのは、学校を卒業したあとも人生の中では色々な形で卒業を迎えます。 そういった区切りのタイミングで人間関係なども整理されていくことを感じるときがあります。私にとっては、一昨年の実父の死がひとつの区切りでした。幼少期の事情により、父方の親戚とは正直色々と難しいものもあったのですが、まぁ極論を言えば縁が本当に薄くなったと感じます。 そして今回三回忌を迎え、実父の再婚相手の方（実母と区別するためにママと呼んでいます）とのあれこれにも区切りをつけることになりました。その結果、私と妹は育った家から完全に卒業することになりました。 人生のステージが変わるごとに人間関係が移ろっていくのは、ある意味仕方がないことなのでしょう。いつまでも気の合う同士でずっと同じ関係でいられるというのは、それはそれで素晴らしいことです。私にも6歳からの友人

以前にネットブックについてちょっと書きました。実はこれ、中小企業向けSaaSと呼ばれている領域との相性が良いのではないかと感じたりしています。 中小企業のパソコンの装備率について触れたことがありますが、まだまだ1人1台パソコンを用意しているというのは、結構少なかったりします。この記事を書いた後にあちこちに回ってみても、その実感が深まる一方です。そしてネットワークの装備率というのは更に低くなります。フロッピーが活躍しているケースもまだまだ多いのです。 一方で、景気が悪くなるとSI業界の悪い癖（笑）ですぐに中小企業市場の開拓という話が出てきます。スモール＆ミディアムビジネスということでSMBなどとも呼ばれます。景気が良くなるとみんな大手企業向けに戻っちゃうのですけど（苦笑）。スタロジは基本的にSMB向けを心がけています。 そのSMBにおいてSaaSというキーワードが踊っています。要するにサーバ

今日は少し技術的な話です。スタロジはいわゆるウォーターフォール型というスタイルで仕事をしています。そして工程別に担当が分かれています。 ブリスタを使っての打ち合わせが完了したら、ブリスタから設計情報を出力してスタロジの中でファクトリと呼んでいる所謂工場のライン的なチームにそれを回します。すると、プロジェクトごとの段取り替えなど含めておよそ20〜30分程度で実際に納品可能なシステムが一式出来上がります。 ・正規化されたデータベース ・追加・更新・削除の一連の処理 ・権限によるアクセスコントロール ・ワークフロー ・多様な検索 ・検索結果のCSVダウンロード ・入力支援のためのポップアップするマスタ検索画面など ・各種仕様書 およそ業務システムとして必要な一式が完成します。これは画面数やテーブル数などの規模には左右されません。工場となっているサーバのメモリ容量などの物理的成約で作業時間が決まり