自分がやたらと片付けたくなる理由

何かと片付けたくなる。特にキレイにかつ物が少ない状態で保たれていないと気持ち悪いのが机の上とかPCのデスクトップ。もちろん他に本棚とかキッチンカウンターとかも散らかっていれば気になる。

しかしなぜこんなに自分が片付けたくなるのかは自分でも謎だった。が、最近自分は脳内メモリが少ないからではないかという気がしている。脳内メモリが少ない故、散らかった状態だとそれを気にかけることによりメモリを消費してしまい、本来頭を使うべきことに集中できないのではないか。

それに気づいてからは自分のワーキングメモリを節約すべく、もっと家の散らかりと戦おうというモチベーションが湧いてきた。

なぜアウトプット志向を目指すのか

改めて考える。

インプットにはキリがない。これは本屋とか図書館に行き、圧倒的な量の書籍を目にすると実感する。絶対にこれ全部読むの無理って思う。また、インプットだと深い考えには至らない。ただ、自分の世界を広げるためのインプットは必要。

アウトプットのチャネルは、

  • 人に話してみる
  • ブログに書いてみる
  • Twitterでつぶやく
  • 何かしらのプログラムを作る

とか。

とりあえずブログをWordpress化して多少HTML, CSSあたりをもう少しマシなレベルに持っていきたい。かつもう少しブログが捗るようにしたい。

とか考えているけど今身につけるべきスキルは3D画像処理とか機械学習。というわけなのでまずはそちらをアウトプット志向で身につけていくとしよう。

ヘボブログだけど、それでも昔の記事を読むと書いてる意味はあるなと思う。

iPad Pro (11インチ)導入して2カ月後の感想など

相当間が空いてしまった。もう一生アウトプット人間にはなれないのかもしれない。

それはとりあえず置いておいて、4月末にiPad Pro 11インチを手に入れた。Apple pencilも。iPadはケチって最下位モデルの64GB wifiモデル。ただ特に不満はない。

iPadは主に文字情報の読み書き専用のデバイスとして使おうと心に決めていたので、割り込みされるメール、LINE等のコミュニケーション系のアプリは入れていない。そうなると常にネットワークにつながっている必要性はあまりない。むしろ読み書きに集中できてよい。

写真、ビデオも使わないので容量もいらない。今ストレージ容量のほとんどを占めているのは楽天マガジンのダウンロード済み雑誌だが、使ってみた結果読み終わった雑誌は基本読み返さないので削除してしまえばよい。最悪iPad OSリリース後に外部ストレージを使えばいいかと思っている。

主に使っているアプリは、日経新聞楽天マガジン、Goodnotesくらいである。あとはたまに長文ウェブサイト閲覧用にchromeを使うくらい。だがこれによってほぼ紙媒体を排除できた。また、技術リファレンスなどじっくりよみたいページもiPadのほうがPCより読みやすい。

さて、そんな中久々にブログを書こうと思ったきっかけは、楽天マガジンで読めるニューズウィークの今週の記事、「世界のリーダーに学ぶリーダー論」である。この記事で言っているリーダーはたぶんグローバルの前線で活躍するような人だと思うので、今のところ自分は正直そこまで目指してはいない。が、リーダーに求められることは人間としての衝動を制御できることであり、その衝動として書かれていた以下4つの弱点がグサッときた。

  1. 気が散りやすいこと
  2. 内集団バイアス
  3. 確実性を好む(バイアス)
  4. 考えることをさぼる癖

見事に全部自分に当てはまっている。人間の衝動なので誰でもそうなのかもしれないが。ただ、1と4は最近特にひどい気がしている。一番の原因となっていそうなのがスマホでの情報収集。はてブから始まり、FacebookSmartnewsが基本の流れだが、これだけでも30分くらいは消費してしまう。しかも色んな情報が断片的に入ってくるので、脱線して深追いしたりしていくとあっという間に時間が過ぎるが大して自分の実にはなっていない。

新聞や書籍とウェブを比べて思うのは、ウェブのほうがつい簡単に頭に入ってくる情報を選びがちだということだ。日経新聞は紙面リーダーで読んでいるが、ネットサーフィン中に同じ日経新聞の記事を見かけてもスルーしてしまう気がする。

そんなわけでスマホは弱点1と4を助長するデバイスであると自分の中で結論づけた。そして自分のアウトプット思考を妨げになっているのもこれなのではと思い始めている。とりあえずスマホでの情報収集を一旦やめて、新聞と楽天マガジンで読めるニュース系の雑誌にしてみよう。

そんあわけでこのエントリはiPadで書いてみた。PCで書くより気が散りにくくてよいかもしれない。ソフトウェアキーボードはあまり速く入力できないけど、考える時間の割合のほうが大きいのでそれほど問題にはならない。

最近はすっかり子供と一緒に21時ごろ寝て、自由時間は早朝というスタイルが定着した。目が覚めた後起きて机に向かえるのがベストだが布団が快適でなかなか出られない。その結果これまではスマホで時間潰してしまうことが多かったが、これからはiPadでの情報収集&ブログの時間に変えていきたい。いつまで続くのか結果はいかに。

しかい冬は寒くて布団から出られないので、朝の時間を活用するのは夏になってからが本番だと思っていたが、夏になると子供が早起きしてしまい、思ったほど一人の時間が多くないのは誤算。。

