LoginSignup
13
13

More than 5 years have passed since last update.

現場でリモートワークを実践する方向けの「リモートワークで避けたいこと 2 つ」

Last updated at Posted at 2017-05-04
  • 抱え込む
  • 気にかけない

これだけは避けましょう。主張したいのはそれだけです。

思いの丈を発散していたら文量がとんでもないことになりました。

お暇な時にご一読いただければ幸いです。

[追記1]
リモートワークに関する新しい記事を書きました
リモートワークに対する見解と避けるべき行為_第二篇
[追記1 ここまで]

本題の前に目線合わせ

A-1. 本記事におけるリモートワークの位置づけ

リモートワーク

「物理的に作業現場を同じにしない人たちが何らかの通信手段を用いて、

あるサービスや製品を作り上げる手段」を指します。イメージは下図通りです。

base_remote.001.jpeg

従来型ワーク

「物理的に作業現場を同じにする人たちが、あるサービスや製品を作り上げる手段」

をこの記事では「従来型ワーク」と指しておきます。

社会がこれまで採用してきた仕事手段だと認識しているので従来型、と言っているだけです。

イメージは下図通りです。

base_remote.002.jpeg

A-2. なぜこのような目線合わせをしたのか

「リモートワーク」の捉え方が人によって違うのかな、という感覚が個人的にありました。

なので念を以って読者と捉え方に相違が生まれないように、冒頭のうちに目線合わせをしておきました。

蛇足ですが「捉え方」とは私の認識上、大別して 3 つのレベルがあると思っています。

  • リモートワークは...
    • そもそも何なのか(そもそも論のレベル)
    • 働き方を変える手段の一つ、どのように活用していけるか考えたい(経営・マネジメンレベルでの話)
    • 開発・管理現場にて「遠隔間で作業すること」を指す便利な言葉。特に意識せず使う(現場レベルでの話)
      • 「ログ吐いた?」「サービス落ちてない?」「リモートワークやるならテレビ会議システム必要ですね」などのノリで使う単語の一つ

この記事では 3 番目の現場レベルでの話をする予定です。

B-1. この記事で書くこと

リモートワークをするにあたって現場レベルで避けたいこと 2 つ を書くことです。

もう少し背景含めつつ砕いて書くと以下の通りです。

筆者が 4 年間 18 案件近く リモートワークをやってきて得られた、
「こういうことをやってしまうと、個々人の精神負荷が重くなるしプロジェクト内の雰囲気が重くなるので
避けた方が良い」と思うこと 2 つ書きます

B-2. 主に誰に対しての記事か

リモートワークをするエンジニア・マネージャー向けです。

  • リモートワーク初めてだ...何に気をつければ良いだろう...
  • 最近リモートワークやって、何がって分からないがヘマ多い気がする...

日頃こんなことを考えているエンジニアや

  • リモートワークするにあたって、どういうチームビルディングをすればプロジェクトが上手く回るだろうか

と気がかりなマネージャーさんはご一読頂ければと思います。

本題

記事内で使われる用語

base_remote.001.jpeg

リモート

ある拠点や人から見て

  • 細い丸で囲われた、物理的遠方に
    • いる人
    • 拠点
    • 地域

図では、おヒゲの男性から見ると

  • 「黒い一軒家」
  • 「そこに関わる地域」
  • 「一軒家に住まわれている男性会社員」

をリモート、と呼ぶこととします。

  • 「リモートとネットワークが繋がらない」
  • 「うちの現場だと識者がいないからリモートに聞いてみよう」

とかそんな感じで使います。

メンバー

BP さん含めた、ある会社のプロジェクトメンバーのことを指します。

図の細丸で囲んだ人たちを全員プロジェクトメンバーだと思ってください。

プロジェクトにて契約を結んでいる顧客は今回含めないとします。

(本当は「顧客」を含めたかったですが、のちの説明がややこしくなるのでやめておきます)

リモートワーク

各メンバーがリモート間で協力しあって製品・サービスを作り上げることです。

図に倣うと、リモート間であるモバイルサービスを作っているような感じです。

では本題です。

避けるべきこと「抱え込み」

base_remote.003.jpeg

よくある話

あるリモートのメンバーが

  • 進捗を出せずにいるがアラートを出していない、つまり
    • 技術的な課題で詰まっているまま
    • ある仕様設計について方向性を明確化できず、考え込んでいる

その状態がここでいう「抱え込み」です。

他のリモートにいるメンバーも「抱え込んでいるのでは」と思いつつ作業を進めています。

納期が近くになった or モジュール間で結合の必要があるのでリモートから声をかけてみると、

「進捗が出ていなかった。進捗が出てないことが事由で体調がまずそう」と判明し始めます。

既にリモートワークやっておられる方で経験はないでしょうか。

そもそもなぜリモートワークは「抱え込み」が起きやすいのか

上記の話は従来型ワークでも起こり得ると思います。個人的にはリモートワークで特に

頻発している気がしています。それがなぜかを「リモートワークの環境」に焦点を当て考えると

リモートワークは「相談よりも自分で考えることに傾注しやすい環境に立たされるから」

