Yokomark Press

峠を越えるチャレンジ

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

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

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

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

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

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

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

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

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

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

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

何のためのチームなのか

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

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

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

仕事の目的

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

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

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

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

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

明確にすべきこと

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

事故りました

会社から帰る途中、路駐の車の影から自転車が飛び出してきて、よけきれずぶつかってしまいました。

怪我をしたのは自分だけだったようですが、転倒時に指を打ち付けていたり、跳ね上がった自転車がアバラに直撃してきたりと痛い思いをしました。今も痛い。 時間が時間だっただけに救急で見てもらいました。専門医の人がいない時間ではありましたが、レントゲンを見る限りとりあえず折れてる感じはないと言う話だったので、いろいろ助けられたなと。 実は生まれて初めての救急車体験でした。最近世間ではタクシー代わりに使う人がいるとか騒がれてますが、ほんとうに助かった。呼んでなかったらどこに病院があるかも分からなかったし、診てもらうのに数時間待つ羽目になってた。

路駐の車を避けるためにある程度その車から距離をとっていたとはいえ、完全に死角で出てくる予測が立てづらい状況だったので、まあ、本当にどうしようもない事故でした。スピードがもっと遅ければぶつからずにすんだとか、そう言う議論は当然あるし、それはどうしたってそうとしか言い様がないことなので、しょうがないです。

事故の形態としては出会い頭の衝突なので、当然ながら過失は双方に出てきます。割合は飛び出した方(今回は交差点でない場所での飛び出しだったため)が重くはなるよね、という話です。 実際問題どのくらいの数字で割合を決めるかはまた別の話なので、警察の人が決めてくれることではありません。

警察の人が言うには、最近の自転車事故の大半はロードバイク等のスポーツバイクが絡む事故なんだそうです。自分も図らずも、その割合に寄与してしまったわけですが、 周りを見ていると信号無視や逆走、無灯火は当たり前のように横行しているので、そりゃあ事故の割合も高くなって当然の結果なんだろうなと思うわけです。 それらをきちんと守っていたとしても今回のような不運な事故が起こるんだから、するべきことをしていないのでは起こるべくして起こるというもの。

ぶつけられても痛いし、転倒したら更に痛い思いをするので、信号はちゃんと守るとか、左側通行するとか、ライトはちゃんと付けるとか、変なところで道路を渡らないとか、基本的なことをちゃんとやるのは最低限のマナーです。 それでも、なにをどう気を付けていようと、起こるものは起こるので、そうなってしまった場合は、痛くて自転車壊れるしキレることもありますが、きちんと警察の人を呼ぶとか救急車を呼ぶとか手続きを踏むべきです。 警察の人も言っていましたが、事故そのものが悪いわけではないです。人間のすることなので、どうしたって起こってしまうことを止めることは出来ない。ただ、気を付けてなんとかなることは確かにあるし、迷惑をかけることには変わりがないので、それはちゃんとケリを付けなければならない。

はあーしかし、あれは修理できるんだろうか……かれこれ6000km弱ともにしてきた愛車なので、ここでさようならはとても寂しい思いがします。 それでも、自分が打ち身を食らう程度で済んでいて、他の誰も怪我をしていないというのはとても幸運なことではありますが。

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

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

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

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

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

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

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

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

Potatotips #17 行ってきた

このところ抽選の倍率が高くてなかなか参加できていなかったのですが、ようやく機会を得たので参加してきました。

今回はnullについての王道パターンの対応策と、Android における深い闇について話しました。

null はちゃんと取り扱わないとすぐNullPointerExceptionで落ちます。ちゃんと取り扱っていても、予期しない理由でNullPointerExceptionで落ちることもありますが、 それはかなりレアケースなので、今回の話のスコープとしては取り扱いませんでした。

最も簡単かつお手軽な手法は、なんといっても Null Check の if 文です。null だったら何もしないとか、null だったら異常なので例外を投げるとか。 基本中の基本といったところですが、null とはそもそも何だったのかということを忘れていると、あちこちで Null Check をし始めてしまい、結果同じものに 3 回も 4 回も Null Check してしまって無駄が多くなる、 みたいなことになり得ます。

null とは値が存在しない、無、ということなので、本当に何も無い時だけnullを返してあげるのが理想です。そのことについて Null Check をしてあげる、と言うのは是非すべきだと思います。

さて、Android には SupportAnnotation と言って、Lint のサポートを活用するべく作られた、値が Null になり得るかどうかを示すためのアノテーションがあります。 @NonNull アノテーションが付いている変数あるいはメソッドの戻り値は、必ず何かしらのオブジェクトが存在することが期待できることを意味します。 @Nullable はその逆で、null が入る可能性があることを期待していることになります。

ここで「期待している」と言っているのは、あくまで Lint が警告を出すだけのためのアノテーションであって、コンパイルエラーにしてくれるとか、何かいい感じにnullが取り扱えるようになる魔法をかけてくれるとか、 そういうことではないということです。つまり、Lint が警告を出さなくても null を入れようと思えば入れられるし、実際混入する可能性はいくらでもあるということになります。

ただ、Javadoc に null について徒然なるままにドキュメントを書くよりは、圧倒的に万人に分かりやすく null について表明することができる点においては、どんどん使って行ったほうがいいな、と思っています。

