2021-09-21

ストレングスファインダーをやってみた話

なぜか下書きのまま数ヶ月以上放置していたのでポストしておく。

ストレングスファインダーとは

才能を34の資質（似たような才能の集まり）に分類して、その34資質のうち最も特徴的（優先度の高い思考、感情、行動のパターン）な5つを診断結果として出すサービス。資質は4つの領域（実行力、影響力、人間関係力、思考力）があり、いずれかに属する。

診断自体はWebで実施できて15〜20分程度で終わる内容とはいえ、時間制限付きなので結構な数量をガッとこなす感じ。数問回答しただけでで結果出されるよりは気持ち信頼もおけるし良いのかな。しらんけど。

書籍にシリアルコードがついており、34のタイプのうち上位5つを診断することができます。別途購入するシリアルで34の全体像がレポートで見られるとのこと。上位5つの診断だけ試したい場合、書籍がなくても2000円ちょっとで出来ますが、書籍のほうが安いし和訳もあり後々見直すにも良いかなと感じました。さあ、才能(じぶん)に目覚めよう新版ストレングス・ファインダー2.0

以下は自分の実施結果です。

上位5つ

1. 着想

「着想」の資質が高い人は、新しいアイデアを考えるのが大好きです。見た目には共通点のない現象に、関連性を見出すことができます。

2. 個別化

「個別化」の資質が高い人は、一人ひとりが持つユニークな個性に興味をひかれます。異なるタイプの人たちの集団をまとめ、生産性の高いチームを作ることに長けています。

3. 信念

「信念」の資質が高い人は、核となる普遍的な価値観を持っています。これらの価値観は、彼らの人生に明確な意義をもたらします。

4. 社交性

「社交性」の資質が高い人は、知らない人と出会い、惹きつけ味方につけることが大好きです。見知らぬ人と打ち解けて親しくなることから満足感を得ます。

5. 調和性

「調和性」の資質が高い人は、意見の一致を求めます。意見の衝突を嫌い、異なる意見でも一致する点を探ります。

以上。 4つの領域から1つ以上挙げられてきており、バランス型なのだろうか。主観的には結構当てはまってるように感じるのと、ここで挙がらなかった資質で明らかに自分じゃないなってモノは上位に入ってきていないので概ね納得です。

2020-08-10

エニアグラムをやってみた話

エニアグラム books

エニアグラムとは

同様な環境で教育を受け仕事をしていても、意識は価値観は多様との前提の中で、人間は9つのタイプに分けられるという考え方。後天的な環境や教育ではなく自身の本質を理解するためのものだそうです。

簡易的ないわゆる診断みたいなもので自分のタイプを出してみたので書き残すことにしました。なので、自分のタイプだけにフォーカスします。
ざっと流してみた限り、マイナスの面を指す「囚われ」をいかに意識するかに焦点をあわせており、なかなかボロクソに言われています。合ってる合ってないの話も前提としてあると思いますが、思い当たるところは自戒として持っておくと良いかもしれない。
しかし、客観的に見てもこのステレオタイプの人だと物凄い面倒くさい人間で嫌だなぁ…

なお、参考にした書籍は以下。
9つの性格エニアグラムで見つかる「本当の自分」と最良の人間関係

タイプ

最初は候補がタイプ2か3に絞られていたけど、妻に意見を聞いたら即答で3と言われたのでこれっぽい。

タイプ3: 成功を追い求める人

常に効率性を心がけ、成功するためには自分の生活を犠牲にしてまでも努力を惜しまない。
自分の掲げた目標に向かって、他人も効率よく邁進することを期待し、周囲の人々のやる気を巧みに喚起する。
自分の人生の価値を、成功か不成功かの尺度で測り、実績を重視する精力家。
自分のよいイメージを周囲に示そうとし、多くの場合自身に満ちた印象を与える。
「成功している」「物事が効率よくうまくやれた」ということでもっとも満足感を得る。

良い状態

積極的
明るい
行動力に富む
勉強家
明確な目標がある
能率が良い
チームプレーが得意
自立心が強い

悪い状態

