Infinito Nirone 7

白羽の矢を刺すスタイル

Kotlin の enum class とシリアライズで気をつけること

Kotlin の enum クラスは、ほぼ Javaenum と同じように扱うことができます。

次の Kotlin コードは FOOBAR という Hoge 型の定数を定義しています。

enum class Hoge {
  FOO,
  BAR
}

enum クラスで定義した定数は String への変換 (nameメソッド) と、 String からの変換 (valueOfメソッド) をサポートしているので、簡単にシリアライズ・デシリアライズができます。またenum クラスに振る舞いを記述できるので、フィールドをもたせたり、メソッドを呼び出したりするコードも動きます。

enum class Hoge(val flag: Boolean) {
  FOO(true),
  BAR(false);

  fun getSomething(): String {
    return "Hello, world!"
  }
}

メソッドは abstract で定義したり、インタフェースを実装したりもできます。この場合、個々の定数の定義で具体的な処理を記述します。

enum class Hoge {
  FOO {
    override fun getSomething(): String {
      return "Hello, world!"
    }
  },
  BAR {
    override fun getSomething(): String {
      return "Hi, world!"
    }
  };

  abstract fun getSomething(): String
}

ここまでがおさらいです。

ここで次のように String? から任意の型のオブジェクトへ変換する Generic なメソッドを考えます。ストレージに書き込んだ文字列から期待する型への変換を行うようなメソッドです。

@Suppress("UNCHECKED_CAST")
fun <T : Any> String?.convert(fallback: T): T {
  return when (fallback) {
    is String -> {
      this ?: fallback
    }
    is Int -> {
      this?.let {
        Integer.valueOf(this)
      } ?: 0
    }
    is Enum<*> -> {
      this?.let {
        val method = fallback.javaClass.getDeclaredMethod("valueOf", String::class.java)
        method.invoke(null, this)
      } ?: fallback
    }
    else -> {
      throw IllegalArgumentException("")
    }
  } as T
}

このメソッドを、次のように標準入力で与えられた文字列からデシリアライズする目的で使ってみましょう。標準入力で FOO と入力すると、正しく定数に変換されます。

fun main(args: Array<String>) {
  println(readLine().convert<Hoge>(Hoge.FOO))
}

enum class Hoge {
  FOO,
  BAR
}

では次の場合はどうなるでしょうか。Hoge には abstract メソッドが定義されています。

fun main(args: Array<String>) {
  println(readLine().convert<Hoge>(Hoge.FOO))
}

enum class Hoge {
  FOO {
    override fun getSomething(): String {
      return "Hello, world!"
    }
  },
  BAR {
    override fun getSomething(): String {
      return "Hi, world!"
    }
  };

  abstract fun getSomething(): String
}

上記のコードの場合、FOO を標準入力に入れると次のようなエラーで異常終了します。

Exception in thread "main" java.lang.NoSuchMethodException: dev.keithyokoma.Hoge$FOO.valueOf(java.lang.String)
    at java.lang.Class.getDeclaredMethod(Class.java:2130)
    at dev.keithyokoma.MainKt.convert(Main.kt:22)
    at dev.keithyokoma.MainKt.main(Main.kt:6)

この挙動の差は生成されるバイトコードの違いを見ると分かります。

メソッドの定義がなかったり、実装を enum クラスの宣言に書く場合は次のようなバイトコードが生成されます。

public final enum dev/keithyokoma/Hoge extends java/lang/Enum  {
  // access flags 0x4019
  public final static enum Ldev/keithyokoma/Hoge; FOO
  // access flags 0x4019
  public final static enum Ldev/keithyokoma/Hoge; BAR
}

一方で、abstract メソッドやインタフェースのメソッドの実装を個別の定数で行う場合は次ようなバイトコードが生成されます。

public abstract enum dev/keithyokoma/Hoge extends java/lang/Enum  {

  // access flags 0x18
  final static INNERCLASS dev/keithyokoma/Hoge$FOO dev/keithyokoma/Hoge FOO
  // access flags 0x18
  final static INNERCLASS dev/keithyokoma/Hoge$BAR dev/keithyokoma/Hoge BAR

