nDiki : モチベーション

WIP でmixi日記を書いてみた

一昨日からつぶやかないでmixi日記を書くことにした流れで、今日は朝に WIP (Work In Progress) なmixi日記エントリを作って追記・編集するスタイルで更新してみました。

• WIP でmixi日記を書いてみる日 (マイミクまで)

やってみた感想

• 朝にこれをやってみよう思いついた時は勢いがあったけれど、結局あまり大きなネタもなくそれほど書き足さなかった。
• age られないので予想通り時間とともにイイネ！などのフィードバックが減ってくるのでモチベーションが下がる。
• 多分完成版を見ている人はあまりいない。

やはり今の仕組みでは書き上げてから投稿した方が良いです。

仕事に対するスタンス共有 2017

去年9月ぶりの「仕事に対するスタンス共有ミーティング」です。下記の設問にあらかじめ答えを用意しておいて、ミーティングの場で発表するというものです。

チームビルディングの一環として、お互いを知り、うまく分担・補いあいながらコラボレーションしていけるようにしようという取り組みなんだけれど、他人を知るだけじゃなくて自分自身を再発見できたりもするのでお勧め。 — 仕事に対するスタンス共有 2013

新しくメンバが増えたこともあり今日は CS 開発チームのリーダーがセッティングしてくれました。「そういえば自分がやっている仕事はいったい何なんだろう?」と考えつつ回答をアップデート。

「自ら実践して模範を示す。」というのを追加しておいたら「実際にどんなことをしていますか?」と突っ込まれて、とっさに「ハンドスピナー」と答えてしまいました。だいたいそんな感じの模範活動です。

Q1. 仕事上でどのようことが得意ですか? 苦手なことは何ですか?

• 得意なこと: 仕事を進めていく仕組み作りをしていくこと。
• 苦手なこと: 大勢の人がいる場所にいること。懇親会。

Q2. 仕事をする上で一番大切にしていることはどんなことですか?

• 「どのようにすればで言ってみる」こと。
• 「いますぐやる」こと。「早くフィードバックを得る」こと。
• 「遊び心をいれる」こと。
• 「笑顔でいる」こと。
• 「情報を共有する」こと。

Q3. 仕事をしていて陥りがちな傾向はありますか?

• 腑に落ちない時に顔に出る。(参照)

Q4. 仕事をする上でモチベーションが下がるとき、上がるときはどんなときですか?

上がるとき:

• 感謝されたとき。ほめられたとき。感動したとき。

下がるとき:

• 知らないうちに何かが進んでいたとき。

Q5. 所属チームで(あるいは会社で)でどのような役割を果たしたいですか?

• ミッション・ビジョン・バリューを常に意識しつつ、グループとして最大のパフォーマンスを発揮できるようにマネジメントする。自ら実践して模範を示す。

Q6. 仕事を通して目指す将来の目標はありますか?

• いけてるマネージャー。問題解決スペシャリスト。

Q7. 仕事をする上で周囲や会社に対して、あなたはどうありたいと考えていますか?

• 周囲の人の良いところを引き出す人でありたい。

Q8. 仕事をする仲間に伝えたいことがあれば何でも。

• 一緒に笑いましょう。 (参照)

[ 仕事に対するスタンス共有 ]

ようやく nDiki に Twitterカードを実装した

書いた日記を Twitter でシェアした際に Twitter 上でグレーの地味なリンクサムネイル付きSummaryカードが出るのちょっと嫌だなぁと思ったので、そのうちと思っていた Twitterカードを対応をようやくすることにしました。

記事中の最初の画像を自動的にTwitterカードの画像に指定する案も考えたのですが、過去記事にも自動的に画像がつけられるという利点はあるものの、小さい画像など適切でないものが設定されてしまうこともあるかなと思ってそれはやめにしました。

なので記事中に [[ogpimage:URL]]と書いてあればそれを

 <meta name="twitter:image" content="URL">

とするようにしました。あとは twitter:card と twitter:site と twitter:title もヘッダに合わせて埋め込むようにして完成。

