▼システム屋として

2012年07月25日

■ショートカット(の続き)

サイン7月も早終盤を迎えた。梅雨?真夏?などといってる間にすっかり夏の中枢に入り込んでしまっている感じだ。(きっと仕事がそんな状況だからか・・・)

今日は恐らく五反田で終日過ごす事になる。とは言え、突然のお客様訪問、これから立ち上がる業務フェーズの準備、そして、新しい事務所になって初めて皆が一同に会する社員総会−と、コンテンツは盛り沢山。そんな中、きっと今日も夢中に1日を過ごすのだろう。

灯台元暗し。五反田の駅隣接にこんな場所があったとは。多少、BGMの音量が気になるが、PCを開いてても苦にならぬカフェ発見。今後も良くお邪魔する事になりそうだ。

続きを読む

sigma1126 at 08:29|このブログを人気ブログランキングで応援する | PermalinkComments(0)TrackBack(0)この記事をクリップ!

2012年06月06日

■マラソン仕事

マラソン今週の出張の初日。

システム再構築案件の基本設計が4月に始まって以来、凡そ2ヶ月余りの時間が経過する。ほぼ毎週、ないし2週に1回は、2、3日かけてお客様と仕様を詰める打合せの為に、横浜・五反田・そしてお客様の本拠である島田で打合せをしてきた。

これほどの規模感、そして、これほど打合せ詰めになりながら設計作業を進めていくのも、いつ以来になるだろう。改めてこの仕事の醍醐味を感じる今日この頃。

そして、同じ「システム開発」と言っても、規模による違い−がもたらす難易度の高さを改めて痛感している。

続きを読む

sigma1126 at 23:55|このブログを人気ブログランキングで応援する | PermalinkComments(0)TrackBack(0)この記事をクリップ!

2012年06月02日

■SEの腕が落ちている?

SE

つい1週間前に、こんな日記を書いた。

SEの腕が落ちている?
http://sigma.livedoor.biz/archives/52016783.html


昨年秋の実体験から、「言われた事しかしないSE」が以前に比べて増えたのではないか−という仮設なのだが、恐らくあながち間違いではあるまい。

何故、そうなってしまったのか。

続きを読む

sigma1126 at 09:57|このブログを人気ブログランキングで応援する | PermalinkComments(1)TrackBack(0)この記事をクリップ!

2012年05月26日

■SEの腕が落ちている?

hanaどうもちょいと忙しくなるとブログ更新がままならない。立場上あってはならぬのだが、一つの事に夢中になると、どうしても他の事が疎かになるのは、射手座のO型ゆえん?(と言い訳をする)

さて、季節は大きく動き、早会社の年度末月の月末を迎えている。おかげさまで様々な変化に鍛えられながらも維持出来ているのは、やはり仲間とお客様に恵まれているからだと思う。この気持ちは初心、絶対に忘れてはならない。

初心と言えば、昨年秋以降、創業期のがむしゃらさを思い出さんばかりに、いわゆるSE業務に没頭する時間が増えているのだが、その時間を通じて実感している事がある。

続きを読む

sigma1126 at 09:39|このブログを人気ブログランキングで応援する | PermalinkComments(0)TrackBack(0)この記事をクリップ!

2007年07月03日

■また偽装請負が...

二重派遣が露見された記事が、今日も新聞トップを飾った。

派遣会社から派遣を受けた会社が、「請負」と称して発注先に実態は派遣していたというもの。
実態は派遣なのに「請負」の契約・・・という偽装請負の問題が一つ。そして、仮にそれを派遣契約に切り替えた時に生ずる「二重派遣」の問題。

なかなか無くならないなぁ−というのが実感だ。

このような事例が、過去よりソフトウェア業界でも当り前の事としてまかりとってきた事は、以前より何度も触れてきた。法に照らせば、明らかに違法行為であるし、また、そこに身を入れてる企業も、恐らくそれとわかっている事なのだろう。

それでも無くならないのは、やはり構造のどこかに問題・課題があるのだろう。

お客様のご要件を、各メーカーないし大手SI会社が「ガバッ」と囲い込むように取り込む。そうなると、他のSI会社、大手であろうが中小であろうが零細であろうが、その下に入り込む事に力を注がざるを得ない。そして、後は階層構造の中、いかにお客様に近い位置、順列で入り込めるか・・・が利益増加のポイントとなる。
一度そこにハマってしまうと、「縄張り」と言っても過言ではない膠着したコミュニティが生まれ、中間業者は、その上位業者には滅多に逆らえなくなる状況。。。

やはり自分が考える打開策は、「お客様に直接選んでもらうこと」だ。もちろん、億の単位でのテーマに対して、「お任せ下さい」とは嘘でも言えない。だが、「ある部分」「ある役割」に絞って考えれば、勝負になるし、むしろ価格競争では優位に立てる筈だ。

だが、次なる問題は、お客様から見える位置に私達が居ない事。
お客様にしてみれば、あるシステム化課題が発生した際、「どこに頼もうか」と検討しても、結局名のあるメーカーや大手SIerを候補に挙げるのは、自然な事でもある。何故なら、「他の会社が見えない」からだ。
いかに優れた技術を持っていても、優れた社員がいようが、見えなければ選んで頂きようがない。

部分的でもニッチでも良い、自分達の特色を出して、「これなら負けない」何かを創造する事。
そして、それをしっかりと広告宣伝する事。

この事に投資できる骨っぽい状態にしたい。
また、これが出来る企業が増える事で、この業界は劇的に変貌する事だろう。それはきっと、良い方向なのだとも思う。

社長日記 - livedoor Blog 共通テーマ

sigma1126 at 13:07|このブログを人気ブログランキングで応援する | PermalinkComments(1)TrackBack(0)この記事をクリップ!

2007年03月14日

■打ち上げ〜本編

昨日は、昨年春から取り組んでいたプロジェクトの打ち上げが、お客様からのお声かけを頂いて行われた。

まだ、残課題はいくつかあるものの、何とかプロジェクトは終焉に向かっている状況での開催。
皆が互いを労いながらの「打ち上げ」、いつもながら、SEとしては感慨深い場だ。

プロジェクトの発足時点では、互いの触れ合い方がまだぎこちない事が多い。

そして、プロジェクトが進行していくと、予期せぬ出来事に苦しみながら、互いに力を併せて、また、時にはぶつかり合う事もある。共にシステムを作り上げていく「仲間」ではありながら、「会社」の利得、懐勘定が気になる局面もある。