  // access flags 0x4019
  public final static enum Ldev/keithyokoma/Hoge; FOO
  // access flags 0x4019
  public final static enum Ldev/keithyokoma/Hoge; BAR
}

なにやら増えていますね。内部クラスとして Hoge$FOOHoge$BAR があるように見えます。そして実行時のエラーでは、Hoge$FOO に対して valueOf メソッドを探したが見つからなかった、というメッセージが出ています。

enum クラス内の個別の定数で実装を定義する場合 Hoge.FOOHoge$FOO 型で、Hoge.BARHoge$BAR 型として解釈されます。これらはすべて単なるクラスなので、Generic な型変換コードの val method = fallback.javaClass.getDeclaredMethod("valueOf", String::class.java)valueOf メソッドを見つけられません (Hoge$FOO 型の Hoge.FOO が格納された fallback 変数に対し valueOf を探そうとするが、valueOf メソッドは Hoge のクラスメソッドとして定義されるので見つからない)。

Hoge$FOO 型と Hoge$BAR 型はどちらも Hoge 型のサブクラスになっているので、次のように修正すると期待通りの動作をします。 fallback の型が enum かどうかを判別し、enum でなければその親クラスから valueOf メソッドを探します。

@Suppress("UNCHECKED_CAST")
fun <T : Any> String?.convert(fallback: T): T {
  return when (fallback) {
    // ...
    is Enum<*> -> {
      this?.let {
        val clazz = fallback.javaClass
        val method = if (clazz.isEnum) {
          clazz.getDeclaredMethod("valueOf", String::class.java)
        } else {
          clazz.superclass.getDeclaredMethod("valueOf", String::class.java)
        }
        method.invoke(null, this)
      } ?: fallback
    }
    // ...
  } as T
}

コンパイラの吐き出すバイトコードまでを考慮しないといけないコードになってしまいました (enum クラスは文法上継承できないはずなので、isEnumfalse のときに superclass を参照しにいくのは一見とても奇妙)。

ちなみに、Java で同様のコードを書いて検証してみたところ、Java でも同じ挙動をしました。

もし、型パラメータの T から直接 Class クラスを参照できれば、このような回りくどい記述は必要ありません。 次のコードでは正しく valueOf メソッドが探せます。

inline fun <reified T : Any> String?.convert(fallback: T): T {
  return when (fallback) {
    // ...
    is Enum<*> -> {
      this?.let {
        val method = T::class.java.getDeclaredMethod("valueOf", String::class.java)
        method.invoke(null, this)
    } ?: fallback
  }
  // ...
  } as T
}

2019/09/03 16:00 追記

型パラメータ TEnum<T> に限定できる場合は、リフレクションは不要になり、代わりに enumValueOf を使います (thank you @red_fat_daruma !)。

inline fun <reified T : Enum<T>> String?.convert(fallback: T): T {
  return this?.let { value ->
    enumValueOf<T>(value)
  } ?: fallback
}

カンファレンスとハイエースと筋肉

カンファレンスとハイエース

カンファレンスを運営するにあたって、当日使用する物資の運搬は非常に重要です。登壇者の後ろに配置するバックパネルや会場案内図、立て看板など、重量があったり、縦横の大きさがそこそこあるものなどの運搬について、一般的な配送方法(宅配便など)では運搬できなかったり、業者に依頼する量ではないにしても電車等での公共交通機関での運搬は不可能な状況があったりします。このような場合に、自分たちで物資を運搬する手段を確保するというオプションがあります。

自分たちで物資の運搬をする手段をとる場合、前提として、大きなサイズの車を運転できる人の確保と、物資輸送にあたって重量物や大きな物を運ぶ体力・筋力の確保が要求されます。 前者については実際に運搬する物資の物量に依存しますが、軽ワゴン車で足りる場合から、ハイエースやキャラバンなどのバンですら容量不足で2tトラックが必要な場合まで様々で、免許区分で NG となることもあります。後者については、バン以上の車であれば、運転手・助手席の間にさらにもう一席あるので、3人の体力・筋力が得られます。