2019年抱負

あけおめです。読者がほぼいないこのブログにおいて誰対して言っているのか謎だが。自分に対してか。

今年の抱負はいい加減にアウトプットを習慣にすることだ。このブログを開設して早5年。細々と続いてはいるが、年間の投稿数は毎年20ほど。しかも20のうちいくつかはほとんど文字数がないので、実質的な投稿はもっと少ない。

露出を増やすのは怖いが、そうしないと得られないものはありそうなので頑張ってみる。

また、自分は注意散漫なので、アウトプットしながら作業を進めないとどんどん脇道に逸れて行ってしまう。それを防ぐ意味でもアウトプットを習慣にしたい。

本当は何を持ってアウトプットを習慣化したと言えるのかを定義したいところだが時間切れ。

アジャイルソフトウェア開発の奥義

一度真面目にソフトウェア設計を学びなおしたいと思い、手に取った。この本がよかったのかどうかはわからない。

第1章 アジャイルラクティス

改めてアジャイルラクティスの復習。

「しっかりしたルールを作って成果を得る」ためのプロセス作りに駆り立てることになる。

完全に今の自分である。ただ、一度作ったルールの撤廃が難しいことは認識しているのでルールの導入には慎重にやっているつもりではある。
付録Cを読む限り、ここでいうプロセスは要はウォーターフロー開発のことを言っているのか?とという気がする。

包括的なドキュメントよりも動くソフトウェアを重視する

ドキュメントのメンテナンスは難しい。また、できる人が限られてしまう。今の開発体制の場合、ドキュメントを書くよりもコードをCleanに保つことのほうが重要であると感じた。

第2章 エクストリームプログラミングの概要

うーん、やはりテストファーストなんだろうか。
CIは次のプロジェクトでは必ず採用したい。

第7章 アジャイル設計とは?

要は仕様変更に対応できる設計をせよという話。その後の章で具体的にどうすればよいかが書かれている。

この本を読みながら考えていること

  • コードをCleanに保つことが重要。
  • ドキュメントも多少は必要。設計ポリシーや実装メモなど。
  • テストファーストは悩ましい。

リモートかつ時差がある場合の朝会について

先週から今週にかけて、チームにおいて以下のような問題が発生した。

問題1

1人のエンジニア(自分とは別拠点, 時差あり、外国人)が一つのタスクを3日以上続けている。タスクの内容としては3日はかかりすぎ。状況を確認してみると、こちらが指定したデザインを実装する方法が見るからずトライ&エラーを繰り返していたとのこと。別のデザインで対応することとしてクローズ。途中で進捗確認をしていたらすぐに方向転換できた。

問題2

1人のエンジニア(自分と同拠点, 外国人)が一つのタスクを5日ほど続けている。彼にとって難しい作業なのは承知済なので、多少時間がかかるのは折り込み済。5日経過したところで、「リモートのエンジニアに相談してみたら?」と言ったところ、すぐに解決。途中で進捗確認をしていたらすぐに解決していた。

対処方法の検討

なんで3日も5日もタスクを放置するのか、という突っ込みがあると思うが(誰から?)、今のチームは自分がプロダクトオーナー(的)かつスクラムマスター(的)という体制になっており、タスクの進捗確認の時間がとれていないためである。なぜそうなっているかといえば人がいないからである。これについては会社として人を増やす方向に動いてくれているので時間の問題ではある。

www.ryuzee.com

というわけでこんな問題が起きているので、やはり無理やりにでも時間を作って朝会的なものにより問題を早期に把握せねばと思った次第。で、朝会について調べてみると、大抵、朝一で立ったまま全員が集まってやるのがいいよ的なことが書いてあるのだが、無理である。時差があるのである拠点では朝でも別の拠点では朝ではない。また、国籍が異なるエンジニアということもあり、口頭でのコミュニケーションが盛り上がらない。「問題ある?」と聞いても「問題ない」と返ってくることが多い。

blogs.itmedia.co.jp

日本語の情報を調べてもあまりよい記事が見当たらなかったので、英語で探してみるとDayly Cafeなる方法があるようである。

blog.agilityscales.com

面白いが、今のチームでは成立する気がしない。

考えた結果、今のチームの場合は次の方法でやってみようと思う。

  1. 日本の朝で自分とゲートウェイエンジニアで朝会を行う (10:00)
  2. 日本のゲートウェイエンジニアとリモート現地エンジニアで朝会を行う (リモート拠点の8:00) 。内容をゲートウェイエンジニアから報告してもらう。

問題は自分が顧客訪問等で会社にいない場合だ。Slack等を使うしかないと思うが、このあたりにプロダクトオーナーとスクラムマスターの兼任に限界を感じる。

アジャイルサムライ

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

第9章 イテレーションの運営:実現させる

ソフトウェアの開発には、分析、開発、テスト、デプロイの作業がある。今は分析作業の成果物がないので、できる範囲でこれを作るようにしたい。また、開発フェーズでのペアプログラミングも今後はアリかもしれない。

また、タイムボックスを区切ったスプリントではなく、カンバンでもよいというのは少し気が楽になった。書いてあるとおり、プロジェクトやチームに合わせて導入すればよいと思う。