<< 将来像を語り続ける 【パターン】 | main | 健全に成長するシステム >>

事業の言葉 【パターン】

「全体」のパターン


システム設計で、健全な「全体」を作っていくためのパターン言語(の一部)。

今回のパターンは、「事業の言葉」

事業のためのソフトウェア


エンタープライズの情報システムは、「事業の言葉」を使って、関係者で話し合い、実装のコードも、事業の言葉で記述する。

サブシステムの分割や、サーバーの配置も「事業の言葉」で検討する。
システムの開発体制、技術者の担当分けも、「事業の言葉」で、考える。

事業のためのソフトウェアシステムが、どうあるべきかを表現するのに、もっとも適切なのは、「事業の言葉」。
技術用語ではない。

「協調分散」、「クラウド」、「アジャイル」、「オープンソース」、...。

どれも、事業のためのソフトウェアのあるべき姿、目指すべき「将来像」を語る言葉として不適切。

経営者が「アジャイルな経営を目指す」という理念を熱く語る人なら、「アジャイル」は、エンタープライズのソフトウェア設計の用語として、適切。

一行一行のコードも、事業の言葉に


「事業計画」とか「事業方針」にでてくる言葉が、ソフトウェアのコードの隅々でも、登場するのが、健全なエンタープライズアプリケーションソフトウェアなんだ。

たとえば、 Java のクラスの一行目のパッケージ宣言。

package humancapital.candidate.career

というのは、人材関連の事業を営む企業の、人材(候補)の、経歴を表現するためのソフトウェアパッケージ、ということ。

事業戦略が、良質な(高く売れる)人材候補をできるだけ多く獲得すること、かつ、「良質」の定義が、そのヒトが、どの業種で、どんな仕事をしてきたかが、一番のポイントになる、ということであれば、このパッケージが、その事業にとっての、コアのドメイン。

あるいは、career ではなく、skillset で、マッチングをしたほうが、良い、という事業方針であれば、

package humancapital.candidate.skillset パッケージにハイライトをあてる。

スキルセットを、どう表現するか、スキルセットで、検索する、というのは、どういうことか、...

これは、ソフトウェア設計の課題であると同時に、「事業をどう営むか」という、事業の課題そのもの。

「事業」という枠組、方向性を、具体的に、意識することが、「情報システム全体」を、健全に、成長させていく、基本のパターンになる。

事業の言葉で、システムを設計した経験


多くの開発現場の実情は、「事業の言葉と、ソースコードの一行が、直接関係する」という感覚は、ありえないこと、あるいは理解不能な発想かもしれない。

私自身は、10年ほど、まえに、DeNA さんや、ES Books というインターネットビジネスのスタートアップ企業のシステム開発に参加したとき、それは、現場のナマの体験として、そこに実際にあったことなんです。

DeNA も、ES Books も、経営幹部が、ソフトウェア開発の現場での議論に参加していたし、どうやって事業を立ち上げるかの議論と、ソフトウェアの設計が、ほとんど、いっしょにやっていた感じ。

こういうサービス機能で勝負したい、という経営幹部、サービス企画責任者と、コードを実際に書いている人間が、同じテーブルで、議論をするのが、あたりまえだった。

事業を立ち上げ、成長させるための格闘を、事業責任者、サービス企画担当者、ソフトウェア開発技術者が、一体となったチームで、実際に行っていた。

ソフトウェアは、事業のための道具・武器である以上、ソフトウェアシステムは、「事業の言葉」で設計すべき。

ソフトウェアシステムの「将来像」(ありたい姿)を、「事業の言葉」で、「語り続ける」ことが「成長し続ける全体」を実現する道。

情報源


Eric Evans DDD の「ユビキタス言語」パターンが、直接関係している。

「ドメインの言葉、概念、発想」というアイデアを、「エンタープライズアプリケーション」という文脈で使うとき、ユビキタス言語は、「事業(=エンタープライズ)」の言葉になる。

大手のコンサルティング会社などが、情報システムも、事業戦略から設計すべき、というような方法論を説いている。

ある部分は、同じ発想。ある部分では、対極的。

情報システムは、事業戦略を実現するための手段、という発想は同じ。「事業」が主である。

「事業の言葉」を「一行一行のコードレベル」で、表現していくべき、というのは、大手コンサルティング会社の方法論には、無い発想だと思う。

コメント
「成長しつづける全体」「事業の言葉」「将来像を語り続ける」「不健全さを取り除く」
ここ最近の記事を読んで分かった気にもちょっとなっているのですが、なんだろうなあ、なんか足らないと感じているのかな。。なにかがしっくり来てないのかな??なんだろう。
#うーん、自分で書いていてよくわからん。自分で何かを足してみるか?
yamauchi さん

コメントありがとう。
私自身も書いてて、もどかしいところはあります。
自分では、その理由は2つあると思っている。

1.モノづくりの楽しさ

動くシステム、ワーキングソフトウェアを作ること自体、楽しいし、自分が、この仕事をしている根本は、その楽しさにあると思う。

「動くソフトを作るのは楽しいね」とモチベーションがちょっとかけていないかな。

2.各論・具体論

一般論になっちゃっているし、具体的なソフトウェア開発の作業レベルからは、だいぶ遊離している内容。

まあ、どちらも「仕組み」とか「細工」のパターンの話しになれば、もっと、身近なテーマとして、興味を持ってもらえると思う。
コメントする









この記事のトラックバックURL
トラックバック
calendar
  12345
6789101112
13141516171819
20212223242526
2728293031  
<< May 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