自分戦略ステートメントカード

エンジニアとしての自分戦略を立ててみる(中村バージョン)

こんにちは、ギルドワークスの中村 洋です。

今回はギルドワークスでやっている「自分戦略 発見ラボ」のアウトプットである「自分戦略ステートメント」を書いてみようと思います。

「自分戦略 発見ラボ」の背景や内容などはこちらのエントリに書いていますので一度読んでみただければと思います。

「自分戦略ステートメント」は名刺サイズのカードですので、財布などに入れておき、ふと思った時に簡単に見直すことができます。そのため「年始に目標や自分戦略を考えてみたけど、その後は…」ということはあまりないかと思います。

■私(中村)の自分戦略

●戦略[方針]
やりたいこと(What)
・「自分が手がけているプロダクトやサービスのことを胸を張って、家族や友人に伝えることができる」エンジニアを1人でも増やしたい
・仕方なく仕事をやっているエンジニア、自分が書きたくないコードを書いているエンジニアを1人でも減らしたい
 
何故やりたいか(Why)
・家族や友人に伝えることができる仕事は「自分事」ととらえている度合いも高く、その結果として、クライアント、(実際に利用する)ユーザーにとって値打ちあるものを提供できる可能性が高くなるため。
 仕方なく仕事をやっていると、それを受け取るクライアント、使うユーザー、かかわるエンジニア全てが幸せにならない。
 
●戦略[行動]
今の強み/弱み(Now)
・強み:アジャイルな開発、チームビルディング、ファシリテーションの知識と実践経験。関係者を巻き込んで、共に越境していくチェンジ・エージェントとしての振る舞い。
・弱み:深いエンジニアリング知識。

どう行動するか(How)
・現場コーチとして組織の中に踏み込んで、チームを巻き込みつつ「あるべき姿」と「そこに至る道筋」を一緒に考え、示し、行動していく。

■最後に

改めて見ると(当たり前ではありますが)自分戦略ステートメントカードに書いたことを実現したいためにギルドワークスを立ち上げのだと再認識しました。

自分戦略 発見ラボは、「このよう自分戦略を一度も考えたことなんてなかった」というエンジニア向けのサービスでもあります。そのためのメンターがいますので、お気軽にお申込みください!

Coderetreatを題材にした設計本

井上です。

Coderetreat (*1)というイベントをご存知でしょうか?
Coderetreat とは、ソフトウェア開発と設計の基本を学ぶためのイベントで、以下のような特徴があります。

  • 一日掛かりで行われる(5〜6セッション)
  • 参加者はペアでコードを書く(ペアプログラミング)
  • 1セッションは45分間
  • ライフゲーム (*2)」を題材とする
  • 各セッション終了後にコードを削除する
  • 各セッションで新しいペアを組む
  • セッションが進むにつれて制約を課す

また、CodeRetreatを世界中で同日に開催する 「Global Day of Coderetreat」 というものもあり、世界中で活発に開催されているイベントで、日本でも度々開催されています。(*3)
私もCodeRetreatに参加したことがあるのですが、一日掛かりのイベントなので大変な集中力を要しますが、とても勉強になりました。

そんな Coderetreat を題材にした設計本(洋書)を見つけたので紹介します。

続きを読む

hcd_2

12月13日(土):人間中心設計推進機構(HCD-Net)のHCD研究発表会で事例発表します。

ギルドワークスの佐々木です。

12月13日(土)10:00〜17:30に、芝浦工大で開催される「HCD研究発表会」(主催:人間中心設計推進機構(HCD-Net))で事例発表をすることになりました。

http://www.hcdnet.org/event/2014hcd_2.php

■日時:2014年12月13日(土)10:00~17:30

■場所:芝浦工業大学 芝浦キャンパス 802教室 (東京都港区芝浦3-9-14)

http://www.shibaura-it.ac.jp/access/shibaura.html

■主催:特定非営利活動法人 人間中心設計推進機構

■協賛学会:日本人間工学会・ヒューマンインタフェース学会・日本デザイン学会

■発表及び聴講参加費:HCD-Net会員:2000円、一般:3000円、学生会員:無料、一般学生:1000円


続きを読む

ドメイン駆動設計とJava 8 ラムダ式

河上です。

Java 8 でやっとラムダ式が使えるようになって喜んでいる今日このごろですが、業務アプリケーション・プログラミングであるドメイン駆動設計という文脈でどういった変化がおこるのかを考えてみます。

まず適用できそうなところとして思いつくのは以下です。

  • Specificationパターンの実装
  • ファーストクラスコレクション内部のコレクション操作

