エンジニアの生産性を奪う会議の見えない影響

基本的に、予定があることがわかっている時は、何も仕事を終わらせられません。時計を見て「1時間後に会議があるから、この大事な仕事はまだやらないほうがいいな」と思ったり、1時間を20分くらいに感じるせいか、一番小さな仕事ですら無意識のうちに先延ばしにします。

生産的な1日は「予定を入れすぎない」ことからはじまる

たった30分のMTGが午前中をダメにする

30分後にMTGが予定されているだけで、次の仕事をやる気がしなくなります。中途半端にやるくらいなら、MTGが終わってからやろうと思うからです。

そして、MTGが終わると何だか疲れてしまい、少し休憩してからやろうと思います。さて、休憩もしたので仕事に取り掛かったのもつかの間、昼休みになります。

このような感じで、午前中に1つMTGが入っただけで、ほとんど生産的なことができずに午前中が終わってしまいます。たった30分のMTGが午前中をダメにしてしまうのです。

見えない影響を考える

このMTGのように、それ自身は些細な時間でも与える影響は大きいものです。会議の時間そのものだけでなく、会議前後の心理的な影響や、集中力が途切れることによる生産性の低下も考慮する必要があります。

予定を入れる際は、その予定自体の時間だけでなく、その予定が与える影響についても考えることが大切です。特に午前中の集中できる時間帯に会議を入れることは、思っている以上に生産性に影響を与える可能性があります。

対策として

会議は予定されている時間以上にエンジニアの生産性に影響をするものです。可能であれば、会議の時間帯はまとめた方がよいでしょう。例えば、同じ日に会議が分散しているのであれば、特定の時間帯にまとめることができないかを検討してみてください。また、MTGの日を設けてまとめた方がトータルでは集中しやすくなると思います。スケジュールの組み方を工夫してみてください。

SetterとBuilderの使いわけ

先日、「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から卒業しようと考えています

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

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

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

リモートワークは別に効率が悪くない

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

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

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

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

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

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

これからの技術書の書き方

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

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

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