2019年現在の普通免許を持っていればバンなら運転可能です。私の免許では5tトラック(最大積載量3t)までなら運転可能ですが、今までで運転したことのある一番大きな車はハイエースやキャラバンなどのバンに相当する車です。カンファレンスでの物資輸送以外に、自宅の引っ越しでハイエースを使って自力輸送をしたこともあります。

この記事では、タイトルにあるとおりバンを用いたカンファレンスにおける物資輸送について、いくらかの Tips を書き残しておこうと思います。

輸送計画

まず物資輸送の計画を立てるにあたって、運転手と車両の確保を考えることになります。 運転手についてはバンの運転ができる人を地道に探すしかありませんが、車両の確保は比較的容易で、レンタカーでバンを借りれます(もちろん、運営チーム内でバンまたはそれに相当する輸送力をもった車両を所有している人がいれば、その人に協力を仰ぐのが最適なはずです)。昨今はカーシェアリングサービスも盛んですが、物資輸送に最適なバンを借りるのであれば、トヨタレンタカーやニッポンレンタカー、ジャパンレンタカー、オリックスレンタカーが大手で取り扱っています。トヨタレンタカーであれば確実にハイエースを借りられます。

レンタカーで物資輸送を計画する場合、借りる時間をどう設定するかが問題になります。レンタカーである以上契約で使える時間に制約があるため、借りる手続きをしてから荷物をピックアップし、荷物を保管する場所まで移動したあとでその荷物を人手で積み下ろしたうえで、給油して返却するまでが計画されなければなりません。レンタカーを借りる店舗ごとに営業時間が異なるので、24時間営業でない場合には特に返却時間に気を配る必要があります(24時間営業であっても、22時以降の返却には料金の上乗せがあったりしますし、借りた店舗とは異なる店舗で返却するワンウェイレンタルに制約があることも多いです)。

レンタカーでもカーナビが標準装備とはいえ、運転者はどういう経路で物資を運搬するかをよく把握し、返却にあたっては店舗の最寄りにあるガソリンスタンドを把握するなど、経路について事前によく調べておく必要があります。また、荷捌き場への入り方はビルごとに異なるため、事前によく認識を合わせておきましょう。

運転

ハイエースやキャラバンなどバンに相当する車両はそのサイズ感から敬遠されがちだったり、用途からして普段遣い向きではなかったりすることから運転したくないと思われがちですが、扱いづらい車ではないように思います。

よく利用されるコンパクトカーやミニバンとの一番おおきな差異はやはり車体の大きさでしょう。車体そのものが長く幅も広いなど、とにかく小回りとは無縁そうなイメージがありますが、その車体の見た目に反して小回りはきくほうです。ミニバンよりも大きいように見えて、実はミニバンよりも小回りがきくなんてこともあります。

バンとその他の車で違うこともいくつかあります。

パーキングブレーキは車種によってまちまちですが、トヨタハイエースならば左手側に引っ張るレバー(ステッキ式)があり、日産・キャラバンであれば左側にフットペダルがあります。ステッキ式は取っ手にボタンが付いていて、パーキングブレーキを解除するときにそのボタンを押しながらすこし引っ張って解除します。 サイドミラーは手動で調整するものがあります。レンタカー屋さんで借りる車の年式などで変わるので、調整が必要なときは出発前に見ておきましょう。 その他、前輪の位置がミニバンとは違って運転席の真下にくるので、ハンドルをきるタイミングに気をつけましょう。もちろん、荷物が空の状態とある程度積んだ状態では重量が違うので、ブレーキをかけるタイミングやらアクセルの踏み方も状況に応じて調整しましょう。

荷物の積み込み

バンは荷室がかなり広く使えます。ただ後輪のでっぱりや両側スライドドアのステップがあったりするので、純粋に長方形のスペースをフルに使えるわけではないことに注意します。 最近のレンタカーではバックカメラがついていて、バックギアに入れるとカーナビの画面がカメラの映像に切り替わるようになっていますが、とはいえミラーから見える視界を遮るほどのたかさまで荷物を積んでしまうのもよくないので、荷物の積み上げは程々に。また角の硬い荷物を積むときは緩衝材で保護するなどして他の荷物や車内を傷つけないようにしましょう。