それぞれの実装例として幾分恣意的ではありますが、シンプルな要件を、ラムダ式を利用しないバージョンと、利用するバージョンでそれぞれ実装してみたいと思います。

要件:「ある会員制サイトで、年収800万円以上、且つ、正社員、且つ、課長以上、というステータスを持つ会員を幹部候補として区別し、絞込などをおこないたい」

まずは、年収800万円以上、且つ、正社員、且つ、課長以上という、複合条件をSpecificationパターンの実装方法の1つである、「Compositeパターンによる条件ツリー方式」で記述してみます。

ラムダ式を利用しない

public class ExecutiveMemberSpecification {
    MemberSpecification 年収800万以上 = new MemberSpecification() {
        @Override
        public boolean isSatisfied(Member 会員) {
            return 会員.年収().greaterEqual(800);
        }
    };
    MemberSpecification 正社員 = new MemberSpecification() {
        @Override
        public boolean isSatisfied(Member 会員) {
            return 会員.雇用形態().equals(EmploymentType.正社員);
        }
    };
    MemberSpecification 課長以上 = new MemberSpecification() {
        @Override
        public boolean isSatisfied(Member 会員) {
            return 会員.役職().greaterEqual(Position.課長);
        }
    };

    public boolean isSatisfied(Member 会員) {
        return 年収800万以上
                .and(正社員)
                .and(課長以上)
                .isSatisfied(会員);
    }

}

abstract class MemberSpecification {
    abstract boolean isSatisfied(Member member);

    MemberSpecification and(MemberSpecification specification) {
        return new MemberSpecification() {
            @Override
            boolean isSatisfied(Member member) {
                return MemberSpecification
                        .this.isSatisfied(member)
                        && specification.isSatisfied(member);
            }
        };
    }

    MemberSpecification or(MemberSpecification specification) {
        return new MemberSpecification() {
            @Override
            boolean isSatisfied(Member member) {
                return MemberSpecification
                        .this.isSatisfied(member)
                        || specification.isSatisfied(member);
            }
        };
    }
}

ラムダ式を利用する

public class ExecutiveMemberSpecification {
    final Predicate<Member> 年収800万以上
            = it -> it.年収().greaterEqual(800);
    final Predicate<Member> 正社員
            = it -> it.雇用形態().equals(EmploymentType.正社員);
    final Predicate<Member> 課長以上
            = it -> it.役職().greaterEqual(Position.課長);

    public boolean isSatisfied(Member 会員) {
        return 年収800万以上
                .and(正社員)
                .and(課長以上)
                .test(会員);
    }
}

ラムダ式を利用しない場合に比べてコードにあるノイズがほぼ消えていることがわかります。

次は、このSpecificationを使って、実際に会員を絞り込むコレクション操作部分です。

ラムダ式を利用しない

public class Members {
    final List<Member> values;

    public Members(List<Member> values) {
        this.values = values;
    }

    ExecutiveMemberSpecification 幹部候補者条件 = new ExecutiveMemberSpecification();

    public List<Member> 幹部候補者リスト() {
        List<Member> members = new ArrayList<>();
        for (Member 会員 : values)
            if (幹部候補者条件.isSatisfied(会員)) members.add(会員);
        return members;
    }
}

ラムダ式を利用する

public class Members {
    final List<Member> values;

    public Members(List<Member> values) {
        this.values = values;
    }

    final ExecutiveMemberSpecification 幹部候補者条件 = new ExecutiveMemberSpecification();

    public List<Member> 幹部候補者リスト() {
        return values.stream()
                .filter(幹部候補者条件::isSatisfied).collect(Collectors.toList());
    }
}

こちらではラムダ式を利用しない場合に比べて絞り込むという部分がfilterというメソッドとしてより直接的に表現出来ている部分に好感がもてます。

コードの例としては以上となります。コードの細かい解説などはなく不親切とは思いますが、雰囲気だけでも感じていただければと思います。

上記例以外にもソートなどの記述がシンプルになったりと、メリットが多いと感じるラムダ式ですが、実を言うと、上記の例も含めて、私がドメインモデルのコードでラムダ式を使う部分は局所的です。

それは、例えば「ドメインモデルの外部からラムダ式を注入するようなモデルの汎用化をおこなう事」が、「用途や文脈に合わせた特殊化を行う」というドメイン駆動設計の思想と相反するのではないかという考えがあるからで、今のところそれを変えるような経験に出会っていません。

もちろん、ドメインモデルの外のインフラストラクチャやフレームワーク内部ではラムダ式をつかった汎用化がかなりの武器になることに疑問はありません。

他につっこみや「ドメインモデル内でのラムダ式活用例」としてなにか事例等あればご意見ください。