システム開発で思うところ

JavaEEを主にシステム開発をしながら思うところをツラツラを綴る

パッケージの循環依存の対処

一般的にプログラムにおいて循環依存は良くないことと言われています*1

とはいえ、Javaは循環依存をしていてもコンパイルエラーになることはありません。
なので気が付かない間に循環依存をしてしまっているケースはあるように思います。

とりあえず、パッケージの循環依存については、チェックするやり方がありますので、それを活用するのが良いと思います。 (本記事はmavenjdepend-maven-pluginの使用例でもあります。)

blog.guildworks.jp

ところで、私もチェックを実施したところ、ちょこちょこと循環依存をしてました。

これからも同じように気がつけば循環依存をしてしまっているケースが発生すると思います。反省も含めて、どういう循環依存の実装をしてしまって、それをどういう風に対処したのか、というのを記しておきたいと思います。

コマンドパターンのような実装をしたい

デザインパターンのコマンドパターンのようなことをしたいと思って実装したら循環依存エラーになりました。

やりたかったこと

  • HogeController:共通の呼出窓口となるクラス。
  • FugaCommandHandler:Commandを実行するクラス。
  • FugaCommandManager:Commandを管理するクラス。
  • Piyo1CommandPiyo2Command:Commandクラス。

FugaCommandManagerで、Commandクラス(Piyo1CommandPiyo2Command)を登録して、 各CommandクラスはCommandInterfaceを実装して統一的な操作が出来るようにします。
また各Commandは個別機能ということでパッケージにまとめておきます。

機能としては、HogeControllerから呼び出したFugaCommandHandlerFugaCommandManagerに登録した各Commandを実行します。

この例ではクラスが少ないので同一パッケージにしても良いかもしれないのですが、各Commandについては複数のクラスを使用しているので、個別のパッケージを設けることにしました。

循環参照あり

GitHub

GitHub - vermeer-blog-circular-reference/sample1-error: 循環参照サンプル1(循環参照エラー)

パス構成

org
└─vermeer1977
   └─sample
       └─circular_reference
           │  CommandInterface.java
           │  EnvironmentItem.java
           │  FugaCommandHandler.java
           │  FugaCommandManager.java
           │  HogeController.java
           │  Main.java
           │  
           └─command
               ├─piyo1
               │      Piyo1Command.java
               │      
               └─piyo2
                       Piyo2Command.java

ぱっと見た感じだと問題なさそうな構成に思っていましたが循環依存が発生しました。

循環依存になったと思われる理由

HogeControllerにて取得した実行環境情報EnvironmentItemを各Commandで使用するのですが、それが原因だと思われます。

対処例

FugaCommandManagerを独立したパッケージに分割しました。 こうすることで、HogeControllerのパッケージとPiyo1Commandのパッケージが直接依存する関係が、仲介するパッケージを経由する状態になり循環依存のエラーがなくなりました。
発想としては、UMLの関連クラスを緩衝材として実装するイメージ、もしくはDTOを仲介させることで直接参照をしないようにするイメージです。

GitHub

GitHub - vermeer-blog-circular-reference/sample1-ok: 循環参照サンプル1(循環参照エラーの解消)

パス構成

org
└─vermeer1977
    └─sample
        └─circular_reference
            │  CommandInterface.java
            │  EnvironmentItem.java
            │  FugaCommandHandler.java
            │  HogeController.java
            │  Main.java
            │  
            └─command
                │  FugaCommandManager.java
                │  
                ├─piyo1
                │      Piyo1Command.java
                │      
                └─piyo2
                        Piyo2Command.java

副産物

分割したことで、今後、Commandクラスを増やした時に改修するクラスがパッケージレベルで整理されているので見通しも良くなった気がします。

呼出元のクラスを引数にしたい

やりたかったこと

呼出元の情報を元に呼出先で編集処理をしたい。

循環参照あり

GitHub

GitHub - vermeer-blog-circular-reference/sample2-error: 循環参照サンプル2(循環参照エラー)

パス構成

org
└─vermeer1977
    └─sample
        └─circular_reference
            │  Main.java
            │  
            ├─callee
            │      Callee.java
            │      
            └─caller
                    Caller.java

循環参照になった理由

説明の余地のないくらい、しっかりした循環依存です。

対処例

呼出先のクラスCalleeで実際に操作したい機能を満たすインターフェースを作成して、引数の型を変更しました。