だが、途中そんな事はありながらも、後半は着地に向かって結束力が盛り上がっていくものだ。

それは、プロセスはともかく、「システムを無事に稼動させること」が、参加者全員の動かぬ共通目標であることに皆が気付いた時から始まる。
その気持ちと気持ちが共鳴し、ある程度きつい課題などの壁にぶつかったとしても、力を併せてそれを乗り越えていけるのだ。

今回も、昨年末から今年初めにかけて、細かいながら、かなりの課題が積みあがっていたが、地道に力を併せてひとつひとつそれを克服してきた。
その行程は、互いの信頼感を高める事に大きく寄与してきた筈だ。

そして打ち上げの場。
その過程を経た面々は、1年前の「ぎこちなさ」からは想像出来ない程、リラックスして互いを労いながら色々な会話が出来るようになる。まるで旧知の友のように。

職人として、「ひと仕事終えた」事を祝いあうお祭りのようなものだ。
ある意味、この一時があるから、この仕事も辞められない・・・と思う。

自分の場合は、もはや実働部隊としてプロジェクトに参画する事は大きく減少したし、また、立場柄、周囲は「ただの1SE」とは見てくれない事もわかる。

しかし、数は減れど、こういう場に参加出来る喜びは、いつまでも絶やさずにいたいものだ。
そしてまた、この感覚を、こういった経験を我が同志にどんどんしてもらうべく、振舞っていきたいと思う。

sigma1126 at 12:12|このブログを人気ブログランキングで応援する | PermalinkComments(6)TrackBack(0)この記事をクリップ!

2007年02月21日

■SEの風景〜仕様変更ですか?

とあるシステム開発の現場の架空の話。

・・・・・

○○システムズ蠅蓮□あす業蠅茲蝓管理会計の機能の一部であるシステムを受託した。

○○システムズはすぐさまSEを数名用意し、お客様からの要求仕様を受け、設計工程をこなす。
ついで、プログラム製造工程にはさらにプログラマーを数名増員しプログラム単品テストを完了した後、結合テストまで完了させた。

プロジェクトは順調に進捗しているかに見えた。

ところが、△△工業のお客様も参画して、実際の運用イメージで動作させてみる「ユーザーテスト」の段階で問題が発生する。

△△工業のご担当いわく、
「勘定科目Yの算出方法は、勘定科目Aマイナス勘定科目Bの筈なのにそうなっていない。」

会計について、少しでも勉強していれば、勘定科目YはA−Bでないといけない事は明白で、これは言わば「常識」の範疇とも言える要件だ。
「そんな基本的なところで・・・」と、○○システムズのマネージャーはやや動揺し、担当SEに話を聞いてみることにした。

担当SEが言うには、「△△工業様より頂いた要求仕様に、勘定科目Y=A−Bではなく、はっきりY=A−Cと書いてあります。その通りに作って何がいけないんですか?」
その後、証拠の要求仕様書も見直してみたが、確かにそう書いてある。
マネージャーは一瞬考えたが、ある決断をした。「それは仕様変更だね。」と・・・。

後日、「A−C」を「A−B」に仕様変更すると、どの程度のプログラムの変更が必要で、それを進める場合、どの程度の費用がかかるか−という内容のプレゼンが○○システムズより△△工業にされた。

「冗談じゃない。そんなの常識だろう。敢えて親切心で要求仕様に盛り込んだ際の単なる書き間違いなのに、何故その修正分の費用がかかるんだ。」と、当然のように△△工業側は思ったのだが、いかんせん証拠の仕様書を提示させられた日にはかなわない。

△△工業は、なくなく追加費用について、起案決裁し、なんとか本番運用にのせるしかなかった。

・・・・・

他業界の方は良くわからないかもしれないが、お客様の△△工業さんの立場にたって読んでいただくと、納得いかない部分も多いかと思う。

こういうケース、実は結構あったりする。
もちろん、お客様側の立場が強く、結局無償で対応するケースがあったり、その行方はさまざまだ。

このような場合、仮にどちらかが提訴して裁判にでもなったらどちらが勝つか。それはより細かい状況を一つ一つ掘り起こさないといけない。

・・・が、ここではそれは置いておいて、「SEとして」という立場で考えてみたい。

数日前の「『たられば』は禁句」の日記の際、コメント頂いた平松社長がおっしゃるように、SEには、「想像力」が求められる。
上の例で言えば、「Y=A−C」と書かれたお客様の要求仕様を見て、「あれっ変だなぁ。普通Y=A−Bだと思うんだけど・・・。」と気付き、次いで、「これはきっとお客様の間違いだ。確認してみよう。」という行動になれば、火種は元々発生していなかった筈だ。

このSE、それが出来なかった理由は二通り考えられる。

1.不勉強で気付かなかった。→やはりSEたるもの、「会計業務」についてのシステムを扱うならば、「会計」について、最低限の勉強をし、知識を付けて舞台に立ちたいものだ。業務系の仕事をする以上、これは避けては通る事が出来ないだろう。むしろ、SEという仕事を通じて、お客様の仕事の生業を学び理解し、少しだも役立てる事−これに喜びを覚えられないとやっていけないだろう。

2.気付いていたが、「書いてある通りに作ればいい」と思った。→これはプロのSEの心構えとしては重症だろう。お客様と力を併せて、システムを予定通りのスケジュールと品質で必ず着地させる。この気構えがないSEにぶつかったお客様は悲惨だ。

今回の例では、書かれていることの間違い−が発端なのだが、「書かれていないこと」で判断に苦しむ事も多々ある。

そのような時におろつかない為にも、

ヽ慮任燭訖念を大前提に
「気付き」を得る為の知識習得
E慘呂靴篤世臣亮韻箏亳海卜△鼎韻気譴「想像力」
と、
づ慘呂靴篤世臣亮韻箏亳海鮖っても想像出来ない事については、聞ける「素直さ」

ケースバイケースではあるが、私達SEは、こんな事を肝に銘じて仕事に取り組みたいものだ。

sigma1126 at 19:48|このブログを人気ブログランキングで応援する | PermalinkComments(2)TrackBack(0)この記事をクリップ!

2006年11月22日

■青ざめる体験

私達のような仕事の場合、ある程度の経験を重ねた方は、ある「冷える思い」、「背筋が凍りつく」体験をします。
例えば、大事なデータを誤って消去してしまったり、上書きしてしまったり、共有のファイルを自分が掴みっぱなしにして、他の方にご迷惑をかけたり・・・と。