最後、発想を転換して、無いことをもオブジェクトとして取り扱ってしまおう、というのが NullObject パターンです。 実装の中身さえ空なら呼び出してもさしたる影響はないはずですから、そういう空の実装をもったオブジェクトを作って、null の代わりに返してあげれば、使う側は null かどうかを気にする必要がなくなります。

そういうわけで、メソッドの返り値にnullを使わないほうがいいパターンというのも勿論あります。特に、コレクションを扱う場合には、nullよりも空のコレクションが好まれます。 あるいは、異常を示すためのnullではなく、ちゃんと例外としてきちんと設計することが好まれるものもあります。 この辺りはケースバイケースなことも多いですが、nullに存在が無いということの他に意味を持つような実装をしようとしているなら、nullではない何かを考慮してもよいのかもしれませんね。

ともあれ、このあたりの話題は EffectiveJava に詳細が書かれていますので、是非読んでみてください。

と言う王道パターンがあるわけなんですが、Android ではいくつか苦しいポイントがあって、特に互換ライブラリには非常にお世話になる一方、実装面で言うと、古いバージョンでは存在しないクラスを取り扱うための苦労が 垣間見えます。 その中でも、API レベルによって処理を分けるためのデリゲートクラスの実装はなかなかに趣があり、古いバージョンでは取り敢えず何もしたくないということで、 メソッドの中身が無かったり、return null; とか書いてあったりします。そこは例外じゃないんだ…という気分ですが、 普通に自分の書いたコードに null が混入してきます。このあたりは、Support Library の実装を見ながら書かないとハマるポイントになるなあと思っています。

奥多摩湖を見に自転車で行ってきた

ゴールデンウィークの最終日、ビンディングも買ったことだし山登りしてみようと、奥多摩湖まで行ってきた。 自宅近くに青梅街道があるので、青梅街道に沿って延々と片道60km弱を走ってきた。

初めての山登りロングライドということで、様子見がてら走ってきた。 自転車の重量が結構あるので、本格的な山登りをするには不向きだとは思うけど、それでもなんとか奥多摩湖まで辿り着くことが出来た。

斜度がどのくらいあるかは良くわかっていないけれども、目的地に到達した時の喜びと、帰りの下り坂を駆け下りる爽快感はたまらないな。 反省点としては、行きはいろいろ考えてハイペースにならないようにしていたり、補給としてあんパンなどエネルギーに替えられるものを摂取したりしていたけれども、 帰り道はずっと飲み物以外の補給をしなかったため、帰宅する頃にはヘトヘトでお腹がグーグーなるほど空腹になっていて、何かをする気力が失われてしまっていたことだろうか。

家に帰るまでがサイクリング。帰りがいかに気持ちよく爽快であったとしても、補給だけはきちんとすべきだということを学んだ。

ビンディングペダルデビュー

自転車に乗り始めて半年くらい経った時に、それまで使っていたペダルが壊れた。中のベアリングが完全にバラバラになってしまって使い物にならなくなっていた。 そのタイミングで、ハーフペダル(片面SPD)を使ってスニーカーでもビンディングシューズでも乗れるようにしていたので、頃合いを見計らってビンディングシューズにしてみようとずっと思っていた。

そして昨日ようやくシューズを買う機会ができたので、慣らしも兼ねていつもの道を走ってみた。靴はCLICK’Rの安いやつで、SPDペダルなのもあって普通に歩くのもできるシューズにした。

最初は外れなかったらどうしようかと思ってたけど、固定の強さを最弱にしていた(それでも最初は結構外しづらい)のもあって、一度も立ちごけせずに乗りこなすことが出来た。 引き足が使えるようになって世界が変わる!とは聞いていたけど、まだ引き足に慣れていないせいか、そこまでの変化を感じられてはいない。 しかしこれからが楽しみだ。

DroidKaigi が終わって、DroidCon Tokyo が動き出す

もちろん、今回募集人数の関係で抽選に外れてしまった人も多数いるし、どうしても東京が遠くて来れなかった人も多数いると思う。 だから、DroidKaigi はここで終わっていいものじゃない。 まだだ、まだ終わらんよ!

というわけで、無事に初めての DroidKaigi が、無事かつ成功のうちに終わった。運営としては学びも多く、もっとよく出来ることは沢山あるのだけれど、 それはそれとして、ひとつ成功体験を得られたことは大きな一歩になったと思っている。 そうでなければ、JakeWharton が上記のようなメンションを飛ばしてはくれない。

今回のこのイベントは、沢山の人たちの、圧倒的当事者意識に支えられた。 去年の12月、potatotips で mhidaka さんが何人かに「DroidCon やりたい!!」と声をかけて始まったのがこの運営委員会。 最初は右も左も分からないのでスモールスタートで行こうということ決めた。 結果フタを開けてみれば、connpass は10分も経たずに溢れ、CFP も予定枠の倍以上の投稿があった。 僕ら運営委員会だけでなく、当落結果にかかわらずすべての参加者の方たちもまた、圧倒的当事者意識で僕らを助けてくれた。

このアツいコミュニティが、変わること無く今後も圧倒的当事者意識で盛り上がっていくこと。そうなったら最高だ。

以上、現場からのリポートでした。