明日は台風なのでリモートワークをします。リモートワーク制度があるので都合のいい時間に自分の働きたい場所で働くことができます。リモートワーク制度のいいところは、「台風がそれたから出社になった」なんてことがないことです。最初からリモートワークをすると決まっていれば朝はゆっくりと過ごすことができます。

朝から会社の判断を待ってどうするかが決まるなんてわずらわしくないですか。出社を判断する方も大変でしょう。会社が判断するのではなくて個々人で判断すればいいのです。会社で働いたほうが都合がいい人は会社で働けばいいですし、会社以外で働いたほうが都合がいい人はリモートワークをすればいいだけです。

先日、「SetterとBuilderはどのように使いわければいいのか？」という質問を受けました。なかなかよい質問ですね。Builderを使うとクラスのインスタンスを柔軟に作ることができます。Builderを使ったサンプルコードです。

1
2
3
4

User user = User.builder()
        .lastName("山田")
        .firstName("太郎")
        .build();

Builderを実装したUserクラスのサンプルコードです。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

public class User {
    private final String lastName;
    private final String firstName;

    User(String lastName, String firstName) {
        this.lastName = lastName;
        this.firstName = firstName;
    }

    public static UserBuilder builder() {
        return new UserBuilder();
    }

    public static class UserBuilder {
        private String lastName;
        private String firstName;

        UserBuilder() {
        }

        public UserBuilder lastName(String lastName) {
            this.lastName = lastName;
            return this;
        }

        public UserBuilder firstName(String firstName) {
            this.firstName = firstName;
            return this;
        }

        public User build() {
            return new User(lastName, firstName);
        }
    }
}

Setterを使うと次のようになります(実装は省略)。

1
2
3

User user = new User();
user.setLastName("山田");
user.setFirstName("太郎");

Setterの問題点として、インスタンスの状態を変更してしまうことがあります。イミュータブルな実装にする場合、原則としてコンストラクタで値は設定するべきでSetterで変更するべきではありません。

では、Setterではなくコンストラクタで設定するようにしましょう。引数が少ないうちは問題がないのですが、次の例のように引数の数が増えてしまうとコードが煩雑になってしまいます。

1
2
3

// 姓、名、年齢、血液型、国が引数のコンストラクタの例
// 年齢と血液型は不明だが、nullを指定する必要がある
User user = new User("山田", "太郎", null, null, "日本");

そこで、Builderを使うメリットが出てきます。Builderを使えば柔軟にパラメーターの設定が行えるようになります。

1
2
3
4
5

User user = User.builder()
        .lastName("山田")
        .firstName("太郎")
        .country("日本")
        .build();

SetterもBuilderもやりたいことはオブジェクトにパラメーターをセットすることです。Setterを使うとオブジェクトの状態を変更してしまうことになります。イミュータブルな実装かつ柔軟にパラメーターを設定したい場合はBuilderを使いましょう。

便利なlombokですが、そろそろオワコンな感じがしています。理由はJavaのアップデートに追従することが困難になってきているからです。詳しくはLombok の Java9以降対応の記事に書いてあります。実際、Java9対応も遅かったですね。lombokを使い続けると、Javaのアップデートに追従していけなくなる未来が想像できます。

Spring Bootも2系からはlombokは使っていませんね。

lombokは便利ですが、別に無くてもなんとかなるライブラリなので、あえてこれから使う選択をする必要はないと思います。

ここ最近は週に1回ほどリモートワークで働いています。プログラミングであればリモートワークで問題ないです。

リモートワークの利点として会議に出なくていいことがあります。会社にいると何かと会議に招集されて時間や集中力が奪われてしまいますが、リモートワークであればその心配はありません。本当に出る必要がある会議であればリモートで参加すればいいですし、多くの場合は対面で話さずともドキュメントベースのコミュニケーションで事足ります。

ほかにも通勤時間が不要になることで1日に余裕ができるメリットがあります。私は往復で通勤時間に2時間が必要です。リモートワークにすればこの2時間が自由に使えるようになります。通勤時間がない分、早めに仕事を切り上げてその後の時間は子供と遊んだりできます。

リモートワークだと集中できない、生産性が下がるという意見がありますが、実際にやってみるとそんなデメリットはありませんでした。オフィスより家の方が集中できます。なぜなら、集中するには静かな場所が必要だからです。テレビがついているような騒がしい場所で集中することは難しいのです。オフィスはテレビがついている部屋と大して変わらないと思います。

リモートワーク導入で生産性が下がるのではないかという意見もありますが、そんなことはありません。通勤時間がなくなるうえ、集中できる環境であれば生産性が上がるのは当然でしょう。コミュニケーションが必要な時はSlackなどのツールを利用すればよいです。ただし、100％リモートワークとなるとコミュニケーションの問題が出てくるであろうというのはわかります。ですので、オフィスワークとリモートワークのハイブリットがバランスがよいのではないでしょうか。

頑張って残業するよりリモートワークを取り入れましょう。そのほうが生産性があがり社員の満足度もあがりますよ。

技術書は少しずつ書いて有料で公開する。これが、これからの技術書の書き方だと思います。具体的な例としては「はじめるSpring Boot 2」があります。

@Makingさんの記事「紙媒体の技術書を書きたくないです…」に書かれているように技術書を書くには膨大な時間が必要です。それを全て書き終えて出版するには相当の時間がかかります。ITの技術はどんどん進歩しているので、出版される頃には古くなってしまう場合もあります。紙媒体だと内容が間違っていても修正できません。また、出版の期日に間に合わせるために、著者に非常に負担がかかります。今の出版のやり方はデメリットが多すぎるんですよね。

だいたい技術書の内容って全ては必要ない場合がほとんどです。一部だけ読みたいのに全てを購入するのは無駄なのです。これからはnoteなどのサービスを使って有料で出版されるケースが増えてくると思います。そうすれば、自分のペースで書けるし取り分も増えます。読むほうも必要なところだけ買えばいいので無駄がありませんね。