育成型のソフトウェア

最近、ソフトウェア開発で、いろいろ考えているキーワードが、ソフトウェアを「育成」すること。

受託開発ビジネスだと、リリースが大きなゴール。昔は、リリースしたら、ソフトウェアはできればいじらないのが一番。


  • 変更のコスト

  • 期待できる効果

  • 変更のリスク



を勘案すると、リリースしたソフトウェアは、できるだけいじらないのが基本。

でも、最近は、このロジック、通用しなくなってきているみたい。

要求の変化



顧客も、競合も、インターネットやモバイルなどの IT も、変化しつづけている。

この環境だと、リリース時の状態でストップしたソフトェアは、あっというまに価値が下がっていく。

あるソフトウェアをリリースして、それまでは、できなかったことができるようになる。ユーザは喜んでくれる。
でも、そのソフトウェアが当たり前になると、今度は、もっと、こうならないの?という不満のネタになる。

まあ、浜の真砂はつきるとも、世に要求のタネはつきまじ。

技術・ノウハウの進歩



そういう、変化への対応の要求が強いと、造る側でも、いろいろな技術の改良が進む。


  • 変更のコストを下げる技術

  • 期待できる効果を大きくする技術

  • 変更のリスクを小さくする技術



技術的なキーワードは、


  • ドメイン駆動

  • アジャイル開発

  • 軽量なアーキテクチャ



ドメイン駆動



問題領域の知識を、いかに深めて、いかに、ソフトウェアに実装する。その哲学と実践ノウハウ。

知識は、その領域で、いろいろな経験を積めば積むほど、広く、深くなっていく。
環境が変われば、知識がさらに増えたり、変化していく。

こういう知識の変化・増殖を、絶え間なく、ソフトウェアに反映しつづければ、そのソフトウェアの価値は高まり続ける。

アジャイル開発



形式的なやり方ではなく、必要なことを、必要なだけ、必要な時にやる。その哲学と実践ノウハウ。

いまは、要件定義は、RDRA、開発は、 ICONIX 、ラストワンマイル(配置)は、CI (継続的インテグレーション) と、して取り組んでいる。

これは、開発のスピードをあげ、コストを下げるの方法として、手ごたえ十分。実践できていることは、Best Practice から、ほど遠くても、それでも、かなり効果が実感できている。

特に、ソフトウェア変更のスピードやコストの改善は、すごい。

軽量なアーキテクチャ



J2EE が、いちじ、ヘビー級指向だったけど、Spring フレームワークとかが、軽量であることの価値にこだわって活動をしてくれたおかげで、アーキテクチャも軽やかなものを選択できるようになった。

オープンソースの、サーバー、フレームワーク、ライブラリも、軽量指向のものが増えて、また、成熟してきている。

安心して使える、までは言いすぎだと思うけど、十分に実用的になっている。

ハードウェアやOSも、Amazon EC2 とかで、好きに時に、好きなだけ使える良い時代になった。

プロジェクトの初日に、フルセットの開発環境、リポジトリ、ビルド環境を、インターネット上からリソースかき集めて、インターネット上に構築する、なんていうことを、実際にやってみると、ほんと、時代が変わったと思う。

ハードの調達、ベンダーからソフトウェアの購入、...などにどのくらい貴重な時間をロスしていたことだろう?

ソフトウェアを育成する



要求側の変化への強い圧力、造る側の技術革新、これが、重なって、ソフトウェアを育成することが、良いソフトウェア、役に立つソフトウェアを提供する、有力な手段になってきた。

今は、まだまだ、変更のコストは高いし、リスクも大きい、期待効果は小さい、のが現実。
でも、あきらかに、経験を積むたびに、コストが下がり、リスクが小さくなり、変更の効果が大きくなっている。

この「ソフトウェア育成」の哲学と実践ノウハウの獲得にしばらくこだわってみようと思う。

今年のチャレンジテーマ

今年は、新しい仕事にもチャレンジしたいと思い、動き始めてみました。
少しずつ、方向感と動きがでてきた感じ。

去年は、国際B2Bの会社と、転職サイトの会社をかけもちで、チーフアーキテクトと若手の育成がおもな仕事。ちょびっと、自分でコード書いたりもしていた。( Hands-on アーキテクトなんで )

今年も2社の仕事は続いている。特に、B2Bのほうは、追加の案件がいくつか控えていて、それなりに忙しそう。

