私なりの通知機能との付き合い方


はじめに

このエントリーを書こうと思ったきっかけは、普段オンライン上で懇意にしてもらっているみやひろ@webディレクターさんからのこんなTweetでした。

確かに、ことコロナ禍に入ってオンラインでのツール群をコニュニケーション手段として使うようになってからは、通知地獄、とまではいかないけれども、ひっきりなしにやってくる通知に自分の作業の手を止めなければいけないというパターンは増えてきましたね。実際に、自分もメールの通知、Slackの通知、Teamsの通知がひっきりなしにやってきていて、おまけに現職ではミーティングの数が1日平均して3〜4件と多いので、それも含めて自分自身の作業が滞ることもしばし。

とはいえ、もうこれからの時代通知機能を完全に切る、というやり方はコニュニケーションロスが生じてしまうので、自分なりにどのようにしてうまく通知機能と付き合っていくのかをまとめてみることにしました。

コニュニケーションツールの通知とどう付き合うか

私が所属しているプロジェクトではSlackをコニュニケーションツールとして使用しているので、それを前提にして書いていきます。

まず、現時点で自分がどのくらいのチャンネルに所属しているのかを数えてみたら、32チャンネルもありました! 人によってはもっと多くのチャンネルに参加しているのかもしれないですが、これだけのチャンネルから通知が来てしまうとそりゃ大変です。なので、こういう風にして主としてウォッチするチャンネルを絞り込んでいるのと同時に、逆に相手を通知で困らせないようにコントロールをかけています。

宛先を絞り込む

つまり、Slackでいうところの@channelや@hereを可能な限り使わず、連絡を取りたい人に対してあくまでもチャンネル上で呼びかける、ということです。ポイントとしては以下の通り。

  • @channelや@hereを使わないことにより、無用な通知を増やさない
  • かつ、チャンネル上(≠DM)でコンタクトを取ることにより、属人化を防いで誰でも横から会話に参加できるようにする

スター機能を使って、常時確認するべきチャンネルを絞り込む

先ほど32チャンネルに所属しているというお話を書きましたが、そのうちにどうしてもみなければいけないチャンネルって大概限られているんですよね。なので、Slackのスター機能を使って常時確認する対象にしているチャンネルを、担当している案件によって常時最大5つくらいまで絞り込んでいます。以下のような感じで。

これだけでも結構負担は軽減されますね。それ以外のチャンネルは、メンションが飛んできたら応答するけれども、そうでない限りはさらっと読み流す程度にしています。

メールの通知とどう付き合うか

次に多いのはメールの通知。これもまた大変ですよねぇ。流石に仕事メールの画像を公開するのは厳しいので、プライベートでの工夫を中心に書きます。

ちなみに、プライベートでも1日あたりでメールは平日30通くらい受け取っているのですが、そのうちにやりとりとかしなければいけないメールの数って1/10くらいなんですよね。なので、こういう形で対応しています。

メールソフト(MUA)を2種類併用する

これってすごーく非効率なように見えるのですが、特にGmailなんかを使っている人だと、とにかくありとあらゆるメールが流れ込んでくるので、とてもじゃないけれども全部のメールを読んでいる暇がないわけです。

なので、メールソフト(MUA)を、

  • 通知を見るためだけのもの
  • きちんと仕分けをして本文をきちんと読んだり返信したりするもの

に分けています。私の場合、前者にはSparkを、後者にはGyazMailを使用しています。Gmailアカウントには、個人で保有しているすべてのメールアカウントから転送をする設定にしているので、Sparkには事実上すべてのメールが流れ込んできます。とにかくこれを通知機能でちらりと見るだけ。即時返信が必要なものを除いては基本的に返信しません。

で、GyazMailの方で実際にちゃんとメールを読んだり必要に応じて返信したりするわけですが、メールのやり取りをしている方はご存知の通り、返信する時間を基本的に7:00台から8:00台にルーチンとして決めています。もちろん緊急でやりとりしなければいけない場合は別ですけれども。そのようにして、タスクを行う時間を自分の中であらかじめ決めておくことによって、コントロールをかけています。直接的には通知とつきあうTipsとは関連しないかもしれませんが、そのタスクを行う時間を決めるというのも大事なのかなと。

通知音を出さないという心理的安全性

そうそう、個人的にはこれが一番大事なんじゃないかと思っているんですが、仕事用のPCでは基本的にスピーカーの音量をゼロにして、あらゆる通知音を出さないようにしています。でないと通知音そのものがだんだんストレスになってくるんですよねぇ。どうせ通知は視覚でわかるものだから、視覚で済むものに関しては視覚から得る情報で済ませてしまえと。これだけでも通知に対する心理的安全性はかなり高まります。