こんな経験がない方は、とても素晴らしいのですが、私は昨日、やってしまいました。

繁忙期のヘルプで、私自身、あるソフトウェアをテストしてる時に、誤って、関係ない別のボタンを押してしまったが為に、大事なテストデータが吹き飛んでしまいました。

今回は、自分達の中でのテストでもあったので、「お客様に多大な迷惑」という事にはなりませんでしたが、間違ったボタンを押してしばらくすると、様子がおかしい事に気付き、スーッと血の気がひいたかと思うと、その後、全身がカーッと熱くなってきました。

「本番データでなくて良かった。」
本日自力でなんとか復旧し、テストも無事終えたのですが、昨日は結構凹み、とぼとぼ帰宅したのでした。

思い起こせば、以前より何度か「冷える思い」してます。
中には冗談ではすまないものもありました。

それはまだ、1年目の頃、コンピュータの「コ」の字もわからずこの世界に入り、日々勉強しつつ業務にあたり、だんだんわかってきて面白くなってきたある日の事。
端末からホストコンピュータのあるファイルを覗いていると、電話が・・・。
「××のファイルつかんでんのは、お前か。なんでそんなファイル見てんだ!おかげでオンラインを5分とめたぞ!馬鹿者!」
当時の勤務先は、計算センター業務を生業としており、自社コンピュータをサーバーに、お客様にオンラインサービスを行っていたのですが、これを5分止めてしまいました。

まさか、「勉強していて興味がわいたから・・」とは言えません。しどろもどろで平謝りでした。

また、お客様先でのシステム構築の仕事で、もうじき本番−という状況を迎えていた頃。
ある日、本番環境で、プログラムをプレランするテストを行いました。これは、本番環境にて、データを0件でプログラムを最初から最後まで動かしてみる−というテスト。環境設定や、処理手順を記述したコマンドに誤りがないか否かを確認する目的です。

一見、何事もなく、無事終了したかに見えたのです。
ところが、その数十分後、1本の電話が・・・
電話でひとつひとつの事象を聞いてるうちに、凍りつくように冷えていきました。
その処理手順を記述したコマンドのたった一文字書き間違えただけで、それ以降の本当の本番業務に多大に迷惑をかけてしまいました。

その業務が、物流系の業務でしたので、それ以降続く請求業務などなどに誤ったデータが渡ってしまい、それがどんどん転移していく−という始末。
これは結局、それらのシステム関係者併せて数十人を土日出勤させてしまいました。
もちろん、私の上司である部長も同席の上、丁重に陳謝。
損害賠償請求されてもおかしくない、これは青ざめた出来事でした。もう20年ほど前になりますが、あの時の冷えた感覚は今でも残ります。

また、これは自分ではありませんが、ある客先でシステム開発をしていて、何を間違えたか、「Drop Database[ENTER]」(データベースもろとも全部消えろ!−という命令)とやってしまった−という話は聞いただけで鳥肌が立ちました。
笑い話では到底すみません。
まぁそんな命令を1開発要員が使える権限設定も問題とは思いますが、ご本人と会社はただではすまなかったでしょう。

これらは、決して、間違っても武勇伝ではありません。こういうミスは犯さない方が良いに決まってます。チームや会社としての取り組みはさることながら、やはり人の手がどこかに絡む以上、ミスは0にはなりません。

自分の経験では、あまりに忙しく余裕がない状況の時や、体調が思わしくないときに、この手のミスを犯しがちになります。
今さらながらですが、やはり基本は、日々の体調管理と時間管理なのだと、改めて気付かされた昨日今日です。

sigma1126 at 15:19|このブログを人気ブログランキングで応援する | PermalinkComments(6)TrackBack(0)この記事をクリップ!

2006年10月23日

■偽装請負

とある製造業様の件に端を発し、巷で騒がれているこの問題。

もちろん、我々「ソフトウェア業界」に於いても、それは全く他人事ではなく、むしろこれから入るメスに戦々恐々とする企業も数多い事だろう。

2年程前に、これに関連する記事をいくつか書いたので、まずはそれをご紹介したい。

・2004年10月13日「ソフト業界の下請構造(1)」

・2004年10月16日「ソフト業界の下請構造(2)」

・2004年10月19日「ソフトウェア受託開発業?」

・2004年10月21日「ぐるぐるまわる!?」

・2004年10月26日「システム屋としてのプライド 」

この偽装請負の件を知ってか知らずか、それに近い部分をだいぶ捲くし立てて頂いている。

「こういうスキルを持った人が欲しいんだけど・・・」
「だったら、この経歴書の人はいかがでしょう。」
「では面接は×月×日。時間は×時という事で・・・」
と話は流れ、結果として話がまとまり、
「それでは、この方に来週から来ていただきましょう。単金は、1ヶ月××万でどうでしょう。あと、時間の増減ですが、月間標準時間を140h−180hとし、これを越えたら時間単価で精算しましょう」

この業界、簡単に言うと、上のようなやりとりで話が決まる事が多い。
これで、堂々と「請負」の契約書が作られる。自分は長く業界に浸かっているのでやや感覚は麻痺しているが、普通に考えるとどう考えてもおかしい。
雇用契約を結ぶ為にスカウトしてもらう話か、百歩譲っても派遣契約の話にしか聞こえないだろう。

いったい、受注元は何を請負ったというのか・・・。
一旦作業が始まると、日々、発注元担当から細かな作業指示が出て、その通りの作業を行っていく。

「これはすでに派遣でしょ!?」

きっとその通りだと思われる。ただ、2年前に書いた記事にもあるように、この業界、階層構造がかなり深い。現実にあわせ、派遣に切り替えたとしても、今度は「二重派遣」の問題にぶつかる。

さてさて、技術者売込み型で飯を食ってきたソフトハウスはこれからいったいどうすることだろう。やはり、この流れは、中途半端なソフトハウスを淘汰する方向に流れるはずだ。派遣で勝負するにも、請負で勝負するにも、コンプライアンス運営を前提に強みを磨いていけたところだけが生き残る。

また、これまで、大量に要員導入することで価値を創造してきた、大手のベンダーも、やすやすと人を集めて提供すれば良い−という状況ではなくなった。

ガリバーのようなメーカーや超大手のシンクタンク、ソフトウェアベンダーを除き、中小ソフトハウスはもはや横一線の戦国状態に入りつつある予感がする。

