【案内】小説『エクストリームセンス』について

 小説『エクストリームセンス』は、本ブログを含めていくつか掲載していますが、PC、スマフォ、携帯のいずれでも読みやすいのは、「小説家になろう」サイトだと思います。縦書きのPDFをダウンロードすることもできます。

 小説『エクストリームセンス』のURLは、 http://ncode.syosetu.com/n7174bj/

2011年8月28日日曜日

いい日曜日だ

午前中はプログラミングしながら新システムに採用する仕組みを考えていた。
Entity、Value Object、サービス。ドメイン駆動設計とはどういうものか? を考えながらの設計というところだろうか…
ソフトウェアはひとつの結果を出すためにさまざまなアプローチがとれる。これはとても楽しいことだ。

15時過ぎからランニング。最近サボらずに続けている。
今日は湘南国際村コース。およそ8kmの高低差の大きな厳しいコース。さすがに筋肉がプルプルしている。

これは頂上付近にある広場からの一枚。
これが湘南国際村からの景色。
これが湘南国際村からの景色。 posted by (C)Satohru

IGESという機関の建物。
IGESかっこいい。
IGESかっこいい。 posted by (C)Satohru

この辺りです。

大きな地図で見る

で、シャワーを浴びて焼酎の麦茶割りだ…

2011年8月27日土曜日

熱海から(その2)

熱海城に登ってみました。
Atami20110811
Atami20110811 posted by (C)Satohru

遊覧船です。
Atami20110814
Atami20110814 posted by (C)Satohru

カモメの飛び方は非常にトリッキーでした。
Atami20110815
Atami20110815 posted by (C)Satohru

Atami20110812
Atami20110812 posted by (C)Satohru

Atami20110813
Atami20110813 posted by (C)Satohru

2011年8月25日木曜日

モデリング、コーディング、そしてテスト



 ソフトウェア開発。久しぶりに自身の手でコーディングしています。流れはこんな感じ…

 Enterprise Architectを使ってクラスを設計する。
 どう設計すべきか迷ったら、UMLからコードを生成してコーディングしてみる。実際の動作を確認することでいろいろ気づきがある。この時、テストとテストデータも一緒に作り、品質を確保するとともにリファクタリングを常に行う。
 書けるだけのコードが書けたら、それをリバースしてクラスモデルにし、まずいところがないか確認しながら既存クラスの修正や新しいクラスを設計していく。
 この繰り返しを行うことで、モデル視点、コード視点、テスト視点でソフトウェアを開発していくことができる。
 取り合えず、今の私にはあってそうなやり方。

2011年8月20日土曜日

熱海から

夏休みに撮影旅行で熱海に行ってきました。
RAW現像できたものから数枚…

これは遊覧船での一枚です。
Atami20110810
Atami20110810 posted by (C)Satohru

Atami20110801
Atami20110801 posted by (C)Satohru

Atami20110803
Atami20110803 posted by (C)Satohru

Atami20110804
Atami20110804 posted by (C)Satohru

右側の薄い雲、羽ばたくカモメのように見えませんか…?
Atami20110805
Atami20110805 posted by (C)Satohru

Atami20110806
Atami20110806 posted by (C)Satohru

Atami20110807
Atami20110807 posted by (C)Satohru

Atami20110809
Atami20110809 posted by (C)Satohru

鏡を使って自分撮り…
Atami20110808
Atami20110808 posted by (C)Satohru

2011年8月15日月曜日

よく見かける花

よく見かける花ですが、なんていう花なんでしょう?
かわいくてきれいですね。

またこの花。
またこの花。 posted by (C)Satohru

2011年8月7日日曜日

甥たち

私にはふたり甥がいる。
姉夫婦の子供だ。

高校3年生の甥は、小学校の先生になりたいそうだ。
この時代、なかなか厳しい世界を選ぶものだと思うが、
本人がやりたいことをやるのが一番。
彼の学ぶ高校は結構優秀な公立高校。
彼曰く、いい子ばかりで平和ボケだそうだ。
今時、いい高校ではないか。

中学3年生の甥は、まだなりたいものが定まっていないようだ。
ソフトウェア開発者になれば、と薦めたら、
「めんどくさい」と言われてしまった。
小説を読むのが好きなようだ。
ひょっとしたらそういう世界が合うかもしれない。

いずれにしても、一度しかない人生、楽しく生きてもらいたいものだ。

私? 楽しく生きているよ。

ひまわり

姉一家が遊びに来るので、マンションの外で待っていると、こんな立派なひまわりが咲いていることに気付きました。

マンションにいつの間にかひ...
マンションにいつの間にかひ... posted by (C)Satohru

2011年8月6日土曜日

業務改善プロジェクト システム化構想立案~要件定義編

 もう14年も見ている我が社の業務だから、どこをどう直すべきかは理解している。しかし、組織のアクションとして実現するためには、私の考えを社に示さなくてはならない。そこで、今回はバリューチェーンを使ってみた。

バリューチェーン
バリューチェーン posted by (C)Satohru

 このバリューチェーン分析によって、各部門の業務の性質やIT成熟度などがとても説明しやすくなり、私の作り上げたアクションプランは社のアクションとして承認された。
 そして2011年4月、具体的に物事を考え始めた。