もちろんですが

もちろんですが、通知されてくる情報にはなんらかの意味があって通知されてくるので、それに対して完全に無視を決め込むことはできないというのは自明です。ただ、その人に対して関係性のない情報まで何でもかんでも流されてしまうと、本当に通知に埋もれてしまう生活になるので、そこのところは、各々うまくコントロールしながら対応していくと、リモートワーク生活もだいぶ楽になるんじゃないかなと思います。

あくまでこれは私が実行している例なので、皆さんそれぞれ、皆さんなりの工夫をしていただければと思います。そしてそれを是非共有してもらえると嬉しいかな。

カテゴリー: Work | タグ: , , | コメントする

Amazon EventBridge + AWS Lambda + Amazon DynamoDBでTwitterのbot機能を実装してみた


はじめに

これまでに幾つか、AWS上で動くリソースを制御するための自動化便利ツールを作ってきましたが、これをきっかけに日常の色々な作業を自動化するための布石として、なんかいいネタないかなぁと考えながら、builders.flashを眺めていたら、よくあるパターンのTwitterのbotをAmazon EventBridge + AWS Lambda + Amazon DynamoDBで実装してみるというちょうど良いネタがあったので、サクッと実装しつつ、若干のカスタマイズをしてみました。

シリーズものなのでまだまだ途中段階ですが、元記事は以下のリンクに示されているので、ここでは自分なりにカスタマイズした箇所のみを紹介していこうと思います。

カスタマイズしたところ

主に第2回に書かれている箇所が中心になるのですが、私の場合は過去に投稿した記事をランダムにTweetさせるように作りたかったため、まずはDynamoDBのテーブル項目に、パーティーションキーとして”Id”を設定しました。こんな感じ。これがまずは下準備になります。

次に、以下のコードのline.32のように、その時にTweetさせたい過去の記事のidを、random.randomint()関数を用いてランダムに生成させ、line.35で生成させたidをキーにしてget_itemさせるようにしました。もちろん、記事の数は(多分)これからもどんどん増えていくので、ここでidの数をハードコードせずに、一旦line.13でLambda関数の環境変数から取得するように実装を追加しています。

また、記事のコードでは現段階ではエラー処理が実装されていないので、エラーハンドラも仮で実装しています。その全体像がこんな感じ。なんか一部余分な処理が入っていますが、そこは大目に見てください。。。

import json
import os
import boto3
import logging
import traceback
import random
from requests_oauthlib import OAuth1Session
from datetime import datetime, timedelta, timezone

logger = logging.getLogger()
logger.setLevel(logging.INFO)

ids = int(os.environ.get('POST_ID'))

dynamodb = boto3.resource('dynamodb')
twitter_bot_message_table = dynamodb.Table('TwitterBotDailyMessage')

JST = timezone(timedelta(hours=+9), 'JST')

# API Key, Access Token(元記事にも書かれているとおりで本来はハードコードしてはいけないです。連載が進んだ時に直します)
consumer_key = "Twitterから取得したAPI Key"
client_secret = "Twitterから取得したAPI Key Secret"
access_token = "Twitterから取得したAccess Token"
access_token_secret = "Twitterから取得したAccess Token Secret"

oauth = OAuth1Session(consumer_key, client_secret, access_token, access_token_secret)


def lambda_handler(event, context):
    
    text = ""
    id = str(random.randint(0, ids))

    try:
        response = twitter_bot_message_table.get_item(Key={'Id': id})

        if ('Item' in response):
            text = response['Item']['Message']
        
        payload = {'text': text}
        response = oauth.post(
            "https://api.twitter.com/2/tweets",
            json=payload
        )
    
        if response.status_code != 201:
            raise Exception(
                "[Error] {} {}".format(response.status_code, response.text)
            )

    except Exception as e:
        logger.error(e)
        logger.error(traceback.format_exc())
        return {
            "statusCode": 500,
            "message": 'An error occured at tweet old Blog post.'
        }

EventBridgeの設定はお好きなようにという感じで。私の場合は、あまり頻繁に過去記事を投稿するのもなんだかなぁ、ということで、以下のcron式を設定。とりあえず週末だけ動かします。

cron(5 5 ? * SAT-SUN *)

で、EventBridgeを発火させたらこんな感じで無事にTweet成功。

今後やりたいこと

