Infinito Nirone 7

白羽の矢を刺すスタイル

森林公園までの往復100kmサイクリング

森林公園には、サイクリング専用の全長約17kmのコースがある。ローディーたちがひしめきあいながらしのぎを削る修羅のコースではなく、 あくまで森林公園をめぐるため自転車乗り入れを許可している自転車専用道路という扱いではあるものの、 道幅も広く(普通の国道の車線一個分はある)、起伏にとんでいて、なにより一方通行なので安心して走れるということで、一度行ってみたかったので行ってみることにした。

自宅からは47kmほどいくことになるそうだ。

行きはとにかく国道254のバイパスを北上することに。ひとまずの目標は川越を通り過ぎること。しかしこれが以外に遠かった…… 三芳町からふじみ野市を越えるのが長く、かつ道路も混んでいたのも手伝って、かなり時間を要した気がする。

川越に入るとバイパスが終わって普通の道に。途中T字路に行き着いて困ったが、うまく国道254に合流することが出来た。

国道254に入って暫く行くと大きな川を2本越える橋がやってくる。これを過ぎると本格的に田舎になって、ひたすら田んぼかでかい工場、配送センターみたいなのしか無くなる。 とにかくトラックが多く、コンテナトラックに幅寄せされて涙目になりながらなんとか市街地へ。と、気がつけば東松山市というところまで来ていた。

東松山市に入るとアップダウンが定期的にやってくる。ひたすら国道254をまっすぐ行き、途中のY字路で国道407に入る。そこから20分ほどで森林公園の案内にしたがって左折。 ここではじめて、熊谷がこんなところにあるということを知った。

途中休憩で補給とかせず、ひたすら飲み物だけでしのいできたせいで、このあたりから脚が悲鳴を上げ始めてしまった……まだ往路なのに…… 後ちょっと……がすごく長かった気もするけど、なんとか森林公園へ到着。

昼飯をとり、公園内のコースをぐるぐる。本当に、起伏もカーブもよりどりみどりな感じで、こんな道が17kmほどあるというのはすごいと思った。 いつかこのコースを借りきってロードレースでもやったら面白そうなんではと思ったけど、それをするにはきっと道幅が足りない気がする。 何より、見る人たちのための場所がないw

とりあえず周回コースをひと通り回って、最後は南口から帰ることに。

ぐねぐねと山を登ったり降りたりしながら、国道254に合流。途中なんどか高架があったけど、 なぜか自転車通行禁止の標識がなくて、しかしそんなところを自転車で行くのは恐怖しかなかったので迂回しつつ、往路で別れた国道407と合流し、ひたすら南下。

川島町にはいるころには完全に脚がヒーヒー言っていて、かつこの間打ち付けたアバラもヒーヒー言い始めた。

取り敢えず頑張って川越をやりすごし、早めの夕飯というか補給ということでラーメンとチャーハンを摂取。 そこからふじみ野市の市街地に入って、薬局で痛み止めを買うことに。本気でアバラの痛みが辛抱たまらんかった……

東武線を超え、行きに使った国道254のバイパスも通り過ぎ、三芳町、所沢へ。 途中、行き先案内標識が、真っ直ぐ行くと「本郷」に行くと書いてあって、どこだか知らないけれど方角はあっているからとまっすぐ向かったら、 2~300メートル行ったところに「本郷」という交差点があって、道に迷いそうになった。いや、そんな近所の案内って無いでしょ……

結局、本郷交差点をまっすぐ行き、所沢の裏道をふらふらしていたら、清瀬に出る道が見つかった。 東京だ!と思う一方で、西に来すぎたことを悟ってちょっとがっくりきた。

ただ、そこからはよく見なれた通りばかりで、小金井街道を南下してから所沢街道を青梅街道方面へ走り、そのまま青梅街道に入って帰宅した。

朝は10時に出発して、帰宅したのは18時すぎ。帰りの途中寄り道や想定外の疲れがなければもう少し早く帰ってこれたと思う。

サイクリングコースも含めると100kmを超す道のりを走ってきた。 つぎはどんなところへ行ってみようか、と思いつつ、自転車自体をもう少し乗り心地よくしなきゃな、とも思った。

何かをするのには合理的な理由が必要だという話

チームで仕事をしていると、人によって同じことでも解釈が違って、モチベーションの度合いが変わってくることがある。
あるいは、新しいプロジェクトを始める時に、人によってモチベーションが最初から高い人もいれば、あとから上がってくる人もいる。

