2007年01月17日
読者からの手紙
メールマガジンを週１に発行し初めて、はや１年８ヶ月になろうとしています。
書くことないなあ。と本当にネタ切れしたときには、
「ネタ切れです。助けてください。」と書いたら
読者の方からアドバイスをいただいて乗り切りました。
わたしもメルマガを幾つか購読しているのですが、
タイトルだけでスルーして読まないことも多々あります。
わたしの拙いメルマガをちゃんと読んでいただいている読者の方がいるというのは
なんてありがたいことでしょうか。
なんて幸せなことだろうかと思います。
今週は、自分には珍しく「ちょっとだけへこんで」いたのですが、
今朝、メールを見たら、読者の方から、激励のメールをいただいていました。
なんか、ものすごく嬉しくてその方を拝みたい気持ちになりました。
システムエンジニアとして「やりがいのある｣仕事をさせていただいて
その上、偉そうに社長として社員も何人か使っている自分です。
自分が今、出来ることは何なのだろうかと考えたときに、
若手の技術者、ＳＥに なんとか、ＩＴ業界の魅力に気づいてほしいと思ったのです。
頑張って「いい仕事しよう！」と本当に思うのです。
みんな、頑張ろうね。
投稿者 sugiyama : 20:45 | トラックバック
2006年03月27日
会計年度の不思議
多くの会社の業務システムに関与してきた私ですが、それでも
えっ、そうだったの？ということに出くわすことがあります。
この会計年度の考え方もその一つです。
入社時、新人に苦労して教えなければいけないことの一つに
ビジネスでいうところの年度は、1月から12月までとは限らない。
むしろ4月から3月が一番多いんだよ。ということがあります。
これは、会社の決算に関わるものだからです。
つまり、決算の期首、期末年月日が4月1日から3月31日という会社が、世の中には
一番多いということです。
もちろん、当社のように10月1日から9月30日ということもあります。
これが2番目にたぶん、多いのではないかと思います。
しかし、1月1日から12月31日という会社も中にはありますし、
6月1日から5月31日という会社もあります。
税務署に提出する決算書は1年を基本にしているため、このようになります。
しかし、これが必ず1日から末日までか？というと、どうも、そうではない
らしいです。
世の中には、会計年度が 5月21日から翌年5月20日という会社もあるらしいし
実は、何日にしなければいけないという決まりはないようです。
次に、会計年度の平成18年度とはいつからいつを指すのか？
という疑問があります。
正直、わたし、これずいぶん長い間、ちょっと誤解していたという経験があります。
で、最後にいきついたのが、当社superSE 小幡が教えてくれた
その期間が長くかかるほうが年度になる、という考え方です。
・平成17年10月１日から平成18年9月30日であれば平成18年度
平成17年は、期間が3ヶ月かかるが、平成18年には9ヶ月かかっているから
・平成17年4月1日から平成18年3月31日は平成17年度
平成17年は、期間が9ヶ月かかるが、平成18年には3ヶ月しかかかっていないから。
しかし、まてよ、じゃ、平成17年7月1日から平成18年6月30日の場合は、どうなるの？
いったいどっちの年度なんだろうか？と思うじゃないですか。
で、会計事務所に聞いてみました。
びっくりしたことに、いろいろな考え方があるようで・・・・・
１．多い月数が年度になる。（7月～6月の場合は不明）
２. ３月までが前年度の会計年度となる。
（17年4月～18年3月の場合は17年度。17年5月～18年4月は18年度。
国の会計年度がもとになる考え方。
18年度予算という場合は18年4月～19年3月を指す）
３．スタートの年が会計年度
ということは、とにかく、期首期末をお聞きするだけでなく
「御社は、平成18年度とは、どの期間を指すんですか？」と
とにかく確認するしかないのか。ということなんですよね。たぶん。
こういうこと聞いたときに、「こいつは馬鹿か？
こんな当たり前のこと聞いて」と、思われそうですが。しょうがないですよね。
投稿者 sugiyama : 17:00 | コメント (1) | トラックバック
2005年05月11日
システムエンジニアとは？
珍しく一日中、大きな予定もなく会社に居りました。
本当は、黒子に徹するだけで現場仕事をしてはいけないと思うのですが
つい、必要にかられてシステムエンジニア業をしておりました。
まだまだ、社長業よりもシステムエンジニア業が得意なことが
恥ずかしいのですが、ちょっと前と違って意識して社員にもそして
他社の人にも教えようと努力しています。
何かを伝えたい・・・
何かとは何なのか。
どう伝えたらいいのか。大きな問題です。
システムエンジニア（SE）とは、どんな能力を持った人
だと思いますか？
私が思うには、
・お客さまの仕事を自分が仕切って改善してあげようと
する人
・お客さまの仕事の話を聞いて自分で運用場面が全て
描ける人
・機能ごとにお客さまが求めている優先順位がわかる人
・作ったものの見栄えを気にする人
・ミスはどうして起きるのかを知っている人
・プログラマの相談に乗ってあげられる人
・プログラマに相談に乗ってもらえる人
・データベースが好きな人
・DB設計を見たらシステムが予想できる人
・全てのテーブルの予想件数が頭に入っている人
・全てのテーブルの意味（存在価値）を語ることが出来る人
・全てのプログラムの意味を語ることが出来る人
・運用の容易性 テストの容易性、保守の容易性を
プログラムの容易性と 同じレベルで計れる人
・シンプル イズ ベストと信じている人
・自分に自信を持っている人
・どんなシステムでも自分がやってみたいと思う人
ちょっと職人っぽかったでしょうか。
私は、やっぱりこの職業に誇り持ってます。
投稿者 sugiyama : 23:13 | トラックバック
2005年01月26日
ドキュメント作成
システムエンジニアとして他の会社に出かけることが多いので
私よりは、ずっと年の離れた若い社員と仕事をする機会も
多いものです。
この仕事をしているせいなのか、２，３年は、あっという間です。
この前、あの仕事で付き合ったときには、まだまだ新人だった
あの子がもう、こんなに成長してきちんと話ができるようになったのか。
もうこんな立派な資料を作ることができるようになったのね。
などと思うことがよくあります。
他人の子は育つのが早いといいますが、まさにそんな感じです。
特に、作成するドキュメント類については、お客様向けに綺麗で
わかりやす資料を作ることがどんどん当たり前になってきているようで
そういう面での成長は、目を見張るものがあります。
当社は、ある意味では、外に見せる部分ではなく、裏方部分を
受け持っていることが多いので、お客様に最終確認をするための資料
だったり、プログラマに指示するための資料を作ることが多く、
どうしても技術の細かな部分の説明資料作りが主になっています。
それでもやはり、人の目を意識したドキュメント作成能力は必要だなあと
常々実感します。
カラープリンタで印刷するのは、常識になってきましたし、
若いうちからお洒落な人達が育ってきている以上、内容だけでなく、
色、デザインといったことも含めて訴える力があると
また一つ強い資料になるといった感慨があります。
魅せるというのもテクニックの１つなのかなとも思います。
もっとも、基礎能力としては、当たり前のことですが、正しい分析・
実行可能な技術に裏づけされた提案や説明でなければ何の意味もなさず
それは、それで、美しいだけの頭が空っぽな誰かさんと同じくらいの
ものなのです。
まずは、基礎能力としてのドキュメント作成能力・・いいえ
順番ではなく、やはりどんな能力も、一夜にして持てるわけではない
のですから、最初からわかり易さや、美しさも含めて目標に同時に持つべき
なんでしょうね。
そういった意味では、理想としてはドキュメント１つにしても、どこまで人を
感動させる力があるかが勝負になるのではないでしょうか。
しかし、「後から来る者、偉大なり。」ですから。
きっとそのうち、当社の中でも、私が「感動するような」ドキュメントを
作ってくれる人がきっと現れてくれるでしょう。
投稿者 sugiyama : 12:45 | トラックバック
2005年01月18日
システムエンジニアは何でも一通りやるべき
プログラマを数年修業してからシステムエンジニアと
なるべき道を進む。
これは、昔、昔、私がこの業界に入ったときの通常の
コースであったのです。
しかし、長い？間には、システムエンジニアにいきなり育てる
という会社が現れ、それは、それなりにシステムエンジニア
としてのある一定の能力を養うのには有効かのように
思われました。
しかし、最近思うに、特に、JAVAの開発がさかんになり
オブジェクト指向というものがさかんに言われるようになり
プログラムのドキュメントがどんどんプログラマよりになる
のを見るにつけ、ある程度のプログラミングスキル。
言い換えればプログラマは、こういう思考で考えるといったもの
は、システムエンジニアにとって不可欠なのではないかと
思うようになっています。
また、これは大規模システム開発の場合に限ってというわけでは
ありません。
まず私がシステムエンジニアに求める最低限のスキルは、
プロジェクトマネージャーとしてのスキルとか、
アプリケーションエンジニアとしてのスキルとか
偏った高度なものではありません。
小さなベンチャーの例えば、５、６人程度の会社のお世話で
あれば、ネットワーク、インフラを含めて業務内容を分析し
パッケージを使ったり、ある部分は手作りしてシステムをすべて
設計、開発、運用指示、保守していくことのできる能力です。
会計を含めた業務知識は当たり前のことです。
どんな簡単なことでも一部分全く知らないでいて正しいシステム提案が
できるのか？と思うのです。
だから、当社は、自分のことは自分でやりたい。
そして、お客様が困ったときだけでなく、将来のさまざまな
不安要素について、たとえばセキュリティもしかり、
新しいインフラもしかり、新しいITにおけるビジネスモデルの
ご相談に常に先んじて提案を持っていけるような身でありたい
と思うのです。
専門に特化したシステムエンジニアもまず最初は簡単な全般の
知識を持っているべきでしょう。
投稿者 sugiyama : 10:47 | トラックバック
2004年12月06日
SEのためのヒューマンスキル入門・・・芦屋広太著
日経コンピュータに連載している当時から、興味深いとは
思っていましたが、こうして、いまさらながらに
一冊の本になったものを読み直してみると
本当にシステムエンジニアというのは、技術だけでなく
人とどうやって付き合うかのスキルも確実に要求されて
いるのだと思います。
システムエンジニアの意識向けの本としては、馬場史郎氏
が長く日経コンピュータに連載されていたものが有名でした。
「SEを極める５０の鉄則」これに私自身はかなり意識感化されたものでした。
システムエンジニアは、必ず毎日勉強しろ・・とかね。
ところが、この「SEのためのヒューマン・・」が一番
これまでの本と違うところは、顧客側の視点にたった場合の
システムエンジニアの能力が書かれているところだと思います。
馬場史郎氏についても、過去いろいろな書籍についても
システムエンジニア読本といったようなものは、たいていが
メーカーのシステムエンジニアだったり、とにかく
IT会社側の人間が書いたものがほとんどでした。
ところが、この芦屋さんというのは、ユーザ側の担当者として
幾つものプロジェクトをメーカーやIT会社と渉りあって
収めてきた方なのです。
その経験の中からシステムエンジニアについてのヒューマンスキルを
論じているのです。
まさに、声にならない客の声を代弁しているかのような
濃い内容の本でした。
具体的な幾つもの例は 私にとって、
長い間思ってきたこと「まさに、その通り」のことから
目からうろこのようなものまで多種多彩です。
確かにシステムエンジニアには
コンサルタントとある意味同じ能力を求められることが
あります。
それは、「問題解決能力」です。
そして結果を出すためには、システムエンジニアとしての
正しい考え、チャレンジ精神と行動力が常に必要とされます。
彼はSEに要求される「ヒューマンスキル」とは
具体的にはこんなことだと語っています。
・問題は解決できるという強い信念を持つ
・問題を細分化し、課題を正しく設定する。
・利害関係者を説得するためには彼らがどうすればYESと言うか
どうかを考える。
・彼らが満足するような戦略を練る。
・戦略を実行する。
SEだけでなく、営業にも、そしてプログラマにも
このIT業界の仕事に携る人たち全員に読んで考えて貰いたい
本だといえます。
・アマゾンでこの書籍を購入する。
投稿者 sugiyama : 13:45 | コメント (1) | トラックバック
2004年12月03日
議事録の役目
SE（システムエンジニア）に必要な能力は、数限りなくあります。
その中でも、新人SEとして一番最初に要求される能力、それは
「文章を書く力」ではないでしょうか？
何故なら、お客さまとの打ち合わせにおいて先輩SEが会議を
仕切って話しを進めている間、書記を担当し、会社に帰ってから
議事録に起こすことは、サブSEの役目なのですから。
実は、私自身は議事録には、「あくまで本当に話されたことを率直に
書くべき」だと思っていました。
会議を重ねているうちに、お客さまの抱えている問題や、希望など
いろいろなことが見えてきます。
会議中でも、Aさんの発言でいったん決まったことが、後になって
Bさんの発言で別の方向に決まったり、保留になったり、方向性が決まる
までも皆さんのさまざまな思いがそこにあるものです。
当日の議題には関係ないように思われたCさんのふとした発言が
後々、実は重要な意味があったのだということもあるのです。
そういう議事録を書こうとすると、会議中は、必死に書き取りを行い、
帰社後、まだ記憶が鮮明なうちに下書きをざっと書いてしまう
必要があります。
議事録は、その日のうちに書くもの。当社ではそう決めてきました。
例え、自分が議事録担当でない場合も、必ず、他人が書いた議事録を
チェックすることになるのですから、自分でも記憶があるうちに自分なりの
メモを整理しておくことにしています。
他人が書いた議事録の間違いは見つけることはできても、抜けていることを
思い出すのは、自分のネタ帳がないと無理だからです。
実際の話、ＳＥというものは、大変忙しい仕事です。その日のうちに
どうしても書けないということもあります。
ただ、１つのプロジェクトについて、会議の時間だけではお客さまと同じ
業務知識レベルにはなかなか到達できません。
何度も何度も過去の議事録を読み返すことによって自分なりの考えや疑問を
まとめなおして会議に臨むことが必要とされるのです。
そう思っていましたが「ＳＥのヒューマンスキル入門」を読んでいましたら
議事録の目的とは、
決まったことを正しく伝える。
いつまでに何をするかを関係者に伝える。
ことであり、わかりやすく簡潔にとありました。
確かに、議事録をお客さまに提出する一番の目的は上記です。
余分なことは書かないほうがいいのかな？自分は間違っていて
実は、議事録と別の会議メモをＳＥチームとして用意すべきだった
のかも？とも思いました。
決まったこと
保留になったこと
いつまでに何をするか
は、箇条書きに、議事録の最初にでも大きく書いておけばいいこと
と思い直しました。
打ち合わせチームにいても、たまたまその会議に参加されない方も
いらっしゃいますからね。
もっとも、私の場合、
１）なるべく話し合った内容を具体的に書いて、お客さまが発言された
ことを自分が正しく認識しているかをお客さまに確認していただく。
２）後で読み直すことによって、どういった経緯で結論に至ったか、
そのときに出てきた懸案などを再確認する。
といったことにも使おうとしているからでしょうね。
投稿者 sugiyama : 13:15 | トラックバック
2004年11月29日
システムエンジニアの仕事
朝礼後、他社を迎えて今後の仕事の打ち合わせ。
何時始まるか未だ決定していない仕事が２つほど。
でもやることだけは決定しているのです。
こういうときが一番・・・よく言う「ビミョー」
状態です。
しかし、話を聞くにつれ、1ヶ月以内にはプロジェクトが
動き出しそうなので、人員調整を見直してみる必要が
あります。
当社は、システムエンジニア数名と、プログラマ十数名
という組み合わせです。
通常、プロジェクトがスタートする場合、最初の設計の段階で
は、システムエンジニアが打ち合わせを行い、資料を作ります。
お客様の会社に直接伺って、現状の業務のお話や、課題、要望
といったものを聞き取るのです。
この作業が大きなシステムでは、何ヶ月もかかるわけですが
最近の潮流として、期間がどんどん短くなっています。
当社が請け負うプロジェクトでは、この概要設計、基本設計
といわれる期間が1ヶ月から3ヶ月くらい迄というのがほとんどです。
3ヶ月といっても、週2回訪問し、その資料を作るという作業は
かなりの集中力が要求される期間です。
お客様ごとに特徴のある専門用語を自分の中に消化し、運用を
頭の中で何回もシュミレーションし、問題点と将来どうあるべきか
の姿を描きながら、今回のシステムでは、どこまでを実現とするのか
の線引きをしていくのです。
大変ですが、システムエンジニアにとっては、力の発揮どころとも
いえるステップなのです。
１つの作業について細かく追求して考えることも必要ですし、
全体として流れの美しさ、シンプルさ、そして何よりもお客さまが
求めているであろう結果を出すための優先順位を常に意識していきます。
このとき、大事なことは、お客さまは、自分が何を作りたいのか
あまり細かなことまではわかっていないのだ。ということです。
「作業を楽にしたい。」
「結果を正確に速く出したい。」
「意味のある数字をほしい。」といったことはどのお客さまにも
通用することなのですが、
「システム会社はプロなんだからわかってくれるだろう。」
といったタイプのお客さまから
こと細かく、プログラムの細部にまでこうやってほしいと
いった要望を出してくるお客さままで、さまざまなタイプの
方がいらっしゃるのです。
具体的な、部品の１つ１つの設計に入ってくると
「お客さまがこうやってくれ」とおっしゃったからこう作りました。
という言葉を簡単に口にするシステムエンジニアがいますが、
自分自身で納得しない限り、システム化すべきではない。と
私自身は考えています。
なぜ、お客さまは、こうしてくれと強く要望しているのか？
それを理解しない限り、その裏に隠された真の問題、願望が
見えてこない場合があるのです。
プロというのは、お客さまが知らない解決方法を提示できる人
なのではないのでしょうか。
投稿者 sugiyama : 08:31 | トラックバック
2004年11月25日
SQLServer2005
SQLServer2005ベータ２のセミナへ行きました。
ヨン様が来日していたので、ひょっとしたら
社長は、成田へ行っているのかもしれぬ。と
思っている社員もいたかもしれません。
でも違います。真面目にセミナに出ておりました。
RDB（リレーショナルデータベースというのです。）
を最初に使い出した頃には、ORACLEとSQLServer両方を
いい具合に仕事で使ってました。
ところが、何の因果か知らないけれど、ここ５年くらいの
私の担当するシステムは、80％以上 SQLServerです。
おかげで、MCPも勉強して取りました。ついでに
MCAだって取りました。（注：両方ともマイクロソフトの
やっている資格試験です）
正直、大規模システムとしての機能は、ORACLEより
ちょっと足らないかもしれないけれど、使いやすさ
RDBを超えた多機能さ、GUI（要するに使い勝手がいいい）
などは圧倒的にSQLServerが勝つでしょう。
とくに、SQLServer6.5まではいろいろ問題があったものが
7.0- 2000とバージョンアップにしたがってカバーされて
強力なエンジンになってきました。
最近の納品したシステムでいうなら、1テーブル4000万件
で問題なく動いているなんていうものもありました。
運用が楽という点ではもともと一目置いていたのですが、
付属でついている各種サービスは、他社が出している
有償のものに比べると例えば、BI（ビジネス・インテリジェンス）の機能
なんて、明らかにおまけでついてる感が強かったのです。
それが、どうも、2005では、画期的によくなるらしいで
す。
セミナーを聞いてその感をますます強くしたのですが・・・
しかし、製品版として販売されるのは、2005年夏？？
これが問題ですね。それでも、今後、来年の春くらいに収める
システムは、2005コンパチブル、要するに、2005移行した
場合にその良さをすぐに体感できるようなものを意識して
収めたいと思います。
