先日、セミナーにちょっと行ってきました。
アプリケーションセキュリティに関するセミナーでしたが、印象に残ったのが、扱うデータの意味を理解して対策を立てるのは、どんなセキュリティ対策のツールを使っても扱うのが相当困難だという点でした。
　企業内で扱うデータの意味を知っているのは、基本的に企業内SEもしくはその位置付けにある人達です。何を知っているかと言えば、具体的にはテーブルとカラム、データ項目、インターフェース設計なんだと思います。前職で一時的にホストを担当した時は、VSAMのレコードレイアウト図として紙でしか資料が残っていなかったので、エクセルのテーブル設計書に落として、把握している範囲で項目の備考欄を埋めていきました。
　備考欄に殆ど何も書かれていないテーブル設計書をたまに見かけますが、項目の備考欄こそデータの意味を記載する箇所ではないかと思います。項目名だけでデータの意味を想定するのは間違いが生まれる元ですので、どういう意味の項目であるか、どういう値が入りえるのか、他とどういう関係を持っているか、出来る限り備考欄を埋める事が、データ設計をする人としてのそのデータを扱う他者への優しさではないでしょうかね？

　先日、上野の国立博物館に「始皇帝と大兵馬俑」を見に行きました。混んでる事を見込んで平日水曜日に行きましたが、平日でも結構混んでます。こういうのはじっくり見たいので、混んでると途端に気持ちがダウンしちゃうんですよね。。でも、展示の最後に職業柄考えさせられる一文、「永遠に皇帝であらんが為の事実を可視化する為に兵馬俑を作った」というニュアンスの事が書かれていたのに注視しました。
　システムに携わる人として可視化という言葉には、反応せざるを得ません。システムは画面以外目で見えないものなので、ドキュメントを書く事で可視化しますが、始皇帝は膨大なリソースを費やし、数千、万？のリアルな陶器を作る事で可視化したという事です。
　数年前に携わった、とある企業の基幹システムリプレイス要件定義フェーズで、一番受けが良かったと感じているのが、既存システム構成を可視化した「絵」です。中規模以上の企業ですと、複数のシステムが連携しながらその企業のビジネスの根底を担っていることが多いかと思います。でも、業務ユーザーの方々は自分の社内システムがどう構成されているかをそれほど把握していません。システム部門の方々は、どちらかというとインフラよりの観点が強いです。要件を聞き出す為に今の形が可視化された物が欲しいと思いましたが、既存資料に該当するものが無かったので、下記に気を付けて全体俯瞰図的な絵を書いてみました。
　１．１枚に収める（A4サイズにすべてを収めないとヒアリング時にすぐ見れない）
　２．サーバマシン等のインフラ単位ではなく、ユーザーが日常業務で言っているシステム名を１つの単位とする（利用部門等の境界が解る）
　３．１つのシステムが大きい場合はその中に分離できそうなものをサブシステムとして枠を引く（作業分担すべき境界が解る）
　４．重要データはどこにあるのか解るように入れておく（データ移行元とすべき場所が解る）
　５．システム間、外部、利用者との繋がりを矢印の線でつなぐ（in outが解る）
　６．完成を待たずに常に打ち合わせ時に持っていて見てもらい足りない所や間違いを指摘してもらう
こんな感じでした。

　その後、空いていた常設展示を見に行き、誰もが知ってる国宝になってる日本の埴輪を見ましたが、明らかにクオリティ的には兵馬俑の方が高いです。しかも、兵馬俑は埴輪に対し７００年くらい古いものです。でも、緊張感に満ちた表情が殆どの兵馬俑よりも埴輪は「いい味」出してるなあという感じがします。これってただの自国びいきなんでしょうか？それとも強大な権力者から言われて作ったものよりも、自発的に作られたもの（真意は知りませんが）の方が共感を得やすいという事を表しているのでしょうか？

