使い方は今までと何も変わりません。Regionに東京が増えただけ。

AMIの品揃えもシンガポールをあまり変わらないと思います。日本語Windowsサーバなんかもあります。

ただ違うのはスピード。レイテンシーは全然違う。計ったわけではありませんが、

普段使っているＩＤＣと体感上何も変わりません。

シンガポールが出たときもかなり速いと思いましたが、東京Regionはやっぱり違う。

今ならまだドル建てなので、多少安めの料金で使えるような気がします。円建てになると、少し料金上がるんじゃないですかね。

今回のはちゃんとしたサーバなのでかなりパワフル。OSも64ビットに入れ替えて64ビット動作にしました。

前のサーバは秋葉原の路地で安価に手に入れたものだったのですが、よく５年以上も持ちました。よくがんばりました。

あ、この書き込みも実は移行テストを兼ねています（笑）。

最近はTwitterばかりでしたが。（とはいえ、Twitterもそんなに書いているわけではないのですが。）

ここ数ヶ月、あまり元気ではなかったのですよね。。最近は開き直ったせいか、少し気力が出てきました。

もしかして、ブレイク前の会社ってこんな感じなのかな？

で、Twitterはじめました。よければフォローしてやってください。少なくとも、ブログよりは気楽に書こうと思ってます。

＃今今、ずいぶん気楽に書いている気もするが。

でも、ようやくブログを書く気になったってことか。ちょっとは元気になったってことかな。

ちなみに、このＩＴの世界で、「この前の戦争」といったら、なんでしょう？

小さな争いごとはいろんなところで起こっていますが、それは世の中どこでも同じことですね。
「戦争」と呼べるほど大きな争いごとといったら、この二つではないでしょうか。

【ブラウザ戦争】 ネットスケープ vs マイクロソフト
【検索エンジン戦争】 マイクロソフト ヤフー グーグル

※この二つのリンクはGoogleビデオの動画にリンクしています。（音声注意です。）

いずれもディスカバリーチャンネルの番組のようです。
タイトルはこんな感じですが、ＩＴの専門家でない普通の人でも、見て分かるようになっています。

面白いところを書くとネタばれになりそうなので、一度ご覧になってみてください。

今使っているインターネットやブラウザがどうして生まれたのか。その歴史がわかります。

人間の歴史って、やっぱり戦争の歴史なんですかね。。。

今までウェブ会議で開いていた会議を、最近は都合でリアル会議で行っている関係で、DimDimは１ヵ月ぶりの利用になってしまいました。

ひさびさに見るDimDimはちょっとマイナーチェンジしている感じでした。「変わったなー」と思うところはこんな感じです。

• トップページが様変わりしている

トップページに、「Host Meeting」「Join Meeting」があったり、「DimDim for Education」や「DimDim Enterprise」などのリンクもきれいな画像が入れ替わり立ち代り表示されています。。きれいになり、整理された感じですね。（特に、Join MeetingはいいUIだと思います。）

• ScreenCasterに代わる、新デスクトップ共有ソフト

どうやら以前のScreeenCasterに代わって、新しいデスクトップ共有ソフトを開発したようです。

Dimdim myScreen™ Instant Screen Sharing なんて書いてありますね。

• 会議の開催が簡単に

会議の開催が簡単になりました。今すぐに会議を開催する場合には、ログインしてすぐ「Start」のInstantActionボタンを押します。今までは、その後ダイアログボックスで各種設定をいろいろ行っていたのですが、現在は、「Start」クリックですぐに始まります。招待したり、設定したりを先にやるのではなく、まず会議を開催して、後に行うスタイルに変わりました。「Start」ではなくて、「Schedule」の場合は、今までどおりダイアログボックスが開きます。このようにユースケースに合わせた作りがうれしいですね。

• 音声の遅延が減った