積み込む量にもよりますが、ハイエースを借りるということはそこそこの物資を積み込み・積み下ろしするはずなので、荷運び人員が必要です。カンファレンス会場の荷捌き場との行き来もあるので、それなりの筋力が求められます。台車がある場合はこれを活用しましょう。レンタカー屋さんで借りることもできます。ただし会場によっては台車の使用に制限(台車を使用していい出入り口やエレベータに限りがあるなど)を設定しているところもあるので、会場のルールに従って運搬します。

重いものがあるときは無理せず複数人でゆっくり運びましょう。とくに腰は大事です。持ち上げる・下ろすときに腰を壊しやすいので、しっかり腰を落として持ちましょう。

まとめ

ハイエースやキャラバンなどのバンは荷物を運搬するために車体が大きいものの、扱いやすさで言えばミニバンよりも小回りがきくなど便利に使えます。荷室も広いのでかなりの物資を輸送できますが、輸送にあたっては人手も必要です。怪我や事故の無いよう安全に十分配慮しつつ荷物を運びましょう。

いただきもののアンクルウェイトをつけてV字腹筋しようとした

片足2kgずつのウェイトを足首にくくりつけてV字腹筋する修行です。 不可能ではないのですが、今の自分には圧倒的筋力不足なので数回でもたなくなりました。

強くなりたい。強さを取り戻したい、が正しいかもしれないが。

急に誕生日が来たので

はれて1E歳になりました。 あれ、まだ10代じゃん?よっしゃいけるやろ。

いろいろ書こうと思ってたこともあったりなかったりするけどもう面倒くさくなってしまったので、現場からは以上です。

http://amzn.asia/5148iaa

DroidKaigi の撮影で Canon EF 70-200mm f/2.8L IS USM III をレンタルしてみた

カンファレンスカメラマンの悩みのタネとして、登壇者が遠いので望遠レンズがほしい、でもそうするとどうしても暗くなってしまう(=ブレまくるしいい絵にならない)ので明るい望遠レンズがほしい(=スーパー高くなる)という葛藤があると思います。

かく言う私も EOS 6D Mark II に買い換えてから標準キットの 24-105 しか使ってこなかったので、寄りたいときに全然寄れないし暗いという悩みを抱えていたので、思い切ってカンファレンス用にレンズを借りてみることにしました。

結論しかないんですが、借りて大正解だったし、最初の一枚をパシャッと撮ってプレビューを見た瞬間の高揚感たるや、こんなレンズほしいに決まっとるやろ!!!!という思いを強くしたのでした。

git merge の 3 つの動き

いまや Git なしでは生きていけないくらい Git に支えられている生活を送っていますが、Git のブランチをマージする手段にはいろいろあって、実際 GitHub でもプルリクエストをマージするときには 3 種類の方法から選ぶよう促されます。

git merge

ブランチをマージするコマンドですが、ブランチの状況によって挙動が変わります。具体的には Fast Forward と non-Fast Forward の 2 種類があり、オプションで指定しない限りは Git が勝手に判断してくれます。ここでは、masterから派生したtopic/aブランチをmasterにマージすることを想定したときの動きを説明します。

Fast Forward

topic/aの派生元のリビジョンがmasterの最新リビジョンと一致するときは、単純にtopic/aの最新リビジョンをmasterの最新リビジョンに変えるだけでブランチがマージできたことになります。このように、マージ先ブランチの最新リビジョンをマージ元ブランチの最新リビジョンにするだけでマージが完了することを Fast Forward といいます。

マージ前の状態
マージ前の状態

Fast Forward マージ後
Fast Forward マージ後

git logで歴史を見ると、マージされたtopic/aブランチはmasterの歴史の一部となっていて、別のブランチが存在したようには見えなくなります。

強制的に Fast Forward でマージする場合は git merge --ff-only とします(Fast Forward とならない場合はエラーとしてマージできない)が、オプションなしで git merge する場合のデフォルトの挙動も Fast Forward です(Fast Forward とならない場合は non-Fast Forward でマージしようとする)。