先日、「Web Performer」というWebアプリ自動作成ツールを見る機会がありました。ま、AccessのWeb版といった感じです。こういう自動作成ツールは大抵、プログラムを書かずにアプリケーションが作れるというものですが、当然データ設計（ここではツールへの入力作業ですけど）をしなければ何も作れません。
　で、データ設計って誰でも出来るのかなという事を考えたのですが、基本的にそのシステムが対象とするドメインに関するナレッジが無いと設計出来ないので、どんなにスーパーなエンジニアでも、まったく知識が無いドメインを対象とするシステムを作る為のデータ設計は出来ません。作る前に業務分析とか要件定義のフェーズを設けて、それらの知識をエンジニアが得た上で設計し始めるといった手順になります。ま、そのフェーズにどのくらい時間をかける必要があるのかはまちまちですけど。。
　となるとデータ設計は確かにエンジニアがしなくてもいい範囲かも知れません。日ごろ使っているエクセルシートや紙の伝票などから大抵のデータ項目は決まってしまいますし。エンジニアがするのはそれを設計書という形に落とすだけです。
　でも、それらデータをつなぎ合わせるという感覚が一般の人ではちょっと難しいのかもしれません。データ設計をデータベース設計と言えるものにするには、最低限、データをテーブルとし複数のテーブルを定義して、それらの繋がりも明確にする必要があります。複数のデータを繋ぐにはエクセルの単一シートや紙には含まれていない可能性のある外部キー項目が必要になってきます。こうなると多少なりともRDBに関する理解が必要です。RDBなら大抵同じかも知れませんが、使用するデータベースミドルウェアの種類によっても、設計は違って当たり前です。物理設計となると完全にミドルの世界です。
　上記のような自動作成ツールを使う上では物理設計は殆ど不要みたいです。でも、データベース設計ができないとツールを使っても単一データ用の一覧・更新画面以上のものは出来上らないので、最低限RDBに関する理解は必要ですね。

源泉徴収手続きの期限が迫ってきたので、e-Taxでやってみました。と、言っても仕事のタイミング的に昨年中は特に払うものは無いのですが、無いなら無いとしての手続きをしなくてはなりません。。
　ルート証明書をインストールし、Webから開始届出の手続きをすると、利用者識別番号が表示されるので、その番号でログインして利用者情報の登録をしたら、各種申告の入力をするだけです。筆者の場合は、特例の申請をしているので、「給与所得・退職所得等の所得税徴収高計算書(納期特例分)」で入力して終わりです。
　ちょっと違和感を覚えたのが、開始届出を画面から入力している時点で殆どの利用者の属性情報を入力しているはずなのに、またログイン後に利用者情報を入力しなければならないという事。２重入力しなければならない理由は何なのか、職業上いろいろ想像してしまいます。ま、殆どの場合システム構成とかデータ設計上の問題でそうなっているだけだと思いますが。。
　他にも、拡張子がdoだからStrutsを使っているっぽいとか、Javaアプレットを使う必要性ってホントにあるの？ブラウザはともかく、端末環境に依存することはやっちゃダメだよね、とか、画面デザインの野暮ったい感じは開発ベンダーに丸投げしたのでは？とか、画面上の文言表記だけでなくユーザー目線で設計された感じが全くしない、とか、既存の用紙や手続フローを置き換える以外のシステム化コンセプトを少しも考えなかったんだろうな、とか、そもそも肥大化・複雑化しすぎたスキームの再設計や膨大な種類の取扱用紙の再整理をせずに表面だけシステム化したところで解りやすくなることはない、など、いろいろ示唆に富んだシステムですね。
　イータ君ってイタキャラって事かな？