自己中心的
スタンドプレーが多い
不誠実
生意気
冷たい
自慢好き
自己過信
過度の競争心

囚われ

成功にだけ固執して、知的興味を限定する。目標達成しか考えないという悪い側面が出る。
本能中枢、感情中枢、思考中枢の中では感情中枢を好む。
自己暗示により成功者を演じる。また、この自己暗示によって自分の属する組織ごとに異なる理想的なキャラクターを演じる。
重要なのは何においても仕事。地位や収入といった外からの見返りを求める。
アイデアがあればすぐに実行に移すが、常に動き回ろうとするのは落ち込んだりしないための防御的行為でもある。
実績や地位を失うと崩れ去る自尊心を持っているため、努力を怠ってステータスを失うことを常に恐れる。
うぬぼれが強い。失敗してもかんたんには負けを認めない。明らかな失敗を目の当たりにしても、それを部分的成功とみなし、詭弁を弄したり他者の責任にしたりする傾向がある。

自分を変える

タイプ6の「私は忠実だ」の誇りを目指し、攻撃的行動に逆らうこと

志向中枢を意識して客観的に物事を見るようになれば、深い洞察力から協力と相互依存の精神を発揮し、自分の組織や仕事だけでなく社会全体への配慮が可能になる。

自分の行動と本心のギャップに気づくこと

自分の行動と本当の感情の食い違いを理解する。
度が過ぎると空想の中の自分の脳力を本当の能力と思い込んだり失敗を成功と思い込んだり、周囲の批判を完全に無視したり妄想的な状態に陥る。

仕事以外にプライベートの楽しみを見つけること

仕事で成功すれば幸福になれると幸福感を先送りする傾向がある。
仕事以外の楽しみを否定する姿勢がワーカーホリックにして家庭を顧みないライフスタイルを生む。
実績を離れた自分に価値を認める。実績にこだわらず、失敗を恐れず、失敗を他人のせいにせず、全ての結果に責任を取る潔さを心がける。

2020-08-02

6年勤めた独立系メーカーを退職しました

はじめに

タイトルの通り、人生の1つの転換期を迎えた記録です。
2014年7月に入社して以来6年在籍した独立系メーカーを退職しました。
特に、当時入社するにあたり声をかけてくれた上司には前々職から公私ともにお世話になっており感謝の念に堪えません。
2020年8月からSansan株式会社でお世話になります。

どんなことをやってきたか

主に情報システム部に所属し、コーポレートエンジニアとして自社の業務システムの新規開発/改修/運用/リプレイスをしてきました。プロダクトの管理システム開発、兼務で自社製品のセールスエンジニア(?)っぽい事などなど。主務兼務といろいろな経験をしましたが、およそ8割は社内向けの業務システム開発に携わっていた格好です。
社内システムに関しては製品導入ではなくスクラッチ開発をするチームに居たため、DDDの実践やクリーンアーキテクチャの採用、技術選定においてもチームでかなりの裁量を持たせて頂いており、挑戦しやすい環境で楽しく仕事をさせて貰いました。
直近のプロジェクトではスクラム開発の実践を提案して、当時全員がスクラム未経験の状況ながら進められたのはチーム全員の賛同と協力があってこそでした。見直す余地は山ほどありますが、実務におけるスクラムの知見を得られて大変勉強になりました。

バックオフィス部門に在籍する身としては比較的珍しくアメリカやデンマークといった海外への出張の機会を頂き海外カンファレンスへ参加も経験しました。
リスニングはギリギリ致命傷、トークは無事死亡といった現実に向き合う事になり、細々ながら継続的に英語勉強に取り組むきっかけになりました。英語はまだまだ標準以下レベルですが引き続き頑張っていきたいところです。
海外出張はいろいろネタがあるのですがここでは割愛するとして、酒の肴にできればと思います。

なんでやめるのか

いろいろありますがざっとは以下のようなところの心境の変化です。

幅広いユーザに向けたサービスに関わりたくなった
お金を稼ぐプロダクトの立ち上げやグロースに挑戦したくなった
プロダクトアウトなものづくりがしたくなった
クラウドインフラの活用とSaaSビジネスに対する興味が増した