non-Fast Forward

topic/aを派生したあとにmasterに異なるコミットがある場合は、masterの最新リビジョンを変えてしまうとtopic/aを派生したあとに積み上げたコミットが無かったことになってしまうため、Fast Forward でマージできません。そこで、topic/aにあるコミットをmasterに混ぜた上で、マージをしたことを示すマージコミットを作成します。

マージ前の状態
マージ前の状態

non-Fast Forward マージ後
non-Fast Forward マージ後

git logで歴史を見ると、マージされたtopic/aブランチの持っていた歴史は時間順にmasterの歴史に取り込まれつつ、マージコミットによって別のブランチが存在していたこともわかるようになります。

強制的に non-Fast Forward でマージする場合は git merge --no-ff とします(Fast Forward でマージ可能な場合でも non-Fast Forward でマージコミットを作る)。

Squash

これは上記の 2 つとは異なり、明示的にオプションで指定(--squash)しない限りこの挙動にはなりません。

topic/aにある全コミットを1つに集約しmasterにコミットを作るマージのことを Squash マージといいます。git logで歴史を見ると、Fast Forward のようにtopic/amasterの歴史の一部になったようには見えなくなります。Squash マージしたあとでさらにtopic/aにコミットを積み上げ Squash マージをすると、もういちど topic/aの全コミットを1つに集約しなおしてコミットを作ろうとします。

Squash マージ後
Squash マージ後

余談

git rebase

なにかと怖がられがちですが、してはいけないこと*1はとてもシンプルかつたいていどこかでエラーを起こして失敗する*2ので、もっと安心して使えるコマンドです。 GitHub のプルリクエストをマージするときの選択肢に出てくるうちの1つでもあります。

名前のとおり、ブランチの派生元リビジョンを変える(re base)ためのコマンドで、手作業で同等のコマンドを打つとするなら、ブランチを目的の派生元リビジョンから切りなおしたうえで rebase 前のブランチにあるコミットを1つずつ cherry-pick するようなものです。たとえば、masterの歴史とtopic/aの歴史がそれぞれに進んでいるときにtopic/amasterに rebase すると、topic/aの派生元はmasterの最新リビジョンとなり、topic/aにあったコミットは別のリビジョン番号を持って積み直されます。

git pull

リモートリポジトリからコミットを取得するコマンドです。デフォルトでは git fetch かつ git merge の動きをしますが、オプション(--rebase)をつけると git fetch かつ git rebase の動きをします。

たとえば、mastergit pull をすると、Fast Forward できるときはマージコミットは作られず、non-Fast Forward の場合はマージコミットができます。また mastergit pull --rebase をする場合、一旦リモートリポジトリのmasterを取り込んだ上で、手元のmasterに積み上がっていたコミットを積み直します。

merge や rebase を取り消したくなったとき

ちなみに、merge や rebase が仮にうまく完了したあとでそれらを取り消したくなった場合、リモートリポジトリに push していなければ*3git reset --hard ORIG_HEADでコマンドを打つ前の状態に戻れます。

*1:共同作業しているブランチでrebaseしてpush

*2:force push しなければ失敗する

*3:リモートリポジトリに push しててもできなくはないけど歴史の辻褄が合わなくなる

自転車で遠出をするときに気をつけていること

自転車の楽しみ方は人それぞれで、近場をちょっと走って散歩代わりに楽しむ人もいれば、ひたすら山を登り続ける人もいるし、いろいろなところにでかけてグルメを楽しむ人もいます。自分の場合はトレーニングも若干考えつつも、いろんな景色を見るために100kmを超えるロングライドをよくします。本当はダイエットやら運動不足の解消やらを目的にしていたはずですが、いろいろ楽しんでいるうちに目的が変わってしまいました。趣味なので気にしない。

自転車で遠出をすると問題になるのが、出先で見舞われる様々なトラブルです。タイヤのパンクが最も典型的かとおもいますが、それ以外にも機材が壊れて走行できなくなることもあったり、事故にあったりすることもトラブルの一種です。