この流れを煽りたい。
改めて言う。
「小さいソフトハウスよ。勇気を持って、強みを作り、しがらみから抜け出そう!」

面白い状況になってきた。

sigma1126 at 15:54|このブログを人気ブログランキングで応援する | PermalinkComments(3)TrackBack(1)この記事をクリップ!

2006年09月03日

■小さいソフト屋のプライド

少し以前の話となるが、とある居酒屋で飲んでいた時の事。

たまたま隣に居合わせた男性二人組の会話から、考えさせられる事が多かった。

お一方は、かなりこの会社歴が長いベテランの方、年齢は40〜50代といったところか。そしてもう一方は1年半位前に、この会社に転職されてきた(会話から判ってしまいました)30代の方。

普段、食事に行ったりしても、周囲の声はほとんど気にならず、自分たちの会話に没頭するのだが、この時は、あまりに近距離で、なおかつお互いにノーガードの大きな声での会話であったので、どうしようもなくその会話の内容まで耳にこびりついてしまった。

とても気持ちよく飲まれていたと見える。内容は、社内組織の事であったり、家庭問題の話であったり・・・。ベテランの方が後輩に向かって、恐らくアドバイスのつもりなんだろうが、語る語る...。
まだまだ「おらおらオヤジ」は存在するのだなぁ−と、何だか感慨深い気にもなった。

それにしても、あまりに自分の会社名を臆する事もなく、堂々と公言しながらの会話だったので、さすがに、「いいのかなぁ、間近に誰がいるかもわからないのに・・・」と思ってしまった。紛れもなく、旧財閥系の大手シンクタンクの方だ。
まぁ、ライバル−と言っては相手に失礼だが、提供しているサービスの内容は遠くはない。

やはり、大きな所帯になると、お客様視点というよりは、社内処世術に興味とエネルギーを裂く方が多いようで、そんな話を自分も最初に入社した会社を思い出しながら聞いていた。(聞こえてきた)
こちらは独立して小さな所帯にいると「なんとくだらない、無駄な時間を」という会話なのだが、組織化の過程で陥りやすい現象でもあり、その辺り、反面教師にしなければならないとも思う。

ただ、聞き捨てならない一言が。。。
「○○○(この方たちの社名です)は、10億以下の仕事はとってはダメだ。」
思わず、「うわぁ、言っちゃった」と心の中でつぶやいた。
確かに、これだけの大手となれば、設備投資や人材開発投資も並々ならぬものであろう。また、恐らくであるが、親会社に対しての年貢的なものや看板代的なものも形はともかく安くない筈だ。それらをカバーするには、高単価かつボリューム大のプロジェクトにのみターゲットを絞り、粛々と業務遂行していく方向となって止む無し−というのは判る。

しかし、これをお客様が聞いていたらなんと思う事か。
また、大きなシステム化投資が出来ない会社は、少なくともこの会社に仕事をお願いしても、断られるか、或いは片手間にされるのがいいところだろう。「大きな会社だから弱きを助ける」というのが世の為人の為であり、格好良いと思うのだが。
結局のところ、今問題ともなっている格差社会にまともに加担している結果だ。
それが良い悪いはともかくとして、この手の方々に、その部分では政府批判する事は恐らく許されない。

さて、仮に大手のご同業のスタンスが、皆これと大差ないとしたら、私達には充分勝機があるとも感じる。何故なら、彼ら大手に手の出せない小さなお役立ちはいくらでもお客様が望まれてるはずだからである。また、どんな巨大プロジェクトであったとしても、その中身は小さい仕事の集合体である。もちろん、サービス体系が整っている大手ベンダーさんに叶わぬところは多いが、それはハナから我々は眼中にすべきではない。少なくとも今は・・・。1対1の喧嘩に持ち込めるようなところにターゲットを絞り、そこで勝負する。そう、ランチェスターだ。これが出来れば未来は明るい。

これを実践する為に我々のような小さきソフトハウスは何をすべきか。

‐さくても骨っぽい会社があることを広くお客様に知って頂く為の広報/広告投資
■餌丕韻侶嘩に勝てる人材育成の為の投資
そしてそして・・・

MΦい鬚發辰董大手ソフトの下請けを抜け出す事。自分たちの働きの多くの部分がお客様の喜びに繋がる前に、吸い上げられる事を理解し、これに加担する事を止め、我が会社のプライドを賭けて、広い広い市場に身を投げ出す事。

みんなでやれば恐くない筈。

sigma1126 at 10:07|このブログを人気ブログランキングで応援する | PermalinkComments(18)TrackBack(0)この記事をクリップ!

2006年08月30日

■30歳限界説

昔、「30歳プログラマ限界説」とか、35歳・・とかいう説があった。
それは、
・プログラムを作る−という作業について頭がついていかなくなる
・プログラム構築の為の基盤技術の進化スピードについていけなくなる
・体力の限界
−など、単に年齢だけでなく、状況の変化などの要因をもって、そう唱えられていたのだろう。

また、ある意味、「いつまでもプログラムばっかりやってないで、上流工程のスペシャリストになるとか、マネジメントを覚えるとかしなさい」−という期待の裏腹であったのかもしれない。

それに反して自分は、その30歳を迎えた当時、まだバリバリにプログラムを組んでいたし、マネジメントや上流工程を行いつつも、それと平行にゴリゴリとプログラムを作っていたものだ。そしてそれは、31、32・・35・・・・歳と、責任の重さはやや変われど、基本的には変わらぬ自分のスタンスであった。
「自分にとっての天職か・・!?」などとうぬぼれていたこともあった。

会社代表となっても、そのスタンスには変わりはあまりなかった。それまでは一つのセクションを管理していたのが、その単位が会社となっただけで、やはり自分は現場でゴリゴリやっていた。

だが今・・・

プログラムを作る−という行為がさすがに苦しくなってきた。
確かに、会社を成長させる為に、組織化を進めるには、まず自分が現場第一線からは身を引き、経営者として行うべき事に身を集中投下するべき−という背景はある。
自分自身としても、他の事に興味を示し始めたのも事実。

であるが、最も大きな要因は、千代の富士関の引退会見ではないが、「体力の限界!気力も衰え・・・」というのが正しいような気がする。
どうもプログラミングに対してはとっつき自体が段々と遅くなってきているし、また集中力もどうも長続きしない。

これは、天の啓示なのか、はたまた右目が歪む影響か・・・。


sigma1126 at 18:45|このブログを人気ブログランキングで応援する | PermalinkComments(16)TrackBack(0)この記事をクリップ!