コーポレートエンジニアとして自社システムを拡充していくのは社内の利用者にとって、価値ある事だと思います。ユーザも近い距離におり、かなりの確度(たまにズレる)でニーズのあるものづくりをしていくことの楽しさがあります。一方で要件がかなり特定の業務ドメインに特化していること、与えるインパクト範囲はごく限られたものであるのも間違いないかと思います。
また、古くから存在する業務システムを抱える宿命かもしれませんがクラウドとは無縁の世界でした。世の中的にはクラウドからオンプレ回帰の流れもあるようだけどクラウドを経験せずにこの流れにはついていけない。5年10年経ったらクラウドとかSaaSとかサブスクとか廃れてるかもしれない。そんな危機感も大きな要因でした。

コロナ禍の転職活動

偶然ですがタイミング的にはガッツリ影響を受けました。
2019年12月頃から本格的に動き出し、2-3月が複数の会社で面接のピークでした。
緊急事態宣言前後も面接の機会を頂いていることがあり、日々こんなに外部要因で翻弄される転職もないだろうなと思いつつ動いていたのが印象的でした。たぶん一生忘れない経験でしょう。
とはいえ、幸いにもこの業界的はオンラインは適性/親和性があると思っており、働き方も含めて柔軟な会社が多かったため求職者目線では大きな苦労はありませんでした。
もちろん採用側目線では多大な苦労をされていたはずで、この状況下で採用に動いて頂いた方々には頭が下がる思いです。この場を借りてお礼申し上げます。

今後は

引き続きサーバサイドエンジニアとしてはたらく予定です。
引き続きと言いつつ、もはや何屋なのか解らなくなることも多いのですが…意識して苦手意識を持たないように取り組んでいきたいと考えています。とくにAWSやGCP等のクラウドインフラは実務未経験なので前のめりに吸収していく所存です。

最後に、おやくそくのリストです
https://www.amazon.co.jp/hz/wishlist/ls/22F07UQW6LVJH?ref_=wl_share

2020-07-29

アウトドア記録 - 奥日光湯元の快適っぷりよ

camp outdoor

緊急事態宣言明けに奥日光湯元キャンプ場でグループキャンプした時の記録です。

キャンプ概況

2020/06, 1泊
気温10~22℃くらい
夜は10℃程、夏でもそれなりの防寒着は必須
梅雨真っ只中だったが当日はびっくりするくらい晴れ
フリーサイトでかなり広いが傾斜地もある
場所によっては駐車場から少し運ぶ必要がある
買い出しは近所ではできないため事前に済ませておくのが吉
温泉街の只中にあるため日帰り温泉たくさん
料理は各自持ち寄り、インドカレー作った

メンバー

仕事でおなじプロジェクトに携わった仲間のうち、アウトドアに興味ありそうなメンバー5組でグルキャン。
ソロキャンパーの集まりに近い感じ。
僕以外のメンバーは奥日光湯元キャンプ場はリピート勢。

とにかく天気が良かった

数日前まで場所を変えるかどうか悩む程度には週間天気予報が芳しくなかったが、この週末だけスコーンと晴れた。この日差し、日中は日光浴ができる…!

f:id:yospig:20200729105602j:plain — 日焼け待ったなし

標高が1900mあるので寒いだろうとは思っていたものの、夜は想像していたより寒く、息が白くなっていた。
ソロキャンパー勢的には酒と焚き火とコーヒーが進むのでとても良い感じだったが、ファミリーで行こうと思うとフリースやタイツが無いとダメそう。雨に降られたら外気に当たるのきつそうだ。
昨年9月に桐の木平に行ったときにも防寒の話をしたが、ソロ装備だとシュラフはコールマンのコルネットストレッチⅡ /L-5があるので寝るときはぬくぬくだ。なんならTシャツでも良いくらいでむしろ暑い。

どうぶつのもり

奥日光はシカ、サル、クマ等、野生動物の生息域です。野生動物への餌やりは絶対にしないでください。また、持参した食料及びゴミは必ずテントの中で管理をしてください。