この記事では、機材や体調に関するトラブルや対処方法は多数ある書籍やブログ記事にまかせるとして、それ以外のトラブルについてまとめてみようと思います。

前提

家に無事帰ってくるまでがロングライドです。 トラブルにあわないようにするための事前準備と、たとえトラブルに見舞われても冷静に対処できるだけの選択肢を持っておくことが大事です。

自分が自転車に乗っていなくても使える話も含まれていると思います。

前もって準備しておく持ち物

コンパクトな財布にまとめるとか、小さめのポーチにまとめておくとかをすると簡単に持ち運べます。

  1. 免許証: 最強の身分証であり、機材トラブルが解消できないときに電車輪行以外の手段として車で運ぶ場合にも必要。
  2. 健康保険証: 病院に行かないといけないときにないと困る。ただし事故の怪我で病院にいくとき、被害者として健康保険をつかう場合は注意が必要*1
  3. 緊急連絡カード: もしものときに自分自身が何らかの理由で動けない場合、緊急連絡先や常用している薬、加入している保険などを記したカードを持っておくと、他の誰かへの意思表示ができる。
  4. 自転車ショップの会員証など: 途中でショップに持っていきたいときのために。
  5. 現金: キャッシュレスサービスが進んでいる中でも現金onlyなものはまだまだ多く、特に自販機に救われることもよくあるので。
  6. クレカ: これがあるだけでホテルに泊まるとかいろいろな手段が取りやすくなる。

地理の把握

太陽の位置と時間がわかれば方角もなんとなくつかめるので、あとは地図とにらめっこしてどっちに行ったらよいかを見極められるとベター(夜はあきらめるか、スマホのコンパスで頑張る)。 あるいは、行きたい場所につながる道の番号や、その周囲の地名(市町村の名前とか駅の名前とか)をなんとなく覚えておくと、道路標識でどっちに行くとどこに行くかを見たときに取るべきルートがわかりやすくなる。最悪引き返すことになってもいいように、目立つ建物や案内の看板の位置とか交差点の名前とかを覚えておくという感じでその場でできることもある。

最低限、駅がどこにあるかは知っておきたい(ここにたどり着きさえすれば輪行で帰るなり近くにある宿泊施設に泊まるなりの行動が取りやすい)。

トラブルへの対処

トラブルと一口に言ってもいろいろあります。事故への対処以外にも、それに至りかける危険への対処も含めて書いていて、特に危険に対する嗅覚は鋭くしておくと、たとえ出くわしたとしても受けるダメージを限りなく小さくできます。

  1. 事故: 被害者としても加害者としても、あるいは目撃者としても事故にあう可能性はある。いずれにしても警察・必要に応じて救急への連絡をすることと、けが人の応急処置を優先する。あとけが人の言う「大丈夫」はだいたい大丈夫じゃないのでしばらくは安静に。ちなみに怪我をみてもらった結果打ち身として病院で処方される湿布には、光過敏症に気をつけないといけないものがある(モーラステープとか)。肌が弱い場合はそもそも湿布の刺激が強く合わないことが多い(自分は全くあわなかったのですぐやめた)上に使用後もしばらくは太陽光を直接浴びないようにしないといけないので、できるならその心配がないものを出してもらう。
  2. あおり運転などによるヒヤリハット: 最近話題のあおり運転は自動車同士だけでなく自動車 vs 自転車でも起こり得る(交通ルールの無理解や感情的な問題など理由はいろいろ)。やばい車がいると思ったら近づかない、向こうから近づいてきたらそっとやり過ごす、もしなにかされても追いかけない、は自分を守る大前提。それでも何らかの縁あって煽られたり幅寄せされたりすることがあるが、その場合はナンバーを控えて即警察に連絡する*2SNSに当該の車の写真を上げる行為はやめておいたほうが無難(ナンバープレートそのものが個人情報にあたるかどうかという論争に火をつけがち、あるいはそれ以外に写っているものとの組み合わせで個人情報の要件を満たしてしまったり他の権利を侵害してしまって燃え上がってしまうなど)。一方で GoPro とか ActionCam をドラレコのように使うのは有用。最近はテールライトとカメラがセットになった製品もあるよう。充電をちゃんとしておこう。
  3. 自転車同士、あるいは歩行者との間のヒヤリハット: 自転車同士でもトラブルはあって、逆走してきた、とまれをまもってくれない、スマホいじりながら突っ込んできた、無灯火のまま飛び出してきたなど状況は様々。話せばわかってくれることもあるかもしれないし、そのまま無視されるかもしれない。こればかりは分からないのでどうすべきかはなんとも言えない。歩行者も突然飛び出してくることもあるので、視覚・聴覚を駆使して得られる周りの状況をよく把握しておく。仮に他の自転車や歩行者が周りをよく見ている様子が伺えても、自分のことに気がついているかどうかは別問題。