ここまで実装した段階だと、Blogの記事を投稿する度にDynamoDBに項目追加をして、Lambda関数の環境変数も手作業で修正しなければいけないのが面倒なところなので、記事を投稿したタイミングをトリガーにしてDynamoDBに項目を追加しつつ、環境変数もさらに外出しして完全自動化していきたいところ。やり方はたくさんあると思うのですが、まだ絶賛連載が進行中のようなので、ゆっくり機能拡張していきたいと思います。

カテゴリー: AWS | タグ: , , , | コメントする

Violaレッスン2回目


今日は朝から、りきひさみねこ先生のViolaレッスン2回目でした。いやぁ楽しい。

先々週のレッスンでは、まずは右手と右腕を大改造しましょう! というところから始まったのですが、今回もその続き。弓の持ち方とボウイング(特にダウンボウ)の時の腕の伸ばし方を徹底的に大改造という感じで進行しています。

やはり長きにわたっての慣れというのは怖いもので、ダウンボウで弾き切った時に肘が完全に伸び切っていない状態に、いつの間にかなってしまっていたようです。というわけで、まずは弾き切った時に腕と楽器と身体が三角形の形になるように、またその時に弓の向きが逆方向に反ってしまうので、可能な限り弓の毛の向きを自分の身体側に向けられるようにとひたすらボウイングの練習です。これがなかなかきついというか、手首の関節が硬すぎて、肘を伸ばし切った時にうまく関節を使うことができていないみたいです。これはちゃんと手首の関節を柔軟に曲げられるようにしないといけないな。

合わせて親指の位置も大幅に修正。弓に対して直角になるように意識することと、今までは親指の腹の位置で弓を持ってしまっていたので、腹の中ではなくてできる限り爪に近いところで弓に指を刺すようにして持つように修正。こちらはなんとかうまくいけそうです。

まぁそんな感じで今回もあっという間にレッスン時間が過ぎていったのですが、りきひさ先生がポジティブな雰囲気で指導してくださるので、こっちも俄然やる気になってくるものですね。

元々基礎を見直すためにレッスンを再開したので、当面の間は基礎を見直すことに集中していこうと思います。実際に曲を弾いていくのはもう少し先になるかな。それでもこれまで当たり前のように続けてきたことを最初から見直して修正していくのって、なんだか楽しいですね。

レッスン後には先生から今回のレッスンのポイントのメモが送られてきて、ありがたや〜。

次回のレッスンも楽しみです。

カテゴリー: Private | タグ: , | コメントする

JBUG広島 #9 x Agile Japan HIROSHIMAに参加しました


JBUG(Japan Backlog User Group)は、ヌーラボさんのプロジェクト管理ツールであるBacklogのユーザを中心としたコミュニティなのですが、単純にBacklogだけではなく、より良いプロジェクト管理やタスク管理の仕方など、さまざまな分野に視野を広げて、プロジェクト管理を民主化できるようにしよう! という目的で活動しています。

最近はもっぱらオンラインでの勉強会が主体となっていますが、逆にオンラインになったことで、物理的な距離を超えてさまざまな場所の勉強会に参加することが可能になりました。

今回は、「JBUG広島 #9 x Agile Japan HIROSHIMA」ということで、Agile Japan HIROSHIMAさんとの共催という形でオンラインで勉強会が開催されたので、ちょっとここのところ本業の関係でサボり気味だったのですが、久しぶりに参加することができました。

敵は敵の顔をしては向かって来ない(福井 桂太さん)

何か新しいことを始めようとする時には、組織の中にいる「抵抗勢力」と1対1で勝負をするのではなく、たとえ劣勢でもいいから公開の場でやりとりをしていくのがいいというお話。

もちろん「抵抗勢力」側の人も正論をぶつけてくるんだけれども、お互いに正論をぶつけ合ってもなかなか幸せになれるとは限らないんですよね。なので、賛成派4割を作らなくても、あえて劣勢派側に回ってオープンに議論を重ねていく方が、結果としてはみんな幸せに新しい物事が進んでいくんだよね、っていうことを感じました。

やさしいBacklogの使い方(待島 亘さん)

クライアントさんに向けてBacklogを使ってもらう際に、こういう形で導入していくといいよというベストプラクティスに関するお話。

Backlogを快適に使用してもらうためのエッセンスが満遍なくお話の中で散りばめられているだけでなく、それをわかりやすくまとめてくれているスライドがとても素晴らしかったです。きっと、待島さん、相当Backlogの良さを理解されていて、理解されているがゆえにとてもやさしい解説ができているのではないかというところが素晴らしかったです。穏やかなお話の仕方がそれに相乗効果をもたらしてくれたというか。とても眼福なお話でした。