この2つの会社の仕事をやりながら、仲間たちと、いろいろな成功や失敗を繰り返してきた。また、書籍やオープンソースコミュニティを漁って、外部の技術情報の勉強もそれなりにやってきた。

こういう中から見えてきたこと、手に入れたノウハウを、もうちょっと整理して、他の人も使いやすい形で提供してみよう、というのが今年の目標。

ビジネスとしては未知数だけど、現場で役に立つ実用的なサービスを、リーズナブルな価格で提供できればと思っています。

テーマは、大きく四つ考えている。

・ドメインモデリング
・アジャイル開発プロセス
・ワークベンチ(開発の場)
・アプリケーションプラットフォーム(実行環境)

ドメインモデリング

これが駆動エンジンですね。
役にたつソフトウェア、価値のあるソフトウェアを作るには、ドメインの理解が基本中の基本。

DDD(ドメイン駆動設計)のアプローチとテクニック、REAビジネスパターンとアナリシスパターン。
これを元ネタに現場で、いろいろ試行錯誤してきた内容を、できれば、現場でいっしょに開発しながらトランスファーできたらよいな、と思っている。

どれも最初な難解だったけど、現場で試行錯誤しながら、だいぶ消化できてきた感じがするんですよね。

アジャイル開発プロセス

まず、要件定義から開発までは、神崎さんの「RDRA(リレーションシップ駆動要件定義)」と ICONIX の組み合わせに手ごたえを感じている。

実践的だし、実用一点張りの感じがとても気にっている。(形式的な方法論ではない)

現場で若手に分析や設計の仕事を教える時に、いろいろ苦労してきた。この2つの方法論に出会ってから、驚くほど、分析・設計の仕事を教えやすくなった。

アジャイルといえばXPが有名だけど、現場で教えるには、ちょっとむずかしい。(私には、無理)

プロセスの後半は、配置と運用。

配置については、 One Click Deploy を目指して、試行錯誤中。
運用も、自動運転フレームワークみたいなものを試行錯誤中。

これも、現場のプロジェクトに入り込んで、いろいろノウハウや失敗談をトランスファーできればよいな、と思っている。

ワークベンチ

方法論の実践の場として、やはり、開発環境は、重要。

特に、アジャイルの方法論を実践するには、

・リポジトリ(情報のストック)とコミュニケーション(情報のフロー)
・テストのセットアップ・実行・クリーンアップの自動化

など、ツールをうまい使い方が成功のポイント。

こういう作業環境って、以外と立ち上げて活用するのがたいへんなことが多かったので、そこらへんのノウハウを外部に提供して、活用してもらえなかな、と考えている。

アプリケーションプラットフォーム

ひとつは、Webアプリケーションのプラットフォーム。
これは、Spring, iBatis, velocity で、かなりパターン化できてきた。
( PoEAA の実践編という感じ)

もうひとつは、システム間の連携のプラットフォーム。

RESTful 系というか、 XML over HTTP の軽量なやり方がてごたえ十分。
あとは、製品だけど、Asteria Warp Light パイプライン もすぐれものです。

これも、わかってしまえば簡単なことも、立ち上げのときは、かなりたいへんだった。
ここらへんのノウハウも、提供してみたい。

ちょっとした活動拠点も確保できたし、今年はいろいろチャレンジの年にしたいと思っています。


シンプルさがたまらない Google Chrome

この三日間ですっかり Google Chrome を気に入ってしまった。

とりわけ気に入っているのが Webアプリケーションのショートカット機能。

パソコン上のアプリケーションをデスクトップに置くのと同じで、良く使う Web アプリケーションのページをデスクトップに置いておける。
この機能を使い始めて、改めて気がついたのが、パソコン上のアプリはほとんど使っていないということ。

デスクトップ上は、すでに Chrome で作った Web アプリケーションへのショートカットが多数派になってきた。

もちろん、このブログの管理者ページもショートカットから。

Chrome のショートカットは、起動も含めて画面表示までがめちゃくちゃ速い。

そしてもっとも気に入っているのは、ショートカットから開いたページでは、URLのボックスを含めて、余計なメニューやアイコンが一切ないこと。 その Web アプリケーション専用の Window が開いている。
画面が広いし、目障りなものはないし、とても心地よい。

ブラウザが脇役で、Web上のアプリケーションと情報が主役という明快なコンセプトで作られたツールであることが良く分かる。

パソコンの時代ではなく、ネットワークの時代ということを改めて実感した。

そして、シンプルであることが、こんなに気持ち良いというのは新鮮な驚きでした。
ソフトウェア開発に従事する者として、 改めて Simple is best を再認識しました。