修正前は呼出元クラスCallerインスタンスを呼出先クラスCalleeで参照したため循環依存になります。
修正後は呼出先クラスCalleeで必要となる振舞いを定義したインターフェースを呼出元クラスCallerに実装することで循環依存が解消されます。
参照する向きを変更したイメージです。
(ちょっと今回の例だと、何のどの概念をインターフェースとしたのか分かりにくいのが難点ですが・・)

GitHub

GitHub - vermeer-blog-circular-reference/sample2-ok: 循環参照サンプル2(循環参照エラーの解消)

パス構成

org
└─vermeer1977
    └─sample
        └─circular_reference
            │  Main.java
            │  
            ├─callee
            │      Callee.java
            │      CalleeInterface.java
            │      
            └─caller
                    Caller.java

実装の抜粋

  • Callee

calleeパッケージにCalleeクラスのメソッドの仮引数の型をCallerクラスからCalleeInterfaceに変更する

<修正前>

    public Callee(Caller caller) {
        this.caller = caller;
    }

<修正後>

    public Callee(CalleeInterface caller) {
        this.caller = caller;
    }
  • Caller

CallerCalleeInterfaceimplementsする

public class Caller implements CalleeInterface {

・・・

}

副産物

インターフェースを介することで、どのようなメソッド(振舞い)が呼出先として必要であるのか見通しが良くなりました。クラスのままだと、どのメソッドが使われているのか使用箇所の調査をしないと判別できません。

とはいえ、呼出元が呼出先の抽象概念の一部である、というのは少々宜しくないような気もします。基本的には素直に循環依存を解消するのであれば1つ目の例のように仲介するクラスを設けて、呼出元で中継するクラスを作成して呼出先に渡す、というのが良さそうに思います。可読性が落ちない程度で、仲介パッケージを作らなくても問題ないくらいの複雑度であれば、こういうやり方もありそうだ、という例にはなるように思います。

さいごに

正直なところ、始めは自分の作成した自分だけが想定される開発者なので循環参照の対応は無理しなくても良いかなと思っていました。ですが、実際、改修することで、見通しが良くなったように思います。

むかーしの話ですが、大規模SIer案件ではコードにインターフェースが使用されているものは、ほとんど*2ありませんでした。そういうこともあって「フレームワークなど抽象度の高い機能を実装しないのであればインターフェースを使うことはないだろうな」と思っていましたが、実際に自分で手を動かしてみると、そんなことは無いな、と思うようになりました。本記事もその一例のように思います。

*1:言語によってはコンパイルエラーになったりするみたいです。

*2:というか全く

新人エンジニアが読んでおいた方が良いと思う本の紹介

春もそろそろ近づいてきています。新人さんの季節ですね。

新人さんに限らずですが「こういう本を読んでおくと良いと思いますよ」と薦めている本がありますので、それを紹介したいと思います。

実際のところは「若いうちに読んでおけば良かった」という自戒の意味が強かったりします。
ここから書籍の紹介までは、おじさんの昔話なので、適当に読み飛ばしていただければと思います。

私は元々COBOLで金融系の開発をしていて、その後、PL経験を積んだ人間です。一応、物事を整理する能力は人並みにはあったということで最低限の仕事はしていたとは思います*1。とはいえ、OJTという名の下に仕事は現場で覚えるものと言い訳をして、物を作る基礎力の無い残念なエンジニアの典型でもありました。Javaでの実装経験が無くても、オブジェクト指向が分からなくても、設計書のレビューもしますし、プロジェクト管理もしますし、さらにはデバッグやプログラム改修もします。なんだか無茶苦茶ですね。でも、それが実態でした。プログラムの良いところは結果が出てくれるというところです。やり方はともかくとしても要件・仕様は把握しているので、そこを満たせば目の前の問題に限っては対処できます。また、幸いにもプログラミングについては、より詳しい技術者もいましたので、そういった方々と協力したチームを作ることで多くの問題も解決できました。PLやPMとして求められたのは、私の技術向上よりも、チームをまとめて大きい金額の仕事をしていくことなので、その意味では問題はありませんし、それも正解の1つだと思います。
ただ、私自身は大きな売り上げを出す人よりも、自分の力で1から物を作ることが出来る人に憧れがありました。だったら自分で行動すれば良かったわけですが、日々の仕事を言い訳に行動をしないままでした。そんな時、色々とあって大きなプロジェクトの開発プロセスに携わるチームに実質一人で参画できます*2。そのことが私にとって非常に良い転機になります。これまでやってきていた、お客様のシステム要件を理解することももちろん大切なのですが、システムを作ることそのもの(開発手法、プログラミング手法、方式検討など)をじっくり考えることが出来る時間が出来ましたし、情報収集・分析の一環としてVBAでツールを作ったりして、自分の手を動かして1から物を作る機会も得ることが出来ました。

