こまメモ

Twitter以上技術ブログ未満

非同期でのディスカッションのための原案作成能力の重要性ほか

仕事上の達成感を記録する

自分はオライリーのサブスク目当てでACMの会員になっているので、ときどき会報誌であるCommunications of the ACM が自宅に届く。読まずに捨てるのももったいないので、目次を見て興味を惹く記事があればパラパラと読むようにしている。今号には "The 10 Best Practices for Remote Software Engineering"という記事があったので読んでみたところ、少しヒントになることが書いてあったのでメモしておく。

目に留まったのは、 "Define Productivity for Yourself" というアドバイスだ。いわく、ソフトウェア開発者の生産性は定量化しづらいが、生産的であることは幸福であることと相関することから、日々のタスクを自分の満足感の観点で評価することで自分なりの生産性を定義できる。

記事では、一つの実装として、仕事中に何かしら「達成したぞ！」と思えたときに、リストに項目を書き足していくというものが提案されている。ここで重要なのは、そのリストに書く項目は必ずしも目に見える仕事上の達成事項でなくてもいいということだ。「チームでのコラボレーションを促進できた」というようなソフトなものでもいいのだ。このリストは、自己理解のためにも役立つという。

慌ただしく仕事をしているときや、困難な課題に取り組んでなかなか成果が出ないときは、自分のやっていることに自信がなくなりがちだと感じる。「なんか気づいたら1日が終わってしまっていたぞ」ということがしばしばある。通勤時間という仕事とプライベートとの切り替えに役立つ時間がなくなったことで、どんな1日だったかを思い返す時間も（意識的にとらなければ）なくなっている。記事で紹介されていた内容は、こうした自分の課題への対応に何かしらヒントになった気がする。

 

書誌情報を貼っておこうと思ったら全文Webで無料で読めることに気づいた。会報誌のWebサイト上の人気記事ランキングトップのようだ。

 

m-cacm.acm.org

 

 

「登壇とかしないんですか？」という問い

「登壇とかしないんですか？」と問われると、即座に「いやぁ別に喋りたいことないですし。」と答えてしまうのだが、少し真面目に考えてみたいなと思う。

登壇をすることへのモチベーションは、人によって異なるであろうが、よくあるのは以下のようなものだろう。

  • コミュニティに貢献したい
  • 自分の得た知見を伝えたい
  • 発表することによりフィードバックを得たい
  • 登壇をきっかけに勉強したい、考えをまとめたい
  • プレゼンテーションの練習をしたい
  • 楽しい

ひとつひとつ、自己点検してみたいと思うが、モチベーションについて考える前に、反対にデモチベートしてくる要因について少し触れておきたい。これはそもそもというところなのだが、知識や考えを限られた長さにまとめるというのは自分がかなり苦手とする分野だと思っている。学生時代、スピーチ的なものをする機会があったが、これの準備が本当に苦痛だった。大した長さではないスピーチの原稿を用意するのに、数ヶ月の時間が与えられていたのだが、全くまとまらなかった。スピーチ自体の性質にも依るところがあったと思うが、いまだに嫌な思い出である。

口頭での発表以外だと、レポートや論文というものもあったが、これも苦手だった。大学に入ってから研究者に憧れて（そう、単に「憧れて」！）、最終的に大学院にまで進学したが、レポートや論文の執筆はいつもしんどかった。じゃあ執筆以外の勉強はスイスイ行っていたのかと言われるとそういうわけではないのだが……。

というわけで、文章にまとめる能力に苦手意識があるということは伝わったと思う。人前で何かを喋るということにはそこまで抵抗はないのだが、準備段階が本当に苦痛なのである。想定される「いやお前今文章書いてるやん」という問いに対しては、「まとまりを無視してダラダラ書くことと、主張を明確にして補足情報を必要十分にして書くことは別なんですよ」とあらかじめ答えておきたい。

以上のような「そもそも登壇（より正確に言えばその準備）に対する心理的ハードルが高い」ということを踏まえつつ、モチベーションについて考えていこう（気づいている人は気づいていると思うが、「少し」と言っていたのに既にだいぶ長い文章を書いてしまった。こういうところが自分が文章を書くのが苦手だと言っているところなわけです）。

まず、「コミュニティに貢献したい」だが、あんまり登壇との関連でそういうことをモチベーションとして思ったことがない。TwitterのTLで困っている人がいて、助けになりそうな情報を自分が持っていたら喜んで提供するけれども、自分が登壇することでコミュニティに貢献できるという感覚がない。とはいえ、ここは自分がもっと知識や経験を蓄えて、自分の持っている知見で色んな人を助けられそうだと思えるようになったらまた変わってくるかもしれない。話はそれるが、コミュニティへの貢献という話が出たのでとりあえず↓を貼っておく。