と公式のガイドにある通り実際に鹿に遭遇した。
サイトには鹿の糞もゴロゴロしており、野生動物の生息エリアも物凄く近いんだろう。
鹿だったから良いもののイノシシやクマと鉢合わせないようにしないと。

f:id:yospig:20200729132202p:plain — 鹿 * 3

なお、夜に食べ物をを外に置いておいて動物に荒らされた話を聞いていたので、そのあたりは気を遣っておかないとヤバそう。
今回はキャンパーがかなり多い方だったらしく、ざっと見た限りテントも20張りは超えていたと思うので問題はなかった。

コロナの影響

緊急事態宣言が明けて間もないタイミングだったのもあって利用者が多かった模様。
メンバー曰く、前回と比べて数倍は違うとの事。
コロナ云々ではなくキャンプ場は単純に空いてる方が好みと言う観点で、区画サイトのキャンプ場だと混んでくるとちょっと嫌かもしれない。

日帰り温泉はほとんどの旅館がクローズ。
残念だけど宿泊客からクレームが来る可能性を考えたら仕方ないか。

キャンプギア

ソロ装備としてコールマンのツーリングドームSTが初参戦。当たり前だけどファミリー向けのトンネルより設営が断然楽ですごく良い。

コールマン(Coleman) テントツーリングドームST グリーン 1~2人用 170T16400J

発売日: 2012/03/26
メディア: スポーツ用品

他にはSOTOの燻製器デビュー。前回まで使っていたダンボール製の燻家くんは自宅の庭で風に煽られて半焼してしまった。。
こちらはお安いながら畳んで持ち運べるのでひとまず十分な働きをしてくれそう。

ソト(SOTO) いぶし処お手軽香房 ST-124

発売日: 2012/04/05
メディア: スポーツ用品

しかし、メンバーのギアを見ると欲しい物がドンドン増える。
今回のキャンプではシェラカップ(追加)と直接焚き火台に突っ込んでおけるようなケトルが良い感じだった。
お湯沸かすシーンって多いしなぁ、、

ユニフレームキャンプケトル 660287

メディア:

インドカレー作った関係で、スパイスをそこそこ持っていったのでスパイスボックスみたいなものがあると荷物のまとまりが良くなりそう。

引き続き欲しいなぁ程度のモノはシングルバーナー、ダッチオーブン、七輪あたりか。
ソロ/ファミリー兼用でイケる装備から優先だろうなぁ。

総じて

広々としていて快適な気候で良いキャンプ場だった。
仲間内では定例キャンプ会場になりつつあるので、温泉もすべて開いて活気が戻ってきた時にでも再訪したい。

2020-07-15

RESTで溺れる者がGraphQLを掴む

GraphQL Kotlin SpringBoot

あまりマジョリティになっていく印象がないGraphQLですが、RESTを使い続けていて修正や拡張を重ねる場面でジワジワ辛さを感じる点もあり一度逃げて試しておこうかなぁという主旨です。

サーバサイドKotlinで試してみようと思ったものの、あまり情報が多く無いため記録として残しておきます。

リポジトリは以下
github.com

GraphQLの超ざっくりイメージ

エンドポイントは単一である
型システム持ち
クエリ言語とスキーマ言語の組み合わせ
単一リクエストで関連するオブジェクトを一括で取得できる
取得したいフィールドやオブジェクトに対してそれぞれ引数パラメータを渡すことができる
引数には型を与えることができ、デフォルト型に加えてカスタムした型を用意することもできる
認証も単一にできる
Fragmentとして再利用可能な共通オブジェクトを作っておける

他にも多くの特徴があり、当然課題解決として銀の弾丸ではないのは認識した上でデメリットについては一旦触れないものとして触っていく。

準備

サーバサイドはKotlinで用意する。
~~公式ページに掲載されているライブラリgraphql-kotlinを利用する~~
調べたところコアライブラリであるgraphql-java以外はgraphql-javaのメンテナンスから独立してgraphql-java-kickstartで開発が続けられている。SpringBoot+Kotlinの環境ではgroupidはcom.graphql-javaではなくcom.graphql-java-kickstart を使うのが良さそう。

参考：GraphQL Java