　以前から、建築業界とシステム業界というのは共通点が結構あるな～と考えていました。作る対象物は違えど設計、構築といった仕事の進め方もそうだし、大手ベンダー＝ゼネコン、多重請負とかの業界構造もです。で、今ミッドタウンの21-21DESIGNSIGHTでやっているフランク・ゲーリー展に行ってみようと思った訳です。
　正直、その斬新なデザインは賛否両論あるかと思いますが、筆者が驚いたのは、昔は模型を作っては壊してを繰り返して設計していたのが、今ではデザインコンセプトを模型で確認した後はコンピューターで3Dモデリングし、決められた予算範囲内でデザインを妥協することなく最適な資材構成となるようシミュレーションを繰り返して決定しているという事です。それにより、建築資材の数や搬入時期までを決める事で施工時のコストまでも最適化し、複数の施工業者が見積もっても誤差は0.5%とか。スゲエ！と思ってしまいました。ようするに、それを実現できるソフトウェアを開発した人であるということなんです。建築業界はまったく解らないですが、こういうやり方は一般的なのでしょうかね？国立競技場とかこの人に任せればよかったのにと思いますけど。。
　で、建築とシステム開発の違いについて、フランク・ゲーリー展を見た後に筆者が感じた所ですが、建築では、住宅からビルやホールとか構築対象物の規模が解りやすいという事と、建築での施工業者なる位置付けの仕事がシステム開発に存在しているか？という事です。
　システムの規模って、誰が見ても大規模なものもあれば、それ程でもないものってかなりあるように思いますが、その規模の判断が人それぞれな気がします。大抵大手ベンダーに依頼すれば大規模と見なされていませんかね？クリティカルなシステムだって、例えば５種類のデータしか扱わないのであればそれは対した複雑さは無いはずなんです。また、扱うデータ量が膨大だとしても実装されたシステムを多数のサーバに配置するだけなので、インフラ含めアプリもちゃんと設計されていれば開発自体のコストは何も変わりません。
　あと、施工業者という点では、所謂上流下流といった分け方をしている場合、プログラマーは施工業者みたいなものだという考え方を持っている人もいると思いますが、それを当てはめた方がよいケースは極少数でしかないと筆者は考えます。どちらかというとプログラマーは施工業者というより建築資材供給者の位置づけに近いと思いますが、システムでは１つの設計＝１つのプログラムみたいなものです。同じものを量産するという概念がありません。すごく似ている機能が多数存在する事もありますが、それを一つまたは最小限にできないなら設計に問題があるはず。であれば、何を作るべきかを把握しているであろう設計者自身がプログラムを書く方が品質が高く、また分業する事によるコミュニケーションコストも最小化できるはずです。
　システム開発に施工業者が存在していないと考えの元では、建築家フランク・ゲーリーにとってのデザイン活動範囲は、システム開発全ての活動範囲と一致しており、構築対象物は違えど、システム開発におけるプログラミングはデザインという活動範囲に含まれているという事になります。施工業者的であるのは多数のサーバで構成された場合におけるインフラ側の仕事だけではないでしょうか？
　筆者の立場では、今は一人か極少数で開発をしているので、これは注文住宅を自身で設計・施工している工務店の大工みたいなものですかね。こういう戸建レベルの規模の開発案件って結構存在しているはずなんですが、欲しているものの実際の規模と受注側が考えているその規模のズレを注文側が感じるとる事を出来るかという所になります。でも、大規模と言われた物を小規模であると主張するのは結構タイヘンなんですよね。発言に対し全てのリスクを引き受ける気合い！がなければ、なかなか言える事では無いかもしれません。別の方法として、一つのシステムを戸建てレベルの集合体と分割することも出来ますけど、構築後の保守フェーズまで考慮するとこちらもタイヘンかなあ。。

　ここ数か月、筆者はとあるシステムベンダーが構築したWebアプリケーションのフレームワークで作成された既存システムのソースを流用して、新規のWebサービスを作ってました。この既存システムは、新規開発から既に１０年近く経過し、その間いろいろと変更・追加があったようです。フレームワーク自体はstruts1＋Spring＋ibatisという構成の上にさらにベンダー独自の実装で構成されたものです。そのベンダーさんに使用許諾を頂きましたが、特にリファレンスとかは無いのでソースを読みながらフレームワークを理解しながらの開発となりました。
　結果、３か月近く開発し、作ったアプリは現在ビジネス要件を満たし動く状態になってきましたが、こういう経験の無い枠組みの中で作るのは思ったよりも結構時間が掛かってしまうものだなあという印象です。一から作れと言われたらそりゃもっともっと時間が掛かるでしょうが。。
　最初、やはり時間の経過でしょうか、今さらこの構成？という感じでしたが、現在は良くできてるなあという思いもあります。ベンダーが作ったフレームワークって知ってる人からすると、結構時間が掛かる調べものの時間がないので、慣れてる人からすれば、ホントに工数を節減できたり、正確な工数を見積もったりできているんだとは思います。ただ、気持ち的には今さらstruts1系？とかここでの経験は他では使えないなどいろいろな感情が絡んでしまい、また、ソースの切り貼りみたいな作業も多く、モチベーションが低下してしまったのは否定できません。Javaの場合は流行り廃りがあるとはいえ、このようなフレームワークは、利用している方からするとシステム更新しない限りずっと使い続けるしかないのはしょうがない事ですが。
　時間の経過と言えば、最大なのはメインフレーム、いわゆるホストと呼んでいるものも一種のフレームワークと呼んでいいと思います。筆者の場合、最初がオープン系畑だったので、前職の時にホスト(zOS)と関わった時は、最初は違和感ありましたが、しばらくして良くできているなあと感じてきました。主にCobolソースとJCLの整然としたリソース構成は、雑然としたオープン系と比較するときれいに見えてきます。80桁×24行しかない画面もむしろ潔いよいです。。
　とはいえ、ホストのような自由度の無いガチガチなタイプがいいか、ちょっとぐちゃぐちゃ感はあるけど自由度のあるタイプがいいのかというと、もちろん筆者は後者の方が断然好きです。