今までは、やはりサーバが遠くにあるせいか（アメリカの東側です。）、音の遅延が大きいときがあった。コンディションに左右される場合もあるようなので、一概には言えないが、今日は音声の遅延がとても少なく、快適に使わせていただきました。普段も会話がなりたちにくくなるほど遅延するケースはまれで、通常はすこし遅れて聞こえることを意識すればちゃんと会話が成り立つレベルです。今日は、そういうことをほとんど意識しなくてもよかったように思います。

全体的に見て、すごくよく改善されている感がありますね。（ページ構成も、システムも、ユーザに合わせて改善した感がものすごくよく出ています。）うちのシステムも、こんな感じでユーザのためになる改善をした感じが出ると良いのですけれどね。

神崎コンサルノート：RDRA関連のブログを追加

神崎さん、ありがとうございます。

そういえば、RDRAを最初に見つけたのは、なんとなく見ていたスパークスシステムズジャパンさんのページでした。

Enterprise Architectで書く要件定義フレームワークなんていうものがあるんだあーというのが第一印象です。
実際にHPを見てみて、「網羅性・整合性・表現力」というフレーズも響きましたね。

当時私は、近々発動予定の開発プロジェクトを抱えていました。
開発自体は、ICONIXプロセスで開発することは決めていたのですが、
その前の要件定義フェーズをどうしたらよいかとても悩んでいました。

・要件定義できる要員がたくさんいるわけでもなく
・短期間になんとかICONIXプロセスにつなげて開発する
・そのためには何から入ったらよいのだろう？

という課題です。

で、実際にテンプレートをダウンロードしてみて、すごく気に入りました。

システム価値→システム外部環境→システム境界→ユースケース、ドメインモデル
といった筋道がこのテンプレートを見ることで、見通しが開けた感がすごくありました。
これならスムーズに開発メンバーへの設計のインプットとして、つなげられそうだというイメージがでました。

また、「リレーションシップ駆動」というネーミングもすごくよいと思いました。
私は要件定義とは個別の成果物だけを指すものではないと思っていたからです。

例えば、要求→業務モデルや利用シーン→ユースケース→画面といった関連こそが大事で、
それを共有するからこそ要件定義になり、整合性も保てると常々思っていました。
RDRAはEnterpriseArchitectを使ってそういう表現を上手にしているところがすごくよいと思います。

それ以来、どんな小さな開発ネタでも、まずRDRAでコンテキストを書いて、要望、要件を整理し、何をがんばって明らかにしていかなくてはいけないかをまず考えることにしています。

また、実際にRDRAを使うことで、実際の開発にすごく安心感が出ました。
開発メンバーへの設計のインプットとして、コンテキストからつながっている感じがすごくよいです。
開発メンバーもこの要件定義はそこがすごくよいと言っていましたね。

うちの仕事では今後も使っていくつもりです。
またネタが出たら、なにかフィードバックできればと思います。

その中に、

仕掛かり作業の増加- 仕掛かり作業が増加すればするほど、開発者はコードを作業結果に反映できるようになるまで待たなければならない時間が長くなる。

というのがありました。

実際そのとおりですね。では、なぜこういうことになるのでしょう。

私がよく見るパターンでは、この後に書いてある、

同時に数多くのプロジェクトで働く–作業をスイッチすることは利点よりも問題点の方が多い。

というパターンとの複合技で起こる場合でしょうか。
優秀な人間に、たくさん仕事をして欲しいというSEマネージャの気持ちはわかるのですが、これでは逆効果になります。

実はこれにはガントチャートによる進捗管理も関係しています。

ガントチャートで進捗を管理しているプロジェクトによくあるのが、ろくに手も付けていないのに進捗が30%のタスクや、90%から全然動かないタスクが数多く出てきたりするパターンです。進捗上は進んでいるように見えるのに、実際には何も出来ていない。こうなってしまうと、仕掛かりタスクが増え、優秀な人のパフォーマンスが低下し、プロジェクトが失敗の方向へ向かっていきます。気づいたときには手遅れの場合もあります。