2006年08月16日

■お酒造りの話

と言っても、お酒造りそのものの話ではありません。

お酒造りを助けるシステム作り、固く言うと「生産管理システム」についての話です。

一般的に生産管理システムは、部品表や工程表などの生産モデルを組み上げ、それを基に、売上計画やお客様からの発注に従って、生産計画を練り上げて作業指示を組み立てます。
一方、指示に基づいて実際に生産作業を行う事で、今度は逆に実績データを拾い上げ、原材料や製品、中間品の在庫管理に繋げたり、またそのデータを利用して原価計算を行ったりします。

最近は、この手のシステムは一から手作りする事はほとんどなくなりました。
ERPを含むパッケージソフトでどこのお客様もほとんど業務を担っている−というのが現状なのではないでしょうか。

もちろん、取り扱い品目の質や種類、数、また、商品サイクルによって、キーポイントとなる機能はそれぞれ異なりますが、「生産管理」と言えば、「財務会計」に続いてパッケージ化し易い部分でもあるので、このようにそお客様の業態別にさまざまなものが、さまざまなソフトウェアメーカーから売られています。

ただ、私の経験からして、お酒は難しい・・・です。

通常、ERP導入の際には、業務とパッケージソフトで持っている機能との間のギャップを見つけ、それを業務で対応するかソフトをカスタマイズする方向とするかを個別に検討しながら進めていきます。
また、追加機能については、「外付け」とか「アドオン」などと称して、パッケージソフトそのものはいじらずに、ソフトが提供している外部インターフェイスを利用して、別途プログラムを新規作成し、これに対処します。

お酒の場合、この「追加機能」にあたる部分で、「この機能がないと実質運用できない」という「帳簿作成」という機能を実装しなければなりません。
お酒の製造は、酒税法によって、かなりしばられており、お酒の製造過程を事細かに記録して、これを税務署に提出しなければならない−事になっています。
恐らくですが、この提出用の酒税帳簿も税務署によって、必要項目やレイアウト、また、その種類が別々となっており、それが尚更パッケージ化を難しくしているのでしょう。

私の経験則ですが、一般的な生産管理データに比べ、この帳簿用に記録し保管するデータは、細かく膨大になります。ですので、処理スピードなどにも気を使いつつ、また、生産管理本体との整合をとりつつ、きれいにアドオン部分を構築しなければなりません。

もはやアドオンだけで、立派なシステム作りと化します。

このような事情から、たとえ「生産管理システムについてはバッチリ!」という経験豊富なSEの方も、ことお酒については「こんな筈では・・・」と面食らう部分も少なからずあるのではないでしょうか。

「生産管理」の経験は、ごく一般的ですが、「お酒の製造・生産管理に絡んで、血だらけになったよ」というのは、かなり価値が高いのではないかと思います。

私達のような小さなソフトハウスには、このような業務特化の道もあるのだと考えています。

sigma1126 at 18:13|このブログを人気ブログランキングで応援する | PermalinkComments(6)TrackBack(0)この記事をクリップ!

2006年08月15日

■「フリー」であるということ

「自分は今度独立してフリーになるよ。」
「へぇ、すごいねぇ。いよいよ独立だねぇ。」

フリーランス=言うまでもなく個人事業主である。

病気や怪我をしてしまえば、すなわちその時点から実入りは0となる。
また、社会保険の恩恵からもやや遠ざかり、基本的に会計処理や税務処理をも自分でしょいこむ。
お客様に対しては、法人に依頼するよりもメリットを感じさせないといけない。
その為、日夜見えない部分で自らのスキルアップに全力で磨きをかける。

そう、腕一本で仕事をしていくプロ中のプロ。職人だ。

ところが、私達の業界の「フリー」は未だこのイメージから遠い部分が多々ある。
やや偏見があるかもしれない。また、もちろんプロ中のプロ、本物の方がいらっしゃるのも事実である。
だが、やはり全体感としては、まだ成熟度が足りないと思ってしまう。

自分がまだ20代の頃には、20代でのフリーランスは見たことがなかった。
目にするのが、30代中盤から40代。以前どこかのメーカーや大手ディーラーにいた方が何らかの事情でその場を飛び出し、何らかのツテを辿って、メーカーや大手ソフトハウスと直接契約をして、「いつ切られるかわからない・・・」とは思いつつも、それまでの人間関係を頼りにそれを信じ、日々、目の前の業務と確定申告時期の忙しさを乗り越えていらっしゃったのを、まだ青い若者でありながら目にしたものだ。

最近はどうだろう。20代の時点で、フリーとなっている方を見かけることも増えてきた。

自分の若い時とは状況は異なり、確かにITの波は、我々に若いうちからSEやプログラマーの疑似体験可能な状況を与えてくれた。繰り返すが、確かにその中から天才は登場している例もある。

自分の考えであるが、そもそも企業システムを構築する必要スキルのカテゴリにも千差万別あるが、その中の一つでも、「自分はこれには自信があり、どこでも通用する」というスキルを身につけるには、やはり5年10年という歳月が必要だ。
それも、あれこれやるのではなく、それに特化して地道に努力した結果として。

恐らく、その道を通らぬまま、独立している技術者が多いのだと思う。
もちろん、勤労形態の多様化や、景気の動向、または企業のコンプライアンス重視傾向や下請法など、さまざまな要素が絡み合った結果であるとは思われる。

ただ、「フリー」はやはりプロでなければならないと思う。

児玉光雄様著の「天才社員の育て方」という書籍を最近読んだ。
それを読むと、プロとは何ぞ−という事が、気持ちよい程に書かれている。
かのイチローも元々天才だったワケではなく、小さな頃からの修行、成長ステージに見合った恵まれた修行環境とご本人の強い集中力と思い入れ、イメージ力があいまって、あのような超一流の「天才」となった−とある。

どんな仕事も、最初はコツコツと基本動作を繰り返すしかない。
その数年を乗り越え、次なるステージ、そしてまた次なるステージへ−と、ひたすら熱中していく事で、一歩一歩プロの道に近づいていくのだと思う。

そういえば、オシム語録の中で、「サッカーで飯を食おうと思ったら、何よりも優先してサッカーづけになるべきだ。それは家族よりも−である」というのがあったように思う。
やや、時代に逆行して、賛否両論ありそうではあるが、自分は素直に頷いてしまった。

