オフィス環境を再現する努力はナンセンス

私はリモート環境でオフィスでの働き方を頑張って再現し、今までのノウハウをはめようとする行動に賛同できません。
いきなりのリモートに慣れず、トランジッションの一環としてオフィスでの振る舞いを再現させることは理解できます。
しかし、リモートでオフィス環境を再現させることが無理で可能な限り再現しようとしたらその努力がペイしないし、リモートワークの特徴を生かす効率化が期待できないと考えています。
例えば、全員が常時ビデオ通話のオンライン状態にキープするアプローチがよく聞きますが、社員のストレスが溜まる一向で、作業に集中しやすいというリモートワークのメリットを抹殺してしまいます。
また、オンライン参加が可能だが集まれる人がオフラインで集まって開催するミーティングがいろんな所でやられていますが、コンテキストが共有しにくく、コミュニケーションがスムーズにならないのでオフラインのデメリットとオンラインのデメリットを顕在化させるだけのプラクティスだと考えています。

非同期優先

リモートでやるなら、リモートの特徴にあわせ、同期性の高いワークフローを排除し、非同期をメインにすべきだと思います。
ミーティングの量を最小限にして、コミュニケーションをテキストベースに持っていくことはわかりやすい実践例でしょう。
ただ、非同期優先というのはやり方の話だけではなく、考え方の話も含まれます。どちらかと言いますと、考え方の方が遥かに大事だと実感しています。
まず、相手のことを常にポジティブに解釈するというマインドセットが大事です。テキストがメインになり、ビデオ通話の場合でも同じ物理空間にいるわけじゃないため、五感を生かしてニュアンスを理解することが無理です。故に、ネガティブな気持ちで説明されたことをポジティブに考えることとポジティブに表現されたことをネガティブに解釈することがありえます。経験上、後者の方がトラブルの元になるケースが圧倒的に多いです。なので、相手の本当の気持ちはともあれ、とりあえずポジティブに解釈することは全員のマインドセットに入れないといけないです。
それに付随し、コンテキストを最小限に収めることに心掛けるべきでしょう。前述のように、コンテキストを伝えることがリモート環境において難しいと言えます。曖昧さを回避し、言うことをはっきり言った方が効率的だと考えます。リアルタイムの対話なら参考情報を文脈の中に差し込むことが難しかったりしますが、テキストだとそんな制限がない為、リンクをどんどん貼り付けても構わないのでそういうリモートこその特徴を生かすべきでしょう。
さらに言うと、リモートになることでアプローチできる人材マーケットは日本に限らなくなるはずなので、全世界から優秀な人材を確保できるメリットが出てきます。異文化間のコミュニケーションにおいて、コンテキストを抑えることが大事なので、そういう意味でもコンテキストを最小限にする必要性があります。
また、アウトプットベースで物事を考えるマインドセットが大切になるでしょう。従業員の生産時間ではなく、成果物で従業員の価値を決めるべきという考え方はだいぶ前から言われ始めましたので、ここで強調する必要がありません。
ただ少し脱線しますが、最近大きな反響を呼んでいるGoogleの給料カットの話についてアウトプットベース思考の角度から分析をしてみたいと思います。この給料カットの話を要約すると、Googleは今までのシリコンバレー水準ではなく従業員が住んでいる場所の生活コストに合わせた給料を支払いたいとのことです。従業員が生活コストが低いところに移すなら、給料が減少するわけです。実際にGoogle以外、TwitterやFacebookのようなIT大手も同じ仕組みを導入しています。なぜこうなるかと言いますと、今までの採用戦略がリモートベースじゃなかったからだと考えます。残念ながら会社は従業員のアウトプットで給料を支払っているわけではなく、あくまでもその従業員を確保するために最も合理的な（大体一番安い）コストを支払っているわけです。すなわち、ローカルマーケットの相場が決定的な要素だと考えても良いでしょう。
しかしよく考えたら、これは昔のプライシングのオペレーションに似ていませんか？メーカーが商品の価格を決める際に、商品の生産コストを計算し、そこから業界平均のマージンを上乗せ、定価を決めるやり方でやっていました。一方で、今のマーケティング界では基本的にはコストでなく、商品の価値から逆算して定価を決めるようになってきています。
話を人材業界に戻しますが、リモートが主流になってきますと、ローカルマーケットの相場に合わせることはナンセンスになりますので、時間がかかりますが、従業員に支払う給料が従業員のアウトプットの価値に左右されるようになるでしょう。

生産性の担保

