Blog

ブログ

ラズパイ で電子ロッカーを作る!(ソフトウェア編)

今回の記事を担当するエンジニアの榎本です。

これまでの記事

電子ロッカー開発始めます → 電子ロッカー開発に至った経緯など

ラズパイ で電子ロッカーを作る!(物理構成編)→ 機器や配線など物理的な構成に関する記事

ここからは Raspberry Pi上で動くプログラムについて書いていきます。

今回Raspberry Pi側で採用したプログラム言語について

Node-REDというビジュアルプログラミングツールを採用しました。Node-REDとは何かというと。。。

Node-REDはハードウェアデバイス、APIおよびオンラインサービスを新しく興味深い方法で接続するためのツールです。ブラウザベースのエディタによってパレットに並ぶ多種多様なノードを結びつけて用意にフローを作成でき、さらにシングルクリックで実行環境にデプロイすることができます。

Node-RED日本ユーザー会トップページより引用

とのこと。
つまり、ブラウザからノードと呼ばれるブロックを線でつなげて思い通りにデバイスを動かせる素敵な言語になります。名前から推察できる様に、Node.js上で構築されてますので、必要に応じて Javascriptでのコーディングまでできるので、編集が容易かつ柔軟性が高い言語となっています。

コードエディタはこんな感じ

画面上で「再起動」などと書かれているかボックスがノードとなります。各処理をつなげてやりたいことを実現できます。

電子ロッカーを構成する各種ノードの紹介

Injectノード
上記コードエディタ左側の「timestamp」と書かれているノードです。時間を指定して処理を起動することができます。

Execノード
上記コードエディタで「再起動」と書かれているノードです。このノードでコマンドの実行を行うことができます。この場合は下記のコマンドを実行することで再起動を実現しています。

sudo shutdown -r now

つまり上述2つのノードの組み合わせで、「毎朝7時に再起動をする」という命令が組み立てられます。非常に分かりやすくて便利ですね。

MQTTノード
今回の電子ロッカーは

ECサイトからの命令をAWS IoT CoreのMQTTへPublish

ラズパイ 側で該当のTopicをSubscribeしメッセージの受信をきっかけに鍵を操作

することで解錠・施錠の実行を実現しています。Node-REDはMQTT処理に必要なノードが用意されているので非常に簡単にこの処理を実行することができます。
入力側のmqttが Subscribeで 出力側がPublishになります。
ノードには MQTT Broker となるサーバの情報・トピック・QOS(=Quality Of Service)を設定することで簡単にPublish/Subscribeを実現できます。(見落としがちですが、QOSはPublish側と合わせる様にしましょう!私はここの数値が食い違っていたために数時間ハマりました。。。)

ノードの設定画面
↑↑MQTT Brokerの設定画面↑↑

余談ですがMQTT Brokerは AWS IoT Coreを SORACOM Beam経由で使っています。AWS IoT Coreの認証を肩代わりしてくれるので ラズパイ 側に証明書などを持つ必要がないことがメリットになります。(これはまた後日記事にします)

PCA9685ノード

こちらは標準のノードではないので、パレットの管理から自分で追加する必要があります。Node-REDのホームページにサンプルを含め説明が載っています。

ノードの追加はこの画面から可能です。
PCA9685ノードの編集画面

基本的には
1. PCA9685 Deviceで対象のデバイスを選択(デバイスの設定方法は下記に記述)
2. Channelはターゲットになる PCA 9685 の チャネルを選択 (直接指定でも良いし、msg.channel という変数に設定した数値でも良い)
3. Unitはサーボモータを動かしたいときは、「microseconds」 LEDを点灯させたりしたいときは「Percent」を選択しましょう。

デバイスの設定画面

PCA9685を指定する画面です。ラズパイ 側で下記の通りになっていれば特に変更する必要はありません。
※Addressは下記の画面で 0x40(=64)であることが確認できます。

例) 15個の扉の解錠を行い、操作がされた時にLEDを点滅させるためのフローは下記の様になります。
1. open_1_all へのメッセージの Publishをトリガーにしてフローが起動
2-1. サーボモータを動かす
  2-1-1. サーボモータを140度回転した位置にするためmsg.payloadに値を設定
  2-1-2. PCA9685 ノードを経由して1〜15チャネルに命令を出す