sigma1126 at 18:13|このブログを人気ブログランキングで応援する | PermalinkComments(7)TrackBack(0)この記事をクリップ!

2005年12月20日

■原因究明

昨日、システム維持契約をさせて頂いている製パン業様の生産管理システムにて、調査依頼を頂いた。不思議な事に、あるレポートの出力依頼を行うと、きちんと出力されたり、途中でフリーズしたかのような現象となるとのこと。

自分は、午前中から夕方にかけて、会社事務や他プロジェクトの打合せに参画していたりしていたのだが、夕方から合流して、システム調査に加わった。

その生産管理システムは、WindowsをプラットフォームにVisual Basicで作られているもの。レポート出力については、Visual BasicからAccessに連携して、クエリを動かす事により実現されていた。

調べていくと、呼び出されたAccessのクエリに、不穏な動作をするものがあった。
そのまま実行すると動作するのだが、一度デザインで開き、少しでも触ると途端に動かしてもそのまま固まる。また、処理対象となるデータの件数によっても動作が変わってしまう。通常有り得ない現象だ。

「なんだこりゃ。。。」

・・・・・

システムの不具合、調査依頼は通常
1.依頼の受付
2.原因の究明及び特定
3.対策案検討
4.対策実施
5.検証
6.報告
という流れをとる。

だが、少なくともWindowsをプラットフォームとしたアプリケーションシステムについて調査する時、必ずしもこの流れでの作業を取らず、機転を利かす必要がある。
それは、2.原因の究明及び特定−を一旦あきらめる−という事だ。
もちろん、最初からそれを諦め、とんちんかんな事をしていてはダメで、あくまで、原因となっている箇所は特定出来ており、それについて、可能な限り調査した上での事だ。

昔(今でもお使いのお客様は沢山いらっしゃいますが)、大型汎用機をプラットフォームに、主にCOBOLやPL/Iで事務系アプリケーションを構築していた頃は、上の作業工程の大前提はまず覆らない。それはアプリケーションシステムを支えるプラットフォームが強固に安定したものだったからである。従って、不具合の原因は、ほぼ間違いなく構築したプログラム群の中に潜んでいる筈であった。

それに比べ、今回のような現象は、構築したVisual BasicプログラムやAccessのクエリをまずは真剣に疑う必要があるものの、ひょっとすると、WindowsやOffice製品の不具合やバージョンの問題、或いはインストールしたソフトの組み合わせの問題。はては、他に関係なくインストールしたソフトが悪影響を及ぼしている−など、自分たちの許容範囲を遥かに越える部分が原因であることも少なくない。

そのような状況で、いつまでも作られたプログラムといつまでもにらめっこを続けることは、そのシステムをお使い頂いているお客様に最もご迷惑をおかけすることとなる。

こんな場合は、原因の究明は、それなりの技術を持った部隊に任せるか、ベンダーに問い合わせを別途行う事で、一旦保留とし、前に進んで対策を検討、実施していく事が肝心だ。
恐らく、今回のケースでは、動作不安定のクエリを作り直すか、別の方法で処理をする−という事になる。

改めて言う事ではないかもしれないが、Windowsというプラットフォームは、確かにシステム開発の生産性向上、また、SEやプログラマの敷居を下げたかもしれない。だが実は、プロとしての仕事をするには、より難解かつ複雑になっているとも言える。

sigma1126 at 07:25|このブログを人気ブログランキングで応援する | PermalinkComments(7)TrackBack(3)この記事をクリップ!

2005年12月16日

■システム維持という仕事

「塵も積もって」タイトルの回でも触れましたが、最近、業務系システムの維持−という仕事が多くなって来ました。

16人という小人数の会社ですので、このようなオファーは大変嬉しいです。
例えば、どんな種類の事をしているかと言いますと、

・勤怠システムの運用・維持・問い合わせ対応

・イントラネット利用者ログレポートの作成

・飲料製造業の生産管理システムの問い合わせ対応

・製パン業の生産管理システム・原価計算システムの問い合わせ対応

・エンジニアリング業の管理会計システムの問い合わせ対応

・総合食品業の社宅管理システムの問い合わせ対応

などです。
物によって、多少の守備範囲は違いますが、作業分類すると、

…蟯的な作業−月次処理が正常終了しているかどうかの監視/月締めでのレポート作成 など

¬笋す腓錣斬弍−お客様からのシステム運用・内容に関してのお問い合わせを受付、それを受けて調査し、お応えする

トラブル対応−システムが何らかの障害に見まわれた際、原因究明し、影響範囲を調査し、応急対応・恒久対応など対策を立案・実施する

て端貂邏函櫃客様からのご要望に応じて、作業を行う。例えば、何かの申請があがり、それを誤って承認してしまったので、それを未承認状態に戻して欲しい−というご依頼があれば、調査の上、データベースの状態を戻す−など。

,砲弔い討呂笋篳未任垢、その他のものについては、多種のスキルにつき、非常に高いものが要求されます。

まずは、お客様からの話をもらさず正確にお聞きする、また、タイミング良く、お客様にイライラさせない報告能力。もちろん、その業務内容及び運用に関する知識。また、システムを読めるIT技術系の能力。

その他、俊敏性であったり、調査時の確実性であったり、場合によっては、切羽詰ったりする事もしばしばあるので、プレッシャーに強いこと−など、数えればキリが有りません。

ですので、性格的に向き不向きはあるのでしょうが、可能性のある技術者にとってみると、成長出来るエキス満載なのです。

もちろん、システムを0から構築する−という仕事にも高い能力は必要です。また、多くの技術者はこちらの方を好みます。「私は開発がやりたいのだ!」と。

しかしながら、システム構築をダイナミックに満喫出来るのは、お客様と接することの出来るほんの一握りのSEのみです。あとの大半は、そのSEの指示、又は、さらにその部下SEの指示の元に動く、「専門の作り手」となります。

ほんの一握りになるには、お客様の業務に精通するなど、努力と経験がそれなりに必要となるのです。

時にバタバタし、追い詰められそうになる事が多く、一見つらそうに見える、このシステム維持の仕事ですが、実は、お客様に最も近い営業ともなります。

その動きが良ければ、お客様からは、きってもきれないベストパートナーにも成り得ますし、以前書いたように、そこからのお仕事のリピートも高い確率で頂ける事となります。

私の気持ちとしては、維持業務の数だけ、私達の会社の営業拠点があるようなもので、それぞれ仲間の担当がお客様と触れ合った実績・経験を聞くたびに、とても嬉しく思うのです。