戦略的な話の後、戦術的なことについて考えてみましょう。リモートワークの生産性を担保するのに何が必要でしょうか？大きく分けて物理環境と情報だと思います。
まずは物理環境。リモートじゃなければ、会社が従業員の生産性を向上させる為に、オフィスを整備したりしてきたと思います。同様に、会社が社員のリモートワークの環境整備に支援することはリモート時代において欠かせないです。実際にGitLabやShopify、日本だとSmartHRなどの会社がそうしていると言われています。
物理環境と比べ、情報整備の重要性が気づきにくいものの、非常に大事だと考えます。非同期のワークフローが主流になることで、作業に必要な情報が素早く手に入るかによって、作業効率が大きく変わります。
ケーススタディーを一つ挙げます。GitLabが情報整備の重要性に気づき、「Single source of truth」を掲げ、ハンドブックファーストという考え方を実践してきました。私のようなエンジニアが「Single source of truth」を見ると、すぐデータマネジメントのイメージが浮かんでくると思いますが、角度が違うもののGitLabのハンドブックはまさに「Single source of truth」の思想を体現しています。
GitLabは、ハンドブックを静的サイトとしてメンテナンスし、ソースコードをGitLab上のリポジトリとしてホストしています。従業員みんなが常時その内容を確認・更新し、それを信頼できる唯一の情報源として利用しています。そのため、何かわからないことがあったら、迷わずハンドブックを調べますし、何か聞かれたら直接ハンドブック内のリンクを送ります。ハンドブックがGitLabのワークフローの中核にあると言っても過言ではないと思います。
GitLabのハンドブックを100%再現する必要がないと思いますが、今までのリモート経験から見て、信頼できる唯一のレファレンスをメンテナンスすることはリモートワークにおいて非常に価値のあることだと感じています。利用するツールは不問ですが、下記の特徴を備えているレファレンスがあればリモートワークの質が高まるはずです。

Read More

Token RingというLANの規格が既に過去形になってしまいましたが、設計思想が面白く、採用しているRing Passingなどは他の技術でも活用されている基礎的な考え方なので、Token Ringを紹介するスライドを作成しました。

Read More

Web 開発を行う際に、ダミーコンテンツを利用したいシーンがしばしば出てきます。データベース内のデータじゃなくてもいいものの、それなりのリアリティが求められるケースも多いです。今日は私が気に入ったモック用サービスを紹介したいと思います。

Mockaroo

1
2
3
4
5

insert into MOCK_DATA (id, first_name, last_name, email, gender) values (1, 'Therine', 'Cawsey', '[email protected]', 'Female');
insert into MOCK_DATA (id, first_name, last_name, email, gender) values (2, 'Melvin', 'Barthrup', '[email protected]', 'Male');
insert into MOCK_DATA (id, first_name, last_name, email, gender) values (3, 'Salim', 'Iacobassi', '[email protected]', 'Male');
insert into MOCK_DATA (id, first_name, last_name, email, gender) values (4, 'Gilemette', 'Pittam', '[email protected]', 'Female');
insert into MOCK_DATA (id, first_name, last_name, email, gender) values (5, 'Gaylord', 'Elliker', '[email protected]', 'Male');

氏名を始め、住所や電話番号、IP アドレス等々、いろんなダミーデータが作成できます。作成できたデータは CSV だけでなく、直接 JSON と SQL 等に書き出せる機能は非常にありがたいです。無料ユーザでしたら、1000 件までしか作れませんが、一時的にテストをする目的であれば十分だと思います。ただ、英語しか対応していなく、日本語のデータ作成ができないことは難点として挙げられます。

avataaars generator

avataaars generator

Read More

去年 2 月あたりにオフサイトを企画しまして、その時アイスブレイクのコンテンツとして wevox values card をコードネーム風にアレンジしたゲームをみんなに遊んで頂きました。かなり反響がよかったので年末年始の時間を使って当時実施したゲームのルールを整理し、チームビルディングのアイスブレイクコンテンツで悩んでいる方のヒントにできればと思います。

紹介

まず wevox values card とコードネームを軽く紹介したいと思います。
wevox values card はアトラエ社より出しているカードで、計 90 枚あって、それぞれのカードに価値観を表す一つの単語が書かれています。詳しい説明は公式サイトを参照していただければと思います。wevox values card のメリットとしてはコンセプト通り価値観の相互理解へ有益だと思います。書かれている単語は全て価値観なので、カード間の優劣が存在していなく否定することは起こり得ないはずです。一方で、既存ルールのゲーム性が弱く盛り上がらない恐れがあります。さらに、チームワークの要素があんまりないので、チームビルディングの目的が果たしにくい面もあります。
一方、コードネームはチェコのヴラーダ・フヴァチルによって 2015 年に考案され、2016 年のドイツ年間ゲーム大賞も受賞した人気ボードゲームです。ルールがシンプルの上、大人数で遊びやすいとの定評があります。Wikipedia のページがあるので、そちらをご参照頂ければわかりやすいと思います。