Basecampではガントチャートは出てきません。

ToDoリストは、タスクは済んだか、済んでいないかだけです。マイルストーンまであとどのくらいかもよくわかります。
ToDoリストが片付かなければ、そこに問題が潜んでいるかもしれないと分かります。
BasecampにはToDoにメッセージが付けられますから、問題の報告が早く行われて早く手が打てます。
（フェイル・ファーストってやつですかね。）
「プロジェクト管理はコミュニケーションだ」というゆえんはこんなところにもあります。

こんなところも私がBasecampを気に入っている理由のひとつです。

＃そういえば、「アジャイルプロジェクトが遅れる理由」は徳武さん翻訳でした。
＃仕事だけでなくて、翻訳のほうもなかなか頑張っているようです。

ようやく電車で外出できるようになりました。

復活できなかったら、正月実家に帰るのも無理かなあとも思っていたのですが、どうやら帰れそうです。

おかげで先週は仕事を休んじまった。さすがに今週もというわけにもいかないので、頑張って出てみた。

さすがにしんどいね。もう帰ろう。

一番大きな理由は、やはりアジャイルなスタイルに合うこと。
あと、私たちが開発元の37Signalsの考えともよく合うということ。

彼らが出しているGetting Realという本があります。日本語版もダウンロードして読めます。
（この存在は一緒に仕事をしている徳武さんに教えてもらいました。）

これを読むと、37Signalsのウェブ・アプリケーションに対する考えがよくわかります。
実用的なソフトウェアを作ることに振り切っているところもとても好感が持てます。
（例えば、Microsoft Projectなんかを「ゴリラのようなソフトウェア」と言っています。意味が分かりますか？）

また、彼らはとてもユニークで、

シンプルなツールを作り続ける37Signals社の仕事術

というようなこともやっているようです。おそらく、日本のほとんどの企業では理解されないと思います。もし少しでも理解できたなら、それだけで十分だと思います。

（うちは割りと似たところがあるかな。。。）

—-

「アジャイルなスタイルに合う」というのは、Basecampのビジョンにあります。
Getting Realから引用すれば、

「Basecamp」：プロジェクト管理はコミュニケーション

という、ビジョンです。このビジョンが、

このビジョンにより、我々は「Basecamp」を可能な限りオープンで透明性の高いものにしました。会社内の範囲だけでなく、我々はクライアントとのコ ミュニケーションにもアクセスを広げました。我々は、全てのメンバーの参加の垣根を低くし、サポートするよう考えました。ビジョンは、なぜ我々がチャート や、グラフ、テーブルやレポート、統計、スプレッドシートといったものを省き、代わりにメッセージやコメント、ToDoリスト、ファイルの共有といったコ ミュニケーション機能を重視したのか、という部分です。ビジョンついて大きな視点での決定をしましょう。そうすれば、これからの小さな判断がはるかに簡単 になります。

というサービスを生み出しました。この「ビジョン」こそがアジャイルなソフトウェア開発に合うところです。

—-

アジャイルなソフトウェア開発は、人とのコミュニケーションを重視します。
チームではドキュメントをやりとりする代わりに、コミュニケーションでカバーし、開発速度を上げます。
顧客コミュニケートすることで、問題領域を明らかにし、解決していきます。

また、今時のソフトウェアはネットワークを介して他のソフトウェアと連携しながら動くものがとても多いです。
そのような場合、クライアントや他の開発チームとのコミュニケーションも非常に重要になります。
逆に言えば、そのようなコミュニケーションの不足がプロジェクトが失敗するポイントになりやすいところです。
（今まで何度それで失敗するプロジェクトを見てきたことか。）

Basecampを利用することで、このような利害関係者と多くの情報を共有できます。
共有する上で大事なことは、各利害関係者がオーナーシップを持つことです。
ただ、参照可能な場所に置いてあるというだけでは、共有したことにはなりません。
Basecampの作りがシンプルであることも、メッセージやコメントがいたるところに残せることも、
利害関係者にオーナーシップを持たせることにすごく寄与していると思います。