と考えられます。これは例えば

  • あるタスクをしていて何か技術課題が出てきた時
    • 従来型ワークであれば、すぐ横にいるメンバーに相談を持ちかけられる
    • リモートワークだと、横にメンバーはいないから自分で「もうちょっと考えよう」とする
      • 「もうちょっと」が何回も続き、結果『抱え込み』に繋がる

こんなところが思いつきます。

どうやって「抱え込み」を避けていくべきか

  • メンバーから「抱え込み」してない? とよく言われる
  • 普段開発業務をしているが、自分でも「抱え込み」が多いのかなと感じ始めている

リモートワークをしていてそのような実感がある方は、以下のように行動癖つけると良いでしょう。

  • あるタスクをしていて行き詰まり感じた or 技術課題が上がって解決の目処が出てこない時
    • まず手を止める
  • これからどうすべきなのかを整理する
    • 「ぶち当たっている問題は何で(解決したいことは何で)、何が分かっていないか」を明確化する」(x)
  • リモートにいる人に相談する( とにかくまずい、ということをリモートへ知らせる )
    • チャットツールを使っているなら「どなたか助けてください」と切り出せば良い
    • 相談相手の当てがあるなら名指しで良い
  • 助けてくれたリモートの方に (x) を説明する
  • どうしていくべきかを相談する
    • 自分の中で解決方法がぼんやりとも分かっていないならば、それもはっきりと言う
      • 一例では以下のような感じで
        • 「ここまで状況整理しました」
        • 「ここから先どうやって課題を洗い出していくべきか分かりません」
        • 「一緒に課題の洗い出しを手伝ってくれませんか」

上記を何度もイテレートすれば抱え込みは無くなっていくでしょう。

「抱え込み」ではない側は何をすれば?というのは後ほど説明します。

付記: 何を以てして「抱え込み」とすべきか

「タスクの進捗が出てなくて、一人で解決しようとしている = 抱え込み」とすべきと思っています。

リモートワークだと、より相手の顔・作業状況が見えづらくなるので

この Delivery の意味づけが仕事の観点では一番妥当なのではと思っています。

避けるべきこと「気にかけない」

base_remote.004.jpeg

よくある話

リモートから誰かが相談してきてくれました。話合いの結果ある方針が立ち

「これでおそらく解決しそうなので、また追って連絡します」と先方から返事をもらいました。

その後の話です。

先方からチャットや電話で音沙汰がありません。ここで相談をもらった側が

「先ほど話合った件、結果いかがだったでしょうか?」という一言を出すか出さないか。

この一言発さないことを『気にかけない』と意味付けておきます。

気にかけない場合、先方は(個人的な感覚で) 3 割ぐらいの確率『抱え込み』をしています。

経験上先方はおおよそこんな感じです

  • 先方は相談してきた技術課題
    • を全く解決できず苦しんだまま(ワーストケース)
    • を後一歩で出来そうにあるが、クリア出来ていない(バッドケース)
    • をクリアできたのだが新しい技術課題にぶち当たってしまった(良いケースだが一旦は連絡欲しかった)

何をして行くのが良いか

相談をもらったリモートのメンバーは何をしていく(気にかける)のが良いのか

私なりの答えです。

  • アラートを発したリモートの「抱え込み解消状態」がわかるようなフォロー環境を作ってあげる
    • 例えば、リモートから技術課題の相談をもらう、かつ解決方針を互いに立てた時
      • 「抱え込みがなくなった状態」 or 「まだ抱え込んでいる状態」を示すマイルストーンを決めておく
        • 「実装のここまでできたら、できなくても一旦この時間に互いに連絡を取り合う」
        • 「X 時までに実装難しそうであればご連絡ください」
        • など
  • もとより、リモート間で連絡・相談しやすい環境を作っておく
    • 普段のリモート間 MTG 時に
      • 「技術要件 X は私が詳しいのでつまづきそうだったら私に声かけてください」
      • 「設計の Y はメンバー A さんが詳しいので質問や仕様変更の相談は A さんへお尋ねください」
      • 「実は喋りが苦手なので、私が顧客と話す時は横に付いていただけませんか...?」
        • と喋っておくなど

こうすればお互いのタスクに負荷なく、相談をもらった側は

「気にかける」仕組みを作ることができるのではないでしょうか。

付記: 「気にかける」規模感はどれぐらいが妥当か

抱え込んでいるリモートのメンバを気にかけすぎると自分のタスクが終わらない現象が発生します。

マイクロマネジメントをすべきなのか否か...(30 分に一回の頻度で進捗を聞きに行くイメージです)

私の答えとしては否でした。やってみた結果自分のタスクが終わらず残業続きで体を壊し気味でした。

その上で私の答えですが上記にあった通りのマイルストーン形式にたどり着きました。つまり、

  • 相談持ち込まれた側へ、解決策と共に次の相談・連絡までのマイルストーンを決めておく
    • 「何時までに、でき次第連絡する」
    • 「何時までに、できそうになかったら何が課題なのか改めて整理して相談する」

こんな感じです。完璧な答えではないですが、個人的に(+ リモートの方と)うまくタスクを回せていると思っています。


リモートワークは結局仕事のやり方なので仕事術を共有することに他ならないのかなと

記事を書いていくうちに感じておりました(記事の文脈が仕事術の共有になったのはそのせいかもしれません)

拝借したアイコンたち

こちらから拝借しました。有難うございました。

13
13
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
13
13