ついでに設定した画像 URL は Open Graph protocol (OGP) の og:image にも指定して Facebook でも認識できるようにしました。

日曜日の朝食にカルディコーヒーファームで買ったパナビの冷凍クロワッサンを焼いたら熱々サクサクで最高だった。また買っておきたい。 https://t.co/VqhUM04lY1

— Naney (@Naney) 2018年2月19日

これで日記に写真を載せるモチベーションもアップしそうです。

Developers Summit 2019 1日目 #devsumi

2015年・2016年・2017年以来、2年ぶり4回目の Developers Summit 参加。一昨年には無かった Wi-Fi のスポンサー提供があってとても快適になった。素晴らしー。

朝1番のセッションの冒頭で今回の事前登録が4000人超という話があった。大盛況。会場の混み具合からするともうキャパオーバーも近いのではと思えてくる。各セッション会場でのバーコードチェックがステージ近くで、まだセッションが終わる前に次のセッションの人が誘導されて入ってきたりして、待機列の問題からだろうけれど、ちょっと発表者に失礼なんじゃないかなーとは思ってみてた。

以下セッションタイトルは2月13日時点の公式サイトより。

10:00～10:45 【14-D-1】 Scrum@Scale入門

株式会社アトラクタ 原田騎郎(@haradakiro)氏

メモ

• スケール
  • 全く同じチームを複製してくことはできない。違いのあるチームを増やしていく。まずうまく行っているスクラムチームを2つ育ててから、スケールさせる(そうでないと悪いものがスケールする)。
• Scrum @ Scale フレームワーク
  • スクラムだけでもスケールする。
  • スクラムマスター(SM)
    • デイリースクラム階層。チームで解決できない課題を上位のデイリースクラムに伝えて解決していく(チームのデイリースクラムの方を1日の先にやる)。トップレベルは役員によるエグゼクティブアクションチーム(EAT)。 EAT もスクラムチームなのでスクラムの全てのアクティビティをやる。
    • SM で寄ってたかって協力。
    • マネージャーの仕事。
  • プロダクトオーナー (PO)
    • チームに1 PO。PO チーフ PO。チーフチーフ PO。
    • PO は上位のオーナーが絶対。
  • 各チームに常に PO と SM がいる。そうするとチーム単位で動かせる。ニーズの変化でチームごと動かせる。チームを立ち上げる時間よりも、チームが新しい担当を覚える方が早い。チームを壊さない。
• PO
  • 「調査してから…」ではなく「今間違えろ」(辛いけど……)

思ったこと

やはり適切な人数の自己組織化されたチームで構成される体制を作っていきたいな。エッセンシャル スクラムだとプロダクトバックログは唯一なものと書かれていたと思うんだけれど*1、現実的なところ抽象度の違う階層化されたバックログとチーム毎にそれぞれあるバックログという感じでいいんだな多分(エッセンシャル スクラムでも階層化バックログ自体は紹介されている)。

11:05～11:50 【14-A-2】 GitHub Actionsはどのような未来を描くのか : コンテナ技術が開くワークフローのOSS化

GitHub 池田尚史(@ikeike443)氏

GitHub Actions で Docker イメージを作成して、デプロイまで実行できるようになるという話。デプロイ以外にも GitHub 内での様々な処理も。

12:10～12:40 【14-A-3】 GCPに恋してHashiCorpを愛して起業したエンジニアのお話

株式会社grasys 長谷川祐介氏

サンドイッチ。HashiCorp 製品と Google Cloud の紹介。それから企業の話についての自分語りを伺えた。

13:05～13:50 【14-D-4】 大学におけるイマドキのエンジニア教育

ワイクル株式会社 角征典(@kdmsnr)氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏

前半永瀬氏による enPiT 事例紹介。

後半角征典氏のエンジニアリングデザインプロジェクト(EDP)を通じた知見紹介。参加者の多様性とモチベーションのばらつきを意識した取り組みが素晴らしい。