仕事場
仕事場 posted by (C)Satohru

  1. IT化のスコープはできる限りコンパクトにして、ユーザーと開発者の負担を軽くしよう。
  2. 工程をいくつかのフェーズに分け、成果を確認しながら、成功(失敗)体験をユーザーと共に積み重ねながら進めて行こう。
  3. 今までと違う手法を試してみたい。今回はドメイン駆動設計を軸にしよう。
  4. ドキュメントはイントラネットに公開しよう。

 やるべきこと、やりたいことが湧き上がってくる。しかし、我が社が持つIT系人的リソースは私ひとり(3月までは部下がいたが、諸事情により退社した)。当然というべきか、計画どおり外部リソースを活用することになるのだが、問題はどう使うかだ。
  SIerに丸投げする気など毛頭ない私は、派遣されてくるエンジニアと私の役割分担を考え、ドメイン駆動とユースケース駆動のツイン駆動だ!(?)、というアイデアにたどり着いた。こうすることで、要件定義手法RDRAの関係性の基づく網羅性の確保がより強固になると考えたのだ。

次期プロジェクトの要件定義手法
次期プロジェクトの要件定義手法 posted by (C)Satohru

  このアイデアのもとSIerと協議し、結果としてふたりのSEと私の3人で今回のプロジェクトを開始することになった。
 
 6月。SIerのSEふたりは業務のフローに着目して分析を行い、業務フローからユースケースを導き出すことを最初のゴールと定めた。一方、私は業務の言葉やものに着目し、ドメインモデルとステートマシンモデルを作成した後、ステートマシンモデルのトリガーからユースケースを導き出した。

 プロジェクトを開始して2週間。私は重要なビジネスエンティティを発見した。これにより、業務のつながりがハッキリと見えるようになった。ドメイン駆動設計を意識したプロジェクトは今回が初めての経験だが、その有用性を十分に体感することができた。

 SEふたりの作業進捗はすばらしかった。モデリングはユースケースからロバストネスモデルの作成まで進み、その過程でラフなデータモデルもできあがっていた。また、私は最初の画面スケッチを手書きでノートに記していた。プロセスには拘らず、今考えるべきこと、今なすことが有効だと思われることをどんどんこなしていった。実に楽しいシステム開発である。

 それぞれが導き出したユースケースを突き合わせ、認識の違いや網羅性を確認していった。これがまた楽しく有用な作業となった。ドメイン駆動とユースケース駆動のツイン駆動。その有効性がこの作業で確認できた。ただし、プロジェクト特性を十分に考慮してこの手法は採用する必要がある。小規模でデータ集約型業務のシステム開発には、極めて有効なのではないだろうか。

 ひとまずユースケースが出そろったので、今後の計画作りのためにも、作ろうとしているシステムの規模を見積もることにし、ストーリーポイントによる規模見積もりを実施した。
 0、1、2、3、5、8、13の7枚のカードを3人が持ち、ユースケースに対する相対的な重みをカードを出すことによって示し合うのだ。意見が分かれたときには議論し、最終的にはチームの合意としてストーリーポイントを決める。
 これもまたエキサイティングな作業となった。この際の議論を通じ、ユースケースの突き合わせを行ったとき以上に、認識ギャップを埋めることに成功し、ユーザーにとって価値あることとは何かについて深く議論することができ、時には実装方法についても議論がおよんだ。

 規模の見積もりをすると、それに時間や単価という要素を加えて金額を見積もりたくなるのが人情である。サクッとSEが見積もったところ、32人月・4,000万円弱というような数字が出た。
 おいおい、ちょっと待ってくれ。仮に私ひとりでこのシステムを作るとして、32ヶ月もかかるわけがない。この意見にSEふたりも賛同してくれた。伝統的システム開発手法(請負契約によるウォーターフォール型開発など)は、知識の伝播を行う課程で相当の工数を消費する。そこでチームで議論し、このチームにPG2名を加えてアジャイルな開発をしようということになり、その後の私の再計画では5ヶ月・700万円くらいでリリースできるというシミュレーションがはじき出された。んーん、700万円かぁ。まだ高い…
 ということで、PGを外し、新たに採用する私の部下を加えた4人で開発していくプランを考えることとなった。

 そしてビジネス部門への最終提案。関係者を大会議室に集めて説明、質疑応答、議論と続いた。いい会だったと思う。ユーザーたちも主体的に業務のあり方を考えてくれている。

 このプロジェクトの最も大きな問題点は、直接的なユーザーである現場担当者と、間接的なユーザーとなるマネジメント層の関心事があまりにも違うということであり、私たち開発サイドの提案は、段階的にみんなの要求を実現していきましょうということである。
 業務においてどんな分析をするにしても、データがなければどうしようもない。マネジメント層が持つさまざまな関心事も、結局は現場担当者が作業することであり、それにはパワーシフトを起こさなければならない。
 今回提案したシステムは、いわば基礎工事である。基礎なくしてはどんな建物も建築することはできないのだから… 

 8月。プロジェクトは第2フェーズに入った。この続きはまた今度…