次に「自分の得た知見を伝えたい」だが、これを考えると「自分は最近どんな知見を獲得できているだろうか」ということを考えざるをえない。そう考えてみると、全く学びがないということはなく、社内に対して共有することは多いのだが、広く世の中に伝えるような知見というのを得られているかというと、（得られているとは思うのだが）そのレベルまで学びを抽象化できていないなと思う。これは反省すべきことだなと思う。

次に「発表することによりフィードバックを得たい」。うーん、フィードバックを得て更にアップデートしたいようなアイデアを今のところ持っていない。上級者向けのモチベーションだと思う。端的に誤っているかもしれないと思うようなことはそもそも発表したいと思わないし。

「登壇をきっかけに勉強したい、考えをまとめたい」。これは、うん、やった方がいいかもしれない。かつてブログを書いていたときはこれが一つの鍵だった気がする。基本的に、自分の勉強は現場での困りごとをなんとか突破しようとするところからエネルギーを得ているので、ブログや登壇に向くようなテーマである確率は低いのだが、チャンスを見つけたらアウトプット駆動でやっていくというのは考えるべきことだと思った。

「プレゼンテーションの練習をしたい」。もしかしたらこれはした方がいいのかもしれないが、仕事で人に物を説明する機会はいくらでもあるのでそこで意識的に訓練した方がいいと思う。ってかそれはやらないといけないな……。

最後、「楽しい」。いや、楽しくないですね。喋ること自体が仮に楽しかったとしても準備の苦痛を上回ることは多分ない。

というわけで、「登壇していくぞ！」という結論になるわけではないのだが、色々と考え直すことがありそうだ、という日曜の夜でした。

アジャイルのライトウィングを志向した Scrum Developers Night! というイベント

昨年の9月ごろから、月に1回弱くらいのペースで、「Scrum Developers Night!」というイベントを（オンラインで）開催している（次回開催は4/28）。

smn.connpass.com

このイベントは、「Scrum Masters Night!」という以前から存在しているイベント/コミュニティから派生したものだ（connpassのグループとしては今でも間借りの状態）。形式としても、参加者がお題を持ち寄ってディスカッションをするOST（Open Space Technology）を共通して採用している。「Scrum Masters Night!」には新型コロナ前のリアルイベントでも参加したことがあるのだが、夏前にオンライン開催されたときに以下のようなツイートをしていたら運営メンバーの人に声をかけてもらい、実際に「Scrum Developers Night!」を開催することになった。以来、運営として関わりつづけている。

最近の自分のTwitterからはそれほど感じないかもしれないが、自分はアジャイル大好き人間だった（今も別に嫌いになったわけではない。価値観としてのアジャイルは会社でも当たり前に共有されているので殊更に主張しなくなっただけだ）。一番こじらせていたときの自分の考えはもう片方のブログの方を漁ってもらえば小っ恥ずかしい文章が出てくるはずなので敢えて今更述べない。

自分がアジャイルに接近したのは開発プロセスの方面からだった。それは『カイゼン・ジャーニー』と『エンジニアリング組織論への招待』という自分の社会人1年目の終わりごろに出版された2冊の書籍から自分が大きな影響を受けた結果でもあると同時に、技術面でのスキルや経験が乏しかった自分が（攻撃的な言い方をすれば）「技術から逃げた」結果でもあっただろう。

前職時代は、アジャイルというものが価値観として受け入れられていなかったのだが、自分は問題を「社会学的なもの」だと同定し、愚かにも正面突破しようとしていたので、その面でも技術の方面への関心事は二次的なものだった。しかし、現職では価値観の水準においてはアジャイルは一定程度には共有されており、（もちろん開発プロセスの方の改善の余地はたくさんあるのだが）技術的な問題の方に自分としても関心が向くようになってきた。また、既に運用に乗っているWebシステムを動かしながらそこに機能をリリースしていくという開発のあり方も、いわゆるDevOpsの技術的なプラクティスへの自分の関心を強めているだろう。

そういうわけで、「レフトウィング」からアジャイルに入った自分が、この1年くらいは「ライトウィング」の方に傾斜してきているのだ。

blogs.itmedia.co.jp

「レフトウィング」の方がスクラムを中心に今でもまとまりを保っているのに対して、「ライトウィング」の方はというと、アジャイルの技術的プラクティスとして始まった（あるいは注目された）ものたちは個別には大いに発展しているのだが、しばしば「技術的プラクティスはXPに〜」などと言われるけど当のXPについてまとまった話もされないし凝集度の高いコミュニティがあるわけでもない、という感じの状況だ。

（時にスクラムを採用するなどしながら）アジャイルの価値観を共有して開発をしようとしていると、自動テストやデプロイの仕組みの改善、技術的負債の解消やインクリメンタルな設計といった技術的な課題がいくらでも出てくる。「技術的卓越性と優れた設計に対する不断の注意が機敏さを高め」*1るのだ。技術の問題も重要なのだ。