こちらでもやはり最適なチームについて(人数・多様性)が取り上げられていた。メンバの多様性によるデメリット(ここではモノづくり工程ではデザイナーができることが少ない)もきちんと示されていて、その上でそうしているという話で説得力があった。

ただ「やってみているという話」ではなく、裏打ちされた方法論を押さえた上での取り組みで学びのある話だった。

東工大生イジりが嫌味がないのも素敵。

14:10～14:55 【14-D-5】 新技術導入を成功させる組織のつくりかた ～spanner、GKE導入の実体験から得たこと～

株式会社コロプラ 廣本洋一氏

• コロプラでのマネージメント事例。2年前に事業部制から機能別組織に。
• コピーベースで新しいアプリケーションを作ることによる課題があった。
• ノーメンテナンス時間というポリシーを前提とした技術選択。
• オーバーエンジニアリングとの戦い。

機能別組織だからこそ、事業部とは別のロードマップで優先度判断ができる部分があるのだなと感じた。

15:15～16:00 【14-A-6】 レガシーとのいい感じの付き合い方 〜15年続くウェブサービスのシステム改善パターン〜

株式会社VOYAGE GROUP 福田剛広氏 小林徹也氏 駒崎大輔氏

ECナビについて2年弱かけて AWS 移行した話。

サービスの長期運用で技術が古くなり、エンジニアから見た魅力がなくなり新規採用で苦戦したり、在籍エンジニアのモチベーションがダウンしたりというのはあるある話だ。

別だったインフラとアプリの管轄を分けないようにする・オンプレから AWS に移行する・いったんそのままの構成で移すなどは、そうだよねというかそうするよねというかそうしているよねとかそういう感じ。現実的・保守的な判断かなと。

発表者の1人が年末で退職済みということで、嗚呼となった。

16:20～17:05 【14-A-7】 ZOZOTOWNのDWHをRedshiftからBigQueryにお引越しした話

株式会社ZOZOテクノロジーズ 塩崎健弘氏

BigQuery 移行事例についての、味わいのある発表。

今日はシャッター音少なめだなと思っていたのだけれど、このセッションは賑やか。聴講者の層が違うのかな。

17:25～18:45 【14-A-8】 「ITエンジニアに読んでほしい！技術書・ビジネス書大賞 2019」プレゼン大会

高柳謙氏 株式会社丸善ジュンク堂書店 平木啓太氏 株式会社スマートニュース 瀬尾傑氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏

技術書・ビジネス書のそれぞれトップ3人の著者(や関係者)によるプレゼンテーションと投票・発表のセッション。

新型コロナウイルス感染対策と猛暑で半年あまり出掛けなかった体の健康診断

恵比寿桜十字クリニックでの4回目の健康診断。

2月下旬から新型コロナウイルス感染対策で外出を控え始めてから運動量がだいぶ減って半年以上。お腹まわりが少し大きく重くなっているなと感じている中での健康診断だ。去年夏前に多少筋トレしたり食べ物を工夫したりしたのだけれど健康診断結果にあまり反映されず、今年は頑張るモチベーションが下がって何もしていなかったというのもちょっと気になるところ。

やはり体重は重くなっていたけれどたしか 1kg ぐらいの差だったので、思ったほどはという感じ。結石も順調に 1mm 程度大きくなっているようだ。

気になるのは矯正視力がガクッと下がっていたこと。今回の測定器での測定で下がっているのがそのせいかは分からないが、老視が進んでいる自覚はある。

総合的な健康診断結果が後日届くの待ちだ。

[ COVID-19 ]

小さな習慣

筋トレが長続きしない。「強い意志をもって続け健康になろう」という精神力頼りでこれ以上失敗体験を増やすのはだめだ。「毎日歯を磨かないと気持ち悪い」と同じになるよう、習慣にすることだけにまずフォーカスした方がいい。以前同僚に『小さな習慣 (Mini Habits: Smaller Habits, Bigger Results))』 という本を教えてもらったことを思い出したので読んでみたところ、シンプルでいけそうな習慣化ハックが紹介されていた。

• 『小さな習慣』
• 『小さな習慣』 (Kindle版)