dependencies

graphql-spring-boot-starter
　SpringBootアプリケーションをGraphQLサーバーに変換する
altair-spring-boot-starter
　Altairスキーマイントロスペクションとクエリデバッグ用
graphiql-spring-boot-starter
　GraphiQLスキーマのイントロスペクションとクエリのデバッグ
voyager-spring-boot-starter
　APIをインタラクティブなグラフ化する

build.gradle.kts

implementation ("com.graphql-java-kickstart:graphql-spring-boot-starter:7.0.1")
runtimeOnly ("com.graphql-java-kickstart:altair-spring-boot-starter:7.0.1")
runtimeOnly("com.graphql-java-kickstart:graphiql-spring-boot-starter:7.0.1")
runtimeOnly("com.graphql-java-kickstart:voyager-spring-boot-starter:7.0.1")
implementation ("com.graphql-java-kickstart:graphql-java-tools:6.0.2")

Schema

.graphqlsファイルを作成しスキーマ定義する。
Intellijでファイル作成時に選択可能なGraphQL File だと拡張子が .graphql で生成されスキーマ定義として認識されないので注意が必要。resolverで作成したfunctionをtype Queryとして定義することでqueryとして呼び出すことが可能になる。
なお、GraphQLではデータ取得はQuery,サーバサイドのデータ変更はMutationと呼ぶ。
今回試すquery以外は割愛します。

models.graphqls

type Query {
    getBooks: [Book]
    getBook(id: String!): Book
    getUsers: [User]
}

User.graphqls

type User {
    id: ID!
    full_name: String!
    first_name: String!
    last_name: String!
    age: Int!
    employee_number: String!
    email: String!
    organizations: [Organization]
}

Organization.graphqls

type Organization {
    id: ID!
    userId: ID!
    code: String!
    name: String!
}

Data Classes

GraphQLのtype定義したスキーマにマッピングするdata classを定義する。
ポイントとしては、入れ子にするOrganizationエンティティはUser data classに含めないこと。

User.kt

data class User(
    val id: String,
    val full_name: String,
    val first_name: String,
    val last_name: String,
    val age: Int,
    val employee_number: String,
    val email: String
)

Organization.kt

data class Organization(
    val id: String,
    val userId: String,
    val code: String,
    val name: String
)

Root Resolvers

今回はqueryのみのため、GraphQLQueryResolverインターフェースを実装するクラスを用意します。
functionをgetXxxx のように作成することでtype Queryの定義と合わせる必要がある。

UserQueryResolver.kt

@Component
class UserQueryResolver(): GraphQLQueryResolver {
    val userRepo = UserRepo()
    fun getUsers(): List<User> {
        return userRepo.findAll()
    }
}

Resolvers

今回はUserに外部キーとして持つ想定のOrganizationのマッピング用としてGraphQLResolverインターフェースを実装するクラスを用意します。
UserクラスをDataClassに指定し、OrganizationのListを取得する処理を実装。

UserResolver.kt

@Component
class UserResolver: GraphQLResolver<User> {
    val organizationRepo = OrganizationRepo()
    fun getOrganizations(user: User): List<Organization>{
        return organizationRepo.findByUserId(user.id)
    }
}

ローカル実行

GraphQL Voyager

voyagerを起動することで定義したSchemaをビジュアル化してくれる。
URLはapplication.ymlに記述します。

f:id:yospig:20200714223132p:plain — GraphQL Voyager

GraphiQL

クエリの実行はGraphiQLを使ってブラウザ経由で確認できる。
同じくURLはapplication.ymlに記述します。

f:id:yospig:20200714223538p:plain — GraphiQL

クエリ実行

Bookの一覧を取得

# query
{
  getBooks{
    name
  }
}

# response
{
  "data": {
    "getBooks": [
      {
        "name": "name10"
      },
      {
        "name": "name20"
      },
      {
        "name": "name30"
      },
      {
        "name": "name40"
      },
      {
        "name": "name50"
      }
    ]
  }
}

ID指定で単一のBookを取得

# query
{
  getBook(id: "100") {
    id
    name
  }
}

