前編「マインド・マップの基本と応用」の最後で、マインド・マップとUMLを融合させるというアイデアに触れました。その中で、発散と収束という思考活動の分類を紹介しました。 思考の発散・概念の収集過程（要求ギャザリング）では、マインド・マップを用い、思考の収束・概念のモデル化過程（要求モデリング）では、UMLを用いる。 しかし、実際にマインド・マップとUMLをどう使い分けて、どう連携させていけばいいのでしょうか。役割分担としては、マインド・マップを使って情報を書き留め、UMLを使ってそれを整理するということになります。しかし実際の手順を見てみないことには、イメージがわきにくいでしょう。また、UMLはツールを使って描くことが多いですが、ツールの使い勝手も考える必要があります。 そこで後編では、マインド・マップでお客さんとの打ち合わせの議事録を取り、その結果をUMLダイヤグラムにまとめていく流れを具

前回（第2回 「なにはともあれ、まずはチームビルディング」）はチームの基本的な作り方を解説しました。今回のテーマはチームの運営に不可欠な「会議」の上手な行い方です。 会議・会議・会議 プロジェクトにかかわる以上、会議は避けて通れません。特にリーダーなら、なおさらです。いままでは、どこかしら「関係ないや」と感じていた会議にも参加しなくてはいけません。会議にも大小さまざまありますが、今回はその中から、「朝会」「進捗（しんちょく）会」を取り上げて、それぞれの運営のコツをお話しします。 ・朝会 まずは小さな会議代表として、朝会です。朝会は、チームの状況をチーム内部で素早く共有することを目的とした、非常に短時間の会議です。最近何かと話題の朝会ですが、その理由として、「手軽に、すぐに始められる」「効果が見えやすい」「ソフトウェア開発チーム以外にも有効」などがあるでしょう。以下、概要だけ説明します。 朝

テスト現場の生の声をお伝えするために ソフトウェアテストに片足だけはまっている人、頭からつま先までずっぽりはまっている人……、テストとのかかわり具合はエンジニアによってそれぞれでしょうが、テストと全然かかわりを持たないという技術者はおそらくいないでしょう。テストへの取り組み方は十人十色なだけに「テスト」と聞いて、自慢するのか愚痴をつぶやくのか、あるいはきびすを返して逃げ出そうとするのかいろいろな反応があると思います。 立場こそ違いますが、テストが大事だという認識はほとんどのエンジニアが持っていると思います。しかし、プログラミング手法や開発手法などのように、スキルアップのための材料が簡単には得られないという印象を（テストに対して）持っているエンジニアが多いようです。テストに関する日本語の情報は豊富とはいい難いのが現状ですし……。 「テストに興味を持って活動しているエンジニアは、テストのことを

今回はUMLよりOCL 今回は、UMLではなくUMLモデルを補助しそのモデル要素にかかわる制約を正確に表現することを目的に導入されたOCL（Object Constraint Language：オブジェクト制約言語）について簡単にご紹介しましょう。 なぜUMLだけでは足りないのか 皆さんの中にはUMLさえあれば、オブジェクト指向でモデルを完全に記述できるのではないかとお考えの人も多いでしょう。実際、UMLを利用することで、自然言語のあいまいさを減らして業務領域やシステム化対象の構造をより正確に表現できたり、逆にJavaで書いた何万行ものソースコードそのままよりは、それらのコードの構造や振る舞いを抽象化してビジュアルな全体感を持つのに有効そうと実感されているエンジニアの皆さんは多いと思います。 しかし、ビジュアルなモデルだけでは表現できない内容が普通に存在します。それは、クラス図がインスタン

フレームワークのStrutsとJSFは目的が似ている。しかし、JSFは後発ながらJCPのJava標準規格として登場した。新たなテクノロジーは、完全に補完する役目を担うのか？　コードベースで徹底比較していく。 2003年、Sun Microsystemsから次世代Webアプリケーションフレームワークとして「JSF」（Java Server Faces）が発表された（関連特集記事）。 Webアプリケーションフレームワークといえば、オープンソースであるApache Software Foundationの「Struts」があまりにも有名であり、既にデファクトスタンダードと呼べる地位を築いている。しかし、StrutsもJSFもJavaテクノロジーによるWebアプリケーションフレームワークであり、サポートする領域は似ている。なぜ、今JSFが必要なのか？　StrutsとJSFを比較しながら最新事情を探

ソフトウェア開発チームを構成するメンバーは大きく2つの種類に分かれます。開発者とリーダーです。開発者にさまざまなスキルが必要なように、リーダーにもさまざまなスキルが必要です。多様なスキルの中で最も習得が難しいとされているのは、開発者と違う視点を持つことです。もし、（教科書どおりにやっているはずなのに）いまあなたがリーダーとしていま一つだと感じているのであれば、開発メンバーから、リーダーへの視点の切り替えが上手に行われていない可能性があります。 この連載を通じて私がお手伝いしたいのは、視点の切り替えです。切り替えというよりは、「もう1つの視点を持つ」といった方が適切かもしれません。メンバーとして、開発者としてプロジェクトチームに貢献してきたあなたが、リーダーとしてチームに貢献するために追加すべき視点を持つにはどうすればよいか？ 次の3つの切り口で説明していきたいと思います。 3つの切り口：「