—-

アジャイルなソフトウェア開発は、イテレーティブ（反復的）に行われます。

ソフトウェア開発は、最初から最後まで舗装された一本道を歩いていけるわけではないのです。
例えて言うなら、地図を頼りにチームでコミュニケーションをとり、周りを観察して山道を探しながらチェックポイントを目指す、オリエンテーリングのようなものです。
（この例えは増田さんに教わりました。）
途中で変だと気づいたら立ち止まる。反復して実践を行い、頻繁に計画を見直しながら進んでいく。
Basecampのマイルストーン・ToDoリストの考え方は、まさしくこれにマッチするものです。

ガントチャートで進捗を管理しているチームは、大抵、計画の変更を嫌がります。
一本道を一定の速度で歩いていって、時間内にゴールする計画を立てているわけですから、
何か起きたら時間内にゴールできないことが分かっているにもかかわらずです。
（時間内にゴールできないから嫌がるんですが。）
タスクの詰め込みすぎも、計画の変更を嫌がる要因のひとつです。
なんとか詰め込んでできた計画は、変更なんてできるわけがありません。

情熱を持ったエンジニアも、そんな計画のために酷使したら情熱が冷めてしまいます。

—-

他にも書きたいことはいくらもあるのですが、このあたりの話は、私が言うより、神崎さんのブログを読んだ方が早いかもしれませんね。。。

「なぜBasecampを使うのか？」

と聞かれれば、

「私たちのやり方に合っているからです。」

と私たちは答えるでしょう。

ただし、万人に理解を得られるものではないこともどうやら事実のようです。

—-

そういえば、以前こんなことがありました。

とある企業にサービスを提供することになり、専用のアドオンを開発していたときのこと。
クライアントに提出工数と見積金額に納得してもらうために、スケジュールとタスクを出すよう営業マネージャから依頼がきました。
Basecampでマイルストーン・タスクを設定していたので、私はBasecampで一覧を出してそれに大体の予定工数を書き入れて提出しました。

営業マネージャは、それを見るなり驚いて、

「これが管理表なの？タスクって、開始日と終了日があるものなんじゃないの？これにはどうしてそれがないの？」

と言われました。どうやら彼はガントチャートが出てくることを予想していたようです。
（暗に「こんなんでいいのか？」って言われているわけです。）

—-

この問いに対する答えは、RDRAの開発者神崎さんのブログにいいものがあります。

スケジュールは毎週変えることで役に立つようになる

私の考えもほぼ同じで、この時はマイルストーンをほぼ１Wおきに置いていました。
だいたいチェックのタイミングも週単位です。進路変更したり、手を打ったりするのもこのタイミングが多いですから、こういう単位でプロジェクトの進行を考えると、取扱いやすいです。

今でもプロジェクトを起こすときには、マイルストーンを１Wぐらいに置き、週単位の目標を明確にするようにしています。この時は１ヵ月半ぐらいの短期決戦だったので、結構タスクは見通せてはいたのですけれどね。

神崎さんのブログ記事を読めば分かるのですが、お互いの考え方やアプローチの違いがこういう発言につながっています。

正直、営業マネージャにいくら説明しても理解を得られるような気がしなかったので、

「うちはそういうスタイルなの。」

で、この時は押し切っちゃいました。

—-

この時はこれで済ませられましたが、おそらく、これで済ませられない場合もあるでしょう。
その時はどうするかって？神崎さんのブログ記事でも読んでもらいましょうか。

翻訳したのは、Domain Driven Design Quickly を翻訳した徳武聡さん。
徳武さんとは一緒に仕事をしていますが、頭が速くて手も速く、good senseです。
SEマネージャからみて、とても頼りになるエンジニアです。