2-2. LEDを点滅させる
  2-2-1. 0番のチャネルに接続されたLEDを点滅させる
2-3. MQTTメッセージを受け取ったことを送信元のプログラムへ返却するため、受け取ったランダムな文字列をそのまま返却用のMQTTトピックにPublishする

他に大きなポイントとして、ラズパイ の死活監視に使っているlwm2ノードがあるのですが、これは監視についての記事で触れたいと思います。

次回は電子ロッカーのネットワークや、利用しているSORACOMのサービスについて触れていきたいと思います!

ラズパイ で電子ロッカーを作る!(物理構成編)

新規事業を担当している榎本です。
前回の記事で、私たちがなぜ電子ロッカーを作るという決定をしたのか記載しました。では早速、ロッカーを動かすための物理的な構成を書いていきます!

全体図

まずは全体図の写真です。かなりシンプルな構成ですね。基本的にECサイトから受け取った「ロッカーの解錠・施錠」に関する命令をラズパイ が受け取って複数のサーボモータに伝達する形で実現しています。

※見やすくするためにサーボモータ などは外した状態で撮影しています。

機器について一つずつ解説していきます。

機器名称役割
Raspberry Pi Zero WH電子ロッカーの心臓部。
内部のソフトウェアは誰でも扱いやすいようにビジュアルプログラミング言語である
Node-REDを採用しました。美味しいものマルシェ(ECサイト)からのロッカー解錠の
命令に従って周辺危機の操作を行っています。
あまり重たい処理は無いためスペックは重視せず、小さくて安価な Zero WHを採用。
AK-020 (Soracom Air)通信は Soracom Air for セルラーを使っています。通信に必要なモデムとしてAK-020を
利用しています。(このモデムの中に SIMが入っています)
Amazonで販売しているSORACOMスターターキットは通信量1,000円分のクーポンも
ついていてお得でした
PCA9685購入者1人につき、1つずつロッカーの扉を割り当てています。それぞれのロッカーの
扉を個別に操作するためにPCA9685を使ってサーボモータを制御しています。
電池ボックスサーボモータを動かすための電源です。プロトタイプでは電池ボックスを
使っていますが、USBからの給電になる予定です。
TowerPro
SG92R
ロッカーを実際に解錠するためのモーターです。扉1つにつき、1つのモーターが
使われます。写真には載せていませんが、PCA9685につなげています。
高輝度
赤色LEDランプ
ロッカーが実際に施錠・解錠されたことをユーザーが認識できるように、操作された
タイミングでLEDを点滅させます。これも写真には載せていませんが、PCA9685に
つなげてます。

配線について

ラズパイ とPCA 9685の配線図です。GPIOは 1,3,5,6 (青枠で囲った部分)を使っています。

ラズパイ のPIN番号ラズパイ側の名称PCA9685側のピンの名称
15V PowerVCC
3SDASDA
5SCLSCL
6GroundGND

実物の写真はこのようなイメージです。PCA9685は基盤にPINの役割が書いてあるので間違えにくいですね。

PCA9685

ちなみに、PCA9685を使うときにはラズパイ 側のコンフィグを変更してI2Cを有効にする必要があります。こちらの手順についての記事は多いので調べればすぐに分かると思いますが、こちらにも掲載しておきます。

sudo raspi-config

こちらを実行すると表示される画面がこちら。ここで5番の Interfacing Optionsを選択して

I2Cを選択

「はい」を選択して I2C interfaceを有効にしておきましょう!

これでラズパイ を通して複数のサーボモータの制御をするための準備は完了です。サーボモーター はこの様な形で扉に取り付けられています。サーボモータが約140°動くことでギアを経由して鍵が閉まり、ロッカーが施錠されている様子がご覧いただけます。

次回はラズパイ の操作に利用しているプログラム言語、Node-REDについてご紹介していきます!

電子ロッカー開発はじめます

今回の記事を担当するエンジニアの榎本です。
トップページにも記載されていますが、松戸の美味しいものマルシェを開催中です!(2021/3/31まで)
ありがたいことに多くのお客様にご利用いただき、めでたく4/23より第2回目の開催も決定しました。