「google/zx」と「Backlog API」を組み合わせたJavaScriptのプログラムからのBacklog操作(豊田 陽介さん)

Backlog APIをうまく用いて、Backlogに関する操作を自動化していこうというTipsに関するお話。

Backlog APIは以前から気になっていたのですが、なかなか使う機会がないまま時間だけが過ぎていったという経験を持っているので、Node.jsや、google/zxを用いて簡単に実装ができるということをわかりやすく解説していただき、これなら自分も実装できるかも! という良いヒントになりました。これAWS Lambdaを使っても十分に何か実装できると思うので、ぜひ実装してこのBlog上でこんなの作ってみたというのをFBしてみたいですね。

小学生がBacklogのプロジェクト管理を参考にして、夢に一歩だけ近づけた話(吉田 彩さん)

Backlogの考え方やエッセンスを応用して、娘さんの学習に活用しているというお話。

正直、初めは娘さんがBacklogを実際に使うのかなというお話だと思ったんです。けれども実際に出てきたのはホワイトボード。なるほどホワイトボードを使ってタスクをコントロールしていくというのは、小学生でもできますし簡単に可視化できるのでいいですね。手段ではなく、あくまでも目的を明確にしてゴールに向かってやるべきことをこなしていこうというアイデアが純粋にすごいなぁと思いました。これうちの娘にも教えてあげたい。

アジャイルの心と未来の働き方(アリスター・コーバーンさん)

Agile Japan 2021の基調講演の中から、アリスター・コーバーンさんの講演を振り返るという内容だったのですが、これもまた素晴らしかったです。

アジャイルって、単純にソフトウェア開発に適用されるメソドロジーであるということに限らず、コラボレーションがとても大事であることとか、信頼関係とオーナーシップが大事だよということとか、これからVUCAの時代の中で仕事を進めていくにあたっての良いエッセンスを得られただけでなく、これから仕事を続けていくということそのものに対して大きな勇気をもらったような気がしました。可能であればこの基調講演の内容、何回か見直して身に染み込ませたいですね。

オンライン勉強会を通して得られる気づきの多さ

ひとつの組織の中でももちろんさまざまな人が働いているわけですけれども、やはり組織という単位ではあくまでもひとつなので、だんだん考え方がサイロ化してしまってなんだか行き詰まるなぁという状況が出てくるわけです。

そんな時に、今回のJBUG広島 #9 x Agile Japan HIROSHIMAにしてもそうなんですけれども、オンライン勉強会に参加すると途端に世界観が広がり、自分の仕事の仕方に対するたくさんの気づきやFBがいただけるんですよね。それがとても心地よいというか、私的探究心を深めていく上で本当に勉強になります。

改めて登壇者の皆さんと、JBUG広島やAgile Japan HIROSHIMAの運営を支えてくださっている皆さんに感謝です。

カテゴリー: Work | タグ: , , | コメントする

Violaのレッスンを受けるのを再開しました


はじめに

ご存知の方はご存知の通り、私は大学入学と同時にViolaを始め、大学オーケストラで4年間活動した後、他大学のオーケストラの賛助活動などを経て、市民オーケストラを中心としてViolaを弾いています。

ですが、このコロナ禍に入ってからオーケストラ活動が完全に停止してしまい、さらに在宅勤務の忙しさも相まってViolaに触る機会がめっきり減ってしまったことと、大学オーケストラ時代にはトレーナーとしてみてくださっていた、元日本フィルハーモニー交響楽団の先生に師事していたものの、社会人になってからは完全に自己流に近い形で演奏を続けることになり、そろそろ基礎力を見直しつつ、定期的にViolaを弾く機会をなんとか作らなければなぁと思っていたのでした。

まぁそこで個人レッスンを引き受けてくれる先生を探そう! ということになったのですが、Violinに比べるとViola人口というのはやはり少ないので、自宅で近いところにあるのかなぁと思いつつも探してみたところ、速攻で見つかり、まずは体験レッスンからということで、りきひさみねこ先生と連絡をとらせて頂き、体験レッスンに行ってきました。

右手の大改造に着手

りきひさ先生、本当に初めてお会いしたのですが、とても明るくてハキハキした方で、レッスン開始前からリラックスできました。とはいえ流石に最初、まずは何かしら弾いてみましょうということで、持参したViolaの教本”SITT”のとある練習曲を弾いた時にはだいぶ緊張するし、突っかかるし、弾きながら辺な汗が大量に出てくるという状態。それでも先生は丁寧に弾く様子を見てくださり、

右手の改造をすればきっと楽器が持っている力が十分に発揮されますよ!