あらためて、システム維持業務は「金」であると感じます。

こういう地道な仕事でスキルをつけ、お客様にもファンになって頂くことにより、より会社の体力が強化され、さらなる高いレベルのサービスでお客様の力になる。

こういった好循環をいつもイメージしています。

sigma1126 at 15:18|このブログを人気ブログランキングで応援する | PermalinkComments(121)TrackBack(1)この記事をクリップ!

2005年12月12日

■立場逆転

私達のようなソフトウェア受託開発を行っていると、「世間は狭い」というのが有り勝ちな感覚だ。

「コンピュータSE」「プログラマ」と呼ばれる職種に従事している人口は、今やかなり多数の筈である。が、一度何らかの仕事で係わった方と、後々また別な現場でお会いすることが私自身過去にもしばしばあった。

恐らく、一言で、ソフトウェア開発業−と言っても、業務系なのか制御系なのか、得意な業務分野は何か−などで、ある程度細かく分類出来る。また、これに加えて、度々触れさせて頂いているが、この業界の下請け構造、「なわばり」がある。従って、会社を渡り歩いたとしても、同じ分類の中で、もしかすると同じなわばりの中の移動となる為、決して遠くない所にいるケースが多いのだ。そして時を経てまた出くわす−という事に繋がる。

例えば、かなり階層の下の会社で雇われて、あるユーザー現場にて、ある業務を従事しているとする。自分は階層構造の下の方の雇われなので、同じ会社として行っている筈の隣の人とは全く知らない仲であることも多い。

やがて、昼食などを共にとりながら、互いの会社、置かれている環境などについて教えあうようになる。幼稚な世界だと思うが、自らの給与などについても情報交換したりする。そうなるとやがて、「隣の島が良く見える」状態となる。

「俺も君の会社に入れてもらいたいなぁ。」最初は冗談だ。
「いいよ。紹介しようか?」
「えっ!?マジで?いいの?」と、きっかけが出来る。
このような流れで会社を辞めていった技術者を、自分もかなり過去に多く見てきた。

また、これとはややパターンが異なるが、階層構造上位の会社からの明らかなスカウトを見ることも数多くあった。最低の商慣習?を守る為、ご丁寧に、一旦別な第三者の会社に入社させ、そこを数ヶ月で退職させて自分の会社に入社させる−という作戦だ。技術者本人は、結果として、中間の会社事務所には一度も足を踏み入れる事無く、これまでより高待遇を提示してきた会社に入ることが出来る。(本当にその会社が彼の居場所としてふさわしいか否かは別問題だが)

さて、このように世界が狭く、人の流動激しい業界であるので、立場の逆転現象もしばしばある。
特に、私のように、もともとは数千人の会社に居ながら、人数規模では小さな会社へと移動してきた者にとっては尚更だ。つまり、この間まで、自分の所属会社の下請けとして来ていた人が、いつの間にか「お客様」へと変貌しているケースだ。また、もともとは同僚だった方が、今はお客様であったり、ビジネスパートナーであったりもする。

なので、仮に今は、立場的には自分より弱い相手であっても、決して横柄な態度は良くない。いずれ立場が逆転し、反撃を食らうだろう。(その前に、その方からは相手にされないとは思うが)
そうならない為に、立場は関係なく、謙虚に尊敬の念を抱いて、目の前の相手と触れ合っていくことが肝心だ。「立場は人を作る」とも言うし、それも確かに言える部分もあるが、それはいかにもエラそうな人格を作る事ではない。
まずは魅力ある自分を創るべく磨くこと。謙虚たるべし。

sigma1126 at 21:31|このブログを人気ブログランキングで応援する | PermalinkComments(4)TrackBack(0)この記事をクリップ!

2005年12月06日

■腹を決める

昨日、私達の会社で携わっているシステムでトラブルが発生した。

お客様はいつもお世話になっている某大手食品会社のグループ会社、システムは生産管理システムだ。

古くから、このシステムについては、その食品会社のグループシステム子会社のご担当の方が維持、問い合わせ対応をされていた。
今年の初め、このシステムの改定案件を、このご担当から依頼され、従事した事を契機に、私達も時折このシステムにも触れ合う事になっていた。こちらの担当は二年目のA君。
10月より、維持契約を結ぶことも出来、このシステムはご担当の方と、ウチのA君が協力をして、このシステムの面倒を見ていた。

トラブルの一報がはいったのが、午後2時〜3時頃。

運の悪い事に、この日、ご担当の方は別件で他のお客様のところへ出張されていた。
連絡は、トラブルの現地から、ご担当の方へ。そして、そのメールが転送されて、A君のもとへ来る。「最悪、現地へ行かねばならないかも・・・」と、出張先のご担当は考えていた。

私達のお邪魔している現場からは、その大手食品会社のネットワーク上で業務をこなしている。グループ会社の中でも、WANで繋がっていて、リモートで保守メンテが可能なお客様はある。だが、このお客様の場合、そうではなく、ほぼこちらからはオフラインの関係にあった。従って、詳しい状況を把握するには、トラブルの現地に赴くしかない。

「どうしたらいいでしょう。」

A君に指示を仰がれた。
A君はこれまで、このシステムを結構面倒見ていたが、このご担当と共に行動する事がほとんどで、一人でこのお客様を訪れた事はないし、ましてやトラブル対応に出かけたこともない。

まずは、トラブルの現象、緊急度合などをそのご担当に伺う様指示。
そして間もなく、トラブル時のシステム画面のハードコピーが転送されてきた。が、やはり事象を追いかけるには情報が絶対的に不足していた。

そして、「Aさん、まずは一人で行ってくれ。行けるよう高橋さんを何とか説得してくれ。」とのお願いがA君のところへ。

・・・行かせるのは良い。だが、原因がつかめず、そのまま深夜までの戦いになる事も想定される。そんな中、大事な彼を行かせる事を良しとするか否か。しかしながら一方、大事なお客様のトラブル、一刻の猶予も許さない。

「わかった。僕の方でまず電話してみる。」・・1つめの腹を決めた瞬間だ。現地のユーザーご担当の電話番号をA君から教えてもらい、トラブルの状況、緊急度、そして何より、お客様の声色から、全体の状況を把握するのが目的だ。

ほぼ面識のない相手から電話が入ったので、そのユーザーご担当もややとまどった事だろう。感覚的には、システムが止まることによって、業務に重大な支障をきたしているというワケではなさそうだ。しかし同時に、その日のうちに解決しなければならないとも認識できた。