さて、第1回目ではお客様への商品受け渡しを人の手で行っていました。しかし、下記の理由により次回のイベント以降の受け渡しは無人で行うことになっています。理由としては。。。

  1. 1. 購入いただいたお客様にできるだけ幅広い時間でのお受取りをしてもらうため
  2. 2. 受け渡しにかかるコストを削減するため
  3. 3. 受け渡し担当が長時間座ることにより発生する腰痛への対策

3つ目は冗談として…お客様の利便性と当社としての収益性を保つためにロッカーを使った受け渡しを行うことにしたのです。このロッカーの実現にあたっては下記の4案が検討されました。
大雑把に分けると、

  • ・アナログにダイヤル錠を使った運用をするか、電子キーを実装するか。
  • ・扉を共通化するか、受取人毎に別々にするか

です。これらのメリット・デメリットを大きく下記の様に分類しました。

方式メリットデメリット
1. ダイアル錠(共通扉)開発コストが小さい
運用が最も簡単
運用の負荷が大きい
セキュリティの不安が大きい
2. ダイアル錠(個別扉)開発コストが小さい
共有扉よりセキュリティが保たれ易い
運用負荷が大きい
ミスが発生しやすい
3. 電子キー(共通扉)後述の個別扉よりメンテナンスは容易開発コストが発生する
セキュリティの不安が大きい
4. 電子キー(個別扉)運用の
セキュリティ面で安全性が高い
物理面を含めると開発コストが最も大きい。
システムのメンテナンスコストも高い

私たちは上記を検討した結果、セキュリティ面での安全性と確実にお客様が商品を受け取れることを重視して案四の電子キー(個別扉)を採用することに決めました。
まぁ、開発者としては茨の道っぽいのですが… IoTは弊社としては初挑戦で、楽しそうなので良しとしましょう!構成はざっくりとこんな感じ。
ラズパイ 、SORACOM 、AWSを組み合わせた構成でラズパイ 上の言語は Node-REDを使っています。

次回からは、システム的な観点からどの様に私たちがこの電子ロッカーを構築しているのかを公開していきます!

オンライン社内勉強会のノウハウを公開!

オンライン社内勉強会はじめました!

社内のエンジニアのスキル向上を目的として勉強会を定期的に実施することになりました!完全フルリモートとなった当社で、オンライン勉強会の開催は初めてだったのですが、社員の皆さんからご好評を頂けましたので、そのノウハウを公開します!

オンライン社内勉強会のシステム構成

zoomsli.doを使って下記の構成で実施しました。1回あたりの時間は60分(厳守!)です。

スピーカーが一方的に話すばかりだと、聞いている方も辛いと思ったので双方向がやりとりできる構成にしています。sli.doを使っているのは、zoomだけだと話づらい上に、複数人同時に発言をしてしまうと話がまとまらなくなってしまうためです。

オンライン勉強会で社員間コミュニケーションを演出するために

メインスピーカーからお題を出す

こんな形でメインスピーカーからお題を出して3分間の間に色々な意見を出してもらっています。

sli.doの活用を活用する

sli.doでは色々な意見が出てくるので、メインスピーカーはそれを読み上げながら、社員同士の情報交換を促していきます。

活発な社員間のやりとり

盛り上げるためのちょっとした演出をする

また、勉強会の冒頭では下記のようなスライドを出して、できるだけ「賑やかしてもらう」ことを意識しています。

社員の皆さんからのフィードバック

勉強会終了後のアンケートでは、このような意見を頂きました!

  • シンキングタイムがリアルタイムで書き込めて面白かった
  • 盛り上げようという意識が非常に良かったです。全員でやっている感、全員が主役感を出そうとしていたと感じました。
  • たまに回答コーナーがあるので、リモートでも、参加している感が出て、集中しやすい。sli.doでみなさんのご意見が見れて参考になりました。
  • 途中途中でみんなのコメントを拾ってくれたので、人がどう考えてコーディングしているかが伝わってきた。とても興味深いし、勉強になると思う。本には載っていない、各々が経験した事例を知ることができるのがとても良い。

やはり、集中力の維持や一体感を演出する上で今回のスキームは良かったのかな、と感じています。

オンラインならではの課題