数ある翻訳候補の中から、「技術的負債を解剖する」を選ぶところも、なかなかgood senseです。

—-

そもそも、「技術的負債」というのはワード・カニンガムがメタファーとして作ったものだとのこと。
マーチンファウラーのBlikiから引用すると

「技術的負債」とは、Ward Cunningham が作ったメタファーである。上記の問題について考える際に、この言葉が役に立つ。このメタファーを使うと、早いけれど汚い解決方法は（ファイナンスの負債と同じく）技術的な負債が発生する、ということになる。 通常の負債と同じく、こちらの負債も利子を払う必要がでてくる。 早いけれど汚い設計を選んだせいで、将来の開発において余分な労力をさかねばならなくなる、というわけだ。 これからずっと利子を払いつづけていくことも可能だし、 リファクタリングによって良い設計に修正し、元本を減らしてしまうということも可能だ。 もちろん元本を減らすのにはコストがかかる。だが、それによって将来かかる利子が減るため、結果的には得なのである。

ということです。SEであれば、多少なりとも身に覚えがあると思います。

これについて、マーチンファウラーの分類では技術負債は４つに分類されるとのことです。

1. 無鉄砲 - 意図的 – チームには設計をしている時間がない。品質を犠牲にして、汚くても素早くソリューションを提供する必要がある。
2. 良識的 - 意図的 – チームは今すぐ製品を出荷しなければならないが、その製品には既知の欠点がある。発送した結果が招く問題についても先手を打っておく。
3. 無鉄砲 - 偶発的 – チームは基本的な設計原則について意識していない。なので混乱状態が生まれつつあることにも気付いていない。
4. 良識的 - 偶発的 – 確かに優秀な設計者がいて、その設計者はビジネス価値を生み出すソリューションを納品する。しかし、ソリューションが完成した後になって、最良の設計手法が何だったのかを理解する。

このような内容になっています。
これらについて、経験から少しどんな時こうなるのかを考えてみます。

「無鉄砲で意図的」な技術負債

「設計なんてしないで、品質を犠牲にして素早くソリューションを提供する」状態とはどんな時なんでしょう？
例えば、「納期が間近に迫っているが、どうしてもやらなくてはいけない」時。このような場合には、それまできちんととやっていれば、技術負債はそこだけで済む。
しかし、「プロジェクト自体がそもそも無理」な場合にも、このような事態は発生する。
マネージャ自身が「設計なんていいから、とにかく、コードを書け」なんて方針になってしまって、結果的に技術負債のかたまりのようなソフトウェアを作ってしまう。
そんなパターンですね。ここまでいくと、正しく動く方が奇跡？のような状態になるので、そのためにまた汚いコードを上塗りすることになってしまいます。

「良識的で意図的」な技術負債

「その製品には既知の欠点がある。発送した結果が招く問題についても先手を打っておく」っていうのはどういうことでしょう？
例えば、既知の欠点について、マニュアルに記述し回避方法を示しておくとか。（マニュアルで逃げるというやつですね。）
「既知の欠点があるが、十分によくできていて、運用可能だから出荷する」と言う状態です。
この場合はやはり「良識的」なので、既知の欠点があっても、よく品質は確保されている状態です。
既知の欠点が山ほどあって、直しても直しても減らないような状態ではありませんね。

「無鉄砲で偶発的」な技術負債

「チームは基本的な設計原則について意識していない。」というのはさすがに無謀ですね。
たとえば、レイヤリング方法や、ネームスペースの名前付け方針、ライブラリの使い方や準備、そういった開始前の準備タスクを怠ってスタートしている場合が該当しそうです。
「混乱状態が生まれつつあることに気づいていない」ということは、メンバー間のコミュニケーションもあまり取らずに勝手に作業を進めている感じですね。
正直、かなりワルですね。

「良識的で偶発的」な技術負債

「ソリューションが完成した後になって、最良の設計手法が何だったのかを理解する。」は、ファウラーが書いたDDDの序文にあることだと思います。

