C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[9]: SEに業務知識が必要か?


(過去ログ 39 を表示中)

[トピック内 15 記事 (1 - 15 表示)]  << 0 >>

■20515 / inTopicNo.1)  SEに業務知識が必要か?
  
□投稿者/ じゅで (38回)-(2008/06/11(Wed) 15:28:48)

分類:[討論] 

じゅでです。
いつもお世話になっております。

たぶん昔から業務知識については、色々話題になっていたと思うのですが、
ここ最近おかしいなと思い、皆様の意見をお聞きしたいので、意見をお聞かせ下さい。

SEに業務知識が必要かと言う事についてなのですが、
私自身は、要るSEと要らないSEが居ると思っております。

要るSEは、実際お客様との要件定義などや、システムに対する提案を行い、
機能設計を行うSEだと思います。

要らないSEは、要件定義書、機能設計などから、クラス設計、システム構成設計などを
行うSEだと思います。

最近この定義があいまいで、SEといった場合に、お客さんと話して、
クラス設計や、システム構成などを考え、下手をするとプログラムまで組んでたりします。
(PGも結構ありますよね)

そこで思うのですが、SEとは、本来どうあるべきでしょうか?

私は上に書いた2種類のSEがそれぞれスペシャリストとして存在するべきだと思っております。
その上で、そのスペシャリスト同士が協力してソフトウェアを開発していくべきだと考えております。

なぜ、こう思ったかというと、お客様と話すのに業務知識を学び、クラスなどの設計について学ぼうとしても、
限界があると考えているからです。

なので、業務知識に対して50の知識を持ち、クラスなどの設計に対して50の知識をもっているSEが二人で
仕事をするよりも、業務知識100の知識をもつSEと、クラスなどの設計に対して100の知識をもっている
SEが二人で仕事をしたほうが良いと考えます。

出来上がるものが、どう頑張っても50のものしか出来上がらないよりも、
内部の調整をしいかりやり、頑張れば100のものが出来上がる方が良いと思うのです。

私の考えとしては、以上となるのですが、実際皆さんはどう考えているのでしょうか?

引用返信 編集キー/
■20517 / inTopicNo.2)  Re[1]: SEに業務知識が必要か?
□投稿者/ シャノン (470回)-(2008/06/11(Wed) 15:53:13)
No20515 (じゅで さん) に返信
> SEに業務知識が必要かと言う事についてなのですが、
> 私自身は、要るSEと要らないSEが居ると思っております。

同意します。
ただし、その場合、依然として両者を「SE」という同じ名称で呼ぶべきなのでしょうか?

> 要るSEは、実際お客様との要件定義などや、システムに対する提案を行い、
> 機能設計を行うSEだと思います。
>
> 要らないSEは、要件定義書、機能設計などから、クラス設計、システム構成設計などを
> 行うSEだと思います。

後者は最近では「アーキテクト」と呼ばれることもあるようです。
また、プログラミング言語を書かない作業でも、それに極めて近いレベルの設計はプログラマが担当すべきだと思います。
引用返信 編集キー/
■20518 / inTopicNo.3)  Re[1]: SEに業務知識が必要か?
□投稿者/ やじゅ (448回)-(2008/06/11(Wed) 15:55:21)
No20515 (じゅで さん) に返信

システムエンジニアの定義が広すぎるんです。
ある意味何でもやになってしまう。

営業と同行して積極的に提案活動を行なうSEを「フィールドSE」といいます
(フィールドSEはプログラム開発やシステム構築・保守を行なうSEではありません)
この方たちは業務知識が豊富である必要がありますね。

「システムエンジニア」の定義
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=8045&forum=18&20
引用返信 編集キー/
■20519 / inTopicNo.4)  Re[1]: SEに業務知識が必要か?
□投稿者/ 特攻隊長まるるう (130回)-(2008/06/11(Wed) 15:57:50)
No20515 (じゅで さん) に返信
> なので、業務知識に対して50の知識を持ち、クラスなどの設計に対して50の知識をもっているSEが二人で
> 仕事をするよりも、業務知識100の知識をもつSEと、クラスなどの設計に対して100の知識をもっている
> SEが二人で仕事をしたほうが良いと考えます。
> 
> 出来上がるものが、どう頑張っても50のものしか出来上がらないよりも、
> 内部の調整をしいかりやり、頑張れば100のものが出来上がる方が良いと思うのです。
なんでもそうですが、一人の人が1つの分野の知識を独占してしまうと、
その人が倒れたり、失敗したり、間違ったらそれで 0 になってしまいます。
ヒューマンエラーをチェックできません。