最近あまり読まなくなりましたが、以前はよくソフトウェア関連書を読んでいました。
関連書と言っても、テクニカルなものでなく、トム・デマルコとかワインバーグといった、辛口でウイットに富んだエッセイみたいなタイプの方です。
特にワインバーグの「ライト、ついてますか」がすごく好きです。これはソフトウェア関連書に分類されているので、大きい本屋のコンピューター関連書の陳列棚に置いていたりいなかったりですが、中身はまったくコンピューターと関係なく、サブタイトル「問題発見の人間学」の通り、真の問題を発見する事の重要性について面白い寓話で説明してくれている内容です。どっちかというとビジネス書とか自己啓発本の方に置いておけば、既に３０年近く前の本とはいえ、結構売れるんじゃないかなと思うんですが、その手の本と比べるとちょっと値段が高いかな。。
仕事の打合せに出ていて、たまに問題が行ったり来たり跳ねたり飛んだりしてるなと感じる時によく思い出す本です。

ソフトウェア関係の書籍としてはあまりにも有名な「人月の神話」の冒頭に、プログラムをプログラミング製品（汎用性を持つデザイン、文書化、テスト等）にすると元の最低３倍のコストがかかり、プログラミングシステム（コンポーネントとしての使用に耐えうるようにするという事か）となるには、こちらも３倍かかるので、これら双方を兼ね備えたプログラミングシステム製品は結果９倍以上になるという記述があります。
で、現在ここでいうプログラミングシステム製品って何があるんだろうと考えますが、OSやJavaのようなプラットフォームしか思い当りませんね。
筆者のような日本にいる「システムエンジニア」と言われる人々は何を作っているのかと考えますと、企業内で使用されるシステムとかWEBサービスとかの構築がメインなんじゃないでしょうか？これらは、上記でいうところのプログラミング製品というものにも当てはまらないように思われます。文書化されてはいても、殆どの場合それを使う為では無く、どう作るか、またはどう作ったかという設計書としての文書だし、テストにしても到底あり得ないケースまで考慮してテストやったり、その為の実装したりってあまりやらないでしょ。
という事で、筆者の場合は特に個々の機能について見積もりをしない前提である為、「人月の神話」の世界にあるような大規模なシステム製品を作っている訳ではなく、参考になる所もあるけど、当てはまらない事が多いように感じました。
結局のところ、どこまでやるかがそのコストになるので、どこまで整理されたシステム構成にするか、どこまで完璧にテストするか、どこまで大多数の人が読める文書を作るかといった判断は、全て予定されたスケジュールと用意されたコストによってある程度決まってしまいます。結果的に「人月の神話」では無く、「人月の制約」の中で必要な機能を全てちゃんと用意した上で上記のような要素に対応するしかないのです。でも、それは全然悪い事では無いと思います。特に筆者のような仕事は、製品を作っているのではなく、エンジニアリングサービスを提供しているからです。
他者が書いた１システム全体のソースを読んでいると、そのような状況が何となく想像されますね。メンバー構成とか役割分担の仕方とか、テストで特に不具合が多かった箇所とか、アーキテクト的な全体を構成する立場の人がいたかとか。一番難しいのは全体の構成でしょうね。人によって読みやすいコードって多分違うので、コンセプトを理解した上でないと、良し悪しの判断さえ出来ないでしょう。

