静養終了

ブログを書く間もなく？忙しい日々を送ったせいか、ちょっと病院にはいっちゃいました。

今週はちょっとリハビリモードで仕事をしてました。（今週の目標は毎日会社で半日以上仕事をすることでした。）

まあ、かなり復活した感じではありますね。。ぼちぼちいきますか。

2009
06/05
CATEGORY
プライベート
コメントを書く

ビジネスソフトウェアの「ラストマイル」

実際にシステム開発に携わるエンジニアには超おすすめの本をご紹介します。

ThoughtWorksアンソロジー

あのマーチン・ファウラーも所属する、ThoughtWorks社のエンジニアのみなさんによるエッセイ集です。
この本では、システム開発の様々なシーンについて、とても実践的に書かれています。
また、当然かもしれませんが、それぞれ書かれている内容はとてもレベルが高いです。

ここに書いてある内容を一つ一つ実践していくだけでも、自分たちのチームはすごくよくなるのではないかと思えるほどです。

まずは、創業者兼会長のRoy SinghamとMichael Robinsonによる、”ビジネスソフトウェアの「ラストマイル」を解決する”について書いてみます。

ビジネスソフトウェアは「稼働」しなくてはいけません。文字通り、「働いて」「稼ぐ（価値を提供する）」という段階に入って、開発プロジェクトはゴールとなります。では、その「ゴールまでのラストマイル」とは何を指すのでしょうか。
”ビジネスソフトウェアの「ラストマイル」”の内容を、この本の表現から引用してみます。

この「ラストマイル」というのは開発プロセスにおけるフェーズの１つであり、ソフトウェア機能要求を満たすところまで完成していながら、まだ稼働に入らず企業に対して価値を提供し始めていない段階に相当します

「ソフトウェア機能要求を満たすところまで」完成した後行う「開発プロセスにおけるフェーズ」とはなんでしょう？このエッセイにも記述されていますが、例えば、次のようなことが挙げられます。

  • システム統合（レガシーシステムとの連携など）
  • データ移行
  • 配置（あるいは、配置するための依存関係や前提の把握）
  • 非機能要求のテスト（性能、可用性、セキュリティ）
  • ユーザ以外の利害関係者の対応（サポート、運用、監査）

この「ラストマイル」がコストが高くつく最大のボトルネックになりつつある、と書かれています。

私の経験から言っても、確かにこの領域ではエンジニアはさまざまな能力を求められます。

システム統合するためにはレガシーシステムを（少なくともある程度は）知らなければなりません。
また、データ移行するための新旧システムのデータ内容をよく理解している必要もあるでしょう。
配置するためのシステム要件については、ミドルウェアやＯＳについてもさることながら、それらを利用して自分たちのソフトウェアがどう動いているかもよく知っていなければなりません。

この領域には単にコードを書くだけでなく、幅広い知識や適切な判断ができる、いわゆる「できるＳＥ」をあてがう必要がある領域です。だからこそ、コストが高い領域でもあるのです。

このエッセイでは、この「ラストマイル」問題に対して、開発プロセスにかかわるすべての人々が着実に取り組むべきだと書かれています。「ThoughtWorksアンソロジー」では、この問いに対して、さまざまなＳＥがさまざまな開発シーンでの対処法を書いていると言えるかもしれません。

system-enablersでも、これらの「ラストマイル」を埋める内容を考えています。
この領域についても、何かしら提供したいですね。

2009
02/22
CATEGORY
ThoughtWorksアンソロジー
system-enablers
コメントを書く

設計ツール

みなさんはシステム開発上のいろいろな設計を行うとき、どんなツールを使っていますか？

私がエンジニアになったころは、ブロックシートに テンプレート定規でデータフローを書いたり、大きなスペーシングチャートに「X」とか「9」なんかを記述して画面設計や帳票設計をしたりしていました。 とっても手作業な時代でしたね。そのあとワードプロセッサで設計書を書くようになって、「おおすごい」と思ったものです。

そのあとは、 Excel等のスプレッドシートを多く使うようになりました。セルをブロックシートイメージで小さく区切って使ってみたり、Excelのオートシェイプで フローチャートやDFDを書いたり、DBの項目表を作ってマクロでDDL文を作ってみたりと、いろんな用途に使っていた覚えがあります。

時代は流れて、今は専用の設計ツールを使って設計する時代になりました。

私の場合は、お絵かきにJude Communityを使う場合もありますが、主にはEnterprise Architect（以下EAと略す）を利用するシーンが断然多くなりました。

—

EAは、リンク先のページを見てもらえばわかりますが、とても多機能です。
UMLからコードを生成したり、データベースの解析をしてくれたりと、ありがたいことだらけなのですが、
一番気に入っているのは、複数人数での設計にUMLを利用したいというケースに有用な点です。
今現在のプロジェクトでもそうなのですが、設計リポジトリをメンバー間で共有できることの威力ははかり知れません。

特に、複数の会社で開発を進めたり、遠隔地に開発メンバーがいる場合には、設計リポジトリの共有はとても有効な手段となります。

—

また、有用なツールは、開発手法も教えてくれます。
例えば、今現在、注目しているICONIXプロセスではEAを使うことを推奨していて、EA用のアドインを提供しています。

  • ロバストネス図を作成する
  • ロバストネス図からシーケンス図を作成する
  • ロバストネス図からテスト項目を作成する

といったものです。「Doug Rosenberg氏よりメッセージ」にも図が載っていますが、ロバストネス分析は、ユースケース駆動で分析した結果をどう実装するかを考える「予備設計」にあたります（詳しくは「ユースケース駆動開発実践ガイド」あたりを読んでみてください。）。要件からいきなり設計しようとするから失敗する。「そうだ、こんなケースを考えるの忘れてた」なんてことよくありませんか？（ICONIXプロセスチックに言うと、「雨の日のシナリオ」や「代替コース」）

このように、ツールを導入することで、設計の不備を補完し、品質を上げる手助けになります。

他にも、以前に紹介した要件定義フレームワークのRDRAもEAのテンプレートを提供しています。
このテンプレートをまず自分たちの仕事に適用するだけでも、「ツールやテンプレート」が自分たちの要件定義に「何が足りないのか」を教えてくれます。

—

「プロは腕も持っているが、道具も持っている」ものです。

わたしたちもプロの道具を上手に使って、いい仕事をしたいものです。

2009
02/03
CATEGORY
ICONIXプロセス
RDRA
system-enablers
コメントを書く