プロジェクトの体制作りにもよるでしょうが、メインで担当する分野を決めるのは
いいと思います。しかし、余裕があるなら出来るだけの知識を共有しておくべきだと
思います。

> 業務知識に対して50の知識を持ち、クラスなどの設計に対して50の知識をもっているSEが二人で
50 の知識が丸々かぶってること前提ですか?かぶってなければ足して 100 になるのでは?
で、お互い 50 ずつだと取っ掛かりがあるのでお互いにフォローしやすいです。
100:0 だとフォローはできません。

引用返信 編集キー/
■20520 / inTopicNo.5)  Re[2]: SEに業務知識が必要か?
□投稿者/ ネタ好き (430回)-(2008/06/11(Wed) 16:07:29)
じゅで さんへ返信
私はシステムエンジニアという名前こそ不要で、プログラマが業務知識を持ち、要求定義から運用までこなさないとならないと思っております。ですから、敢えてシステムエンジニアというものを上流工程の人と定義するのならば、【業務知識は絶対必須】だと考えております。
私はひとまず会計の学習と実地で様々な業務を少しずつ学習し、OSからアプリまで一通り実装の練習をしております。システムエンジニアと言う名前に縛られず出来る限り全て学習しましょう。
とはいえ、勿論特定の領域を極める道もあると思います。
じゅで さんが自分のスキルをどのように売り込むかにかかっていると思います。

引用返信 編集キー/
■20521 / inTopicNo.6)  Re[2]: SEに業務知識が必要か?
□投稿者/ じゅで (39回)-(2008/06/11(Wed) 16:13:35)
No20517 (シャノン さん) に返信
> 同意します。
> ただし、その場合、依然として両者を「SE」という同じ名称で呼ぶべきなのでしょうか?

SEの定義がすごく広すぎると思います。
それが、逆に業界を混乱させてるような気がしてなりません。

> 後者は最近では「アーキテクト」と呼ばれることもあるようです。
> また、プログラミング言語を書かない作業でも、それに極めて近いレベルの設計はプログラマが担当すべきだと思います。

なるほど「アーキテクト」ですか。
いっその事完全に呼び方を分けてしまった方が良いと思います。
別々の事に特化していっているのですから。

また、プログラムに近い実装レベルでの設計は、SEとPGが協力してやるべきかと思っております。

No20517 (やじゅ さん) に返信

> システムエンジニアの定義が広すぎるんです。
> ある意味何でもやになってしまう。

おっしゃるとおりだと思います。
本当に広いです。
各客先によって、必要とされる技術が違いすぎるのに対して、呼称が一つしかないのが
非常に誤解を招きます。

人によっては、SEは業務知識をもって、お客様との折衝が出来なければならないと言う人もいれば、
いや、設計書がかけなければならない。それもクラス抽出などを行い、システム全体の構成を
設計できる必要がある。(機能設計とは別です。)という人も居ますし。

正直、そのような事は、現場、仕事によって違うだろうと思います。

No20515 (特攻隊長まるるう さん) に返信

> なんでもそうですが、一人の人が1つの分野の知識を独占してしまうと、
> その人が倒れたり、失敗したり、間違ったらそれで 0 になってしまいます。
> ヒューマンエラーをチェックできません。

申し訳ないです。
極端に書きすぎましたね。

たとえばこれを10人として考えて5人5人として考えていただければと思います。

> 50 の知識が丸々かぶってること前提ですか?かぶってなければ足して 100 になるのでは?
> で、お互い 50 ずつだと取っ掛かりがあるのでお互いにフォローしやすいです。
> 100:0 だとフォローはできません。

また、上の知識がかぶっているどうこうも、極論です。
ただ、実際に医療、法律、金融などの業務で、多岐にわたる知識が必要な場合に、
素人がかじった程度では、かぶっていない知識は、限りなく少なくなると考えております。

> プロジェクトの体制作りにもよるでしょうが、メインで担当する分野を決めるのは
> いいと思います。しかし、余裕があるなら出来るだけの知識を共有しておくべきだと
> 思います。

これは、非常に同意いたします。
ただ、前提は、自分のメイン分野が限りなく100に近い状態での事です。
これを50でやられた、ほかの知識は、広く浅くで20ずつみたいな事があると、
困ると思います。

引用返信 編集キー/
■20522 / inTopicNo.7)  Re[3]: SEに業務知識が必要か?
□投稿者/ じゅで (40回)-(2008/06/11(Wed) 16:15:47)
2008/06/11(Wed) 16:23:50 編集(投稿者)

