前エントリの続きで、「業務システム開発学科」の単元を挙げてみる。
これがないと作れないという要素をボトムアップ（上流・下流からいくとボトムではないけど）で挙げていったつもり。（「エンタープライズ・コンピューティング学科」は要らぬ誤解を招きそうなので、止めておく。）
やりたいこと・やるべきことを決める (Why/Whom/What)
- 現状のヒアリング
- 理想形のヒアリング
- 目的の確認
- 誰が使うのか
- どのようなものを作るのか
計画を立てる (When/Where/Who/How much/How)
- スコープを決める
- 実現方法の検討
- 見積り
- スケジュールを決める
- 担当を決める
道具を知る (How)
- コンピュータサイエンスの基礎 (設計しテストするのもプログラミングの一部としてここに入る)
- ネットワークの基礎
- コンピュータアーキテクチャの基礎
- OS の基礎
- RDB の基礎
- アプリケーションのための製品知識・技術 (programming languages, VMWare, HULFT, JP1, JCL, ABAP, ApacheHTTPD, WAS, BIG-IP, Tomcat, OracleDBMS, Sybase, DB2, SQL Server, ActiveDirectory, Visual Studio, Eclipse, etc...)
ということで、ぼくが書くと業務知識は入らない。異論反論多そな内容だなぁ。
あ、金融系などで計算系のシステムをやるなら数式の意味を理解できる程度の数学の知識っていうのはあるかもしれない。対数？微分？わかりません（＞＜）とかだと困るだろうから。（数式読めるってこと。数式発明する必要はない。）
あとは日々のチーム運営だとか、これだけだと契約を取ってこれないから営業面を強化すべきとか思想信条によってご意見があることでしょうが、「業務システム開発学科」だとやはりこれかなぁと思う。
迷いがあったのはユーザビリティとセキュリティ。ただ、これも上記を目的を見失わずに学べば十分にカバーされると思い、個別には挙げなかった。
それから、これは非常に重要なのだけど結果としてはコンピュータサイエンスに集約されると思うので挙げなかったのが「ドメインに見られる変化のボトルネックを抽象化するスキル」。これは・・・面倒だから説明は端折る。
最後に、主張したいのは「業務知識要らない！」ってことではなくて、「業務知識偏重 or 製品知識偏重はかえって危険ですよ」ってこと。そりゃ、無いよりはあったほうがいいですよ。念のため。