シンプルだから役に立つ Google Chrome

Google Chrome を使ってみて、すっかり気に入ってしまった。

シンプルなのが良い。

IE や Firefox で、私がめったに使わないメニューやアイコンは全くない。
画面がとてもすっきりしている。

機能の多さで競争しがちなソフトェアの世界で、後発なのに、シンプルな機能で勝負してきた Google の発想に敬意を表したい。

URL 入力と Google の検索ボックスを一つですませているのはとても実用的。
他のブラウザ+Google バーより数倍使いやすい。

新しいタブを開くと、良く使うページがサムネイルで選択できるのも実用的。

ブラウザの使い方という問題領域を深く検討した成果を生かしたソフトウェアだと思う。

役に立つソフトウェアとは、機能の多さではなく、使う人のニーズにぴったりあった、ソフトウェア。

ブランザのメニューやアイコンをめったに使わない私のようなユーザにとっては、Chrome のシンプルだけど、必要なことは全部そろっている設計は、良くできていると思う。

役に立っていた(?) google

google は、昔はすばらしかった。

私は Java とか Struts とか技術情報の検索が中心だった。検索結果は、ほぼ自分が見たい順に表示された。 I'm Feeling Lucy ボタンが意味があった時代。

今は、ノイズが多くて、検索結果から見たいページを探すのに、手間取るようになってきた。まあ、単語を複数組み合わせると絞れるけど、見落としページも増える。そもそも単語をいくつも入れるのは面倒。

google は昔に比べれば、役に立たない情報が増え、機能も役に立たなくなってきている。

私は、どちらかというと公式情報、体系的に整理された情報、論理的な文章のページを探していることが多い。この傾向は、google 側で検知できるはず。 こういう個人的なバイアスを理解して、注目ページにマーキングしてくれたり、フィルタリングがワンクリックでできると、google はもっと役に立つソフトウェアになる。

これは、全ユーザごとの好み、という意味ではありません。 google の使い方としていくつかパターンがあるはず。ユースケースですね。そういうパターンを知識として検索ロジックに組み込んでくれれば、もっと役に立つソフトウェアになりそうということです。

役に立っていない Outlook

会社では、メールソフトは、Microsoft Outlook.

役に立っています。メールでやりとりしている情報は、仕事に必要な情報ですから。でも、役に立っているのは「データ」が役に立っているからです。

プログラムとして Outlook は役に立つソフトウェアではない。

自分がやりたいことが、簡単にできるようになっていない。
メールを整理したいんだけど、整理のしかたがとにかく面倒。

一覧の並べ替えメニューだけで13アイテムもある。おまけに、カストマイズ機能まで付いている。

差出人で探したい時に、並べ替えてスクロールとか、検索条件入力とか、余計な作業が必要。

メールの多い順に差出人のリストがあって、差出人をクリックすると、日付け順にならぶ、特に最近3日以内。

最近3日も、営業日ベースが良いな。営業日以外は受信メール数は極端にすくないから、メールの数だけで営業日を判断してくれれば役に立つ。

仕訳ルールも恐ろしく面倒ですね。
キーワードを指定したら、ワンクリックで、件名や内容にその単語を含むメールを、キーワードを名前にしたフォルダを作って、勝手に放り込んでくれれば十分なんですけどね。

ウィザードは(ソフトェアが)私は馬鹿です。何も知りません。しつこく質問させてください。という象徴で、私は大嫌いです。

メールの実務的な使い方の知識(問題領域の知識)をソフトウェアが知っていて、ワンクリックでそういう操作ができると、役に立つソフトウェアになるんですけどねえ。

役に立つソフトウェア : プログラムとデータ

ソフトウェアは、プログラムとデータですね。

役に立つデータ

役に立つデータと役立たないデータがある。どんなデータが役に立ち、どんなデータが役に立たないかは、業務側の価値感ですが、その価値感を開発者が理解できれば、ソフトウェアの価値は確実に向上する。

開発者が作るテストデータは、業務に役に立たない、意味がないことが多い。そんなデータでデモすると、プログラムが良くても、役に立たないソフトウェアに見えるということが気がつかない。
乱暴に言えば、少々のバグがあっても、仕事に必要なデータが簡単に手に入ることがわかれば顧客は、そのソフトウェアに満足する。

どんなデータが、顧客が喜ぶデータかを理解することが、役に立つソフトウェア開発の基本事項だと思います。