# response
{
  "data": {
    "getBook": {
      "id": "100",
      "name": "bookName100"
    }
  }
}

Userの一覧(フルネームのみ)を取得

# query
{
  getUsers{
    full_name
  }
}

# response
{
  "data": {
    "getUsers": [
      {
        "full_name": "鈴木太郎"
      },
      {
        "full_name": "田中一郎"
      }
    ]
  }
}

Userの一覧(項目追加)を取得

# query
{
  getUsers{
    id
    full_name
    first_name
    employee_number
    organizations {
      userId
      name
    }
  }
}

# response
{
  "data": {
    "getUsers": [
      {
        "id": "1",
        "full_name": "鈴木太郎",
        "first_name": "太郎",
        "employee_number": "1000",
        "organizations": [
          {
            "userId": "1",
            "name": "情報システム部"
          },
          {
            "userId": "1",
            "name": "新規事業部"
          }
        ]
      },
      {
        "id": "2",
        "full_name": "田中一郎",
        "first_name": "一郎",
        "employee_number": "2000",
        "organizations": [
          {
            "userId": "2",
            "name": "クラウドサービス部"
          }
        ]
      }
    ]
  }
}

複数クエリを一括実行

# query
{
  getBooks{
    name
  }
  getBook(id: "10") {
    id
    name
  }
}

# response
{
  "data": {
    "getBooks": [
      {
        "name": "name10"
      },
      {
        "name": "name20"
      },
      {
        "name": "name30"
      },
      {
        "name": "name40"
      },
      {
        "name": "name50"
      }
    ],
    "getBook": {
      "id": "10",
      "name": "bookName10"
    }
  }
}

雑感まとめ

今回は単純なqueryの実行、複数クエリの一括発行、複数エンティティの入れ子構造の取得などを試しました。

先の複数クエリの一括実行のサンプルは有用性の薄い情報でしたが、1画面で必要な情報のデータソースが外部に点在しているようなシステムの場合は、クライアントサイドでの恩恵は大いにありそう。必要なフィールドに絞ったレスポンスを得られるのもシンプルに良い。
一方で、あまり一括にすぎるとエラー処理やパフォーマンス面では混乱が起きそうな予感もしており、そのあたりの感触は運用してみて初めて解るツラミがあるかもしれない。
調べきれていない点も多い。クラウドインフラのオブジェクトストレージなら問題無さそうだがバイナリデータの扱いはどうなるんだろうか？
RESTのような規約ではなくスキーマとクエリ仕様がカッチリ決められているため、実装の揺れは少なそうなのは良い感じ。
typeで外部キーまで全て定義してしまうと折角の柔軟性のあるリクエストが阻害される予感がした。queryを一括で複数発行できる強みを活かすならtypeを別定義として適度な疎結合を保つのが良さそう。

参考: Spring Boot + GraphQLでAPIを作成してみよう！ - Yahoo! JAPAN Tech Blog

2020-05-03

フルリモートワークに移行して2ヶ月目メモ

COVID-19 リモートワーク

TL;DR

- だれでも変化が起こしやすく、受け入れやすい状況になっている
- 環境が揃わないと仕事どころじゃない
- 自分のコントロールはできても家族のケアの方が大事かつ難しい

普段は新宿にある会社でWebアプリケーション開発をしている身ですが、COVID-19の影響で3月から開発チーム全員でリモートワークに切り替えました。つまりリモートワーク移行からおよそ2ヶ月。ある程度リズムが掴めてきたものの、リモートワーク生活はこれから長期化することも想定しています。
アフターコロナとかウィズコロナなんて言葉も聞こえ始めてきて、後々before/afterの比較がされることも増えそうですが、世界中で同時多発的に生活の変化を迫られることはそうそうない経験になると思われるので、現況を忘れる前に記録しておくpostです。

フルリモート切り替えの経緯

2月中〜下旬

クルーズ船の報道に混じって都内での感染記事も見かけるようになった頃です。所属会社としては特別な対策をするアナウンス無し。対外的にはGMOインターネットグループが突出して早くリモート化を宣言していた印象がありますが、この時点では多くの企業がまだまだ通常営業だったと思います。
そんな中、2/26に東京駅近郊や職場のある新宿での感染報告の記事が上がりました。

