TRICHORDは可愛い(^o^)

　今のプロジェクトで、TRICHORDのニコニコカレンダーを使っている。
　帰り間際に１日の気分をニコニコカレンダーへ書くだけで、特にプロジェクト管理へフィードバックすることを意識しているわけではない。
　元々、プロジェクトから出る黄信号をキャッチしたい、というのがそもそもの動機だったらしい。
　でも、書いてて楽しい。

　ニコニコカレンダーを書いている時、事務の女性が見て、すごく可愛いツールですね♪と言っていた。
　３種類のアイコンがいい。

　ＩＴ企業といえば、大部屋の壁に「今期の業務目標」「今期の目標は品質強化だ！」とかいう貼り紙があって、それを見るたびに気持ちが何故か萎えてしまう。
＃品質なんてどの企業もボロボロでしょ。

　もうちょっと癒し系グッズがあってもいいのでは？とか思ってしまう。
　TRICHORDの機能は豊富すぎて使いこなせてないけれど、人を和ませてくれる雰囲気がある。

プログラミングは「ブロックを組み合わせる」感覚に似ている

　若い開発者に僕が書いた設計書を説明後、プログラムをJSPから書き始めるのか、それともServletから書き始めるのか、聞いてきた。
　僕は、まずJSPを動かしてからServletを書いたら、と言ったら、コンパイルエラーばかりで全く進まない。
　僕の意図は、JSPやServletを確実に動かしながら、fakeした機能を一つずつ実装していけばいいだろ、ということだった。
　結局、若い開発者にValueObjectからボトムアップで書かせたら、コンパイルエラーもなくなり、ようやく書けた。

　プログラムを書く時、トップダウンから始めるか、それとも、ボトムアップから始めるか？
　ＰＧやＳＥなら一度は、はまった経験があると思う。

【１】プログラミングとは、機能を組み合わせていくこと

　ＩＴ業界に入った時、先輩から、「プログラマは数学者とは違った能力を要求される。機能を組み立てる感覚が大事だ」と言われた事がある。

　プログラミングとは、小さな部品(モジュール)を別の部品からコールして、メインプログラムを作っていくこと。
　その時に、データ構造とかアルゴリズムなどの数学的知識はあった方が良いが、それよりも、機能を実現するために、数多くのモジュールを組み合わせて整合性を合わせるのが大事。

　Perl関西で知り合ったプログラマが「Perlの面白さはCPANモジュールを組み合わせる所にあるんです」と言っていたのが印象的だった。

　これはまさにボトムアップからのプログラミングの感覚。

【２】テスト駆動ツールがあれば、トップダウンのプログラミングは可能

　ボトムアップのプログラミングで怖いのは、作った小さなモジュールが正しく動かないまま、メインプログラムを実装して動かないこと。

　でも、JUnitなどのテスト駆動ツールを使えば、モジュールが小さいほどテストしやすく、品質も良くなる。
　逆にテスト駆動ツールがあるならば、トップダウンでインターフェイスを定めながら、仕様が不明な機能はfakeしながら実装できる。

　ボトムアップのプログラミングの弱点は、細部にこだわりすぎて、実現する機能をインターフェイスとして考えられなくなること。
　テスト駆動ツールを使えば、その弱点を補うことが出来る。

【３】設計者はトップダウンで要求を仕様化していく

　設計者の仕事は、あやふやな要求を仕様として落としていくことにある。
　つまり、要求から大まかな機能を洗い出し、その整合性を取りながら、機能を矛盾なく実現できるレベルまで細分化していく。

　設計者の頭の中では、機能をInputとOutputのペアで考え、ひたすらそのペアの連鎖で全ての機能が矛盾なく動くか、ロジックを組み立てる。
　つまり、どう実現するかというHowよりも、何を実現するかというWhatを重視している。

　そして設計手法は、自然にオブジェクト指向設計になる。
　機能をオブジェクトに見立てて、メッセージを送ったら、自分が何をするか知っているから期待した結果を返す。
　そのオブジェクトを整合性を保持したまま協調動作できるか？という考えをずっと突き進めるだけ。
　これは、トップダウンで仕様を煮詰めていき、最終的にインターフェイスを決めるまで突き進めることと同じ。

　オブジェクト指向設計の良い所は、メッセージ送信という発想によってInputとOutputの関係だけに注力できることと、実現できるかどうかというHowの部分をカプセル化して設計を先に進めることができること。

　トップダウン設計では、要求から仕様へ落とし、最終的にはクラス図へ落とす。その時点で、ほぼ設計は出来上がる。
　クラス図ができれば、実装は単なる機械的作業にすぎない。

【４】WhyとWhatとHowの関係

　Howを考えるのは、実装であり、プログラマのお仕事。
　Whatを考えるのは、仕様であり、ＳＥのお仕事。

　Whatを洗い出す時、要求の理由や背景を考えた方が良い時がある。
　つまり、何故そんな機能が必要なのか、をぶつけていくと、そもそもそんな機能は必要ではなかったとか、実は別の本質的な機能が必要だった、ということもありうる。

　要件定義とは、Whatで考えるために、Whyをどれだけお客から引き出せるか、という技術を要求しているのだろう。

【５】プログラミングの楽しさはモジュールの組み立てにある