多かれ少なかれ、チームとして何かしらの目的に向かって仕事をしていこうというときに、何故それをするのかということを明示することは、その仕事を成功させる上でとても重要な事だと思う。 言い換えれば、みんなで同じ目的地に到達するために同じバスに乗せようとするなら、メンバーを納得させるだけの十分な合理的理由を説明する必要があるということだ。

何故それをするのか

僕らが持っているリソースは無限ではない。時間も、人も、お金も、限られた量しか持ちあわせてはいない。

そんな中でも最大限の成果をあげられるように様々な工夫が考案され、その中でも汎用的なフレームワークが色々なところで活用されている。 できれば、効果の高いものから順に取り組んでいきたいし、自分たちが目指す世界とは相容れないものは不用意に取り入れないようにしておきたい。

端的にいうと、自分たちの目指す目的に適っているかどうかを判断して優先順位をつけていきたい。そしてその判断の中には、それをするに十分な納得の行く合理的な説明があるはずだ。合理的でないことをしても目的に適うかどうか判断出来ない。

理由は振り返りにも効果を発揮する

たとえば新しいアプリを作るというような大きなプロジェクトから、アプリの一部機能を変更するというような小さめのプロジェクトまで、何故それをするのかという考え方はとても大事だと思う。

なぜ、なんのためにそれをするのかが定かで無いと、結局後になって振り返っても、どういう視点で振り返ってよいかが不明確になるからだ。もはやそんな振り返りにはなんの意味もないし、得るものも少ないだろう。

目的と理由から目標をたてる

目的があって、それをなす合理的な理由があるならば、目標が設定できるようになる。目標は KPI などとも言い換えられると思う。数字に落としこんで、自分たちがどれだけうまくやれたかをあとで振り返ることが出来る。 この KPI の設定の仕方はほんとうに難しい。何を軸に数字を見るべきかは目的によっても変わるし、それをする理由によっても見なきゃいけないものがあったりすると思う。

いずれにしても、目的やその理由がはっきりしないまま目標をたててもふわふわしたものにしかならなかったり、まったく何を軸にしたらいいか見当がつかなくなったりしてしまう。

まとめ

そもそも自分としては、何故それをするのか分からないものをしたくないという思いもありつつ、分からないまま進めても良い成果は出せないという信条もある。 だからこそ強く、合理的な理由が欲しいという思うのだけれど、それを抜きにしても、とても根源的な部分で理由をはっきりさせておくというのは大事なんだということを、この記事を書いていて思った。

峠を越えるチャレンジ

怪我も癒えたので、久しぶりにロングライドに出かけた。

以前クロスバイクで五日市通りを武蔵五日市駅まで行ったことがあって、そのときは駅につく頃には脚が終わっていたのだけど、ロードバイクだと難なく辿りつけた。

今回はそこに行くだけではなく、そこから秋川街道を通って山を超え、青梅に向かった。

秋川街道に入って五日市線の高架下を過ぎるとすぐにキツい坂が始まった。そこから日の出町の中心部を抜けるまではアップダウンがあるが、中心部を抜けたらいよいよキツめの坂がずっと続いていった。 そのまま二ツ塚峠の交差点を越えるまでずっと登りしかなく、下りも平坦もない。途中で足をつこうかと思ったが、二ツ塚峠の交差点を見てこれが最後だと思ったらそのまま走り抜けることが出来た。よかった。

その後はずっと下り。あっという間に青梅に出られた。

さて、ここからは何も考えていなかった。取り敢えず青梅街道の旧道に出てみた。しばらく東に行ったところで、入間に向かう道があったのでそちらを走ってみることにした。

さすがにずっと走りっぱなしだったので、水分と食料をコンビニで調達した。その後は入間の市街地(工業団地、アウトレットのあるあたり、入間ICの近く)を抜け、そこから所沢へ。 所沢からは多摩湖を目指し、西武ドームをかすめて多摩湖を超え、そのまま青梅街道に出て、新青梅街道を使って自宅に返ってきた。

全行程90kmほどを5時間で走った。やはり、長く続く坂を登り切った時の達成感が最近ツボにハマってきているので、またどこか初心者にも手頃な峠を超えてみたい。

チームワークのためのコミュニケーション

なんか意識高い系みたいなタイトルだけど、チームとして何らか成果を上げるための活動をしていこうと言う時に、最も丁寧に扱わないといけないのがコミュニケーションだと思う。