また、例えばスクラムでは、スクラムという名を冠したロールである「スクラムマスター」や、何かと期待値が高すぎるといわれるプロダクトオーナーの方に注目が集まりがちだと思うのだが、チームの大多数は開発者なのだという事実がある。それはスクラムを採用していないチームであっても変わらないだろう。アジャイルやスクラムでいい感じに開発しようとしてもがいている人のうち、少なからぬ量が開発者であるということだ。

というわけで、もっとdevelop(er)の話をしようぜ、ということで「Scrum Developers Night!」が生まれたんだよ、というお話でした。自分はまだまだ経験が足りないけど、他の運営メンバーには開発者としての経験も豊富な人がいるし、参加者同士での情報・意見交換から生まれるものも多いと思うので、興味ある人は一度覗きにきてください。Discord開催なので、一言も喋らなくても大丈夫ですよ。

*1:「アジャイル宣言の背後にある原則」より。

個人目標って難しい

自分の会社では、開発者1人1人が個人目標を設定している。個人目標は評価制度に従属していないので、個人目標というものの使い方は人それぞれだ。前職でも個人目標を立てるという制度はあったのだが、自分はどうもこの個人目標というものをうまく活用できていないな、と思う。

新卒で入った会社で初めてプログラミングに接してからの2年くらいは、何を学んでも新鮮で、興味を持ったこと（ソフトウェア設計や開発プロセス）について本を読んだり勉強会に出たりしているだけで「前に進んでいる」感覚が得られた。それらは実際の業務でも役立った、と自分では思っているし、おそらくそれらの勉強をしていたことは、転職をしようとしたときにも助けになったのだろうと思う。

しかし、現在の会社に入ってから、目の前の仕事での課題を解くために書籍や勉強会から得られる知識が役立つ割合が減っているという感触がある。これはおそらく自分の成長が知識の点においてはある種の踊り場に差し掛かっているということなのだと思う。同じようなジャンルの本ばっかり読んできたからなぁ。

この1年の自分の課題感のほとんどは実践の水準にあって、思ったよりも自分がうまく仕事を進められないという悩みが中心だ。本を読んで適用すればうまくいくという気が全くしていなくて、目の前の課題に（今まで学んできたことももちろん使いながら）真っ向から取り組まなくてはいけない時期かな、と感じる。

こうなったときに、個人目標の立て方としてわかりやすいのは、今まで触ったことのない技術の勉強をするとか、そういう方向だろう。自分が今まで勉強してきた分野と同じく、それぞれの分野には読むべき書籍というものがあるわけなので、これを各個撃破していけば書籍からの学習による知識レベル向上の踊り場とはしばらく無縁でいられる。ということで、昨年度の個人目標では、今まで読んでこなかったようなジャンルの技術書を毎月は読もうというものを立てたのだった。

ではそれで続いたかというと、続かなかった。モチベーションがなかったのだ。技術書を全く読まなかったというわけではない。仕事でぶつかった課題が、技術的に新しい分野のものであれば、その分野の書籍を読むようにはしていた。しかし、仕事と離れて単に本を読むということがどうにもできなかった。

それ以外にも昨年度の個人目標では色々と立てていたのだけど、あんまりうまく使えなかったなと思う。単純に意志が弱いというのもあるんだけど、自分が心底信じられ、また信じ続けられるような像というものがなくて、いつの間にか取り組みをやめてしまったものが多かった。目標で掲げたことに取り組むことで仕事がうまくできるようになると信じ切れなかった。

思えば、大きな目標を立てて、そのために努力をして、目標を達成した、という成功体験が、自分にはあまりない。努力をしてこなかったとか、何も達成してこなかった、というわけではないが、特に目標を立てずに過程自体を楽しんでいたら何かが達成されていたとか、目標に向かって努力はしたけど達成できなかった、という思い出の方が多い。

今は止めてしまっている「週一でブログを書く」というのはかなり頑張っていたし、それなりに長い間続けることができたけど、あれは何かを達成するための努力というより、努力を続けること自体が目的だったので、違うな、と思う。当時の自分は「このままだと開発者として生き残れない」という焦燥感に駆られていて、かなり転職を意識してブログを書いていた（「転職を成功させること」を目標として設定してブログを書いていたわけではなかった、というのがまた自分の不徹底なところなのだが）けど、今の自分は、そこまでの切迫感を持って何かに取り組むことができていない。転職して安心してしまったという側面もあるし、目の前の仕事の課題に取り組むことが大事だと思っているという側面もある（後者なら後者で、もっと頑張れよ自分、とは思う。やっぱり甘えてるんだね）。