そして、この頃から、ようやくシステムに関する本を少しずつですが読み始めます。そして思います「あぁ、こんなにサクッと読める本もあるのに、なんで私はもっと早く読んでいなかったんだろう。。あの時、知っていたら、もっと良い結果に導けたかもしれないなぁ」と。

とまぁ、そんな経緯もあって、私が読んだ本の中で、達人プログラマーになるというよりも、浅く・広く・難しすぎない・目を通すだけでも見ておくと後々良いと思う、という本を周囲に薦めるようになります。そして今回紹介している本はそういう経緯で選定した本です。

では、おじさんの昔話はこのあたりにして新人さんが読んでおいた方が良いと思う本を紹介していきたいと思います。

Javaアソシエイツ

SUN教科書 Java アソシエイツ (SJC-A)

SUN教科書 Java アソシエイツ (SJC-A)

Sunテキスト Javaアソシエイツ EXAM 【310-019】 (SKILL-UP TEXT)

Sunテキスト Javaアソシエイツ EXAM 【310-019】 (SKILL-UP TEXT)

何から勉強したら良いのかなぁ、と思っていらっしゃる方であれば、まずこれらの本を薦めています。どちらの本でも良いですし他にもあります*3。ページ数が多いから前者、通勤電車で読むからコンパクトな方が良いというのであれば後者、など立ち読みして好みの方を選んでください。知っておいてほしい知識はどちらでも学べます。

言い過ぎかもしれませんが、この資格そのものに実際のところ何の価値もありません。なので合格を目的としなくて良いです*4

では、なぜ私がこの本を進めるかというと「教科書」的な位置づけの本だからです。SIerで勉強というと、まず出てくるのが基本情報処理試験だと思います。こちらも悪いわけではないです。ただ情報分野への理解には良いですが、システムやプログラミングへの理解という意味だと良くはないです*5。良し悪しではなく目的が違います。

教材にすることでJavaで開発をする人にとって一通り知っておいてほしい知識が身に付きます*6。AWTとかSwingとか「今、それ使う開発はあるの?」という情報もありますが、知識として知っておいて損はありません。メンテナンス対象となっているシステムが使用しているケースもあり得ます。また、Javaは関係ないから、という人もいると思いますが、もしSIerで仕事をする方であれば、UML*7や継承など、オブジェクト指向での開発に必要となる知識は必要です。言語特有の知識はありますが、自分の開発言語に置き換えながら読むなどして、いろんな言語があるんだな、という学習の仕方もあると思います。

「この程度の事をわざわざ勉強しなくても」という方もいらっしゃるかと思いますが、むしろ「この程度の事」だからこそ、きちんと勉強をしておくことが大切だと私は思います。

もし理解を深めたいというのであれば問題集もあります。私は資格取得までしたので問題集まで読みましたが、私がまず知っておいてほしい知識と思っている内容は参考書で十分です*8

徹底攻略 Javaアソシエイツ問題集[310-019]対応 (ITプロ/ITエンジニアのための徹底攻略)

徹底攻略 Javaアソシエイツ問題集[310-019]対応 (ITプロ/ITエンジニアのための徹底攻略)

開発現場の掟

開発現場の掟 (プロの鉄則) エンジニアが現場で生き残るための極意 (開発の現場セレクション)

開発現場の掟 (プロの鉄則) エンジニアが現場で生き残るための極意 (開発の現場セレクション)

実際の開発現場での経験を踏まえた知恵が書かれた本です。経験豊かなエンジニアからすれば当たり前であったり、平凡なことばかりかもしれません。でも、これから経験を積む入り口に立っている新人の方には有用な情報が多いと思います。

当たり前のように思うかもしれませんが、この当たり前が実際は難しいものです。

例えば、新人の方でも、自学してスクラムとかアジャイルとか、そういった開発手法を導入しよう、なぜ導入しないんだ、あぁだからSIerは・・・と思うことがあるかもしれません。確かにそういう一面もあるかと思いますが、それを取り入れない理由もあります。おじさんになると、そのあたりも勘案するようになったりしますが、若さゆえの衝突もあると思います。ひょっとしたら、正しい、間違っているは別にして「アジャイルの劇薬の鉄則」あたりが現場の経験としてあったためかもしれませんよ。