新丸ビルで新型コロナウイルス感染者を確認－イベントに参加 - Bloomberg

オリックス生命、協力会社社員1人が新型肺炎に感染 [新型コロナウイルス]：朝日新聞デジタル

社内ではこれを機に各自判断で時間差出勤やリモートワーク推奨が唱えはじめられ、弊開発チームのボスはチーム内判断でメンバー全員のリモート化を決めて、自宅で作業できる環境を準備開始。もともとリモートができるメンバーが半数、環境がなかったメンバーのためにオフィスにおいているiMacを自宅に郵送する事になりました。なお全社としてリモートワークの制度はないもののVPNやリモートデスクトップ、セキュリティ周りなど仕組み的にはほぼ出来上がっている状態のため特段の混乱は無し。

3月上旬

チームメンバーは自宅に端末を送り終えて、自宅環境も落ち着いてきた頃です。
オフィスに通勤していた非エンジニアの部門も徐々に交代勤務やリモートに切り替え始めたことで、それまで対面/メールベースだったやりとりをチャットベースのコミュニケーションに切り替える提案をしました。具体的にはTeamsに普段から緊密なコミュニケーションが必要な同フロアの方を含めたTeamと目的ごとのChannelをつくりました。そうしようと明言した訳ではないですが、それまで社内メール文化だったところをコミュニケーションのスピードアップを狙ってやんわりとTeamsの利用に誘導していきました。ちょっとこのデータがおかしいんだけど見てもらえますか？とか、毎月必ず行う定形業務のほぼテンプレ依頼メールなどなど。

3月下旬

弊社では勤怠管理は毎月配られるExcelファイルに自分で出勤/退勤時間を入力して紙に印刷しハンコ押して上司のハンコをもらい、管理する部門へまとめて持っていく素敵昭和イベントがあります。普段からアレな気持ちを抱いていることはさておき、フルリモートワーク環境下でこれを愚直に遂行する気はサラサラなかったため人事部へ相談の連絡を入れたところ、ハンコなんて誰も見ていなかった事が判明。上長による確認はしてほしいとの事だったので押印欄にテキストで名前を入力して終了。

4月

世間は7都府県で緊急事態宣言があり、その後全国に拡大しましたが、僕の周りではすでにリモート生活に入って1ヶ月前後経っており慣れてきたという意味でも大きな変化はありません。
チーム内に限って言えばフルリモート前と後で開発効率の低下や大きな問題は起きていない状況。

普段の業務はどうなったか

コミュニケーション

前提としてSlackでもTeamsでもなんでも良いが何かしらのチャットツールが無いと壊滅的だと感じます。これを導入しないと仕事にならない。エンジニアだからという訳ではなく、オフィスワーカーは全員要るのでは？もしチャットツール無しでフルリモート化した場合はおそらくコミュニケーションの極端な不足と仕事のスピードが出ずにリモートワーク全然ダメじゃん烙印を押されて終わりだと思う。

あくまで体感ですが、今までチャットツールに触れてこなかった非エンジニア部門の方も慣れてくるにつれメールによる依頼・相談事が減ってきたような気がします。人間、必要に迫られたら適用できるんですよね。一方、@で特定の相手に対するリプを投げたりスレッドで返事するような使い方とかチャット文化みたいなものはある程度レクチャーが必要かなと感じました。リテラシーの低い人やツールに興味の無い人もいるわけで、存在を知らない機能みたいなものは知ってる人が柔らかく伝えていくのが大事。
ただしチャット文化は人類全員が受け入れられるモノでも無いのは確かなので、嫌々使わされている人が身近にいる場合にどうするべきかは悩みどころかもしれません。

ちなみに開発メンバー間はもともとチャットのほうが多い文化なのでほぼ影響無し。口頭で相談したい場合のビデオコールだけまだ少し気を遣っているかもしれないので、コミュニケーションのロスを減らしていくプラクティスは必要そう。このあたりはもっとリモート文化の進んだ人たちのアドバイスが欲しいなぁ。