と、ここまで書いていて、自分が楽しいと思えることにちょっと真剣に取り組むことを続けるのがいいんじゃないかという気がしてきた。楽しいと思えないことは続けられないけど、楽しいと思うことをただ楽しんでいるだけでは進歩が得られない。だから、楽しいと思えることを探して、それにちょっと努力の要素を追加してみるのがよいのではないか。

最近の自分としては、個人目標は、（「ブログを書く」や「技術書を読む」といった）日々の行動で定義されるべきではなく、何らかの到達点として定義されるべきなのではないかという気がしている。ブログを読んだり技術書を読んだりというのはアウトプットであって、アウトカムではないのだ。これはおそらく評価という観点からみても妥当で、「ブログ書いてます」「技術書読んでます」と主張しても「で、それが会社のビジネスにどう関わるの？」と言われてしまう（自分のところのマネージャーはたぶんそんなことは言わないけど！）。採用とかの場面では、継続的に学習できていることは評価されていいとは思うけど、成果で見せることができる社内の評価においては、学習できていることは二次的な資料の地位に止まるのではないかな、と思う。

と、いうようなことをぼんやりと考えて、今年度の個人目標は、1年後にどうなっていたいかを考えて立てたいなと思っている。そして、この「どうなっていたい」というのも、個人として考えてしまうとどうしても「いや別にそんな明確なビジョンないですわ」となってしまうので、「チーム・組織やプロダクトが、1年後にどうなっているといいか」から考えるといいのではないか、と思っている。自分自身には特に目指したいビジョンはなくても、チームや組織、プロダクトというのは、一緒に作っていく仲間がいるし、それらをよくすることで喜ぶ人も（自分以外に）たくさんいる（ユーザーに使ってもらえるプロダクトを作れているって幸せですね）。「目標を立てて、その達成のために努力をして、達成する」という自分に不足している成功体験も、会社という仕組みに乗っかることで得られるのではないだろうか。

そういえば、これまでの人生で、スポーツや将棋で団体競技をする機会はそれなりにあったのに、「みんなで目標に向かって頑張った」という思い出が全然ない。スポーツも将棋もエンジョイ勢だった。自分が気づいていなかっただけで、チームメイトの中には目標に向けて頑張っていた人もいたのかもしれないなと思うと、今更ながらすまんかったという気持ちになる。

集中する時間を作る

ブログはすでに https://ky-yk-d.hatenablog.com/ というのを持っていて、2018年4月から1年半くらいは毎週ペースで記事を書いていた。転職をしようというタイミングでブログを書くよりもやるべきことがあったので定期的に記事を書くというのはやめてしまって、今の会社に入ってからは以前ブログの素材にしていたような勉強があまりレレバントなものだと思えなくなってしまって、いいネタがあったら書くという感じでほぼ更新を止めている。

ブログを書いていないこと自体にはあまり問題は感じていないのだけど、最近の自分の集中力の欠如には危機意識がある。仕事でも集中力が足りないなと感じることがよくあるし、プライベートで本をじっくり読むことができなくなっている。原因が何なのかはよくわからないのだけど、「何かに集中する」という時間が取れていないことは確かだと思う。そう思ったときに、ブログを書くというのは、ネタを集めたり文章を書いたり推敲したりで集中力を必要とする作業から成り立っているよなぁ、と思った。

「何かを書く」ということでは、Twitterの方ではそれなりにツイートはしているのだけど、元々、「情報を発信をする」というよりは、「思っていることを特に選ぶことなく垂れ流す」式の使い方をしているから、集中してアウトプットするという感じではない。特に、Twitterは（ツイートを繋げて一気に投稿すれば別だが）自分のツイート以外の色んな人のツイートが流れていくものなので、アウトプットとインプットが同じ場所で行われている点で、集中しづらいメディアなのだろうなと思う。

最近ランニングをしながら過去に聴いたポッドキャストを聴き直すということをしていて、omoiyari.fm のep.17、konifarさんゲスト回を久しぶりに聴いていて、konifarさんの2つのブログの運用*1がいいなと思ったので、真似してみようということでこのブログを作った。

lean-agile.fm

konifarさんの Konifar's ZATSU の方は雑とは言いながらも有意義なことが書いてあってすごいなぁと思うのだけど、自分のこのブログはもっぱら自分のために書いていこうかなと思っている。元々他人のためにアウトプットをしようという感じの気質でもないのだけど、他人に役立つことを書こうとか、情報として意味のある記事にしようという思いは持たずに（そういうネタがあったら https://ky-yk-d.hatenablog.com/ の方に書こうと思う）、単純に「集中する時間を作る」ための手段としてのブログ運用をしてみようと思う。

*1:Konifar's WIPとKonifar's ZATSUという2つのブログを運用されていて、ZATSUの方がよりWIPよりも「雑」に時間をかけずにさっと書いているらしい。