No20520 (ネタ好き さん) に返信
> じゅで さんへ返信
> 私はシステムエンジニアという名前こそ不要で、プログラマが業務知識を持ち、要求定義から運用までこなさないとならないと思っております。ですから、敢えてシステムエンジニアというものを上流工程の人と定義するのならば、【業務知識は絶対必須】だと考えております。
> 私はひとまず会計の学習と実地で様々な業務を少しずつ学習し、OSからアプリまで一通り実装の練習をしております。システムエンジニアと言う名前に縛られず出来る限り全て学習しましょう。
> とはいえ、勿論特定の領域を極める道もあると思います。
> じゅで さんが自分のスキルをどのように売り込むかにかかっていると思います。
>

私としては、絶対的な一つの知識があり(業務にたいしてでも、実装にかんしてでもいいです)
その他知識として、広く浅くが理想と考えます。

何もかも中途半端な知識しかない人間に、何か仕事を任せても、出来上がってくるものは
中途半端なものしか出来上がってこないと考えているからです。

No20517 (やじゅ さん) に返信

HP見させていただきました。
やはり、必要な知識が多様化してきた今の時代に、何もかもひとくくりでSEという単語で
まとめてしまうのは、よくないと感じました。

やはり、各担当する業務毎に分けるべきですね。呼び方を。
引用返信 編集キー/
■20523 / inTopicNo.8)  Re[4]: SEに業務知識が必要か?
□投稿者/ ネタ好き (431回)-(2008/06/11(Wed) 16:23:40)
No20522 (じゅで さん) に返信
そういう考えもありだと思います。じゅでさんが企業や名前に縛られず、自分が思う理想の開発者を目指し、スキルを高める事が一番だと思います。
引用返信 編集キー/
■20525 / inTopicNo.9)  Re[5]: SEに業務知識が必要か?
□投稿者/ じゅで (41回)-(2008/06/11(Wed) 16:27:35)
No20523 (ネタ好き さん) に返信
> そういう考えもありだと思います。じゅでさんが企業や名前に縛られず、自分が思う理想の開発者を目指し、スキルを高める事が一番だと思います。

そうですよね、自分が10年後や20年後にどのようなスキルをもっていて、
どのような仕事をしたいのかを考えていくのが大切ですよね。

ちなみに、皆さんは将来的に、どのような知識を得たいと思います?
10年後の自分のスキルとして、何を目標においています?
やはり、色々な考えがあると思いますので、広く意見を募集したいです。
引用返信 編集キー/
■20526 / inTopicNo.10)  Re[6]: SEに業務知識が必要か?
□投稿者/ ネタ好き (432回)-(2008/06/11(Wed) 16:37:22)
> ちなみに、皆さんは将来的に、どのような知識を得たいと思います?
> 10年後の自分のスキルとして、何を目標においています?
> やはり、色々な考えがあると思いますので、広く意見を募集したいです。

私は情報処理技術を愛する変人ですから、自分用OSをフルスクラッチで作って、趣味でLinux、Windows、FreeBSDとかと自分のOSと見比べつつ「くそーWindowsのこの機能が欲しいぜ。よし、実装だ。Linuxのこの機能が欲しい、よし実装だ。」と鑑賞とプログラミングに浸りたいと思っています。
ですから、OS実装、DBMS実装、プロトコル実装、コンパイラ実装、アプリ実装が出来て、お客の要望に応じてお客様専用OSを作れるような「名匠」になりたいです。そして勿論何か一つは世界一になりたいです。私はとくかく情報処理技術を溺愛しているので他人の参考にならないと思いますw
引用返信 編集キー/
■20527 / inTopicNo.11)  Re[7]: SEに業務知識が必要か?
□投稿者/ シャノン (472回)-(2008/06/11(Wed) 17:30:32)
No20526 (ネタ好き さん) に返信
>>ちなみに、皆さんは将来的に、どのような知識を得たいと思います?
>>10年後の自分のスキルとして、何を目標においています?
>>やはり、色々な考えがあると思いますので、広く意見を募集したいです。
>
> 私は情報処理技術を愛する変人ですから、自分用OSをフルスクラッチで作って、趣味でLinux、Windows、FreeBSDとかと自分のOSと見比べつつ「くそーWindowsのこの機能が欲しいぜ。よし、実装だ。Linuxのこの機能が欲しい、よし実装だ。」と鑑賞とプログラミングに浸りたいと思っています。
> ですから、OS実装、DBMS実装、プロトコル実装、コンパイラ実装、アプリ実装が出来て、お客の要望に応じてお客様専用OSを作れるような「名匠」になりたいです。そして勿論何か一つは世界一になりたいです。私はとくかく情報処理技術を溺愛しているので他人の参考にならないと思いますw

