先日、5/20で42歳になったので、抱負、というか今ぼくが課題に思っていること、考えていることをいくつかメモとして書いてみます。技術的なことと、ビジネス的なこと、そして人生についてのことがあります。 1.ソフトウェア工学 ソフトウェアアーキテクチャ、および開発方法論はまだまだ進歩過程にあるが、次の2つのことが最近分かってきており、今後より強く浸透していくのではないだろうか。 ・再利用性、という価値観と、変更容易性という価値観が独立し、これら2つの価値観は別個に発展する。オブジェクト指向をはじめとする設計手法は、再利用性という方向では組織・流通・資産化を含んだプロダクトライン、変更容易性という方向ではリファクタリング、テスト駆動、アジャイル、というそれぞれのプロセスを伴った方向に分化する。再利用性は、設計のみならず、知識の再利用がキーとなりパターンのようなコンテキスト情報を含んだ知識流通形態
ハードウェア開発のフロントローディング、とソフトウェア開発におけるそれの平行概念を考察しています。 http://d.hatena.ne.jp/sakataakinori/20080129/1201620434 TPSのソフトウェア開発への現場適応を実践している坂田さんは、この概念をソフトウェアに持ち込むことについて、慎重に議論しています。 製造と設計が分離されたハードウェアにおいて、 製造時に発生するコストがライフサイクルコストを支配する製造時に発生するコストドライバは設計段階においてつくり込まれる。 フロントローディングとは、この原理に基づく考え方、源流管理の実現によって発生する負荷の前倒し現象です。また、この現象が原価企画の取組みによって制御可能性が高まるために、手法として取り扱われることが多い。というのが、本質だと考えています。 一方 ソフトウェアは、開発と製造が同時一体として進行
継続可能なソフトウェア(sustainable software) というキーワードで、現在のソフトウェアを取り巻く技術や考え方を統合したいと思っています。以下に、メモ。 何がソフトウェアの品質の中心となるか。 ・保守性(EoM)=テスト可能性(EoT)+変更容易性(EoC) http://blogs.itmedia.co.jp/hiranabe/2005/08/post_353b.html このための技術がオブジェクト指向(部品再利用やコード再利用ではない)、という位置づけ。テストしやすい設計、リファクタリングしやすい設計にすること。そのために、言語要素として継承・カプセル化・ポリモフィズムを使う。さらに原則として、DMP(問題領域概念とのダイレクトマッピング)、SRP(問題領域の変更を閉じ込める)などを使う。また、シンプルで愚直な設計をよしとする。 また、プロセスとしてはアジャイルなも
最近、「見える化」という言葉が広く使われるようになった。ソフトウェア開発やプロジェクトマネジメントの文脈において、「トヨタ生産方式」が再度見直されていることが理由の1つであるが、この「見える化」という漢字かな混じり語のベタっとしたインパクトも大きく貢献していると思う。 この言葉からは「現場」や「アナログ」のにおいがする。スマートさからは離れているが、逆に「粘り強さ」や「実践感」といった点で「可視化」という無機質な言葉とは一線を画している。 実は、ここが「見える化」の肝であり、物理的な「モノ感」であったり、体を使った実践的な「行動」に繋がってはじめて見える化なのである。つまり「見える」だけでは「見える化」とはいわない。そこから喚起される実際の物理的な感触が、問題の解決にむけた身体的な行動を生み出してはじめて「見える化」なのだ。 そういう意味で、「何のための見える化か?」ということは、常に問わ
結城さんの、「ソフトウェアは、私たちの想像よりもずっと複雑」を読んで。 http://www.hyuki.com/d/200606.html#i20060616093839 本を書く、という行為の中で結城さんが至った一つの結論は、執筆活動は章立てや理論的なブレークダウンで進んでいくのではなく、「具体的な本文を書き出す」ことが、必要だ、ということ。以下、引用。 本全体のテーマを決める。つぎに各章の内容を考える。全部の内容が決まったら、さらに詳細な内容を考え、節ごとにブレークダウンする。全体の節が出来たところで、いよいよ本文を書き始める。こんな風に、まっすぐな流れで詳細化が進み、その結果として最後に完成する――というふうには進まないのです。 本全体のテーマを決め、各章の内容を考える。まあここまではよい。その次の有効な一手は、「さらに詳細な内容を考える」ことではなく、「本文をいきなり書いてみる」
当サイトは、UMLとastah*(旧JUDE)及びマインドマップに関する情報の共有によって、ユーザーとastah*が共に成長するための場であり、またUMLやマインドマップに関心を持つ全ての人々にとっての入り口となることを目指しています。 製品名称の変更に伴い、当サイトもastahへ名称を変更しました。2009年10月以前の書き込みには、JUDEに関する内容が含まれるため、最新の状況と異なるものがあります。ご了承ください。 当サイトにユーザー登録されると、次の機能を利用できます。 新規トピックまたは返信の投稿があった場合に通知する ユーザー同士でプライベートメッセージを送信 なお、ライセンスの登録や再送、各製品のダウンロード、製品サポートについては、ChangeVisionメンバーズサイトをご利用ください。
Web2.0とは何かを定義するのは難しいが,大きな流れとしてテクノロジからビジネスへと多くのエンジニアが視点を移していることは間違いないだろう。言語,設計,コンパイラ,ライブラリ,といった要素技術から,SOA(Service Oriented Architecture)の視点,例えばGoogle APIをどのように使ってサービスをミックスし,新しいビジネス価値を提供できるか,というサービスの視点がより時代に合ったものになっていると思う。エンジニアがビジネス・モデルに関心を示し,ビジネスの言葉で技術を語るようになってきているのだ。さらに,アジャイル開発の考え方が浸透し,「ビジネス価値(Business Value)」を開発の最優先とする考え方が広まっているという背景もある。 この連載では,このような時代におけるソフトウエア製品開発にはどういった視点が必要か,また,その開発はどのような手法によ
前回の記事で、ソフトウェア開発における「分析」「設計」とはそれぞれ、なんであるか、ということを、問題解決、という観点、および、現実・モデルという観点から説明した。 さて、UMLである。… UMLは、当然、Modeling Language なのだから、【モデル領域】をカバーするものである。UMLのカバー範囲を、黄色で図示した。ただし、現在のUMLは、問題の分析にはとても非力だと思っている(ちなみに、UMLの"U"は、"Universal"ではなく、"Unified"であり、羊頭狗肉という訳ではない)。 そして、MDA(Model-Driven Architecture)である。…(sign) MDAでは、PIM(Platform Independent Model)を元に、アーキテクチャ記述にあわせて実装が「自動生成される」(らしい)。それはそれですばらしいことだとは思う。しかし、当然、現
JUDEのプライベートセミナーの盛況ぶりをお伝えしたが、最近のぼくのソフトウェア開発と営業に対する考えを書いておこうと思う。これは、理論的に正しいとかカッコいいとかいう話ではなく、ビジネスパースンとして。 ぼくはソフトウェア開発が大好きです。 自分がいい、と思うもの、役に立つと思うもの、気持ちのよいもの、そういうものがあれば紹介するし、なければ(ソフトウェアであれば)どんどん作りたいと思う。その気持ちがとても強い。ただ、開発者は、ともすると、独りよがりになってしまい、「売れない」ものを作ってしまうことがある。売れないものを作ることは、それが趣味や研究であれば、まったくOKだ。ただ、 ぼくは幸せなことに、ソフトウェア開発を「仕事」に選んでしまった。だから、「良いものが売れる」、という考えは捨て、「売れるものが良いもの」という考え方をしている。 そして、売れるためには、と考えて開発している。今
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く