やはりネットワーク系の課題が大きかった気がします。在宅ですとスピーカーも聞くひとも使える帯域も限られるので、難しいところです。

  • 録画の影響なのかスピーカーの声がたまにロボ化してた

オンラインならでは、というわけではないのですが、

  • sil.doの最初に入れる番号をあらかじめslackとかで共有していただけると助かります!!スタート、入れてませんでした。。。

ということもあるので、sli.doを使う時には予め、イベントの番号やURLを伝えておくようにしましょう!

最後に

オンラインの開催なので盛り上がるかどうか最初はとても不安だったのですが、社員の皆さんからの温かいリアクションもあり、非常に有意義な勉強会になっていると感じています。(本当に感謝です。。。)

「松戸のwebシステム開発会社といえばジョーレン」と広く認知して頂くために、これからも社員一体となってスキルの向上に努めていきます!

リモート作業報告用ガジェットが誕生していましたw

以前、投稿しましたが弊社も完全リモートワークに切り替わっております。リモートで作業する際には、席にいるかどうかを把握するためにも勤務開始時や離席時、作業終了時にこの様な感じでSlackへ連絡する様な運用になっています。

大した手間ではないのですが、先日、投稿された社員の動画が話題となりました。

名前が秀逸ですねw 面倒臭がりは、エンジニアとしての美徳です!技術としては、WAWS IoT → AWS Lambda 経由でSlackのAPIを実行してます。ハードウェアはM5StickCというスグレモノです。

ちょっとした作業でも、技術を学ぶきっかけになる良い例でした!リモートワークでも工夫して楽しんでいきましょう!

ECサイトへの一時的なアクセス増をしのいだ話

はじめに

弊社にて担当させて頂いているお客様がテレビ番組にて紹介される!という事で、どうやってアクセスを捌くかどうかが話題となりました。 結果的に、アクセス数は平常時の120倍くらいでしたが無事に乗り切ることができました!やはり、テレビの影響力というものは相当なものですね。

お客様の要望

  • 取り扱われる番組はtoB向けだが、対象のECサイトはtoC向けなので機会損失はあまりない。
  • だが、正確なテレビの特集効果を測定をするために、サーバへの過負荷によって、落ちないように可能な限りの対応を検討したい。
  • よってなるべく安いコスト・少ない工数でできることをやる、

という形でした。

対応内容

小規模サイトということもあり、スケールアウトしづらい構成でした。
(DBもWebサーバも画像もセッションも1インスタンスに全部入り!)

そのため、オートスケール等ではなく、TV放映前に一旦サービスを落としてインスタンスの入れ替えをしています。具体的には、vCPU数48倍、メモリ容量48倍にAWSのインスタンスを変更しただけですが、最大アクセス時にも動作サクサクのまま乗り切れました。小規模なサイトならスケールアップだけでもある程度なんとかなる、という事例となりました!

まとめ

弊社でも、現状のクラウドサービスには多くの便利なサービスがあり、お客様に貢献できる効果が見込めるサービスはどしどし使っていきます。一方でこの様に簡単かつ大きなコストをかけずに対応する柔軟性も大切ですね!

DevRel(広報?)の悩み相談に答えてもらいました

始まり

「松戸のwebシステム会社といえばジョーレン」として、エンジニアに対して高い技術を持つ会社だと認知してもらう事を目指しています。(既に茨の道ですw)

最近多く更新しているブログや、公式SNSアカウント(facebook , twitter , Instagram)からの情報発信もその取組みの一環です。しかし、新卒以来一貫して、エンジニアである私には右も左もわからない状況です。(もちろん、他の社員も未経験ジャンル!)という事で、ここは既にこの様な活動をされている人に、相談するのが早いだろう!と思い立ち、IBMでDeveloper Advocateをされている萩野たいじさん(萩野さんのtwitterアカウント)に、DevRelとしてどう動くのが良いか相談してみました!

今回のブログはこの相談内容を改めてまとめていきます!

アピール始めるにあたって

技術という見えないものをどうやってアピールするか?

一言で、Webの技術といってもすごく広いですよね。弊社でよく使っているPHPでも様々な方が既に情報を発信している中、ジョーレンという会社はどの様なPR戦略を撮っていくのが良いのか?これについての一つのアドバイスはこちら。