ハードウェアも自力で作らねば気がすまなくて、そいつを動かすのに他人が発電した商用電源なんか使うのは嫌なので発電機も発電メカニズムも自作して…

そして彼は宇宙までをも創造してしまったという。
引用返信 編集キー/
■20529 / inTopicNo.12)  Re[8]: SEに業務知識が必要か?
□投稿者/ ネタ好き (433回)-(2008/06/11(Wed) 17:49:37)
No20527 (シャノン さん) に返信
シャノンさんナイスです。「そして彼は宇宙までをも創造してしまったという。」このくだりがセンスを感じます。
確かに私はハードウェアも気になるんですよねw
でも、ハードウェアはCPUとか自宅で作れないから除外する事にしてます。
私の手の届く範囲は「OS実装、DBMS実装、プロトコル実装、コンパイラ実装、アプリ実装」ですね。
ひとまずOSは動く程度まで作れますし、DBMSはSQLぐらいならなんとか、プロトコル実装はまだやった事無し、コンパイラ実装についてはなんちゃってC・なんちゃってLisp・なんちゃってPrologは作った事があります。他にも人工知能とデバッガも自作した事があります。だから私は本気です。
でもハッカーに勝つためには機械語レベルの理解が必要なので、今機械語を勉強しているところです。
その様子は、http://indori.blog32.fc2.com/で書いてあります。
来てね。
引用返信 編集キー/
■20534 / inTopicNo.13)  Re[7]: SEに業務知識が必要か?
□投稿者/ じゅで (42回)-(2008/06/11(Wed) 19:38:30)
No20526 (ネタ好き さん) に返信
> 私は情報処理技術を愛する変人ですから、自分用OSをフルスクラッチで作って、趣味でLinux、Windows、FreeBSDとかと自分のOSと見比べつつ「くそーWindowsのこの機能が欲しいぜ。よし、実装だ。Linuxのこの機能が欲しい、よし実装だ。」と鑑賞とプログラミングに浸りたいと思っています。

この未来図は、かなり素敵だと思います。
実際仕事として考えるよりも、楽しみとしてやれる方が、良いと思いますので。
ここまで出来るようになると、それはそれで本当にプログラムがたのしいのでしょうね。
引用返信 編集キー/
■20535 / inTopicNo.14)  Re[8]: SEに業務知識が必要か?
□投稿者/ 出水 (71回)-(2008/06/11(Wed) 21:20:55)
現場から見れば足りない知識を持つ人材が欲しいわけで、
それが何かなんてのはケースバイケースで、絶対的な軸なんてないわけです。

で、敢えて必要な物といえば、人を見極める眼だと思います。
知っている人を知っていれば仕事としては解決なんじゃないかなぁと。
まぁ、それを見極める程度の知識は必要ですけど。

自分の知識外の仕事を振られたとき、必死に勉強してやりこなすよりは
得意な人を見つけてその人の雑用的な仕事と交換したほうが、
時間もかからないし、なによりチームとしての品質が上がるんです。

という、向上心0スタイルもいいんじゃないかと。
引用返信 編集キー/
■20537 / inTopicNo.15)  Re[9]: SEに業務知識が必要か?
□投稿者/ じゅで (43回)-(2008/06/12(Thu) 07:10:37)
No20535 (出水 さん) に返信
> という、向上心0スタイルもいいんじゃないかと。

向上心0というよりも、向上心を向ける先が違っていて当たり前で、
それをうまく要員計画して、プロジェクトをまわした方が品質が上がるのでは?
という感じです。

お客様が望んでいる物を作るのに、向上心という名の勉強としょうして、
業務知識を学びながらつくり、出来上がる物が不良品でしたが、
とりあえず納品しておきましたというのは違うのかなと思っております。

なんで、スペシャリストのチーム単位で、DBスペシャリスト、プログラムスペシャリスト、
と同じレベルで、機能設計のスペシャリストなどのチームがあり、
プロジェクトにあわせて、要員計画を行うPMはPMOなどがあって
良いのかなと考えております。

とりあえず、お客様からみたら、向上心があろうがなかろうが、品質が良い物がほしと思うので。
これが、向上心をかって、不良品でも買いますよといって、それで全てが丸く収まるなら、
それはそれで、お客様が満足されているので、ありだと思いますが。

引用返信 編集キー/


トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

管理者用

- Child Tree -