ルール

準備フェーズ

準備フェーズ

Read More

こちらは 【増枠】社会人学生 Advent Calendar 2020 25 日目の記事です。メリークリスマス！

UoPeople

まず具体的なタイムラインを紹介しますと、2018 年春の Term 4 から授業を取り始め、今年の Term 3 にて最後の Capstone を修了し、3 月 31 日に卒業申請を出してから 2 ヶ月強を待ち、6 月 8 日に学位記が届き、晴れて Alum と名乗れるようになりました。

UoPeople とは

UoPeople は University of the People の略称でアメリカの非営利オンライン大学です。ググれば Wikipedia の記事や内容を紹介するブログが一杯出てくるので、説明は割愛させて頂きます。ただ、入学記が多いものの、卒業後の感想を述べる記事はあんまり見当たらなかったので、自分の振り返りを兼ねて軽く綴りたいと思います。

なぜ UoPeople の MBA を取ろうと考えたか

Read More

アクセス解析は昨今のウェブサービスを実装する上で欠かせない要件になってきています。アクセス解析を実現するのに、いろんなツールやソリューションを活用することができます。その中で最も利用されているのは恐らくGoogle Analyticsだと思います。Google Analyticsから提供してくれたスクリプトタグをHTMLファイルに埋め込むだけで来訪者のデバイス情報やブラウザ情報等を把握できてしまいます。一方で、Google Analyticsのようにスクリプトタグを埋めることはJavaScriptを使うことです。もしユーザがそのスクリプト（もしくはJavaScriptの実行自体）をブロックしたら、当然ながら情報の収集ができなくなります。そのような場合、アクセス解析が不可能になるでしょうか？簡易的ではありますが、実は純粋なCSSでもある程度代用できたりします。

メディアクエリを使ってデバイス情報を取得する

まずHTMLファイルに見えない要素を一つ置いておきます。

1

<p class="invisible-element"></p>

そしてurl関数を活用し、こういうCSSを書けばOKです。

1
2
3
4
5
6
7
8
9
10
11

@media screen and (orientation: portrait) {
  .invisible-element {
    background: url(https://example.org/analytics?orientation=portrait);
  }
}

@media screen and (orientation: landscape) {
  .invisible-element {
    background: url(https://example.org/analytics?orientation=landscape);
  }
}

Read More

ストーリーポイントはどのように見積もっていますか？PO がユーザーストーリーを紹介した上、各自が手元のプランニングポーカーから一枚を引き（もしかしたらアプリかもしれません）、「せーの」と唱えった後おもての数字を見せ合います。もし違いが存在していたら、互いに説明をし、最終的に同じ数字に揃えるようにします。とても定番的なやり方ですよね。しかし、そのやり方を貫くだけで、上手く行くとは限りません。例えば、A さんが 1 を出しているものの、B さんがその数字をはるかに上回った 5 とかを出しているケースが頻出していたら、回し方に問題が潜んでいるはずです。自分の経験上、以下の 3 点に関する問題が起因となった可能性が高いです。

バックログアイテムがうまく作成されていない

正確なストーリーポイントが出せていないというのはあくまで事象で、そもそも土台に当たるバックログアイテムが見積もりにくい状態になっていることはよくあります。バックログアイテムの完成度を判断するのによく使用されているのは「I.N.V.E.S.T」という基準です。要するに、取り扱いやすいアイテムは以下の基準を満たさなければいけません。

• Independant (独立している)
• Negotiable (交渉できる)
• Valuable (価値がある)
• Estimatable (見積れる)
• Small (サイズが小さい)
• Testable (検証できる)

ネット上「I.N.V.E.S.T」を説明する良い記事がたくさん存在している為、細かい説明は割愛しますが、ここで Independant と Estimatable に注目したいです。例えば、「上のアイテムを完成しないと、下のアイテムが見積もれないよ」という言い方はよく聞きます。それは恐らく独立性の不足を表している証拠です。上手く切ったユーザーストーリーなら、お互いに干渉しないし、不確実性の急増がしません。

また、Estimatable も大事です。ストーリーポイントを出す前、開発チームが見積もる対象のスコープと情報を理解していなければ、正しい見積もりが出せません。もしバックログアイテムが見積もりにくいと感じたら、リファインメントもしくはプランニング 1 のタイミングで開発チームと PO が擦り合わせを行うべきです。

Read More