他にも仕事の進め方や、開発時に「始めからやっておけば良かった」ということなど、まぁそういう引き出しが色々と書かれている本なので、読んでおいて損はないと思います。

楽々ERDレッスン

楽々ERDレッスン (CodeZine BOOKS)

楽々ERDレッスン (CodeZine BOOKS)

データベースはシステムにおいてほぼ必須です。データベースを使わなくてもモデリングは必須です。

データベースの設計は、設計時の初期にシステムをモデリングする際に検討することが多いため、新人はなかなか経験できません。そして経験年数を重ねて設計工程に参画することになって、いきなりやれと言われます。そこから改めて過去の自分の携わったシステムを正解として自分なりに試行錯誤をすることになりがちです。でも、まだ「やれ」と言われて経験が出来るのであれば幸せかもしれません。

設計はセンスではなく技術なので、そうやって経験を積む中でより良い設計が出来るようになるわけですが、モデリングおよびデータベース設計は、やり直しのリスクが大きいため、始めから出来るだけ品質の良いものにしておきたいところです。そうすると案件的に「経験者優先」となってなかなか経験そのものを積むこと自体が難しいことの方が多いです。

では、本当に、その既存の設計や経験者の設計は妥当なのでしょうか?自分が設計したデータベースがただのデータの入れ物になってはいないでしょうか?

経験を補完するためには知識と疑似トレーニングが有効だと思うわけですが、紹介している本は、その2つを満たしていると思います。SQLについても基本的なところだけでなく、難解なものも事例として書かれています。この本は、モデリングだけ、SQLだけ、ではなくて、自分がモデリングしたものを実際にSQLで検索してみると、、という実践の流れまでを一通り押さえてくれているところが良いと思っています。

ひょっとしたら、本書を薦めつつ、新人さんがいきなりデータベース設計をすることは無いだろうということで、矛盾しているように思われるかもしれません。確かに設計そのものをすることは無いかもしれません。ですが、知識の習得や疑似トレーニングをしておくことで、目にするテーブル設計の意図を通じて仕様をより深く理解できるようになるのではないでしょうか。興味を持つと仕事が面白くなります。ER図を自分なりに紐解いていく中で、システムのイメージを掴めるようになります(それはモデリングの追体験かもしれません)。無機質に思えたテーブル定義が、システムを抽象的に表現していると感じるようになったら楽しいと思いませんか?少なくとも、私は、そういうことを楽しいと思うエンジニアさんと一緒に仕事をしたいです。

Javaルールブック

Javaルールブック ?読みやすく効率的なコードの原則

Javaルールブック ?読みやすく効率的なコードの原則

最後に紹介する本は、ぐっとプログラミングよりの本になります。Java5までのコーディング規約です。今はJava8なので情報としては古いのですが、紹介している理由は新しい古いとは別の事なので問題はありません。

こちらの書籍を薦めている理由は、プログラミングでの「良い例」「悪い例」と比較してくれているところです。プログラムをする中で大切な要素に、レビューをしてもらう、という工程があります。その延長で「他人のコードを読んで勉強しましょう」と良く言われます。でも良いレビュアーに出会えないかもしれません。また、コードを読めと言われても闇雲に読むのも難しいですし、目の前にあるコードが読むに値するものか判断するためには、やはりそれなりに経験が必要です。でも、その経験そのものが無い状態では・・・というループになってしまいます。

その第一歩として、この本を薦めています。

その上で、より良いコードを書く技術の本はたくさんありますし、その中には平易なものもいくつもありますので、そちらの本を読むようにしていけば良いと思います。

最後に

紹介した書籍は「絶対に正しい事」とは限りませんし、私自身も紹介した書籍の全てが正しいというつもりもありません。プログラミングも設計も開発手法も、色々な「正しさ」を持っている人がたくさんいますし、好みの問題もあります。とはいえ、まずは土台となる基礎が無いと、そういった判断をすることも難しいと思います。
また、上述で紹介した本の後に読んだ方が良いと思う、割合と平易な本もいくつかありますが、それを言い始めるとラインナップを見ただけで、お腹が一杯になってしまうことになるような気がしましたので、私なりに厳選をしたつもりです。

これからエンジニアになろうとしている方にとって、紹介した本が一助になれば幸いです。