アジャイル開発とか、スクラム開発とか、そういったものには、コミュニケーションのためのフレームワークとしての意味合いがあると思う。日々仕事を進めていく中で必要不可欠なコミュニケーションをある程度形式化することで、チームの人達の目的意識を合わせて仕事をできるようにするのがこのフレームワークの肝だと思う。

何のためのチームなのか

チームでも部署でも、もっと広く見て会社でも、何らかの目的意識があると思う。◯◯な世界を実現する、とか、社内の◯◯を円滑にする、とか。
チームの流動性もいろいろあると思う。ずっと同じメンバーでミッションを受け持つこともあれば、プロジェクトごと違うメンバーでチームを作ることもあると思う。

どんな形態にしろ、何のためにチームとして成果をあげようとしているのかは全員の認識として揃えておく。

アジャイルサムライに書いてある、みんなをバスに乗せる、という話はまさにこのことだと思う。同じ目的を共有することで、チームとしてのパフォーマンスを最大化できる。
とはいっても、これをしたからといってみんながみんなまったく同じものの見方をしているとは限らない。少しずつ違った見方があって、そうすれば当然同じ物事でも優先順位が人によって違ってくることだってある。
そういう見方の違いは、早めに話し合っておくのが重要だし、必要なら優先順位付けのための基準を明らかにしておくことも大事だと思う。

仕事の目的

チームの目的をすりあわせたら、次は目的を実現するためのプロダクトバックログを作る。ここでもやはり、バックログの項目ごとに、その目的や、それをすることによって何が良くなるかとか、そういったことを明らかにしていく。

当たり前だけど、チームの目的に適わないバックログを実行するわけにはいかないし、できるだけ価値のあることを優先して実行していきたい。それをするには、バックログごとにも目的と目標が必要だし、それなしには優先順位は付けられない。
何より、チームが円滑にコミュニケーションを進めるためにそういったものごとをはっきりさせておく必要がある。

定期的な棚卸しと調整、振り返り

チームの目的も、バックログで明らかにする目的も、時間が経てば陳腐化する可能性がある。遅かれ早かれ、それらの目的は価値を失ってしまう。

あとになって気付いた時にはもう遅い、というのはよくある話で、だからこそ、出来る限り早く致命傷になる前に修復したり調整したりする必要がある。振り返りをするのはそのためのコミュニケーションを取るためだ。

明確にすべきこと

これまで見てきたコミュニケーションのタイミングでは、いろんな主張が出てくると思う。 その主張の中には、その主張をした人なりの解釈や、その人なりの基準、見方が含まれていて、それらをはっきり言う人もいればそうでない人もいる。いずれにしても、その”前提”はコミュニケーションを取る上でとても大事なことだと思っていて、コミュニケーションがうまくいかない理由の大半はその”前提”を見誤っていたり誤解していたり伝えきれていなかったりといったことが原因なんじゃないかと思う。

計画、実行、振り返り。どのタイミングでも、意思決定をするには目的や目標、前提の理解は必要不可欠だと思う。 何故なんのためにやるのか良くわかってもないことを率先してやれるほど自分でモチベーションがあげられる人ばかりではないし(少なくとも自分はそう)、どうしてそういう判断に至ったのか良く分からないことに同意するほど狂信的な人もいないと思う。そして何の効果があるのか分からないことをやれるほどお金も時間も潤沢にあるわけではない。

自分の意志を伝えるというのは、単に言いたいことを言うことだけじゃなくて、何故そう考えるのか、何故それが大事なのか、そしてその成果としてどんなイイコトがあって、それがもたらす効果がどうで、だから重要なんだっていうことを伝えなければ意味が無い。もちろん、主張を受け取る側としても、理由や目的、前提が不明確なときはそれをちゃんと伝えるべきと思う。そういうキャッチボールがないまま言いたいことを言いたいだけ言って肝心なことを言わないのはコミュニケーションじゃない。

主張がうまく伝えられていないのは、そういった目的や前提が不明確で伝わっていないときか、チームとしての目的と主張している目的とがうまくつながって理解されていない時だと思う。

なんとなく、昔ひとに物事をお願いするときのコミュニケーションの取り方を注意された時のことを思い出したのでまとめてみた。

Keystore はどこに置くのが良いか

署名鍵は非常に重要なものです。無くしたら取り返しがつきません。何とかして無くさないようにしないといけないのですが、 共有ストレージに置いておくと大抵無くします。頻繁に使うものでもないので、どこに置いたか忘れやすいのが原因ですが、 忘れてしまったがために何かのタイミングでうっかり消してしまってなくすパターンが多いような気がします。