レガシー文化

エンジニア界隈のモダンな会社ではあまり目にすることがないと思うけど、ハンコ承認のような形骸化している作業があることが明らかになるのは大きな意味があって、臭いものに蓋をしてたり現状維持を貫く体制に対しては強い気持ちで立ち向かう必要があって変えることに相当なエネルギーが要るところですが、ここ2ヶ月は外出自粛のような仕方がないけど生き方を変えて適合していく状況が多いせいか、変化を受け入れる空気感が増してると思います。トップダウンで大鉈を振るうにもボトムアップで改善を提言するにもチャンスなんじゃないかな？
事実、会社の中では可能な限りハンコ承認は減らせそうな気配がありとても健全な方向に進んでいるのを感じます。

ビデオ会議

映像でお互いの顔が見えてることは大事なポイント。相手が話をする様子や聞いてくれている様子が見えるだけでだいぶ違う。感覚値だけども昨今のビデオチャットツールはブラーをかけたり背景画像で部屋の様子を見せなくて済むので映像をonにするのに抵抗が無くなった人は増えた気がする。通信環境が悪くなければ顔見せする方が良いし、その点で一昔前のテレカンと比べるとだいぶハードルが低くなってそう。
音声のノイズを取り除くのも随分と楽。マイクにお金をかけなくてもソフトウェアレベルで所謂ホワイトノイズや電車の音や子供の鳴き声は聞こえなくなる。この点はテクノロジー万歳としか言いようがないです。

リモートの仕事環境

人によって差が大きいポイントですが、僕の場合は普段家族が生活しているのとは別の階に小さな書斎があるため、仕事にあたる日中は家族との干渉がかなり少ない方です。最初は子供が興味津々で侵入してくることもありましたが、1ヶ月程度経つと慣れたのか飽きたのか頻度が激減して、今ではだいたい週に1度くらいしか仕事中に声を掛けられない状況です※1

他のメンバーの状況をビデオ会議越しに垣間見るとこれは結構レアなケースかと思ってßいて、小さい子供が同じ空間にいたら何かしら邪魔されるのが普通でカメラとマイクを乗っ取られるのが日常です。僕もたまにリビングで子守しながら仕事したらバチクソ子供に絡まれています。我が家は妻が専業主婦として子供をみてくれているので仕事ができていますが、この環境は子供が小さいほど避けては通れないし、共働きしてたらどうにもならなそうだな〜と思って日々過ごしています。

今こそBBCパパの気持ちが分かる社会に変わってきているので、この状況が治まった後も子供の乱入微笑ましいな〜くらいの感覚で見守っていられる文化が出来上がるとスイマセンスイマセン言いながら会議する事も減って、健全な進化になるのかなと期待してます。

仕事以外の生活はどうなったか

1.5hほど掛かっていた通勤時間が1分弱になり、単純計算で使える時間が約3時間増えました。これだけ言うと超メリットに聞こえますが、実際のところ今までは通勤時間を読書と英語の学習に充てていた時間が何故か消し飛んでいます。
その分増えているのは子供の世話や家事。自炊が増えたせいか買い物の量と頻度も上がっていると思う。掃除機をかけたり洗濯したり昼休みはそもそも昼食を作ったりもするので明らかに通常時より時間はカツカツになっている日もあるのですがこれは妻が普段負担してくれている仕事なので当然のことでした。
自分を律してルーチンをつくったりQOLを意識した生活を鉄の意志で推進しないとダメになると思って以下を始めました。

朝、窓を開けて外の空気を吸いながら仕事する(春で良かった)
昼に縄跳びをする
朝と昼と夕方にトレーニングボードで懸垂

ただし平時のリモートというよりは小学校や幼稚園/保育園も閉まっている緊急事態だからこその生活サイクルなので、子供の勉強をサポートする必要が平時以上に重要だったり、本当に特殊。自分のだけじゃなくて家族のケアの方がどうすべきか悩ましいと感じてます。

QOLの向上については別の機会に書き残そうと思っています。

※1 妻が未然に子どもの足止めをしてるケースも山ほどありそう、、感謝しかない