ECという特定の領域に対して、当社が技術を使ってどの様なソリューションを提供しているのかをアピールしていってはどうか、という事です。確かに、今までは漠然したと「技術」を使ってアピールをしがちでしたが、「ECに特化」している当社の特徴や事例をもっと出していくと良いのかな、と感じました。下記の様に特定の技術(PHPやSymfony)などに偏ってしまうことなく、ECという軸を一つ持った上で、それに繋がる技術をアピールできればと思います。

ECを柱とした当社の業務状況

もちろん、これまでの様な社内の文化なども発信は続けますが、技術という領域に対してはこの様なアプローチが良さそうです。

DevRelの評価方法は?

短期間で目に見える数値(売上など)に反映される様な活動ではないので、「1年間、投資をしたのに何も変わっていないじゃないか!」という評価をされてしまうと、DevRelとしては失敗するケースが多い様です。会社や自分自身がどの様な形であれ、何を世に出したか(ブログ・登壇・論文など)というところに目標を持って活動をすると良いと思います。ちなみに、目標は状況によって変わるものなのでこまめに見直していくと、活動をする自分自身の心の持ち方が楽になるのかな、と思いました。

また、エンジニアからDevRelを始めるにあたって、自分の稼働を工数として管理しないことも肝要とのこと。例えば、DevRelとして動き出すとコミュニティで活動している時間がプライベートか仕事か、という区分けすら難しくなってきます。「仕事をした分、お金を貰わなければ」という考えからシフトして、「成し遂げたいことに対して動く」というところにモチベーションを持っていく方がうまくいくと思われます。

「技術」という見えないものをアピールするには?

個人のブランディングと会社の関係をどうする?

自社の社員の勉強会の登壇や技術ブログなどをアピールする時には、その開発者個人の技術にフォーカスがあたりがちです。これはこれでセルフブランディングとしては良いのですが、自社プロダクトなどをもたずに、これらのを会社としてのPRにつなげるにはどうすれば良いのか、という疑問がありました。これに対する一つの答えは、

「私はその会社の中の1エンジニアであり、私の様な人たちが自社には沢山いる。だから、自分の会社は高い技術でソリューションを提供できる」

という伝え方をしてはどうか、ということでした。たいじさんは、毎回、事例などを自身のスライドに差し込んでいたそうです。 意識することは、シンプルで「自社の事を好きになってもらう、興味を持ってもらうにはどうすれば良いか?」という事を出発点として考えるのが良いとアドバイスを頂きました。視点としてはエンジニアというベースに広報や経営といった視点を加え、自分が経営者になったつもりで考えると、自ずとやるべきことが見えてくるとのことでした。

SNSやコーポレートブログなど、発信する時に気をつけることは?

最低限のSNSのガイドラインを遵守するのは当然。あとは、押し付けがましくなりすぎない様に気をつけているそうです。製品のアピールが全面的に出過ぎない様にすると、エンジニアから引かれることを避けることができると思われます。技術的なブログであれば、そのネタをメインとして、最後にそのネタから自社のイベントやサービスに興味を持ってもらうきっかけを持たせる、という手も良い様です。

自分の活動を社内では、どの様に理解して貰っていましたか?

一緒に活動をすると、理解を得られやすくなると思います。DevRelの活動を一緒にするだけはなく、逆に営業をサポートするなどして自社内の社員と一緒に動くことで自社内の認知が広がり理解を得られる様です。(外から見ると遊んでいる様に見えがち、という点にわかりみがありましたw)ただ、あまり外に出たくないというエンジニアを無理に引っ張り出すことはNGです。外に出てコミュニティに貢献したいエンジニアを支援したり、登壇の機会を提供するなどの支援をする方が良いでしょう。

アピールすることによって社内外で、どの様な変化が生まれましたか?

ほとんど開発者の人たちに、非常に知名度の低かったサービスがだんだんと認知されていくのが実感出たそうです。やはり、地道な広報活動が身を結んでいくということだと思います。徐々に生まれる変化なので、気付きづらいですが日々、コミュニティやイベントでアピールしていく事が非常に効果的と感じた、とのことでした。

終わりに