開発は可能な限り、実データを使う。業務的に価値のあるデータ、問題があるデータ、フィルターしたい(価値のない)データを、業務の現場から集める。

そして、開発したソフトウェアが役に立つ情報を表示できているか、顧客の反応を観察する。あるいは、おしゃべりする。 画面の Look & feel よりも、データの中身のほうが重要です。

役に立つデータに敏感になるポイント

・検索結果の順番は「役に立つ」順になっていますか? 顧客と確認しましょう
・プログラムの検証用のデータは、顧客にとって魅力的なデータですか?

検索結果のトップは、一番役に立つデータがうれしいですよね。
動作確認も、実データでリアルに使えれば、やりやすですよね。

役に立つプログラム

役に立つプログラムは、業務の知識、問題領域の知識を豊富に適切に組み込んだプログラムです。

ドメイン駆動設計 ( DDD : Domain-Driven Design ) は、そのためですね。
XP で、ユーザストーリーを元にして、顧客と話をするのも、 ICONIXプロセスで、ドメインモデリングをやって、顧客と話をするもの、すべて「業務知識」を正しく豊富に組み込んだプログラムを作るためです。

ソフトェアが、業務の常識を持っていれば、こんなにありがたいことはありません。

動くソフトェアを作ってから、顧客と確認するのでは遅すぎます。
プログラムを書き始める時に、自分は顧客にとっては常識の「業務の知識」「問題領域の知識」を理解している、という手ごたえがあって開発をしていますか?

ビジネスロジック、ドメインロジックは、ソフトウェアのレイヤ構造の議論のネタではありません。顧客にとって役に立つソフトウェアを作るための、中核の課題なんだということを、いつも意識しましょう。

業務上、重要な機能をまず最初に作りましょう。作る都合で順番を決めない。
いちばん優秀な技術者をいちばん重要な機能の開発に割当ましょう。

顧客にとって、これが一番重要だと、開発者が考えるものを、顧客に提案する。
それがぴったり一致すれば、顧客からの信頼感が高まります。
もしずれていたら、作る前にそのずれが発見できたことを素直に喜びましょう。
苦労して作った後で、ろくに使われないことが分かったら、めげますよね。

何がもっとも重要な機能かの確認作業。 業務知識の獲得の第一歩です。

役に立つソフトウェア

会社に入って2年目に、はじめて書いたプログラムが原価のシュミレーションシステム。開発部門ではなく、工場の原価計算部門の事務屋としての仕事。

既存の原価計算システムはまったく役に立たない。しょうがないので、表計算ソフトを使って簡単なシュミレーションシステムを書いたら、効果抜群。

3日かかっていた作業が、ものの5分で済むようになった。一番のポイントは「原価計算のやりかた」をソフトに埋め込んだこと。特に「みなしで計算する」項目とか「とりあえず無視」できる項目とかの「業務知識」。

既存の原価計算システムが役に立たなかったのは、詳細な原価データ、原価計算ルールを、網羅的に詳細に設定することが絶対条件だったから。しかも、計算途中で矛盾が起きないように、人間が、設定データの整合性を検証する必要がある。一箇所でもモレや矛盾があれば、大量のエラーメッセージ。 エラーが起きても中断もせず、すべての計算を最後までやろうとするものだから、エラーメッセージ量のすごいこと。

私が作ったパソコン上のシステムは、業務上、致命的でないエラーやデータ不明箇所は、適当な値をセットしたり、計算を省いたりして、それなりの答えがでるようにしていた。

この原価のシュミレーションは、特殊な半導体や基板の原価が大きな変動要因なので、それ以外の要素は、それなりの値が入っていれば十分に役に立つ。

今から考えれば、ぐしゃぐしゃのプログラムだったけど、業務に、ほんとうに役に立った。 現場では当たり前の業務の知識を少し書いただけで、手作業がほとんど自動化できた。徹夜で再計算が当たり前だった職場で、みんなで定時退社ができちゃうんだから、ほんと革命でした。

これが、私のソフトウェア技術者の原点になっている。

「役立つソフトウェア」を作ると回りの人が喜んで使ってくれた。そういうプログラムを書いた私は、天才扱い、神様扱いですよ、ほんと。(最初だけですけどね)

結局、原価管理のプロではなく、ソフトウェア開発を仕事にするようになったわけだけど、「役に立つソフトウェア」を書きたい、使う人に喜んでもらいたい、というのが、私の原点だし、今でも追い求めていることです。

calendar
1234567
891011121314
15161718192021
22232425262728
293031    
<< July 2018 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM