アクセスカウンタ

プロフィール

ブログ名
鬱は個性なり
ブログ紹介
鬱病のチェックに多数該当するので心療内科に行ってみた。
「あなたは鬱病ではありません。それはただの性格です」と診断された。

なんということでしょう!
病気ならば治すこともできるけど、性格ならば治す方法が無いなんて。

どうしたものか。とりあえず、個性として受け入れよう。
zoom RSS

ちかんの思い出

2012/07/27 04:22
このブログエントリは、変態アドベントカレンダー in Summer 13日目(7月27日)です。
前日は @daiksy さんの scalaの変態的ライブラリ util-eval でした。


ITに関する話題をそんなに持ち合わせていないので、
ダジャレと昔話を話の枕にしてお茶を濁し、話を脱線させます。

人にもよるし仕事にもよるのだろうが、私は一括置換をしたことがほとんど無い。
おそらく、一括置換をしたのは1996年の夏に ある作業をした時だけ。
その作業とは、複数の hoge.ini ファイルと autoexec.bat 、 config.sys に対して、
『A:\』を『C:\』に一括置換するというもの。


なぜこんな作業をしなくてはいけなかったか。
それは、FreeBSD をNECのPC-9821シリーズ、Cx2 というPCにインストールしようとしたから。

当時の私は大学の卒論のために、研究室のPCで Fortranの計算プログラムを走らせていたのだが、
研究室にあるPCは台数が限られており、古いために処理速度も速くなかった。
「自宅のPCのほうが速いし自由に使える。自宅のPCで計算できるようにしよう」

で、研究室と同じ環境にするために FreeBSD をインストールしようとしたのだが、
『ハードディスクの初めのパーティションにインストールされる』とある。
何ですと!?そのパーティションには、Windows 3.1 が鎮座ましましていましてよ?

この時代のことを知らない人や、もう忘れてしまった人のために、
大雑把に昔話をする。
------------------------------------------------------
対象となるNECのPC-9821シリーズ、Cx2 という型式は、1995年の秋に私が初めて購入したPC。
おおまかな仕様は以下のとおり。

CPU: Pentium 75MHz
OS: Windows 3.1 + MS-DOS 6.2
HDD: 850MB
メモリ: 8MB

時代はPC/AT互換機が爆発的にシェアを伸ばし、
NECのPC-98シリーズのシェアが劇的に低下していたころ。

NECのPC-98シリーズはハードディスクの初めのパーティションに
Windowsがインストールされるのだが、そのドライブレターはA(Aドライブ)である。
少なくともCx2 という型式では、リカバリCDに入っている設定ファイルの中に、
すでに直に『A:\』と記述されている。
基本的に、Aドライブ以外にWindowsを移動することは不可能。
基本的には。
------------------------------------------------------

仕方がないのでハードディスクを3つのパーティションに分割し、次の形で運用することを目指した。

Aドライブ(300MB):FreeBSD
Bドライブ( 50MB):MS-DOS 6.2
Cドライブ(500MB):Windows 3.1 + MS-DOS 6.2 → Windows95にアップグレード

さて、やるぞ。
MS-DOSの起動フロッピーディスクを作り、FORMAT.EXEも起動フロッピーにコピーする。
起動フロッピーディスクから起動し、ハードディスクを物理フォーマット。パーティションを3つに区切る。
リカバリCDから Windows 3.1 + MS-DOS 6.2 を再インストール。(Aドライブにインストールされる。)
Aドライブの、使わないアプリケーションを徹底的に削除する。
(なにしろ再インストール直後は、「98ランチ」を始めとする余計なものが山ほどあるので。
 「98ランチ」って、こんなムダなもの。 )
A:\DOS フォルダを、Bドライブにコピー。
Bドライブの autoexec.bat 、 config.sys を適切な内容に書き換え。
再起動し、Bドライブ(MS-DOS 6.2)からboot。Aドライブにある全ファイルをCドライブにコピー。
Cドライブの autoexec.bat 、 config.sys にある『A:\』を『C:\』に一括置換。
再起動し、Cドライブの Windows 3.1 をbootできないことを確認。
再起動し、Aドライブの Windows 3.1 をboot。
Cドライブの 複数の設定ファイル( hoge.ini )中の、『A:\』を『C:\』に一括置換。
再起動し、Cドライブの Windows 3.1 をbootできることを確認。
Windows95のアップグレードCDでCドライブに Windows95をインストール。
再起動し、Cドライブの Windows95をbootできることを確認。
再起動し、Bドライブ(MS-DOS 6.2)からboot。Aドライブを論理フォーマット。
FreeBSDのインストールCDでFreeBSDをインストール。


できた。
そして私はFreeBSD上でFortranの計算プログラムを走らせることが出来るようになった。

ついでに、使いもしないのにお遊びで X-window をインストールしたりもした。
その結果、ユーザーレベルでのUNIXの知識が増えた。
vi を使えるようになり、make install とかカーネルの再構築とか、
ls、rm、cp、manなどの基本的なコマンドとか、.hoge ファイルの置き場所とかを覚えた。

大学の講義や演習で、次のようなことも経験した。(学んだ。)
・トランジスタの仕組み
・NANDとNORを用いた論理回路の作成
・CPUも、集積度が高いだけのただの論理回路であること。
・Z80を使った学習用キットで、7セグメント表示を出力するプログラムの作成。
 命令セットでプログラムを書き、ハンド・アセンブルで機械語に変換し、
 機械語を手入力して実行する。


さて。ここまでは話の枕で、ここからが本題。Σ( ̄□ ̄;) エッ・・・!!
こうして私は、PCの基本的な部分を学んで工学部を卒業し機械メーカーに入社したのだが。
ここで愕然とする。
会社には工学部を最多として理系学部(または大学院)出身者がごろごろといるのだが、
あまりにもPCを使えていない。うとい。
『多数の測定データを系列ごとに平均して一覧表示する』のを短時間でおこなうために、
『Quick BASIC で計算プログラムを作成し、誰でも使えるようにバッチファイルと組み合わせて使う』
ように私がしただけでビックリされた。「えっ?」「えっ?」

その後、つらつらと社内の人間を眺めてきて十数年。ようやく分かってきた気がする。

PCをまともに使いこなせるかどうかは、次のことと関係している。
・理系出身か文系出身かは、関係無い。
・年齢(世代)も関係無い。
・学歴も関係無い。
・個人で購入してPCを所有しているかどうかが関係している。
・特に、『自分で調べて、自分で試して、やりたいことができる環境を作る』ことをやってきたかどうかが関係する。
・『元に戻せなくなるかもしれない』レベルまでPCを使い倒そうとしたことが
 あるかどうかが関係している。個人で所有するPCなら思いきってやってみやすいが、
 会社のPCでそれをやる度胸のある人は少ない。
・Windows95の普及以後に初めてPCを購入した人は、
 PCを家電同様に、『あるがまま』で使おうとする傾向が高い。
 余計なことをしてトラブルを招くことに恐怖心を持っている。極度に保守的な傾向が高い。

・MS-DOSやUNIXなどで、CUIによる設定を経験しているかどうかが関係している。
・現在40歳以上の世代の理系出身者は、PCがCUIベースならば、もっと使いこなせる可能性がある。
 PCがGUIベースになって以降は、自分が知っているCUIベースのコンピュータのイメージと
 目の前のPCのイメージが乖離してしまった。
 GUIベースのコンピュータを「よく分からないもの」と思いこんでいる。


だから。↓↓こういう話は、本人たちの人間としての在り方が問題であり、世代によるものではないと思う。

るな速:「ファイルの圧縮ができない」 「Excelの操作もままならない」 40代会社員のポンコツ化が深刻


昔は、周辺機器の拡張とか、設定ファイルの書き換えとか、バッチファイルの作成とか、
簡単なプログラムの作成とかは、老若男女理系文系に関係なく、誰でも当たり前にやってたぜ。それぐらいでは、変態でもなんでもないぜ。

使いやすいように道具や環境を作り替えるのは、人間の大事な能力やん。
ちかんぐらいしようぜ。

せいき表現を使えとまでは言わないから、ちかんぐらいしようぜ! > IT業界以外の方


以上です。
明日の変態アドベントカレンダーは「うらがみさん( @backpaper0 さん)」の予定です。
よろしくお願いします。
記事へブログ気持玉 / トラックバック / コメント


変態、ITシステムの発注に関わる

2012/07/16 07:52
変態アドベントカレンダー in Summer(http://atnd.org/events/29918) 2日目(7月16日)です。


2008年夏のこと。
Aさん(上司。課長)「こういう社内システムを発注して開発することにしたので、それを取りまとめて中心になって推進するように」
私(ヒラ)「えっ!(絶句)」(やりたくない。そんなシステム、作っても会社の利益にならないし。)

ということで今回は、ITシステムの発注側の裏事情と、それに関わった私の変態的な立ち回りについてのお話です。
なお、私はIT関係者ではありません。機械メーカーに勤務しています。


私については、
http://red-lemon.at.webry.info/201207/article_1.html
http://red-lemon.at.webry.info/201207/article_2.html
を参照ください。



私「それは・・・私の全工数をそちらに振り向ければ可能です。が。いま担当している本業に一切、手を付ける余裕が無くなります。工数的に無理です」
Aさん「Bさん(後述)の直々の指名だから。工数のことは、そのうちBさんがなんとかしてくれるだろう」
私「じゃあ、やってみます」

引き受けちゃいました。
BさんというのはAさんの上司で、○○長という肩書きを持つ、私の組織のトップ。
そこそこ大規模な私の会社において、○○長というのは、中小企業における社長並みの意味と権力を持ちます。

どんなシステムを発注するのでしょうか。以下に前提条件をまとめました。

【期間】2008年度内に稟議書を作成、承認を受け、2009年度末までに完成。
【予算】8000万円くらい。
【目的】とある費用が増大しているので、その費用を低減する。
    今回開発するシステムで(全世界に拠点がある)弊社グループ全体のその費用をリアルタイムで集計する。
    それにより、早期に費用の増大を検知し、その原因を分析し、対策を講じることを可能にする。


【裏事情や関連事項】
・私の所属する○○という部門は、2008年度(4月)に組織変更があり、○○部から1段階格上げされるという形で発足した。(人員・担当業務は元のまま)
・Bさんは○○部門の長として、2008年度(4月)に着任した。以前は他部門の長をしていた。
・Bさんは○○部門の発足1年目として、『何か会社に貢献しそうな構想をブチ挙げなければ』というプレッシャーにさらされている。
・時を同じくして2008年度(4月)に、全社のITシステムを統括する部門(以後、X部門と呼ぶ)が発足した。
・X部門の仕事は、各部門が個別に開発・運用している社内システムを全社的な観点で統廃合していくこと。
 また、新規システムの発注案件について、当該部門のサポート・コーディネートをすること。
・X部門は、社内や社長に存在をアピールしたい。そのための、分かりやすい案件がほしい。
・社内システムの開発は、グループ会社であるY社に発注することが多い。Y社はITシステム・ソフトウェアの開発を専門とする会社。
・2008年秋、リーマンショック勃発。今後の投資案件は廃止・延期・減額されるのが世界的な趨勢となる。
・当然のことながら、類似のシステムはすでにある。
 ただし、データを入手するタイミングや経路が統一されてはいない。
 月次ごとのデータ入手であったり、経路がメール添付による送信や海外拠点のシステムへの定期的なアクセスだったり。
 また、常に自動的にデータ収集するようになっておらず、手動(人力)での収集のため、工数がかかっている。
・データは年間数万件。1件の項目数は30項目程度。
・Bさんはこの社内システムの開発について社長に口頭での説明をしており、発注の内諾は得ている。


【私の見解】
・この社内システムが理想どおりに完成しても、低減するべき『とある費用』は、低減できない。
・とある費用が増大しているのは、『費用をリアルタイムで集計できない』ことが理由ではないから。
 理由は『その原因を分析し、対策を講じる』ことができないから。その能力が無いから。
 したがって、『早期に費用の増大を検知する』ことができても、その費用の増大を防止することができない。
・現行のシステムは古いものの、『素(す)のデータ』をいつでも抽出して取り出せるようになっている。
 データを処理(加工)し、分析できるITスキルが無いだけ。
 つまり、システムの問題ではなくて、人の能力の問題。

・作る価値は無い。それでも、メンツその他のしがらみで、どうしてもやらねばならないとすれば・・・

・要求されるシステムを真剣に作るならば、8000万円では足りない。倍くらいかかりそう。
 期間も、1年間では苦しい。やはり、倍くらいかかりそう。
 基盤となる部分、根幹部分はこの予算と期間でできるだろう。
・これは、表向きは『1年間、8000万円』だが、実際は『2年間、1億6000万円』で進めないと無理な案件だ。
 追加の予算と期間は、次の年度に『システムの修正』という名目で、申請すればいいや。
・木で例えるなら、根っこと幹の部分だけは、1年間でしっかりとしたものに仕上げよう。
 枝や葉は、後からで良い。
 『どのようなデータを』「どのような形式で』『どのタイミングで』収集し、保持するか。
 が、根っこと幹の部分だろう。
・後からの拡張がきちんとできるシステムにすること。
・拡張ができるための余裕を多すぎず少なすぎず、適切に確保しておくべき。
・ITシステムを建築物に例えるなら、敷地は広くとり、建坪も余裕を見るべき。
 大黒柱と動線の確保はしっかりと。間取りや内装はどうでも良い。
 後からどうにでもなる。それよりも、早期に仮住まいが開始できることが大切。

・リーマンショックの影響で、投資案件が軒並み削られている。
 このままだとY社が潰れかねない。
 Y社が潰れると、うちの会社の多数のシステムの維持・管理や新規開発ができなくなる。
 これは長期的には、うちの会社の損失になる。
 この時期をY社が乗りきるために、金銭のサポート(仕事の提供)は必要だ。


・この仕事は私にとって多大な工数を必要とする。
 発注側でシステムの全容を把握している人は必要で、できる限り1人きりであることが望ましい。
 私1人でそれをやり遂げるのは、全力を尽くせばなんとかなるだろう。
 だが、現業務をこなすのにも、私がもう1人必要だ。余力では到底できない。
 私が1人足りない。本当に工数のサポートを、してもらえるのだろうか?


さて、読んでいただけているかどうか不安なほど、グダグダと書き連ねてきましたが、
上記事情に私の変態的解釈が発動され、次のように進めるという方針が決定しました。
誰にも言ってないけど。


【期間】 × 1年間 → ○ 2年間
【予算】 × 8000万円くらい。 → ○ 1億6000万円くらい。
【目的】この案件によってY社が事業量を確保でき、Y社の経営を維持できること。
    システムが完成しようがしまいが、知ったことではない。



さて。それでは、稟議書を書きますか・・・・
稟議書の項目の中に、『効果』という欄がありました。
「こういう効果があり、何年で新システム開発に投じた費用が回収できます」ということを書く欄です。
私は頭をかかえました。Bさんに相談に行きました。

私「新システムができても、費用的な効果はゼロだと思っています。『効果なんて無い』って書いていいですか?」
Bさん「効果が無いことは無いやろー。『過去の案件で総額1億円の費用がかかったものが、もしも新システムができたら早期に低減できるので、類似の事例が発生しても5000万円で済みます』とか。5000万円の効果や」
私「あー、そうですか。そんな感じで良いのですね?」

過去の事例では、費用総額が1億円程度に達するものが1年間に0〜2件程度発生しています。
そこで、
「そういう金額の大きな案件を1年に1件、半減できたとして、2年間で回収できます」と『効果』欄に記入してBさんに意見を求めに行きました。

Bさん「2年間で回収っちゅうのは、早すぎるなー。半減できます、っちゅうのも、言い過ぎやなー。『費用を30%低減できるようになって、3年間で回収できます』というストーリーにならんか?」
私「やってみます」

やってみましたが・・・過去の事例というのは数が限られています。
なので、どんな事例に『費用を30%低減できる』というのを当てはめて足し合わせても、『3年間で回収できます』というストーリーには至りませんでした。

私「3年間で回収できるというストーリーにはできません。費用効果が少し足りません。元々『30%低減できる』という数値には根拠など無いのですから、『40%低減できる』とさせてもらえませんか?」
Bさん「あかんあかん!そんなに効果があるとか書いたら、ウソになる」
私「それでは、『全ての事例について30%低減できる』とするのは、どうでしょう?」
Bさん「あかんあかん!そんなたくさんの事例について対応策を考えて実行できるワケがない。そんなウソあかん。稟議書は、役員さんも見るんやで。そんなツッコまれるようなウソはあかん」
私「そもそも、費用効果があるということ自体が疑問だと思いますが・・・」(冷ややかな目線)
Bさん「そんなことはないよ!分かった。私も案を考えてみる。他の人にも、案を考えさせる」
私「お願いします」

稟議書の提出期限が迫るなか、待てど暮らせど突っつけど、誰からも案は出てきませんでした。

私「稟議書の提出期限は今日なんですが、何か案は出ましたか?」
Bさん「スマン。無い。今日は他の用事がたくさんあって忙しい」
私「ああ、そうですか・・・」

私は「どうでもよいのだな」と判断して、鉛筆をなめました。
マジメに費用効果を計算した数値を『1.15倍して(15%増しにして)』効果とし、稟議書を提出しました。
うちの会社の役員の目が節穴で無ければ、細かいところに疑いを抱いて稟議が通らないハズです。
・・・稟議は通りました。そうですか。



さて。稟議も通り、予算が確保されたので、細かい要件定義に取りかかり始めた2009年の春。

私「そろそろ仕事が回らなくなり始めてるんですが・・・工数を増やす話はどうなってます?」
Aさん(上司。課長)「どうもなってない」
私「Bさん。このままだと工数が足りません。現業務と新システム開発の両方に半分ずつ工数を割り振ることはできません。そんなことをしたら、どちらも全く進まなくなります。新システム開発は放棄できないと思います。現業務はどうするのですか?放っておくのですか?」
Bさん「放っておいたらいいよ」

私「ああ、そうですか」

ここに至って、私はブチ切れました。放っておきました。新システム開発のほうの仕事を。
全力で実力行使して、新システム開発の業務から逃げました。打ち合わせがある日には「腰が痛い」「腹が痛い」「頭が痛い」「用事がある」で会社を休み続けました。
振り切って逃げ切りました。


2010年春。
新システム開発を専任で担当する課が新設されました。
担当する人も総勢4〜5名が(1人ずつではありましたが)増員されました。

私「(兵站の補給が遅きに失している。戦力の逐次投入は最悪の戦術・・・)」

2012年7月現在。
この新システムはまだ、部分的にしか稼働していません。いつ完成するのでしょうか。
X部門は、部門ごと無くなりました。2012年春の組織変更で。
Bさんは2009年4月に、他の部署に異動しました。2012年に定年退職しました。
Bさんの後任で着任したCさんは、2010年4月に、他の部署に異動しました。
Cさんの後任で着任したDさんは、2011年4月に、他の部署に異動しました。
Dさんの後任で着任したEさんは、2012年4月に、他の部署に異動しました。
Aさん(上司。課長)は、今も私の上司のままです。
Y社は無事、存続しています。

以上です。
明日は「うらがみさん(backpaper0さん)」の予定です。
よろしくお願いします。

記事へブログ気持玉 / トラックバック / コメント


私がITエンジニアに絡む理由

2012/07/16 06:53
・根っこがロジック好き。プログラミングも多分、大好物。

・しかし、「食っていけそうにない」という理由から、IT関連を仕事として選ぶことはしなかった。
 大学のゼミの教授の、次の2言は大きい。
 「
  自分の好きなことを仕事にすると、『好きなことがキライになってくる』か、
  思うようにやらせてもらえなかったり食えなかったりで『仕事を辞めたくなる』か
  のどちらかになりがち
 」
 「目に見えないソフトウェアの仕事は、他者から適切な評価をしてもらえないことが多い。
  やっていることの凄さを認めてもらえず、やりがいを感じにくい」

・趣味としてプログラミングをすることもしなかった。
 好きすぎて趣味の範疇には収まらなくなるだろうとの予感があったため。
 熱中しすぎて、人生に差し障るように思えた。
 なので、徹底してプログラミングからは距離を置いた。

・機械メーカーに勤務している。
 機械もシステム(or ソフトウェア or コードの集積全般)も製造業でのモノづくりという点で同じ。
 作っているモノが違うだけだと思っている。
 業務分野としては機械メーカーが古く、IT関連メーカーが新しい。
 考え方としては機械メーカーが非論理的で古くさく、IT関連メーカーが論理的で洗練されている。
 機械メーカーは人・モノに関するノウハウの蓄積が多く、IT関連メーカーは情報・部品の集積に関するノウハウの蓄積が多い。

・(機械)メーカーがIT関連メーカーから学べることが多数あると思っている。
 プログラミングにおけるAは、(機械)メーカーのBに適用して改善・改革の参考にできるものが多い。
 ここで、A・Bは次のとおり。
  A:データ処理の手法、デバイス制御の手法、例外処理の手法、エラー回避の手法、一部の問題解決アルゴリズム
  B:業務規定・社内規定などの制度設計、人員・組織の管理手法、業務の工程管理手法、部品・製品の管理手法

・逆に、IT関連メーカーが(機械)メーカーから学べることもあると思っている。
 たとえば、キャリアパス・キャリアマップの設計・運用手法や、個人が持つ固有技術・固有技能の伝承手法とか。
 あえて弱い部分を作ってそこをウォッチすることで、重要な部分のエラーや故障を未然に防止し、製品全体への致命的なダメージを回避する手法とか。

・プログラミングは(機械)メーカーにとってネタの宝庫だと思っている。
 高度成長期に作り上げたシステム(ITシステムではなく、制度・仕組み)は、
 部分的な修正の繰り返しで延命され続けた結果、実態には合わない使えないものになっている。
 もはや修正はできないくらいになっており、新規に構築しなければならない。
 そういう破綻したシステムをスクラップ&ビルトするための、重要なネタ。
記事へブログ気持玉 / トラックバック / コメント


エンジニアってなんだろう

2012/07/15 22:02
みなさんはエンジニア(engineer)って、どんな仕事をする人か知っていますか?
えっ!?知ってるの?それは素晴らしい。ならば、尋ねましょう。

「メカニック(mechanic)のことを、エンジニアと呼びますか?呼んでもよいですか?」

答えは一応、Yesです。英語であっても、日本語であっても、エンジニアと呼んでよいです。間違いにはなりません。
機械の製造・組立・整備・修理などができる人を、メカニックと呼びます。メカニックは、広義のエンジニアに含まれます。

日本語での広義のエンジニアとは、なんらかの技術的な仕事をしている人全般を指していると認識しています。
工学、技術は英語で engineering 、technology 。
それに携わる人が工学者、技術者で engineer 、technologist 。
工学者と技術者、engineerとtechnologistは、日本語でも英語でも区別が難しい場合があり、ここでは議論しません。
同じものとしてここではカタカナのエンジニアとし、これは広義には技術的な仕事をしている人全般を指す。
付け加えれば、『実用的な』技術的な仕事をしている人、と言うべきでしょう。
理論的な仕事をしている人は学者(理学者)や研究者と呼ばれ、エンジニアとはあまり呼ばれません。

広義のエンジニアはそれで良いのですが、エンジニアには様々な仕事をしている人がいます。
これを少し区分して、私の持っている『狭義のエンジニア』のイメージを記します。

漠然と「自分はエンジニアだ」と思っている方、あなたは『狭義のエンジニア』でもあるでしょうか?
これが、エンジニアを自認している方に問いかけたいことです。


例として機械の新製品を開発する部門の場合。
技術部と呼ばれることが多く、英語では Engineering department。
ここでの実務をしている人は全員、広義のエンジニア。(管理職、マネジメント職は除外します。)
『新製品仕様の構想』というインプットから、製造部門へ『部品の図面』『組立図面(全体図)』『組立に関するマニュアル(留意事項)』をアウトプットするのが、主要な仕事となります。
この仕事は、概ね次のプロセスから達成されます。

1.新製品仕様の構想(とりあえず、どこかから降ってくるとします。)
2.仕様を満たす(であろう)全体設計
3.部分設計(製品をいくつかの部分や機能に分けて設計)
4.詳細設計(最末端の部品レベルまで設計)
5.部品の図面作成
6.部品の作成
7.部品の組立(試作機の製作)
8.試作機の性能確認(テスト)
9.性能を含む新製品仕様を達成するまで、『2.〜8.』の繰り返し
10.書面・データおよび実地指導にて、製造部門へ『部品の図面』『組立図面(全体図)』『組立に関するマニュアル(留意事項)』を伝達

小さい会社やあまり複雑でない製品では、これら全てのプロセスを1人(または少人数)で行います。それをやる人は、間違いなくエンジニアと呼ばれます。
大きな会社や高い専門性を必要とする複雑な製品では、これらのプロセスが複数人の分業で行われます。

A:『6.〜8.』の、実在するモノを取り扱うプロセスを担当する人。これを私はメカニックと呼びます。
B:『2.〜5.』の、想像上のものである『仕様』を実在するモノに置き換えるまでのプロセスを担当する人。これを私はやや狭義のエンジニアと呼びます。

より分業が進んだ現在では、Bが次のようにB1とB2に分かれることが多くなりました。

A :上記と同じ。メカニック。
B1:『2.〜4.』の、設計を担当する人。これを私は狭義のエンジニアと呼びます。
B2:『5.』の、部品の図面作成を担当する人。これを私はCADオペレータと呼びます。

つまり、広義のエンジニアは、
実在するモノを扱うメカニック、
設計をする狭義のエンジニア、
図面作成をするCADオペレータ、
に区分することができます。

もっと細かく分業がされている場合もありますが、いずれにしても私の考える『狭義のエンジニア』とは、『設計をする人』になります。
設計とは、想像上のものでしかなかった『仕様』を、実在するものに置き換えること。新しいものを作ることです。
設計には大きな自由度があり、設計内容の良否は、お客さま(使用者)の利益に影響する『性能』やコストに大きな影響を与えます。
メカニックやCADオペレータが行う仕事には、その自由度がほとんどありません。ほとんどが『作業』です。

私がエンジニアという言葉を目にするたびに思うのは、「それは、設計をする狭義のエンジニアなのか。新しいものを作り出しているのか」ということ。
自由度の無い『作業』をやらせるために、カッコイイからという理由だけで『エンジニア』という言葉を使っていないか?ということ。
安易に自分を『エンジニア』だと自認している人は、その呼ばれ方だけで「自分は良い仕事をしている」と錯覚していないか?ということ。


さて。ここに『ITエンジニア』という言葉がありまして・・・これをどう捉えるかは、なかなか難しい。
『広義のエンジニア』であることに異論は無いのだけれど、機械の新製品開発の場合の『メカニック』や『CADオペレータ』に相当するような、自由度の少ない『作業』をしている人が相当数含まれているのではないだろうか?
『設計』をしている『狭義のエンジニア』、すなわち、想像上の『仕様』を実在するもの(人が操作して使えるもの)に置き換えて新しいものを作っている人、そういう人が『ITエンジニア』にどれだけいるのだろうか。
『ITエンジニア』が私の考える『狭義のエンジニア』『設計する人』に該当するのは、少なくとも、アルゴリズム(algorithm)の引き出し(知識)や新しいアルゴリズムを創造できる能力を持っている人。
あるいは、全体設計・部分設計の段階での、フローチャートを(書いても書かなくてもよいが)思い描ける人。
SE、プログラマという区分で見ると。SEは概念設計か全体設計、プログラマは部分設計かそれ以上、が出来る人が『狭義のエンジニア』。
それ以外は、『オペレータ』です。


エンジニアってなんだろう。あなたは、エンジニアですか?
記事へブログ気持玉 / トラックバック / コメント


月別リンク

鬱は個性なり/BIGLOBEウェブリブログ
文字サイズ:       閉じる