とおっしゃってくださいました。別に右手を手術するというのではなく、弓の持ち方をまずは修正していきましょうということですね。

弓の持ち方や楽器の構え方のような基本的な奏法に関することは、大学オケの先輩だけではなく、学生時代に師事していた先生からも教え込まれていたのですが、そこから20年も経過すると流石に崩れていくるものですね。なんだか変な弓の持ち方で慣れてしまっているので、逆に右手の変なところに力が入っていたり、手首の曲げ方もおかしくなっていたり、そういったところを丁寧に修正してくださいました。とはいえ、簡単に修正できるわけではないので、ここでも先生に教えていただきながら大汗。

少し期間を要することにはなると思いますが、まずは右手の使い方の改造に着手をして、そこから本格的に曲を見ていただくという形になると思います。

確かに何をするにしても、その時の姿勢ってものすごく大事で、ちゃんと往々にして修正していかないとだんだん崩れていくわけで。その点から着手してくださるところ、とても感謝です。

というわけで、これから2週間に1回、継続して先生のレッスンを本格的に開始することにしました。自分の弾き方がどんな風に変化していくのか楽しみであります。

カテゴリー: Private | タグ: , | コメントする

娘と一緒に福岡 & 太宰府へ


すごく珍しいね、と言われることが往々にしてあるのですが、父娘で旅行に出ることが多いです。

コロナ前の2019年11月には韓国ソウルへ行きましたし、コロナに入ってからも、感染状況の谷間を見ながら、特に福岡県を中心に飛行機で旅行に出ています。

そんなわけで、フライトログをかねて簡単に記録。

フライトログ

  • 2022/1/15 NH245 HND → FUK 788 JA802A 4H
  • 2022/1/16 NH258 FUK → HND 788 JA831A 1C

往路のCAさんに、娘が高校に合格してそのお祝い旅行なんですよ、という話をしたら、素晴らしい神対応をしてくださいました。本当にこのような細やかな心配りをしてくださるANAさんは大好きです。

簡単に旅行記録

福岡空港からは地下鉄と11番の西鉄バスを乗り継いで渡辺通にあるホテルに一旦荷物を預け、68-1番の西鉄バスで天神へ向かい、前回食べてとても美味しかった「おむや」さんのオムライスを堪能。相変わらずボリューミーで美味しかったです。

その後西鉄福岡(天神)駅13:00発の大牟田行き特急と太宰府線普通を乗り継いで太宰府天満宮へ。娘が3年間お世話になってきた家庭教師の先生が、今年医師国家試験を受験するため、その合格祈願をしてきました。おみくじは小吉だったなぁ。

で、参道に戻ろうとした時に、カフェの看板がこじんまりと立っているのを見て行ってみようということになり、行ってきたんですが、これが当たりで、居心地が良くとても良い空間でした。イチゴのタルトも美味しくいただきました。「CoRicco」というカフェです。店主さんとリノベーションの話についても盛り上がったり。素敵な店主さんでした。

太宰府からは太宰府線普通と西鉄福岡(天神)ゆき特急を乗り継いで薬院駅で降り、夜に16番の西鉄バスと214番の西鉄バスを使って博多で軽く晩御飯を食べて1日目は終了。

2日目は、どうしても行きたいカフェがあるという娘からのリクエストを受けて、一旦タクシーで博多駅まで出て荷物を預け、JRの線路沿いをてくてく歩いて「AIMAI」というカフェへ。娘はその空間にどハマりしていて、僕はカウンターの窓越しを走るJR九州の電車に見惚れてました。

そうこうしているうちに復路のフライトの時間が迫っていたので、博多から地下鉄で福岡空港へ向かい、サラッと帰ってきました。

娘との二人旅もいいもんだ

何故かわからないけれども、娘とは嗜好とか空気感が似ているところがあるようで、二人旅していても飽きないんですよね。いや父親冥利に尽きるものです。いいもんですよ。これからも感染状況を見つつ、娘と国内色々なところを巡ってみたいですね。

カテゴリー: Private | タグ: , , , | コメントする

AWS請求関連の情報を表示できないようにするためのIAMのカスタマー管理ポリシーを書いた


はじめに

この記事は2022年1月12日現在で発生している現象を元に作成したものです。Amazon Web Services側の仕様変更により記述した記事の内容に変化があるかもしれない点についてはご了承ください。

AWSマネージメントコンソールのホーム画面がカスタマイズできるようになったという知らせを知ったのですが、その影響なのか、元々実装していた、見せてはいけない人に請求関連のサービスの情報を見せないという内容のカスタマー管理ポリシーが効かなくなっていたので、急遽該当するカスタマー管理ポリシーを、以下のように書きました。