*1:おそらくですが、そういうSIerシステムエンジニアと呼ばれる人は多いのではないでしょうか

*2:その時の上司に拾っていただいたというのが本当のところです

*3:私が読んだのは、この2冊です。

*4:試験料は馬鹿になりません、結構高いです

*5:無駄ではないです。というか無駄な勉強は無いです。

*6:お恥ずかしい話ですが、私はこの教科書的な知識すらありませんでした。

*7:クラス図だけだけど

*8:資格を受けるのなら黒本問題集は必ずやった方が良いです。参考書だけでは演習量が足りないです。

NetBeansのメモ

自分向けのメモ

基本設定

netbeans.conf

環境設定メモ。アップデートや再インストールしたときにはチェックする。

netbeans_default_options="-J-client -J-Xss2m -J-Xms32m -J-Xmx2048m -J-Dapple.laf.useScreenMenuBar=true -J-Dapple.awt.graphics.UseQuartz=true -J-Dsun.java2d.noddraw=true -J-Dsun.java2d.dpiaware=true -J-Dsun.zip.disableMemoryMapping=true"

引用元は忘れたけど、これもつけておいた方が良いみたい。

export JAVA_TOOL_OPTIONS='-Dfile.encoding=UTF-8'

プラグイン

NetBeans Backlog Plugin | junichi11.com

Web上で直接編集してしまうことも多々あるけど、NetBeans上でも確認できたりコミットするときに連携できたりするので便利。Bitbucketにタイミングで課題管理をBacklogに。一人開発だからGoogleスプレッドシートでも問題ないけれど、IDEでの操作するかどうかは別にして、できるのであればそれに越したことは無いかなと思ったのと、有償のJIRAは過剰かなというところでBacklogに落ち着く。
GitHubにも同様のプラグインがあるので、GitHubで課題管理をするときには、そちらも選択肢。ただ課題管理が色々あるのも面倒なので基本的にはBacklogで一元管理をしていこうと思う。

使い方

NetBeans でコード内の TODO を一覧表示させる – わーどぷれすっ!

NetBeansでJavaソースコードのステップ数も測定できるメトリクスプラグイン「SourceCodeMetrics plugin」 - yappynoppyの日記

Mavenメモ

自分向けのメモ

基本

pom.xmlの各要素デフォルト値と変数置換について - Qiita

Maven pom.xml のバージョン番号を Java プログラムから取得する / 桃缶食べたい。

Mavenでビルドする際にpomによく書くことメモ - Qiita

Exec Maven Plugin

Exec Maven Plugin で maven コマンドでアプリを起動する

[Maven2][Java]Maven2で作ったjarプロジェクトを簡単に実行する - SOSOG

Apache Mavenで簡単Javaアプリ実行 | hiro345

Maven pom.xml のバージョン番号を Java プログラムから取得する / 桃缶食べたい。

モジュール管理

Mavenプロジェクトをモジュール化する | Java好き

java - Maven / FatJarのビルドについて - スタック・オーバーフロー

パッケージのグループ化

プラグイン

Jacocoでレポートがファイルが出力されない。 | BOATRIP

警告は出るけど、とりあえず出力はされている自分のpom.xml抜粋

<plugin>
    <groupId>org.jacoco</groupId>
    <artifactId>jacoco-maven-plugin</artifactId>
    <version>0.7.7.201606060606</version>
    <executions>
        <execution>
            <id>prepare-agent</id>
            <phase>test-compile</phase>
            <goals>
                <goal>prepare-agent</goal>
            </goals>
        </execution>
        <execution>
            <id>report</id>
            <phase>prepare-package</phase>
            <goals>
                <goal>report</goal>
            </goals>
        </execution>
    </executions>
</plugin>

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.19.1</version>
    <configuration>
        <skipTests>false</skipTests>
    </configuration>
</plugin>

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-report-plugin</artifactId>
    <version>2.19.1</version>
</plugin>

出力される警告
file.encoding cannot be set as system property, use <argLine>-Dfile.encoding=...</argLine> instead

ということでmaven-surefire-plugin<argLine>を追記するけれどカバレージレポートが出なくなる。
現状は警告を放置してレポートが出力される方を優先することにしている。

循環参照チェック

パッケージ間の循環依存を自動で検出する | GuildWorks Blog

テストクラスは、とりあえず、言われるままに実装。
今のところ循環は無いみたい。

