文章の濃度

文章には濃度がある。濃厚なものは味わいが深いが解釈に予備知識を必要とし読み下すのに手間がかかる。一方薄いものはさらさらと読めるが、本質には影響を与えないような枝葉が数多く含まれる。

小説として楽しむなら薄い方がよい。ちょうど主食として常食する材料がどれも薄味であるのと同じだ。
一方、記録や智恵の書の場合は、濃い記述になっている。これは言葉を凝縮していることによる。

例：
濃い文章
　法王アレッサンドラ６世の死後、ジュリオ２世により囚われの身となったチェーザレ・ボルジアが逃亡した先はシャルロットの兄であるナヴァーラ国王の元であり、パンプローナから自由宣言が発せられた。

薄い文章
　チェーザレ・ボルジアの父である法王アレッサンドラ６世(ロドリーゴ・ボルジア)がローマにおいて死去したまさにその時、チェーザレ自身も生死をさまよう重病であった。続く法王ピオ３世はチェーザレに同情的であったが即位から１ヶ月もたたずに世を去ってしまう。その後、チェーザレは最大の誤りを犯すことになる。ボルジアに煮え湯を飲まされてきたローヴェレ枢機卿の法王就任に対して手を貸してしまったのだ。ジュリオ２世として即位した新法王は、チェーザレを破滅されることを画策し、ボルジア家の故郷でもあるスペインへの軍務を餌にして誘い出し、幽閉することにも成功する。しかし、スペイン王家の内紛に乗じて逃亡したチェーザレは、フランスに残してある妻シャルロット・ダルブレの兄であるナヴァーラ国王の元へとたどり着き、自由の身となることができた。ナヴァーラ王国はフランスとスペインの国境近くにあり、その首都パンプローナからイタリアの各地へとチェーザレの自由宣言の手紙が発せられた。

開発方法

大きな流れとしては「要件定義、分析、設計、製造、テスト、配備、運用」となるのだが、
構造化にしろ、OOにしろ、DOにしろ、いまいちしっくり来ない感じがしていた。

ベストプラクティスとしての方法を紹介するというスタンスであって、
論理的でない部分が多かったように思う。
今にして思えば、論理的に説明するための基礎が不足していたからではないだろうか？

そこで、いくつかの素案をメモしておく；

・要件定義：実現したいシステムを表現したもの(単なる要望でなく、実現基準を持つ)
・分析：モヤモヤしている要件を複数の次元に分解して詳細を明らかにしたもの
　　例）業務機能、基盤機能、性能、システム把握、運用性、操作性、、、
・設計：上記の複数次元からなら定義を１つのシステムとして実現(実装、運用)できるような要素に分解し、その作成の筋道を明らかにしたもの
・製造：設計指示をもとに実行できるコードを生成し、単体レベルテストを実施する
・テスト：システム全体の要求を満たすかのテスト
・配備：実際の運用環境に適用する
・運用：

■トレーサビリティ

システム開発で分析や設計に力をいれるのは、トレーサビリティを確保するためだと思うようになった。
というのは、実際のシステム運用において、障害が発生したり拡張要求が発生した場合に大元の要件と対応する実現物(コードなど)の対応がとれないことが多く、これがシステムの理解を悪化させているのではないかと思えたからだ。トレーサブルでないシステム(これが大半だと思うが)では、システムの現状に関して信頼できる資料は実際に動作しているコードのみとなる。要件とコードの対応がつかないのでは当然である。

しかし、トレーサブルでないことがデファクトとなっているシステムをトレーサブルなものにすることができるのであろうか？これに対する構想を以下に述べる；

■現在使用可能なトレーサブル

たとえば、DBのテーブルやOOのEntity定義などはほぼ完全にトレーサブルと言える。要件として、「これ、これ、これ」と指定された項目をまとめて管理するという枠組みは非常にシンプルであり、正規化などで形式が変わってみていても上流の定義に戻すことは容易である。つまり、下記のような双方向変換が容易にできる。

データ定義　＜＝＞ モデル ＜＝＞ コード

■モデリングの限界

UMLなどのモデリングでは、なんでも出来そうに思われるが、それは上記のデータ構造に関してであり、動的な側面の記述という観点からは、基本的に用意された定義だけを使っている限り意外と表現力が乏しいと感じる；