作成したカスタマー管理ポリシー

こんな感じです。要点としては、

  • AWSマネージメントコンソール上で請求に関する情報を見せることを明示的に拒否する
  • AWS Budgetsのすべての権限を明示的に拒否する
  • AWS Cost and Usage Reportsのすべての権限を明示的に拒否する
  • Amazon Cost Explorerのすべての権限を明示的に拒否する

という内容になります。もっとこうした方がいいんじゃないのという意見もあるかもしれませんが、結構緊急避難的に90分くらいで仕様確認と実装と動作確認をしたので、その辺は何卒ご容赦を。。。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "aws-portal:*Billing",
                "aws-portal:*Account",
                "aws-portal:*PaymentMethods",
                "budgets:*",
                "cur:*",
                "ce:*"
            ],
            "Resource": "*"
        }
    ]
}

なんか、AWSさんの作り込んだバグなんじゃないかという情報もちらほら聞こえてきて、しれっと仕様変更が入ってまたこのカスタマー管理ポリシーを直さなければいけないという可能性もあるのですが、その時はその時で、このエントリー上で修正版を共有しようと思います。

カテゴリー: AWS | タグ: , | コメントする

“会社は「仲良しクラブ」でいい”を読んだ


はじめに

株式会社ヌーラボといえば、プロジェクト管理ツールとして課題をわかりやすく可視化しながら共有することのできる“Backlog”や、構成図やワイヤーフレームを共有しながら作図することのできる“Cacoo”のような、チームやステークホルダーの人たちとコラボレートしながら快適に仕事を進めていくことのできるプロダクトを世に送り出している、福岡発のベンチャー企業として多くの人々に知られています。

ただ単純に知られているといえばよくあるベンチャー企業のひとつとして捉えられてしまうかもしれませんが、「知られている」だけでなく、送り出しているプロダクトを通じて「愛されている」のもこの企業の特徴なのかもしれません。実際にBacklogやCacooには、企業が出しているプロダクトであるにも関わらず、それらを使用する人のコミュニティが存在し、活発に活動が行われているように、企業が開発したプロダクトを通じてより良く仕事ができるようにナレッジを共有している事例が多数あるのも特徴的なのではないかと思います。

そんなヌーラボを率いているのが橋本正徳さん。ベンチャー企業だと、創業者の顔がものすごく際立つという傾向があるのですが、私の知る限りでは、「ヌーラバー」と呼ばれるヌーラボの社員の方々が自律的に活動していく中で、一歩引いてその姿をやさしく穏やかに見守っているようにも見えます。

そんな橋本さんが「会社は「仲良しクラブ」でいい」という本を出されるという話を聞いて、橋本さんの人となりだけではなく、どうしてヌーラボという会社を立ち上げたのか、その中でどんなことを大切にしながらチームを率いているんだろうかというところに興味を抱いて、早速手にとったのでした。

プロジェクトや組織をポジティブに進めることのヒント

組織やプロジェクトには、実際にさまざまな属性の方がいます。プロパーやビジネスパートナーといった所属会社の違い、役職の違い、各々が持っているスキルの違い、考え方の違い、挙げていったらキリがありません。けれども組織やプロジェクトという「集団」として考えるとひとつのまとまりのようなものであって、それがとある目標に向かって進んでいくというミッションを持っています。

とはいえ前述の通り、そこに所属している方たちにはさまざまな個性があるわけで、時にはその個性を押しとどめても集団のために動かなければいけないという状況が往々にしてあるということも、私自身のこれまでの勤務経験の中で痛感してきたというのもまた事実です。

問題はその個性の部分を集団の中でどのように生かしていくと「新しい想定外の1」に変わるのかという、ある意味ポジティブな工夫やマインドの持ち方のヒントが数多く、しかも余すことなくオープンに書いていただいているところが本当に勉強になりました。

特に、私がどちらかというと自分のウィークポイントとして認識しているアンガーマネジメントに関する考え方だけでなく、この状況の中でオンラインでのコニュニケーションが中心となっている中で、「コミュニケーションは上手くいかなくて当たり前」という前提のもとで、「まず相手を信用する」というところから対話や仕事上でのタスクを渡すというアプローチは、現在の仕事の中でも活かすことができる部分が多くあり、自分のこれまでの仕事の仕方を省みてこれは改善できるかもしれないという形で、自分が変えたい側面に対して背中を押してもらうことができました。