pom.xmlの関連個所のみ

    <dependency>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>jdepend-maven-plugin</artifactId>
        <version>2.0</version>
        <scope>test</scope>
        <type>jar</type>
    </dependency>


<reporting>
    <plugins>
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>jdepend-maven-plugin</artifactId>
            <version>2.0</version>
        </plugin>
    </plugins>
</reporting>

依存管理

Mavenでプロジェクトの依存関係を解析する - CLOVER

JavaSEのメモ

ブックマーク的なメモ

パス関係

Javaで絶対パスを取得するgetAbsolutePath()の罠と解決方法 - Qiita

【Java Tips】ディレクトリ配下の全ファイルを処理する

指定パッケージ内のクラス一覧を取得するサンプル - うなの日記

ResourceBundleでクラスパス上にない外部ファイルを指定する - Challenge Java EE !

Javaでプログラム実行後にJARファイルをクラスパスに追加したい - torutkの日記

URL to load resources from the classpath in Java - Stack Overflow

Javaクラスローダーを自作する - Qiita

java - How to get classpath from classloader? - Stack Overflow

プロパティ

【Java】システムプロパティの扱い方について(System.getProperty) - TASK NOTES

型検証

異型のオブジェクト比較 - プログラマーの脳みそ

JavaオレオレFrameworkに欠かせないリフレクションでの総称型解析 - Qiita

JavaCompiler

Javaコンパイラークラスメモ(Hishidama's JavaCompiler Memo)

Java技術最前線 - (4/4)「Java SE 6完全攻略」第89回 プログラムからコンパイル - Compiler API その1:ITpro

Java Code Example

Java Compiler API - Compile and Load in Memory Dynamic Code

JavaでScript(Nashornも)

[Java8] Java上でJavaScriptを動かす - Qiita

JavaスクリプトAPI

逆引きNashorn - やりたいことからNashornのサンプルコードを引く - #侍ズム

Apache Shiro(JavaSEと違うけど)

Java Authentication Guide with Apache Shiroをテキトーに訳した - kagamihogeの日記

パフォーマンス

StringBuilderの初期化方法パフォーマンス比較|Pimp my Code. @wataru420

  • StringBuilder.setLenght(0)

AnnotationProcessorメモ

AnnotationProcessorの自分向けメモ

Annotationの基本

アノテーション

Visitor

Annotation Processorで注釈したクラスが実装したインターフェースの型パラメータを取る · GitHub

型検証

Java に独自の型検査処理を追加する方法 — Elliptium

Annotation Processorで注釈したクラスが実装したインターフェースの型パラメータを取る · GitHub

情報抽出

java - How to get method body from ExecutableElement - Stack Overflow

Filer

出力先を編集する

jpa-annotation-processor/Compiler.java at master · irobertson/jpa-annotation-processor · GitHub

その他

Meta-Annotations について

アノテーションプロセッサーで自動生成するときにハマったあたりの話 #ソースコード自動生成 - mike-neckのブログ

シン・UX 2017に行ってきました

togetter.com

感想とまとめををざっくりと

  • UXはUIの延長でも無いしUIのためのものでもないよ

  • 共通認識の構築の実践がUXデザインってことかな?

  • UX白書読んでみよう。

  • UXデザインの教科書を読んでみよう

  • UXは現象・研究・実践の3分類あるので混ぜて話すのは危険

  • 基本的な概念と道具は整っているので、ちゃんと学んでちゃんと使おう(アカデミックな研究も大事)

  • UXは戦略で、スクラムペアプロは戦術という感じ?

  • UXを実現する根幹はチームであること。チームになる事でも、チームにいる事でもない。

  • 体験を体感することが大切。上手にふざけよう。そして一体感を育む努力をしよう

  • 体験の継続は勝手にできるものじゃない。コストは必要。放置すると枯れる。

  • 検証が大事&仮説・検証のループが大切。

  • 検証結果には誠実に向き合おう。もったいないから取りあえずリリースは、それまでの仮説・検証ループに不誠実な行為。

  • UXは体験だから可視化が大事(ペルソナ・カンバン・プロトタイプ・ユーザーストーリー・モデリング

  • 解決したい課題と解決すべき課題は違うかもしれない。思い込みはダメ。

  • 2人のペアが組めない?じゃぁ3人で組めば良い。1人は駄目。そこを妥協するのはダメ。

  • 役割はあるけど領域分担じゃない。チームであることが大事。お互いを理解することが大事。

  • Always be kind. ユーザーを思いやるために、まず自分たちに思いやりを。