例えば、簡単は電卓の動作をUMLだけで記述することが出来るであろうか？ 特にNキーロールオーバのような複数同時実行する場合の挙動を記述するのは簡単ではない；さらに、それが出来たとしても、そこから何らかの言語への変換が出来るであろうか？ 既存の変換ツールは状態変化(ステート図)を対応するクラスの挙動に変換するという極めて狭い領域をカバーするものが多いと感じる(すべてを見たわけではないのだが、、、)

■代替えとしてのDSL

では、UML以外のモデリングとして何が考えられるであろうか？ それはDSLだと考えている。
UMLで特定のDSLを記述することができれば間接的にUMLで表記したことにはなるが、そこにこだわる必要性を今は感じない。

例えば、機能表現に特化したDSLでシステム要件の機能部分を分析し、性能に特化したDSLでシステム性能要件と記述するという形にすれば、分析作業とは「システム要件をM次元の直交要素に分解しそれを固有のDSLで記述すること」と考えることができる。

さらに、設計は記述されたDSL要素から実現コードへのコンバータの生成(定義)と捉えることができる；
DSLをテストフレンドリにしておけば、生成されたコードをDSLを使用してそのままテストすることができ、要件が変わってDSLを書き換えたらテストまで自動で流すことができるようになる。

要件 ＜＝＞ M次のDSL記述 ＜＝＞ 実行コード

■開発作業の変化

DSLを中心に捉えてみると、システム開発作業は以下のような形にすることができる；

１）要件定義：聞き取りと文書化
２）DSL作成
３）コンバータ開発
４）生成、テスト
５）システムテスト

DSL作成の中でもUI部分やデータ定義などで分業できる要素があり、コンバータ部分は開発会社の強みとして自社で抱え、システムテストは人件費の安いところに外注するという工程も成り立つと思う。

そのためには、DSL ＝＞システムテスト という生成ツールが欲しいところである。

教材開発指針

自分の得意な形式にする

■トラブル解決型学習
・トラブルが発生し、その解決を通して学習する
・流れの一例
１）導入：イラスト、アニメーションなど
　状況説明：場所や組織、自分の役割、発生している現象、これまでの経緯など
２）ディスカッション：グループ分け、発表
　目的の確認：何の為に行動するのか、なぜそう思うか
　調査方針の作成：何をどこまで進めるか、役割は何か、何を仮定するか
３）資料の収集：グループ作業
　何を集めるべきか、なぜか、何をすれば集まるか
　誰、何の力を借りるべきか
４）分析、考察：
　どこに着目するか、どこの統計処理をすべきか
　何が分かるか、何が不足しているか、
　仮定との食い違いはないか、説明できうるか
　さらに調査が必要か、
５）整理と報告：グループ発表
　調査の経緯と収集した資料、分析・考察の結果と結論

アイデアソン

ログビューワ：
　縦横で設定した範囲の折りたたみができる
　例）左端から、XXのカラムまでを折り畳む
　例）XXサーバに関するログの行を折り畳む

作業表に入れる項目：
　日付、目的、完了基準、消費時間
　指示(6W2H)、リソース(機材、ソフト)
　作業環境(H/W, O/S, N/W,,,)
　意見や感想

半透明の看板：
　景色を遮断しないで広告をだせる

自動糸通し：
　糸側と穴側の双方が自走して相手を捜してつなげる＝＞狭い場所での配線

ピンポイントヒートガン：
　ピンポイントで高熱の空気を発射できる
　ドライヤーのように広範囲に熱を拡散しないで加熱処理ができる

IDバンク：
　共通モバイルクーポン
　1回登録すると、複数のショップで使用できる

スキルマップ：
　クイズに答えて作成する
　知識：事実を確認できる
　理解：メタ情報をTPOに合わせて選択できる
　技術：一定の時間内で水準を満たす作業ができる
　表現：伝達、説明できる

セキュリティブリッジ：
　FireWallで守られた２つのドメインを結合するDMZサーバ
　一切の発信接続を禁止して、必要な業務処理を実行できる

ソフトの開発とは；
　DSLを作成すること
　DSLとDSL間の解釈器を作成すること

無騒音発電機：
　燃料電池で発電するので、モータを使用しない

寿命とは：
　壊れそうも無いものが寿命を迎える理由は？

グレゴリオ暦の１月１日は自然科学的な意味があるのか：
　どうもなさそう、ローマは法治主義でカレンダー(ローマ時代は月初日のこと)は恣意的にきめられた

音による位置合わせ器：
　縦横高さを音で表現して離れた物体の位置的な同期を容易にする

局所と大局：
　局所の最適より大局の最適をもとめるべき