設計学？その三。

東大の先生が提唱している設計学のページがありました。
皆さんの設計業務の再考にお役立てください。

http://www.race.u-tokyo.ac.jp/~takeda/designtheory-j.html

設計学？その二。

思い出しました。

行き当たりばったりはよくない。
計画、設計は、大切だということに気づいた
という話でした。

まぁ、設計しろと言われても
どこまで設計できんだよ！という話で。

そんな設計時点では、はっきりしていなくて、
決めらんないこともありますよね～。

そいうときは、ある程度抽象的なレベルでの
設計になっていいはずですよね！

それに設計したよ！って渡されても、
その設計の内容がいまいち良くわかんない
こともあります。

それは設計者が実装者にちゃんと
伝えなきゃいけないと思うのですよ。。。

。。。。そんな話です。

設計学？その一。

一品香でラーメンを食べていた思ったことがありました。
どこかに記録しておかないと忘れるのでここに
残します。

もし皆さんもこのテーマについて、意見がありましたら
書き込みをお願いします。

何年か前、ITアーキテクトという雑誌がありました。
JavWorld がインターネットの普及で売れなくなったのか
IDG（だったかな？）が発行を始めたものです。

その雑誌も時が流れて、今はなくなり（だったかな？）
ITアーキテクトと言う言葉だけが、私の記憶の片隅に
存在していました。

IT の建築家？そりゃ分かるけど。。どういう意味？

そのときの私の理解は、情報システムを構築する
基盤を設計する人のこと。。。。

確かに情報システムは、度重なる変更にも耐えうる
アーキテクチャが必要だと言うのは、わかります。

-------

設計をするときにそのシステムの変更可能性についての
要求は、あまりはっきりせずにシステム化することは
多いのではないでしょうか？

今は、オブジェクト指向が普及しているので
クラスの継承によって、新しい振る舞いの
プログラムを安全に追加できる仕組みができてきました。

-------

プログラムの変更が安全にできるかどうかは、
プログラム変更者がそのプログラムの構造を理解しているか
によるのではないでしょうか？

ある部分への変更が他の箇所へ影響しないことも
必要かもしれません。（情報の隠蔽、カプセル化）

-------

あと早くプログラムを作ることも要求されがちです。

早く作ると言うことは、その分、コストが下がり
顧客の必要なそのときに必要なシステムを提供する
ことができます。

-------

プログラムを作るうえで規約やルールに
従順であることは。。。規約やルールを作り出すことにも
創造性が発揮されるのではないでしょうか？

ルールや規約に柔軟に対応できると言うことは
ルールや規約に縛られているようでも
実は、ルールや規約から自由なのではないでしょうか？

-------

設計やプログラミングをしていて、
うちの会社はこういうやり方があるから。。。とか
うちの会社の習慣だからという理由で
実装が決まったりすることがあるように
思います。

たとえば某ＳＩのシステムでは、
理由が分からないですが、データベースにメニュー項目を
持たせます。

一見、何でそんなことをするのかと問いたくなります。

今回のシステムでそれほど頻繁にメニューの追加や削除が
あるのでしょうか？

システムの実装の習慣を引継ぐことは、
本当に変更に強いシステムになるのでしょうか？

そんな時、システムのアーキテクトが必要だと感じます。

---------

なんか大事なことを忘れた。。。。。気がする。

進捗管理が難しいという管理者の根本的な問題。

私は、プログラミング作業の進捗は、プログラマにしか
分からないと言っていいのではないかと思う。

よく進捗管理は、難しいという管理者がいるが、その人が、
Java プログラマでなければ、Java の開発プロジェクトの
進捗は、把握できないと思う。

まず、なにか問題があっても、プログラマでなければ、
問題の難しさも分からないし、原因も分からないと思う。

マイクロソフトは、プログラマでなければ、管理者には、
なれないとも言われている。

顧客要求管理表を作りましょう～！

あるプロジェクトで顧客要求管理表を作っておけばよかったと
プロジェクトの終盤になって、後悔した。

どういう風に後悔したのかは、もう覚えていない。

本当は、顧客からの要求は、書面以外では、受け付けない！方が
いいのではないかと思う。

口頭でどこそこをこうしてくれと、顧客は、思いつきで
好きなことを言うが、それにいちいち振り回されていたのでは、
システムの開発プロジェクトなんて、進捗するはずない。

要求事項を書面で受け付けて、それを管理表にして、
要求事項の実装可否を顧客と共有すれば、
言った言わないで喧嘩になることもないのでは、ないだろうか？

顧客要求は、プログラマが設計を理解するうえでも
重要な資料になります。

これからは、どんなプロジェクトでも
顧客要求管理表を作って、
顧客要求の明確化、共有化を行いたいですね。

ある生徒さんの話。

その生徒さんは、パソコンを使ったことがない。

今回の授業で初めてパソコンを覚えている。

見ていると、教えたいろいろな操作をしないで

自分なりのやり方で課題をこなしている。

それを見て、「この人は、難しいことをしたく

ないんだな。。。」ということを思った。

確かに学ぶスピードは、ひとそれぞれで、

自分で好きなペースで学べばよいと思う。

でも、集合研修の現在では、個人の好きな

ペースで学ぶということができない。

みんなに同じように教えて、同じことが

できることを要求する。

果たして。。これでよいのだろうか。。？

今日からは、Excel の授業です。

今日からは、Excel の授業です。

基本は、そんなに難しくないと思うのだけど、

うまく伝わるかなぁ～。