　プログラミングの楽しさは、少年時代に積み木やブロックで好きなように組み立てた経験に似ている。
　そして、その組み立てた物は、実はすごく脆い。
　ほんの少しバランスが崩れただけで、全部壊れてしまう時だってある。
　その辺りのハラハラドキドキ感が楽しいのかもしれない。

　デスマーチではハラハラドキドキしたくないけどね(^^)

HCPチャートって何？

　要件から仕様を確定していくと、オブジェクト指向であろうが、構造化設計であろうが、どうしてもフローチャートのようなものを描かざるを得ない時がある。
　シーケンス図は、横長になりやすく読みにくい。
　オブジェクトをそもそも洗い出せていない時は、シーケンス図は使えない。
　アクティビティ図も、アクティビティに入れる文章が長くなると、読みにくくなる。
　
　そんな時に、HCPチャートという図法がある。

【問い】
　HCPチャートって何？

【答え】
　HCPチャート（Hierarchical ComPact description chart）とは、日本電信電話公社（現NTT）の横須賀電気通信研究所で開発されたプログラム設計図法である。

　以前の設計図法（フローチャートなど）と比較すると、次のような特徴がある。

・処理の階層的な記述が可能。
・データと処理の関係を明記しやすい。
・フリーハンドでも比較的書きやすい。
・フローチャートのように枠の中に説明を入れるのでなく、HCPチャートでは記号の近くに説明を入れるので、1枚の用紙に多くの内容を盛り込むことが容易である。

　元々、組み込み系でよく使われているらしい。

【感想】
　単なるフローチャートに過ぎないが、シーケンス図に比べて縦長になるので、描きやすく、印刷しやすい。

　つまり、アーキテクチャを考えた設計では、一つの機能は、複数のオブジェクトに階段状にメッセージ送信されてゆくため、横長になりやすい。
　ＨＣＰチャートでは、呼び出し元を別の線で書くため、縦長になりやすい。
　更に、ＩＦ文や繰り返しの処理を細かく書いた時、縦長に書きやすい。

　こんなツール「HCP作成プロジェクト」もあるらしい。
　丁度、ＵＭＬお手軽ツールUMLmemoに似ている。

A-AUTO って何？

【問い】
　メインフレームだけでなくオープン系システムでも、UnixのcronやWindowsのタスクスケジューラのようなジョブのスケジューリング機能はある。
　それをもっと高度化し、ジョブ管理システム、つまり、バッチ処理システムとして使える製品は、メインフレームやオープン系システムに限らず汎用的に使えるものはあるか？

【答え】
　回答の一つに、A-AUTOがある。

【解説】
　株式会社ビーエスピーのA-AUTOは、メインフレームからUNIX、Windows、そしてLinuxに至る各種サーバーにおける統合的な、 ジョブのスケジュール管理を実現するソフトウェアです。
　メインフレームとオープン系システムとのジョブ連携を含めたジョブスケジューリングのツールとして、メインフレーム系で普及している。
　他の同種ツールと機能面では大きな違いがないのだが、他のツールが特定ベンダーのメインフレームに対応しているのに対し、A-AUTOはメインフレームではMVS、MSP、VOS3、XSPに対応するほか、オープン系のプラットフォーム各種でも利用できることで人気がある。

【感想】

　大規模ＥＲＰならば、オンライン処理だけでなく必ずバッチ処理が組み込まれている。
(例：月末の締め日に計上する、月初に集計結果を経営陣に報告する、など)

　普通は、Ｗｅｂなどオンラインで業務データをかき集めて、計上する日の近くで、大量データをバッチ処理で集計加工する事が多い。

　バッチ処理システムは、複数のジョブが順番に正常に動いて、初めて結果が得られる。
　途中で異常終了した場合、一連の処理が業務に悪影響を及ぼさないように、アーキテクチャ上の設計だけでなく、業務でも設計しておく必要がある。
　A-Autoでは、一連のジョブを業務フローとして一目で見れるようなツールがあり、非常に便利。

HULFTって何？

　今の世の中、オープン系システム開発が流行しているが、特に、金融やミッションクリティカルな業務では、全く異質のシステム、メインフレームが世の中にはたくさんある。

　メインフレームとオープン系業務システムのファイル送信をシームレスにつなぐためのアーキテクチャとして、例えば、ＩＢＭのMQシリーズなどがあるが、HUFT送信というアーキテクチャもある。

【問い】
HULFTって何？

【答え】
読み方 ： ハルフト
フルスペル ： Host Unix Linkage File Transfer
セゾン情報システムズが開発したファイル転送ソフト。企業内・企業間の業務システムにおいて、日常のシステム運用で発生するデータ連携を自動化するツールである。

　メインフレーム、UNIX、Windowsなど、多様なプラットフォーム間で、大量のデータを確実に集配信することができ、LANやインターネット、ダイヤルアップなど様々なネットワーク環境に対応する。

　業務システムの基盤として使えるように、文字コード変換機能や、転送が異常終了した場合のリカバリー機能、帯域を占有しないための間欠転送、複数ファイルの一括転送、複数拠点への同報配信、複数拠点からの同時集信など、多彩な機能を備える。

【感想】
　重要なデータをバイナリファイルで確実に配信したり、逆に集信する時に使われる。
　特に、Unixとメインフレームとの間の送受信で使われて、その技術ノウハウも枯れているため、技術的にも信用がおける事が多い。
　でも、コーディングは非常に詰まらない。。