ソフトウェア工学教育の全体像

saltheads @saltheads

@zacky1972 ソフトウェア工学全体を教えるのですね。全体の中のどの分野を学ぶのか意識付けさせるのにもシラバスに知識体系の軸をおいてみてはいかがでしょう。

Susumu Yamazaki (ZACKY) @zacky1972

@saltheads そのアイデアは，全体像が伝わるので，とてもいいですね！ 知識体系をイメージ化するには，具体的にどうすればいいでしょうか？

saltheads @saltheads

@zacky1972 ありがちな軸ですと、技術管理の軸と、仕様事例の軸で4つに分けた、開発方法論、開発プロセス、リファレンス、プラクティスの4分類。どの分野もしっかり学びたい。

saltheads @saltheads

@zacky1972 開発方法論では、構造化設計がすべての基本であり、OS、並行化はUML書けないけど大切、カプセル化からOO、要求を見える化とモデルから自動化するためにUML、可変性を見つけてPLまで。

saltheads @saltheads

@zacky1972 開発プロセスでは、実はコンピュータ向かってもくもくやってるあなた一人ではソフトをうまく作れないこと、手順や進め方、成果物がどうなってるか見えるようにする大切さ。QCD大切。

Susumu Yamazaki (ZACKY) @zacky1972

@saltheads 1つ1つ整理させてください．技術と管理が対立概念である軸と，仕様と事例が対立概念である軸の，2軸ということですね？ このうち仕様と事例が対立概念であるというのが，今ひとつピンと来ないのですが．

saltheads @saltheads

@zacky1972 リファレンスでは、ソフトは過去の経験から学んで無駄な再発明しないものであること、先人が苦労して発見した原理原則、よい設計から学ぶことの大切さ。そして自分の経験を次に残すことの大切さ。

saltheads @saltheads

@zacky1972 プラクティスでは、具体的にどう実施してゆくのか、良い取り組みをリーダーとしてどうやって他の人に伝えてゆけばいいか。良い設計をみんなができるようにするには、どうすれば良いだろうか。

saltheads @saltheads

@zacky1972 また、機械にちゃんと仕事をさせるための工学と、人の考えていることを理解するための工学の軸があると思います。後者はコミュニケーションの技術であり、他人の要望を聞き、自分の表現に変え、機械も理解でき、どうしてそれでうまくいくのかまた他人に理解してもらう技術。

三浦　元 @MIURA_Hajime

@saltheads 少ない経験ですが、学生さんにレビューのチェックポイントを示してからレビューしてもらっても、その提示を無視して自己流に走ってました。たぶん、Howにばかり目がいっていたのでしょう。方法論の意義の理解（覚える、のひとつ先）は重要。

三浦　元 @MIURA_Hajime

@zacky1972 技術と管理は対立軸では無いと考えます。私はいつも「管理はエンジニアリングのためのエンジニアリング」と言っていますが、成果を得るための、相補的なものかと。

三浦　元 @MIURA_Hajime

@saltheads 知識体系ってのは「俯瞰」ですね。マップを示すことはとても良いとおもいます。

三浦　元 @MIURA_Hajime

@zacky1972 SESSAMEのサイトに知識体系のドキュメントがありますよ。管理技術は入っていませんが。

三浦　元 @MIURA_Hajime

@zacky1972 管理についておおざっぱに俯瞰したもの（短いですが）を後ほど直送しますね。

Tachi_4423 @Tachi_4423

昔，エライひとに「モノはカンリで作るんだ」と言われました．

Tachi_4423 @Tachi_4423

当時はもっと青くて，ケッて思った（笑）ですが，少し大人になってその言葉の意味が分かったような気がします．

三浦　元 @MIURA_Hajime

@neutrinobeam カンリだけで作るかと言うと・・・？まぁたしかに正規分布の幅をいかに狭く維持するかはカンリだけれどね。これは製造カンリ。ソフト開発管理はこれだけにあらず、だね。

@neutrinobeam

@MIURA_Hajime その通りと思います．たぶんそのエライ方は，局所技術一辺倒な若者を見て，ある意味「俯瞰」の大切さを対極的比喩で教えてくださったんだと思っているんです．

Tachi_4423 @Tachi_4423

実は「わかってない」管理おやじだっただけなのかもしれないですがwww

Tachi_4423 @Tachi_4423

管理と技術，研究と開発．このあたりで教育（学習）課題のマトリクスとかできないかなあ．

あきやま🐯 @akiyama924

@neutrinobeam 管理と技術は、マトリクス関係にあるのではなく一つの軸上にあって左右に触れながら上達していくようなものだと考えています。研究と開発は全く狙いが違うものですね。

あきやま🐯 @akiyama924

今気がついたけど、だから私は管理と技術を分けるのが嫌なんだな。QT akiyama924 @neutrinobeam 管理と技術はマトリクス関係にあるのではなく一つの軸上にあって左右に触れながら上達していくようなものだと考えています。研究と開発は全く狙いが違うものですね。

三浦　元 @MIURA_Hajime

@neutrinobeam そやね。管理と技術マトリクスでクロスする（管理&&技術）領域はさしあたりPBLが有効か。このあいだ、社会人チームに混ざって学生さんだけのチームがPBLやったけれど面白かったですよ（はらはら、どきどき）。

Tachi_4423 @Tachi_4423

@akiyama924 はい，管理と技術は対極に置くのはまずいのかもです．ただ，歳取っても純粋に技術を追求したいひとの方向があっていいんじゃないかって思っただけなんです．それは研究（の方向）と同じとは言えないですよね．．

Tachi_4423 @Tachi_4423

@akiyama924 それで，技術・管理軸と開発・研究軸の２次元を考えて，若者や経験者に限らず，次に目指したい象限には（自分にとって）何が必要かがある程度明示できるといいかなあとふと思ったと言う次第なんです