小さな習慣とは

本書では新たな習慣にしたいと思っている行動をもっとも小さい形にしたものを「小さな習慣」と呼んでいる。例えば「腕立て伏せ1回」のようなものだ。

わずかな意志の力で毎日実行し習慣化する

習慣化するには行動の繰り返しと報酬が必要だ。習慣になるまではモチベーションか意志の力を使って行動することになる。

モチベーションは心理状態やエネルギーによって上下しやすく習慣化のためには信頼できないので、意志の力で実行するようにした方が良い。

「小さな習慣」であれば忙しくて時間がない日や疲れている日でもほんのわずかな意志の力で実行できる。常に目標を達成できていることが励みにもなり、毎日続けるうちに習慣として定着するのだ。

行動開始の合図(habit cue)は?

行動開始の合図は決まった時刻(時間ベース)やなにかの行動の後(行動ベース)などが一般的。

本書では「小さな習慣」で行動開始の合図を決めずに(行動開始の合図を複数とし)就寝時間までにやるというフリースタイルも選択肢として提案している。特に生活の一部にしたい習慣は特定の開始合図を設けない方が良いのだという。

小さな目標で意味があるの?

毎日「腕立て伏せ1回」で意味があるのか?

行動を起こしてしまえば、ほとんどいつも「おまけ」でもっと多くをこなしてしまうよというのが本書の主張である。「行動するとやる気がおきる」とよく言われているので頷ける。また「小さな習慣」が本当の習慣の定着につながっていくので、早く習慣化される「小さな習慣」をすることに意味があるという。

なお、小さな目標以上を達成すると無意識が新たな期待値を設定してしまうことから大きな目標に変えてしまいがちだが、これは意識的に拒む必要がある。

その他気になった点について

疑問に感じたことについては以下のように書かれていた。

• やりそびれたらどうなる? → 1日だけやりそびれたとしても習慣化の流れが途切れてしまうわけではないので大丈夫。
• 小さな習慣はいくつまで? → 全部合わせても10分以内に終わるもので。2つか3つがおすすめ。4つ以上はすすめない。
• 毎日やる必要のない習慣はどうする? → ふたつの選択肢のどちらかを毎日するハイブリッド版にする方法があるが、選択に意志の力を使うことになるため著者は好んでいない。

まず「小さな習慣」にして続けてみる

すぐに始められて毎日継続できているので気に入っている。習慣化についてはまず「小さな習慣」にするだな。

• 『小さな習慣』
• 『小さな習慣』 (Kindle版)

[ 読書ノート ]

Clubhouse で初めて音を聞いた

一昨日登録した Clubhouse で初めて音を聞いてみた。「週末に自宅で1人イヤホンを耳にして……」という過ごし方をしたく無かったので今日になった。

今日ミーティングでの雑談で「低遅延でいい感じ」って聞いたのだけれど、たしかにたしかに。スピーカー間の会話のタイミングに違和感が無い。スピーカー同士が同じ収録室にいるのではと感じちゃう。

「音声版 Twitter」と表しているのをちらほら見かけていたので、短い音声単位でポストしていくようなイメージをもっていたのだけれど、全然違った。全然「音声版 Twitter」じゃない。

とりあえずいくつか Room に出入りしてみたけれど、だべっているのを聞かされている感じで興味を持てず出るのが大半だった。「人に関心がある」ので聞くのか「テーマに関心がある」ので聞くのか。人に関心があって聞きたいという人に向いているのかな。

自分が面白いと思える Room に出会うには好きなジャンルのユーザーをフォローすれば良さそうなので、ちょっとずつフォローしていってみる。

逆に興味が無い Room を出にくくするには、現状さくさくアンフォローするしかないのかなー。

「おしゃべりしているのをみんなに聞いてもらいたい」というモチベーションがないし「おしゃべりを聞く」のに時間を奪われるのもなという懸念があるので、まだ距離感をつかめていない感じ。

初めて Twitter Spaces にリスナー参加