きっと、この本を読むと、私だけでなく誰もがこのような気づきを感じるのではないかと思います。橋本さんのことなので、「金言」と書いてしまうといやいやそんなことはないよと言われてしまいそうですが、色々な属性や個性の方々と仕事(だけではないかもしれません。オーケストラなんかもそうかもしれませんね)をしていく中で、どのようにコラボレートしていけば物事が上手く流れてくれるかというエッセンスをたくさんいただいたような印象を持っています。

「偏愛家」というキーワードに関してもとても興味深く思いました。「偏愛家」というと、世間的にはオタク的なちょっとネガティブともとられてしまうかもしれない印象を持たれてしまいがちですが、それも実は個性の一部で、誰もがそのひとつやふたつは持っているのではないかと思うんですよね。

その偏愛的な部分を自律した個性やスキルのひとつとして尊重して生かしながら、集団としてのアウトプットにポジティブに反映するにはどのようにすればいいのかという点に関しても非常に興味深く読みました。

他にも組織やプロジェクトの価値をボトムアップしていく上でのさまざまなエッセンスが詰まっているのですが、これ以上書くとネタバレになってしまうので書くことはやめておこうと思いますが、全体的に思ったのは、これまでプロジェクトの中で働いていくことに対する閉塞感やモヤモヤ感を意外な形で払拭してくれた本でした。

組織論やチーム論に関する書籍は数多く出ていますが、これまで読んできたものに比べて非常に読みやすい印象を受けました。この本をこのタイミングで執筆してくださった橋本さんには心から感謝です。

カテゴリー: Work | タグ: , | コメントする

2022年の始まりに寄せて


ご挨拶

新年おめでとうございます。旧年中はさまざまな方に本当にお世話になりました。心から感謝しております。本年も多方面でご迷惑をおかけすることもあるかもしれませんが、どうぞよろしくお願いいたします。

そして、皆様の仕事や生活が、少しでも安全で心穏やかなものになりますように、心からお祈りしております。

今年何したいんだっけ?

あまり今年の抱負的なものを書いてしまうと、色々がんじがらめになってしまうので、あまり強く意識しないようにはしているんですけれども、去年に続いてこの言葉は心に留めておきたいですね。

だれでもキリストにあるならば、その人は新しく造られたものである。古いものは過ぎ去った、見よ、全てが新しくなったのである。

[第2コリント 5:17]

世間的には大変な状況が続いているのは現実です。まだまだ行動も制限されているし、思うようにいかないことも多いかもしれません。トンネルの先が見え始めたかなと思いきや、また元通りになりそうな気配もしていて、多くの人が一喜一憂していることと思います。

けれどもそういった状況だからこそ、日々の生活のどこかしらに小さな喜びというのはあるもので、そういう意味でも、古きものは記憶として残しつつもとりあえず置いておいて、何か新しいことにチャレンジしていったり、新しい環境に敢えて身を置いてみたり、そういった新しいものを取り入れていくことで、気持ちの新陳代謝を図っていきたいなと考えています。

それから何よりも、こういうご時世だからこそ心穏やかに、マインドをできるだけオープンにしていきたいですね。社会を眺めていると、さまざまな要因によっていろいろな分断があちこちで起きているのは確かに事実です。そういう時だからこそ、一人一人が心を広げていく必要があるのかもしれませんね。それは自分とて然り。変に威切ったりしても仕方がないですから。

もうこの年齢ですし、少しずつ心の中の強張りを緩くしていって、まんまるな感じで行きたいと思います。

あとは前のエントリーでも触れましたが、もう少し働き方にメリハリと自由度をつけていきたいですね。こういう時代にあった働き方で、これまで以上に成果を出していきたいなという思いはあります。できるかな?

結局今年何をするのかよくわからない文章になってしまいましたが、2022年の念頭にあたってのご挨拶と思うこととさせていただきます。

カテゴリー: Private, Work | タグ: | コメントする

46歳になって2021年を振り返る


46歳になりました

2021/12/30に無事に46歳になりました。45歳の1年間も色々な方にお世話になったことに、まずは感謝したいと思います。ありがとうございました。

四捨五入すれば見事に50代になってしまうので、アラフィフと呼ばれる世代にまた一歩片足を踏み入れつつあるという感じになるんですかね。体力的というよりも、このご時世もあってなのか、あまり無理はできなくなり、1日の生活パターンが段々と前倒しになってきたような気はします。朝はだいぶ早い時間から活動できるようになってきた一方で、夜は遅い時間まで活動することがかなり厳しくなってきて、徹夜なんてもってのほかというような感じになってきました。