システムを作る際に、要件定義として何かしらドキュメントを書きますが様々なタイプがありますよね？
筆者が社内SEやってたときは、メイン読者は誰なのかを特に意識して書いてきました。それによってドキュメントの目的が違ってくるからです。それに読む人が理解できないものを書いてもしょうがないじゃないですか？
よく見かける「要件定義書」を成果物と設定し、ドキュメントそのものが目的物になっている場合って、何かピンとこないことが多いように思うんですが、ドキュメントって全ての読者向けに書いた、もしくはターゲットを特定しない場合は、ページ数が多くて読む気もならなかったり、ちょっとの誤字脱字を発見して読む気なくしたりして、誰にも伝わらない、もしくは各自の思いで解釈し後で痛い目にあうというなんて事も多々あるように思います。
という事でメイン読者を軸にすると主に４タイプに分類できるかなと思います。
１．経営者向け
　あまり書く機会は無かったけど、この場合の目的はビジネスがどう変わるか、予算がどのくらいかかりそうかが焦点かと。
　とにかく簡潔に少ないページ数でまとめる。図を多く使ってパワポで書く。
２．利用者（利用部門）向け
　この場合の目的は、業務がどう変わるか、システム化される範囲としない範囲の指定なんで、具体的な対象物の明記が必要。
　概要説明と解りやすそうな業務フロー（UML的に書いても理解されない可能性が高いです）
　また、外部設計を後でやるかやらないかにもよりますが、画面・帳票設計に近いもの付け加える。
３．開発者向け
　開発工数を見積もるという目的がメインと考えます。
　どういうレベルの工数見積もりを期待するかで、たくさん書くこともあれば、ちょっとの時もあり・・
　開発者の理解レベル次第では、２と同じにする事も多々あり・・
４．運用管理者向け
　この場合の目的は、どう構築して、その後維持管理していくかなんで上記とは別物ですね。いわゆる非機能要件に分類される内容がメインになると思われます。

現在の筆者のスタンスでは、自分では要件定義書的なものを書きません。
だって見積もりもしなければ、別の開発者に伝える必要もほとんどないし・・・
開発者という立場の場合、見積もりしない限り、手間が掛かるだけで必要性を見いだせないからです。
よく開発ベンダーに要件定義書を任せるというスタンスの所もあります。開発規模次第という面もありますが、出来ればしない方がいいですね。あれもこれもといろいろ盛られて、見積もり見てびっくりします。

現在、筆者はある企業のあるシステムのリプレイスプロジェクトに参画していて、ある大手ベンダーが請負開発、筆者はユーザー企業側のメンバーとしてその一部機能を開発しています。

毎週、進捗会議としてその大手ベンダーが進捗説明をするMTGを２時間くらいで実施しており、その後の時間で設計レビューの時間という流れになっています。進捗会議はWBSを見るというよりも、サマリとして何の予定工数XXのうち消化はYY、予定に対してZZ遅れと言った説明する形になっています。（XXとかは人日ですね）

このような説明の仕方をしていると、このZZの遅れ以外に話題がないので、ユーザー企業から見れば何で遅れているのかを聞くくらいしかなく、ベンダー側はなぜ遅れて、どう取り戻すかを説明するようなことを毎回繰り返している事に気が付きました。

筆者としては、進捗説明後の設計レビューあたりしか感心が無いので聞き流している箇所なんですが、毎週同じようなやり取りなんだけどこれって要るの？とふと考えてしまいました。

筆者の経験上、大手ベンダーはだいたいこのようなサマリ資料を用意して進捗を説明するやり方が多いように思われますが、そもそも、おえらいさんが参加するような進捗会議でなく、システム部門の担当レベルだけが会議参加メンバーである場合においては進め方は違うのではないでしょうか？サマリ資料じゃなくWBSを見た方が、各タスクの関連とかを意識した上で指摘することもできるし、また、本当にその後に影響を与える遅れがある場合なんかは、このような進捗会議の場でそれが表面化することはほとんど発生せず、別途個別にこっそり通知されるのが殆どのケースではないでしょうかね？

ベンダーが進捗サマリ資料を毎週作成する工数が、どれだけユーザー支払工数にはねているかをちゃんと説明していますかね？その工数を理解すれば、その資料作らないでいいよって大抵なるんじゃないでしょうか？

結果的にこの進捗報告にやり方を、サマリ資料でなく、プロジェクト管理ツールから直出力されるチャートのみで簡単な説明で済ませれば、ベンダーの担当者も負担が減るし、MTG参加メンバーの時間も節約できてみんなうれしいんじゃないのかな？
筆者の立場ではちゃんと設計レビューする時間取ろうよ！後で痛い目見ますよ！というのが本音ですが。

これでうれしくないのはベンダーの営業だけだと思うんだけど。。