作成はもちろんリスナー参加もしたことが無かった Spaces だが、会社の人がやっているラジオなら聞いてみたいなとブラウザ版 twitter.com でリスナー参加してみた。なるほどラジオっぽい。身近な人が生で喋っている配信を聞くの面白いな。

Twitter はアクセシビリティに力を入れていて、Spaces には聴覚障害者向けに自動キャプション機能が提供されている。そこそこの精度で文字起こしされてるのはすごいな。

ライブ動画・ライブ音声で発信したいというモチベーションが無く、また有名人でもない面識が無い人のトークの視聴に時間を費やすことに抵抗感があるので、サービスに対する印象は今の時点では Clubhouse で感じたことと同じかな。

やっぱり Logseq を使う

先週で Logseq を使うのをやめることにしたのだが、離れてみてやっぱり使いたいなあと思えてきたので使うことにした。

• https://logseq.com/

Mac で常時起動してデスクトップの端っこに置いておき、思い浮かんだことをさっと書いたり膨らませたりする用途で使う。スマートフォンでも追記ぐらいはできるようにしておきたいので、Logseq の Android 版を入れた。今のところ問題なし。 Logseq graph を Obsidian vault の中に入れて一緒に Obsidian Sync しちゃうことにした。

あとはプロジェクトのプランニングや行動デザインの管理にも使ってみるつもり。

Markdown ファイルとはいえ独自記法が多いし、ネストの深いリストはアウトライナーがないと扱いづらいので、ファイルは基本 Logseq 専用と割り切ろう。

SEO に不利なのでエクスポートして公開といった用途には使わない。そもそも SEO 以前に、階層の深いアウトラインノートは他人に見てもらうのに向かないんだった。開閉・ズーム機能が使える形だったとしても、相当なモチベーションがない限りそこまで頑張って読もうとは思われないし。

フォッグ行動モデルとタイニーハビットが学べる『習慣超大全』

フォッグ行動モデルの BJ Fogg 氏が書いた行動デザインについての本。原題は Tiny Habits: The Small Changes That Change Everything だ。良書なのに「超大全」などと安っぽいイケてない邦題がつけられているのが非常に残念だ。実際内容も習慣についての大全ではない。BJ Fogg 氏の本だと気づかなかったら買っていなかった。

今回は「フォッグ行動モデル」を調べていて BJ Fogg 氏自身が書いた本だと知り購入したのだった。

行動デザインとフォッグ行動モデル

本書は BJ Fogg 氏が「人生を変えるシンプルな方法をデザインすることを目的」とて考案した「行動デザイン」システムについて述べられている。「行動をデザインする」という言葉がかっこいい。しびれる。

フォッグ行動モデルは行動デザインの主なモデルの1つとして取り上げられて詳しく説明されている。習慣化というテーマの中での説明だが、消費者行動モデルとしての理解にも十分つながった。

フォッグ行動モデルとタイニーハビット

フォッグ行動モデルを基礎とした習慣化メソッドとしてのタイニーハビットは「小さな行動」を実践していくという点で、『小さな習慣』と通ずるものがある。

『小さな習慣』ではモチベーションに頼らず意志の力を使うとしていたが、このモチベーションと切り離された意志の力というのが分かりづらかった。

タイニーハビットでは行動を起こすことについてフォッグ行動モデルの3要素(モチベーション・能力・きっかけ)で説明されており、しっくりきた。

分かりやすいフォーマット

邦題が残念な翻訳書ではあったが、フォーマットはとても見やすくわかりやすかった。過不足なく強調・囲み表現されていて自分でハイライトしていく必要がなく、それでも後で読み返すのに困らなかった。

強調だらけの本は、Kindle で学習用に自分でハイライトしにくいというのがあるのだけれど、本書は特に困らなかった。

何度も読み直しやすい良い本だ。

• 習慣超大全——スタンフォード行動デザイン研究所の自分を変える方法 (単行本)
• 習慣超大全——スタンフォード行動デザイン研究所の自分を変える方法 (Kindle 版)

[ 読書ノート ] [ お薦めの本 ]