なお、相談の様子はpodcastでも配信されていますので、お時間のある時に、ご視聴くださいませ!(配信URL

当社のテキストコミュニケーション事情

弊社の現状

多くの社員が在宅勤務を行っている弊社では、Slackを使ったやりとりがコミュニケーションの多くを占めています。業務上の簡単なやりとりはSlack、込み入った相談はzoomを使う、といった具合ですがzoomを使ってのミーティングの頻度は多くはありません。ということで、今はオフィスに社員がいる時よりもSlack上でが賑わっています!

当社のSlackチャネルの構成

当社では全社員が参加するチャネルがいくつかあります。一例ですが、こんなチャネルがあります。

  • joolen_all ・・・全社員向けの連絡事項を通知するチャネル
  • joolen_nippou・・・業務開始前後に、仕事の予定と実績を報告する
  • joolen_リモート・・・リモート勤務している人の在籍状況を連絡する
  • joolen_dev・・・最新技術やIT業界に関する話題でシェアしたい情報を投稿する
  • joolen_off・・・日常の出来事、松戸のお出かけ情報など業務に関係ないことをシェア

社員同士で話がワイワイと盛り上がるのは、やはり joolen_off または joolen_devですが、最近のリモートチャネルではこの時期ならではの、微笑ましいやりとりもあります。

直接顔を合わせなくても、ちょっとした雑談をすることで社員間のコミュニケーションを保つ様にしています。

絵文字クリエイターの登場

単なる文字でのやりとりだけではなく、Slackのカスタム絵文字を使ったコミュニケーションも楽しんでいます。最近は、社員に絵文字クリエイターを名乗る怪しげな人物も登場しており、Slackでのやりとりを盛り上げていますw新しい絵文字が作られるたびに、こんな感じの絵文字が飛び交っています。

Slack絵文字の一例

AIボットもメンバーの一員

Slack弊社のSlackには、IBMのAI(Watson)と連携するチャットボットも存在しており、ここではちょっとした社員の癒しを提供しています。

botに慰められる社員
botに慰められる社員

botにはAIやServerlessの仕組みがふんだんに盛り込まれており、「技術の無駄遣い」と大変、好評を頂いております。(笑)

※社内Slackbotの構成はこんな感じ。別記事で内容の詳細をまとめる予定です。

プロジェクト管理はBacklogで

また、プロジェクトのタスク管理やGitはBacklogを利用しています。これによってタスクの消化漏れも無くなりますし、対応の優先順位も簡単に行うことができます。Gitのコミットログにも、タスクを紐づけることができるので、誰が、いつ、何故、そのソースを修正したのかが一目瞭然になります。

それでも生産性をフルリモートで生産性を保つのは難しい。。。

色々と良いところ、工夫を書いてきましたが一方で難しさも見えてきました。例えば

  • 自宅の環境をリモートを前提として作っていないので、作業に集中できない。(自宅には座椅子しかないので、長時間の作業が厳しい。気が散る etc)
  • 先輩社員に質問したくても、zoomをつないで良いか聞かなければいけないので、質問しづらくなった。
  • フルタイムフレックスに甘えてしまい、生活のリズムを保てない
  • ひたすら寂しい。(zoomで「お疲れ様でした」としか喋らない)
  • ネットワーク環境が貧弱または冗長化されていないので、ネットワークトラブルがあると、とてもキツイ。

というものです。

いっぺんに全てを解決することはできませんが、一つずつ、社員同士で話し合いながら、フルリモートでもより良い環境を作っていきたいと思います!

在宅勤務が中心の今、運動していますか?

運動できていますか?

最近、リモートワーク関連の話題が多いですね。今回は社員に、最近は運動できていますかー!?というアンケートを取ってみました!

早速ですが、結果はこちら!!

というわけで、運動量が変わらない方もいらっしゃいましたが、運動量が減った人が多いみたいですね。社員の
家から出ないし、基本家の中しか歩かないので太りますよね。※子供と一緒に3時のおやつも食べちゃうし。。。
というコメントに、とても共感できます。
一方で、なるべく運動する様に心がけている!という方も一定数いました!
やはり、家でじっとしていると少しずつストレスは溜まってきてしまうもの。運動を心がけている方からはこんな取組例(?)も頂きました!

  • 自転車をこぐ+子供と朝のラジオ体操でなんとか運動量を確保、、、
  • 子供も運動不足なので、一緒になわとびやったり、子供が壊滅的にできないボール投げやったり、YouTubeで公開されている運動動画を見てやったりしてます。
  • モムチャンダイエットっていうDVD(10年前から愛用)をやってます。

なるほど、、、人それぞれですね〜。
ちなみに、「むしろ筋肉増えた」と答えてくれたのは、弊社が誇る筋肉系副社長殿です。
期待通りの回答、本当にありがとうございました!(日中は日光浴→夜はストレッチ派だそうですw)

みなさん、引き続き、健康には気をつけて生活しましょうね〜。

ちなみに、、、
アンケートはSlackで使えるアプリPolly を利用しています。(リンク)
とぼけた顔の青い鳥のキャラクターが目印ですが、今回の様なちょっとしたアンケートをとるのには便利ですよ!Slackにアプリをインストール後、/poll コマンドですぐにアンケート作成可能です。
まだ、使っていない方は、是非とも、お試しあれ!

小さい子供のいる社員の在宅勤務と社内制度

弊社の現状

2020/4/7に千葉県を含む7都府県に緊急事態宣言が出たことにより、ほぼ全ての学校や幼稚園が、休校または休園となりました。また、保育園や学童も基本的には利用を自粛する様に通達を受けた家庭も多かったと思います。このため、小学生以下の小さなお子様のいる家庭でも、子供と一緒に在宅勤務をする必要が出てきました。

弊社では、新型コロナウィルス感染拡大前からも一定の条件付きでリモート勤務が可能ではありました。現在はその条件もなくなり、多くの社員が毎日リモートで勤務を行っています。しかし、通常時のリモート勤務とは状況が異なるため社員の間でも、子供と在宅しながらどうやって仕事を進めるかという点で盛り上がりました。ちなみに、話のきっかけとなったのはこの日経新聞のこの記事。(在宅勤務ままならず 保育園休園で見えた働き方の課題)

ままならぬ現状の一例…

社内でのちょっとしたミーティングも、後ろで大騒ぎされると気になってしまって、上手く話が進まなくなってしまったりします。

兄弟のいるご家庭では、兄弟喧嘩勃発→仲裁のために作業中断なんてこともありますよね。例えば、、、

二人揃って自宅にいるので、毎時間何かしらでトラブってます。。。
お願いだから、zoomのマイク入れた瞬間に叫んだりしないでくれと願うばかりです。。。
というコメントもありました。みなさん、とても苦労されている様です。もっと小さいお子様がいる家庭では、だっこだっこ星人が表れたり、、、

子供のいる社員の工夫例

一方で、お母さん社員の方からはこの様なコメントも頂いて、非常に参考になりました。
小学2年生、保育園年少の子供が毎日在宅中ですが、上の子はともかく、下の子は長時間親が相手しないで過ごすのは無理なので、 仕事を早朝にシフトし、仕事中はテレビを見せ、 仕事の間に長い休憩を挟み相手する時間を取っています
がっつり遊んであげればしばらくは満足します。
小さい子を見ながら長時間連続で仕事するということ自体、そもそも無理って諦めているので、 適度に相手できる体制を整えるしかないかなーと個人的には思っています。

つまり結論は、フレックスがあってよかった!ですかね・・・

「子供に仕事を邪魔されない様にする」よりも、「仕事のしやすい時間帯を見つけてそこで働く」というのも選択肢の一つの様です。
ちなみに、弊社はコアタイムなしのフレックス勤務可能(5:00〜22:00の間)なので、この様な柔軟な働き方が可能になっています。
(もちろん、自社のチームやお客様との連絡は必要です!) AM5:00から毎日稼働する強者もおりますw

制度だけではなく文化も大事

弊社では、元々お子さんのいる社員も多く、何らかの用事があって子供を会社に連れてきてもWelcome!な雰囲気でした。 そういうこともあり、多くの社員がリモートになった今も、子供の声が聞こえると軽く答えてくれたり、手を振ってくれたりが自然にできています。 打合せ中も多少の割り込みであれば、寛容に受け入れてくれますw制度だけではなく、社員同士のこういった距離感も働きやすさに繋がるのかな、と思います。この文化は大事にしていきたいと思います。