Another lesson you’ll learn from this book is that domain models aren’t first modeled and then implemented.
Like many people, I’ve come to reject the phased thinking of “design, then buld.”
But the lesson of Eric’s experience is that the really powerful domain models evolve over time, and even the most experienced modelers find that they gain their best ideas after the initial releases of a system.

他の教えでは、あなたはドメインモデルは初期モデルで実装されることはないことをこの本から学ぶでしょう。
大多数の人のように、私は「設計し、そして構築しなさい」という段階的な考えを拒絶するようになっている。
しかし、エリックの経験からくる教えは、長い時間をかけて、本当にパワフルなドメインモデルを考え出す。
そして、熟練したほとんどのモデラーでさえもが、システムの初期リリースの後に彼らの最良の考えを発見する。

この辺ですかね。実際、熟練したエンジニアが設計しても、リリース後にもっとよい設計手法が見つかるものだということです。

エンジニアは最初からドメインのプロであるわけではありません。

スペシャリストからの知識を噛み砕き、ドメインモデルを構築し、システムを構築する。
そしてファーストリリースをした後に、そのドメインについての知識が深まったことに気づき、最良の考えが他にあったことに気づくわけです。

—-

こうして見てみると、「良識的なもの」と「無鉄砲なもの」で、かなり差がありますね。
「良識的なもの」は、最後つじつまをうまくあわせるために、技術負債で穴埋めする場合もありますよという感じです。
あるいは、「技術負債なし」で作ってきたつもりでも、実はドメインの知識が深まると、技術負債に気づく場合もありますよ、ということでしょう。
「無鉄砲なもの」は、まさに「無知は罪」という感じです。こんな仕事をするのは、本当に罪深いことです。
後の面倒を見るエンジニアは、本気で「自己破産」を考えなくてはなりません。

徳武さんとも話したのですが、「無鉄砲」の元の単語’reckless’は、かなり「悪い」においがします。
「無鉄砲」というよりも「無茶」とか「滅茶苦茶」とか、もっと「悪い」単語の方が感覚的には合う気がします。
もっとも、この文書の翻訳ではそんな単語はちょっと使えそうにはないので、他にいい言葉は見つかりませんでしたね。
（お行儀の悪い言葉なら、いくらもありますが。ファウラーも’reckless’が精一杯だったのでしょう。）

私の現場は、冒頭に書いたように徳武さんがgood sense(良識的)なおかげで、変な技術負債は少なくて済んでいます。

でも、徳武さんが来る前にこさえた借金はたんまりあるんですけどね。
いつも借金払わせてばかりで、どうもすみません。

話をして思い出したのは、昔金融コンサルと組んで、金融機関の収益シミュレーションシステムを作っていた時のこと。

—-
最初はスプレッドシートでマクロを組んでやっていた。
でも、結構壮大なシミュレーション仕様で、一回実行すると一時間以上返ってこなかったりした。
当時のPCとスプレッドシートでは荷が重いことがわかった。

で、UNIXサーバでCで組むことになった。

このころは増田さんが言っているような、

ネットワーク（ノードとエッジ）構造を扱うプログラムを、C 言語でうまくかけて実践できたときは、「オレすげー」と思ったのを思い出します。

そのために、ループ構造、関数呼び出し、再起呼び出しなどを駆使して、メモリ上のデータ操作の手続き記述に、どっぶりはまっていた。

なんて時代です。「オブジェクト指向」という言葉はありました。
たとえば、技術評論社のSoftwareDesignなんかでは、「オブジェクト指向って何がいいのか」なんて記事が書かれていたような時代。
日経コンピュータあたりでは、「業務アプリにはオブジェクト指向なんて不要。データ中心アプローチでやり直しちゃったよ」なんて記事が書かれていたような時代。
まだ、実際の開発現場で市民権を得る前の話ですね。