そこで結局どうするかというと、アクセス権限の制御ができるリポジトリであるならば、いっそ署名鍵もリポジトリに突っ込んでしまいます。 これで、うっかりで消しても履歴から戻すことが出来ます。やったね!

ただし、パスワードやエイリアスは別管理する必要があります。一度決めてしまえば変わることがないはずのものなので、 喪失リスク(忘れる)をケアできれば、バージョン管理システムに頼らずに済みます。

ポイントは、十分な長さを持つパスワードであれば良いのですが、だいたいそういうものは覚えられないので、パスワードそのものを覚えなくてもいいようにします。 その代わりに、パスワードを生成するロジックを覚えておくようにします。とある文字列を sha1 なり md5 に掛けたものをパスワードにする、とか。

あとは、環境変数にそれをぶち込んで、ビルドスクリプトからそれを読むようにすれば、晴れてリリースビルドが自動化されます。

作業と仕事は違うという話

学生の時、いくつかあるチームのうちの 1 つをまとめる役割をもっていたことがある。

まったく初めての領域の仕事、ましてそのリーダーという役割。まずは自分のチームでやるべきことはなにかを考え、 出来そうなことから進めていった。 結果無難なところに落ち着かせることはできたが、それはあくまで無難であってそれ以上ではなかったように思う。 何より、人をまとめるという役割においてはどれほどの仕事ができたか良く分からないままだ。

その最中、以下のような言葉をかけられたことを覚えている。

「作業をするな、仕事をしろ」

仕事というからには、何らかの目的があってそれをしているんだと思う。 目的の達成には何が必要で、何をしなきゃいけないかってことは、きっと誰もが考えることだと思う。 そしていつかどこかのタイミングで、自分がそれまでにしてきたことを振り返って、軌道修正をしたり、次のステップに前進したりするんだと思う。

その時の自分は、これから何をしなければいけないかばかりを見て、今まで何をしてきたかを振り返っていなかった。 つまり、目先のことしか考えていなかった。その時手元にあったやることリストを眺め、一つ一つを潰していくことが仕事だと思っていた。

たぶん、リーダーとしてはかなり失格だったと思う。チームとしては、メンバーのスキルが高かったのに助けられて悪い方には行かなかったけれども、 リーダーとして何をしたかと問われたら何も答えられない気がする。

仕事とは誰かに価値を生む行為で、それをする必要があると感じるからどうしてもやりたいと思う類のものだと思う。 でもその時の自分は、ただただやらなければならないことばかりが眼前にあって、やりたいかどうかは兎も角として、それらをひたすら片付けることしか考えてなかった。 いずれにしてもやるべきことには変わりないのだけど、そこにあるタスクだけを淡々とこなし続けるのは単なる作業であって、仕事ではなかった。

きっとこの「作業をするな、仕事をしろ」っていうのは、目先のことだけに囚われていないで、ちゃんと目的を理解して取り組みなさい、ということを言っているんだと思う。

プレゼンテーションのなかでコードを乗せるときのノウハウ

と言いつつ、自分は単に JakeWharton 氏がよくやる手法を真似しているだけなんだけれども。

プレゼンテーションの中でコードを取り扱うと、どうしてものんべんだらりとした感じになってしまって、 どこが重要なのか分かりづらくなることがある。特に、話の流れでフォーカスすべきところがどんどん変わっていくようなページだと、 ちゃんと聞き漏らさないようにしてないと、今どこのコードのことを言っているのか分からなくなる。

勿論、そんな長いコードをプレゼンに貼り付けるな!という意見もあって、それは確かにもっともな意見なんだけれど、 それはそれとして、短いコードスニペットでも、ここが重要なんだ!というところに注目されるように作るのは大事なことだと思う。

そこでどうするかというと、注目して欲しいコードの部分以外の文字色を背景とほぼ同化するくらいまでに設定してしまう。 で、全部が同じ文字色のページと、(結果的にそうなるという意味で)コードをハイライトしたページを分けておいて、 適当にフェードかなにかでページのトランジションをしてやると、うまい具合にコードに注目が集まる、という寸法だ。

JakeWharton 氏はおそらく、箇条書きの表示の切替え(追加で出てくるやつ)の各段階ごとにページを分けているか、 あるいは PDF 出力のときにそういうオプションで出力しているように思われる。

自分はもっと過激に文字色の不透明度を下げまくっている。ハイライト部分以外は10%とか20%とか。

ページのトランジションは普段あまり使わないけれども、こういうトリックを使おうと思うと重宝する。