危険を避ける、あるいは危険度を下げるための行動

自分を危険に近づけなければトラブルにあうこともない(それでもあってしまうものがトラブルではあるが…)。

  1. 合図を出す: 自動車ならウィンカーやブレーキランプ等コミュニケーションの手段がいろいろあるように、自転車も手で合図してコミュニケーションを取ることができる(法律で決まっていて教習所でもらう書籍にも書いてある*3)。なれないうちは合図のために片手を離すのが億劫かもしれないが、合図があるだけで何をしたいかが周囲に伝えられるようになるので練習しておく。
  2. 声を掛ける: 特に追い抜くときは合図では伝えられないので、追い抜くことを後ろから声をかけて伝える。追い抜くときは左によるための合図を出すことも忘れずに(自動車がウィンカーを出すときと同じ考え方)。
  3. 他の交通を運転している人を見る: 自動車にしろ自転車にしろ、運転手の視界は限られているので、こちらに気づいていなさそうな車両には近づかない。顔がどちらを向いているかを見たり、アクセルの踏み具合や加減速の様子などから判断する。タクシーなんかは急に合図を出して止まり始めるなどトリッキーな動きをしがちなので、歩道でタクシーを捕まえたそうにしている人がいるとわかったら気をつけよう。
  4. 周囲の交通を音で把握する: スポーツカーや大型車、バイクなんかは大きな音をたてるのでわかりやすい。
  5. ミラーを付ける: 後ろを振り向いて確認する行為そのものがまあそこそこ危ないので、視線の動きを小さくまとめるためにミラーをつけておくとよい。ただし死角もあることを忘れずに。
  6. スピードを出しすぎない: 速度制限のある道路は当たり前だけどそれ以上出しちゃいけないのは車と同じ。下り坂などどうしてもスピードが出やすいところも自分がコントロールできる速度から上がらないようにブレーキを使う。ただしずっとブレーキを握りっぱなしにするとリムまたはチューブが熱でダメになることもあるので機材の扱いには気をつける。そうでなくても握りっぱなしは疲れるので、休み休み下るほうがいい。
  7. 目立つ服装: 反射材がついているとか、あるいは反射板を取り付ける、反射バンドを身につけるなど。黒い服装でナイトライドは自ら危険を招いていると言っていいくらい見えづらい。

まとめ

日本の道路がそもそもその構造からして自動車と自転車がノートラブルで仲良く走れる作りかといえば全くそうではない(自転車レーンにまたがって路駐してたり、自転車レーンがそもそもなかったり、運用でカバーしているルールもあったり)こともあるのだけれど、その中でできうる限りの自衛策とアピールは身につけておきたいですね。

*1:健康保険が負担する分は本来加害者が加入する保険から支払われるべきなので、健康保険を使って支払ったら「第三者行為による傷病届」を出して健康保険が加害者の保険から回収することになっている。事後の提出もできるのでよく話し合っておく。

*2:警察からその車両の所有者に警告をしてもらうことになる。自転車が原則として車道をはしるものということを知らない人もまだまだおおい。もちろん、自転車が通ってはダメなところを走るのは論外だけれども。

*3:右左折はわかりやすい。停止の合図は法律の定めるところと実際に使われるものが違うので注意が必要。