何せ、仕様の元がスプレッドシート＋マクロなので、構造体を使って大きなメモリイメージを作り、それに対して手続きを書いてまたメモリに壮大に展開していくようなプログラムを書いていた。

シミュレーション仕様は金融コンサルとエンジニアで一生懸命考えた。
金融コンサルの頭の中は基本スプレッドシートで考えられていて、私たちもそのイメージを一緒に共有して考えた。
当然、オブジェクト指向なんて考えはどこにもなくて、すごく手続き的に考えられていた。

で、実際作ってみると、思ったような「いい数字」が出ない場合が多かった。なにせシミュレーションなので、実際の動きをモデルに、ある程度簡略化した計算をしていた。
そのため、実際こうはならないだろうという数値が出る場合がある。そんな時は、また金融コンサルと一緒に新仕様を考えた。
また、実際のデータとシナリオが合わない時や、ユーザの計画方法が無茶な場合もいい数字は出なかった。
そんなときも、実際にプログラムで「いい数値が出るように」合わせに行った。

大変なのはこういう時で、時折とんでもない仕様変更になる場合がある。もとのデータ構造が変わり、精度が変わり、計算方法がガラッと変わる。
当時の作り方では、こんな変更に耐えられるだけの保守性は持ち合わせていなかった。「ほとんど書き直さないとダメなんですけど。。」という感じだ。

仕事としてやりがいはあったけれども、このころはやっぱり大変だった。夢でメモリイメージと手続きが出てきたのもこのころだ。
UNIXサーバのメモリ一杯に広げられたデータと手続き記述の海で溺れていましたね。

—-
これをブレイクスルーできたのは実は何年かたった後。

収益シミュレーションは、実は商品と経済イベント（ex:金利更改があった、手形の書き換えを行う、とか。）と、そこで起こることだけを書いておけばいいんじゃないか？
あるべき結果（いい数字）に向かって処理を羅列していくのではなくて、プログラム的にそういう整理をすれば、保守性高く、スマートにできるんじゃないか？

という発想がやっていくうちに出てきた。

で、実際にそのように書いてみたら、以前よりもずっとわかりやすく、スマートな作りになった。
一緒にプログラムを書いていたＣ言語の師匠も、その設計に手ごたえを感じていた。

おそらく、これが私にとってはじめての「オブジェクト指向発想」だったと思う。

でも、まだ難関が残っていた。

—-
一緒に仕事をする金融コンサルと、この考えは共有できなかった。
説明もしてみたが、どうやら分かってはもらえなかった。
そのあとも、スプレッドシート＋手続きイメージでしか、仕様を考えてはくれなかった。

実は、上司の理解も得られなかった。「イベント？何だそれ」「何でそんな作り方になるの？」と、かなり否定的だった。
当時の私たちには、ここで戦うだけの武器を持ち合わせてはいなかった。

この後は、金融コンサルと考えたスプレッドシート＋手続きイメージを、自分たちの経済イベントモデルに置き換えて実装していった。

—-
もう十年以上前の話だが、おそらくこれからもそういうことが起き続けるのだと思う。

業務領域を考える人たちは、ほとんどの人がやはり「手続き的」なものの考え方をしている。
そして、我々にもそういうように伝える。我々はそれを深く理解して、オブジェクト指向発想で設計する。
そして、変更に強いソフトウェアを作り上げる。

ビジネスルールや業務手順なんていうものは、実はあやふやなものなんだとも思う。
エンジニアはそのあたりを誤解していて、すごく固いものだと思っている。（実際に固いところもあるとは思いますが。）

今どきのビジネス書なんかには、「イノベーション」「ルールを変えた者が勝つ」なんて書いてあるわけだから、
むしろ、成長・発展するにしたがって、「変わって当然」「変わらなきゃダメ」なものになってきている。

「オブジェクト指向発想」を使って、保守性高い業務アプリを作ることはすごく価値があることだと考えている。