近年セキュリティの強化でお客様の所にパソコンを持ち込めないケースが増えている。
情報流出によって企業の経営が傾くことが起きている以上　仕方がないのであるが、いざ自分の身に降りかかると大変である。
１年ほど前ある案件でお客様のところでの作業は全て、渡されたノートPCで作業することになった。そのプロジェクトでも体制が整うまでは自分のパソコンを持ち込んで資料作成をしていたが、体制が整ったところでパソコンを渡された。同時に自分のパソコンの持ち込み禁止となった。
それからというもの自分のパフォーマンスの悪さに驚いた。

２月２２日シナジー研究所の依田さんとAs-Is分析のための既存システムの分析について話をします。
既存システムの再構築プロジェクトでは既存のプログラムドキュメント化がよく行われます。
私も過去２度ほどそのようなプロジェクトに関わったことがあります。
そのような場合大抵システムの仕様を明らかにするためにプログラムソースを掘り起こしドキュメントを作成しています。
その作業を無駄だとは言いませんが、コストパフォーマンスが非常に悪いと感じています。
今回はシステムの仕様を個々のプログラムに頼らずに整理する方法をご紹介します。
ポイントは　いかに「プログラム」に影響されずにシステムの仕様を把握するか　ということになります。

このブログ面白い
意志決定の核心をついている。
JavaからScalaへ。 - このブログは証明できない。
どうしてこんな決定が下されるの？
と疑問に思うときは大抵現場レベルの関心と管理レベルの関心にギャップがあるときである。
それが端的に表れていて面白い。

以下のブログが大変面白かった。
受託開発が本質的に非効率である理由の考察 - GeekFactory
この主張にはまったく賛成でその通りだと思う。
また膨大な時間をコミュニケーションロスで費やしている大規模プロジェクトをいくつも見てきた。
しかし、しかしである。
受託開発が本質的に非効率　か　というと　そんなことはないのではないかと考えている。
私は過去に自分の家を設計し、そのときに建築家さん施工屋さんと話し間取りの話をし、実際に家ができる現場も見ている。
その後も何度か建築家の方と話す機会があり、鉄骨造りの家と木造作りの家については結構知識を得た。

先月行われたセミナーの中の説明ではアーキテクチャの位置づけがわかり難かったが、最後に質問して確認したことでしっくりきた。
結論からいうと包括FWをベースにプロジェクトを進める場合はアーキテクチャはほぼ決まっており、決められたアーキテクチャに沿って開発を進めることになる。
要件分析プロセスでアーキテクチャ案の決定というアクティビティがあるので、該当システムとしてアーキテクチャ案を策定するようなことが考えられているようだが、実態としてはあらかじめ決められているアーキテクチャを超えるような要件が出てきたときの対応といったところだろう。