その電話後、
「A君、一緒に現地に行こう。」・・2つめの腹が決まった。
決断して、行動の一歩を踏み出すと、かなり気持ちは楽になる−というよりは、目の前の課題に身体を入れた事により、その課題に対して、前向きに取り組めるようになる。

・・・・・

そうなると後はなるべく早く現地に赴き原因を追究し、対策を講じるだけ。

たまたまかもしれないが、到着後1時間余りで原因を突き止めることが出来、その後の一時間で対策を講じて、お客様に報告させていただき、当座すっきりすることが出来た。

お客様に対して、当り前の行動かもしれないが、腰の重たいSEにはなかなか出来ないことだ。久しぶりにSEとしての腹を決める経験をして、あらためて行動のあり方の勉強をしたような気分だ。

そして...

今日、ご褒美として、現地のお客様、及び出張から帰られたシステムご担当より、感謝の言葉を頂いた。

これがまたたまらない。

sigma1126 at 22:04|このブログを人気ブログランキングで応援する | PermalinkComments(4)TrackBack(0)この記事をクリップ!

2005年06月09日

■製油業さま向け商品情報データベース

経営者という立場でありながら、未だ現場でシステム構築の実務をしている。そろそろ、その力の何割かずつでも、他の事に回すべきなのだろう。が、その反面、現場での生の姿を見ていただくという事も大切な事だと思っている。

2〜3年程前に構築したこのシステムだが、会社の分社/統合の影響で、ややシステム要件が変化した。昨年暮れに話があり、今年の2月頃から本格着手した。システム改定としては、ある程度の規模だ。

SQLサーバーをバックエンドのWebでのイントラシステム。自分としてはやや経験が足りない部分もあったが、当時はなんとか力でねじ伏せた格好であった。あれから数年、やはり色々な事を忘れており、なかなか作業のペースがあがらなかった。

「もはや限界!?」そう感じる事もしばしばありながらの数ヶ月。途中泣きそうになった事もあったが、ようやくメドがたった。
ほっとして体調が壊れないようにしたい。

まだまだ頑張れるかな!?

sigma1126 at 20:47|このブログを人気ブログランキングで応援する | PermalinkComments(1)TrackBack(0)この記事をクリップ!

2005年05月18日

■隣の島

自分は未だに現場に出て、システム構築の仕事も行っている。
HP等でも書かせて頂いているように、ウチの会社は小さいテーマを数多く手掛けている。ほんの数日間で納品を求められるもの、1週間程度は当り前で、半年などというテーマはかなり珍しい。

このような仕事柄である為、主に「赤い筋肉」を使う。つまり、俊敏性が求められるという事だ。お客様からのご要望やお問い合わせに対し、早く正確に反応して、速攻でご要件をとりまとめ、設計し実装して納品するという事だ。時には2、3本の仕事が重なってひぃひぃ言うことがある。だが、それが生業と信じて行っている。仕方がない。よりスピード感と精度の高さを求め、訓練に励むつもりだ。

ところで、現場の隣の島は、統合業務パッケージ(ERP)の導入プロジェクトに拘わっているグループらしい。プロジェクトは巨大かつ長期の仕事だ。実稼動が来年の春なのか、又はそれ以降なのかは不明であるが、今現在の私達の仕事に比べると気が遠くなる。恐らく紙一枚ではとても収まりきれないタスクリストを作成し、それを地道にこなしていく。前進を妨げる障害が発生した時には、それを課題リストにUPし、共有化を計り、担当を決め対策を進める。一日のうちに約半分は打ち合わせの為に時間が使われる。

時代が変わり、コスト云々は別として、全体感としては、昔の汎用機を駆使したシステム構築プロジェクトとあまり変わらないようだ。担当されている方にとってはそうではないだろうが、極めてゆっくりとプロジェクトが進捗していくように見える。
ここでのポイントは、あくまで他のメンバーとの情報の共有、打ち合わせや他部門等との調整だ。これは、「白い筋肉」が発達していないと、とてももたない。

一言でSEと言っても、これだけ普段の動きがまるで違う。それは、「業務系」「技術系」などのカテゴリ分類ともまたやや違う。

私達のようなソフトウェア会社は、技術的・業務的な特化は言うまでもないが、それ以外にプロジェクト、テーマの規模・性格に対しても、ある特化が必要なのだと感じている。と、同時に、お客様も、そのような観点でのソフトウェアベンダー選びをしていただくと、より一層のコストダウンが図れることだろう。

小さい仕事をこなします。
土の香りのソフト屋さんホームページ

sigma1126 at 12:15|このブログを人気ブログランキングで応援する | PermalinkComments(0)TrackBack(0)この記事をクリップ!

2004年11月01日

ソフトウェアの見積(0)

日経ITプロフェッショナルの2004年9月号には、ソフトウェアの見積技術についての特集記事が掲載されている。私達のような仕事を生業とする方々には大いに参考となろう。

ただ、この特集記事では、ソフトウェアベンダー側にかなりの非があるが如く記載されているように見受けられる。が、実際はお客様と我々ベンダーとの共通作業なのだと思う。

たとえ、見積り技法がどうであれ、お客様とベンダーがWinWinの関係となれば、それはそれで成り立っていると私は思うのだ。もしその逆のケース、どちらかがリスクをかぶるようなやりとりであれば、それは見積り等何か是正する余地があるのは当然であるが。

また、以前記事にさせていただいたように、下請構造をある程度何とかしない限り、見積単価がお客様に納得出来るものにはならないだろう。

しばらくは、このシリーズもテーマアップして考えていきたいと思う。

シグマクレスト
人気ブログ一覧

sigma1126 at 17:28|このブログを人気ブログランキングで応援する | PermalinkComments(0)TrackBack(0)この記事をクリップ!
よろしくお願いします
土の香りのソフト屋さん
高橋和美

1984年 銀行系シンクタンク入社
その後、中小ソフトハウスにて経験を積ませて頂き、
2001年9月10日、螢轡哀泪レストを東京五反田に設立

当初6名で始めた会社も、徐々に体制が大きくなり、目下数々の壁に体当たり中。

夢は、第一線を退いても自分の居場所となる憩いのエリアを設立すること。

一人の成功は望まない。
仲間との成功分かち合いを好む。
年に一度はビールかけをするような元気で暖かい仲間・集団、そしてそれを周囲に伝染させていきたい。
月別