仕事柄、時たま夜間にリリースの立ち会いをしなければならないケースもあったりするのですが、そういう時でも、いつまでも身体が持つというようなことは、正直なくなってきましたね。

このコロナ禍で社会全体の時間の流れ方がだんだん朝方にシフトしてきつつあるのかなという傾向を見ると、その流れに従うかのように朝方にシフトしてきたというのは、もしかしたら良いことなのかもしれません。

2021年の振り返り

その上で2021年をざっくりと全体的に振り返ってみると、特に上半期はちょっとワーカホリック気味になっていたかなというのは正直あります。社会的にはコロナ禍が続き、リモートワークが急激に進むようになって以来、通勤時間というものがほとんどなくなったということは、1日の過ごし方を考えてく上である意味においてはアドバンテージになった一方で、2020年初頭のリモートワーク環境移行時の混乱で身についてしまった、「朝早くから働く」という意識が悪い意味で身についてしまって、結果として、ついつい長い時間働くのが当たり前になってきてしまったというのはちょっと反省しなければいけないのかなと感じています。

もちろん、リモートワークの環境も様々なバックグラウンドを考慮すると人によって様々なので、朝早くから働くということが絶対悪ではないと思うのですが、多分課題だったのは、朝早くからにしようが一般的な勤務時間に合わせようが、家の中だったり、またそれに類する環境の中で、いかにして時間管理をうまくしながら効率的に適度にアウトプットを出しながら仕事をできるかというのが、この時代におけるライフワークバランスを考えていく上で重要な鍵となるのかなということは振り返りながら考えています。この点は来年はもう少し工夫していかなければいけない点ですね。

その一方で、このような働き方をしていく中で、どのようにすれば直接見えない相手に対してもうまくアウトプットを見せることで安心感を得てもらうかということに対しては、相変わらずの試行錯誤はまだ続いているものの、少しずつ前進してきたのかなというように考えています。

コロナ前の働き方って、ある意味「暗黙知」でも十分に相手の意図や考え方が通じ合っていた部分があっただけに、去年に関してはその前提が崩れたことで多少の混乱があったのは、それはそれで仕方がなかった部分があるのかもしれませんが、そこから1年が経過してくると、現在の働き方に対して十分に適応できてくる人と、なかなかそれが難しいという人が明確に分かれてきたような気がしています。これまで暗黙知でもなんとなく仕事をできてきた人が、「可視化」という行為に移行することになかなか順応できないことでそのような状況に陥っているような、そんな感覚をこの1年間の中で感じています。

とはいえ、そういう「人の特性」に近い部分を一気にボトムアップさせようというのは結構厳しくて、その人の考え方や姿勢に応じる形で、柔軟に対応していく必要もあるのかなということも学びました。そこは重要な学びポイントだったのかなということを考えています。

あとは、「集合知」って大事ですよね、ということも改めて強く感じたところではあります。こういう働き方をしている以上、ひとりがスーパースターでもあまり意味がないのかなと。確かにスーパースターであることそのものはすごいことなんですけれども、スターが一方的に引っ張ってくのは物理的にも結構無理があって、チームで働いていく上で、何かに強い人が何人か集まって、お惣菜を持ち寄るような感覚でアイデアを集めていくことが大事な時代になってきたのかなと。そういう意味での集合知という表現を使いました。個として自律しつつも、ある時には知見を共有し合いながら仕事を進めていく、そういう働き方が必要になってきているのかなということを強く感じていますし、そういう観点でのチーミングが必要なのかなということも、今年を振り替えていく中で、同時に感じています。

来年に向けての抱負的なものは年初に改めて書こうかなと思っているのですが、組織を大事にしつつももっと自由に働けるようになってもいいのかなと思っています。

今年も去年と変わらず羽田福岡間を頻繁に飛行機で往復したのですが、約1,000kmという距離を2時間弱で移動できるわけです。そして物理的な距離の制約にとらわれず成果を出そうと思えば成果を出せることも実際問題わかってしまったわけで、そういう意味では組織としての最低限のルールは守りながらも、もっと自由度を持って、その人が成果を出しやすい方向や環境で仕事をしていくのはアリなんじゃないかなと思いました。

このような状況が続いているからこそ、「自分にとっての心地よい働き方ってなんだろう」ということは強く感じます。今年はまだ準備段階ですが、来年以降は自分なりの心地よい働き方を少しずつ実現していく段階に移行していくのではないかなということを考え、目論んでいことになるかもしれません。

46歳も精神的に老いることなく、新しいことをどんどん吸収して変わらず成長していきたいと思っています。

カテゴリー: Private, Work | タグ: | コメントする