リバーカヤックの川読みとプロジェクト管理スキルについて - おがさわらなるひこのオープンソースとかプログラミングとか印刷技術とか

本当はもっと書かないといけないこと（香港レポートとか）あるんですがすがすが……。英語書くの気合いるので、とりあえずエッセイっぽいことを書いてごまかす。

えーと私の趣味の一つがリバーカヤックであるということはたびたび書いております。

最近ちっとも漕いでないんですが、土曜日に師匠（というと大げさですが）のウクディパドリングスクールの皆さんが近場の埼玉県は長瀞で講習するというので、ほいほいと出かけてきました。

メンバー的なものもあって、その日は川の流れを読む、「スカウティング」に重点を置いたものになりました。
スカウティングというのは要は「偵察」であって、初めて下る区間（初めてでなくても、水量が大きく変化した場合など）で、難易度が高いと予想される場合、陸に上がって、その瀬*1 に危険はないか、ちゃんと下れるか、どのルートがいいルートか、を見るという行為です。概ね上陸して行います。

独り歩きすると困るので書きにくいのですが、ウクディのトド校長こと石川さんの指導はこんな感じでした。

まずは瀬の頭から終わりまで全体像を把握する。例えばトントントンと三回落ち込みがあってあと白波が続いてそれが壁にあたって左に折れてるなとか。
次に、瀬の部分部分で、すーっと流れているところを見る。そこがライン。しゃばしゃば波が立ってるところは何かあるということ。障害物を見るのではない。人間、見た方向に行ってしまうのでｗ
部分部分のラインが分かったら、あとはそれをつなぐ。流れを乗り換えなければいけないときは、どこでそれを決めるか、目印をしっかり決めておく。
長い瀬の場合は一旦止まって立て直したほうがいい場合も多い。その場合はどこで止まるか、そのランドマークはどこか、それは川の上で見えるか、流れの上で漕いでいる状況でも見えるのか、上流からも見えるか、しっかり確認する。立って見るだけでなく、カヤックに乗った目線をシミュレートするためにしゃがんだりするのも大事。
それから上流に上がって瀬の入り口を見る。入り口で綺麗にラインに乗れないとあとが大変。入り口をきちっと決めておく。ここでもランドマーク選び大事。
最後！肝心なのがスカウティング終わってボート乗って漕ぎだすとき。今自分がいる位置からさっき見た瀬の入り口にアプローチできるよいルートはどれかを考える。川に出たら入り口を視界に入れながら漕ぐ。

と、こんな感じでした。

これって、ソフトウェア開発プロジェクトでもおんなじだと思うんですよね。

プロジェクトの全体像を把握する。期間とか予算とかコアメンバーとか。
マイルストーンごとに区切って、プロジェクトの流れを事前に確認する。ここは全体像をきちっと捉えるところだからお客さんとの折衝が多めになるねとか、ここのシステム設計ちゃんとやらないとあとでキツイからエースを投入しようとか、ここはマンパワーで押しきれるところだから最悪ここだけ外注使うとかありだねとか。
そして各段階がスムーズにつながるように考える。成果物ベースでつなぐのがいいのかな。
ゴールにしろサブゴールにしろみんなが共有してないといけないのできっちり確認する。自分たちの立ち位置がちゃんと見られるか。プロジェクトが走ってる中で確認できるような指標にすること。

……だんだん言葉あそびっぽくなってきたので対応させるのはやめときますが、よーは全体像を把握して部分を抑えてライン決めて、プロジェクトががーっと動いてる中でも見失わない指標を最初から決めとくってことです。

カヤックだとこの指標というかランドマークの存在は超重要なんす。「あ、あの岩が見えたってことは流れ乗り換えないとダメだな」「げげ、このホール左抜けるはずだったのに右通っちゃったよ、どこかで左に移らないと」みたいに、上手く行ってるときには次のステージにつなげる安心感になるし、失敗したときには早くミスに気付ける。で、川の流れがキツイときほど陸で見えてたランドマークなんか視野が狭くなって見えなくなるので、ランドマークはとにかく分かりやすく。これってエクストリームプログラミングにおいて「管理指標は精度はそこそこでも収集コストが低いほうがいい」っていう鉄則と同じだと思うんですよ。プロジェクトで全力疾走してるのに細かな管理指標とかつけられないじゃないですか。あれと同じ。

あと、長い瀬だと最初から最後までランドマーク覚えておくのがキツイんですよ。なので、途中で止まれたら止まって、「ああ、ここから下はこうだったよな」って思い出すことができたほうがいい。でも瀬の途中で止まるというのはそれなりにテクニックが必要だし十分なテクニックがないと却って危険だったりする。カヤックというのはまあまさしくウォーターフォールｗなわけですが、その途中途中を細かく刻むテクニックが身についてると却って川下りは楽になるし、一気に下るより失敗が少ないんですな。ここらへんはアジャイルで一個の開発粒度をどう小さくしながら開発の速度を落さないかなんて話に通じるんじゃないかと思う。

ま、能書きはともかく、狙った通りのコースをとれたときでも上手く行かなかった（けどなんとか帳尻を合わせた）ときでも、ハードな瀬を下ってのんびりするのはまた格別なのでありますよ。それはプロジェクトがなんとかランディングしたときと同じですよねー。

リバーカヤック楽しいよぉ〜♪

*1:斜度がきつくなったり、川幅が狭くなったり、場合によっては落ち込みがあったりして流れが激しくなり、波が立ったり危険な障害物などがあるところ。英語では rapid。