自転車初心者の MATE City (MATE.BIKE) 最低限カスタム

最近電動アシスト自転車を買いまして、中でもママチャリではなくスポーツタイプの自転車に電動アシストがついたものを e-BIKE というらしいんですが、その e-BIKE を買ったんです。

買ったのは MATE City というなんともシャレオツなルックスのものなんですが、 いやこれが非常に楽しくてですね。 天気が良い週末は無駄にチャリンコを漕いでます。

アシスト力が強いのでびゅーんって感じで、といってもちゃんと法律で定まっている時速24kmに達するとアシストは止まり、ただ重いだけの自転車にはなってしまうのですが、とにかく楽に漕げるので10km~20kmくらいの距離ならちょっとしたアトラクションくらいの感覚で楽しめます。

そんな楽しい自転車なのですが、この Mate City は買っただけだとライトはおろか付属品が何もついていないので、自転車初心者の私なりにネットで調べたりして購入したパーツを紹介します。

フロントライト

自転車の無灯火運転はそもそも違法なのでライトは必須、ということでこれは純正のライトを購入時に最初からお店(MATE.BIKE TOKYO)で付けてもらいました。

純正のライトだと電源は本体のバッテリーから供給されるので電池切れの心配はないし、手元のボタンひとつで電気がつくのでとても使いやすいです。

リアライト

道交法的にもリアライト、もしくはリフレクター(反射板)は必要なようですし、安全のためにもあったほうがいいだろうということで、 knog の BLINDER MINI SQUARE REAR を購入してシートポストに付けています。

下の写真のサドル下の赤いやつがそれです。

フェンダー

フェンダー(泥除け)は雨の日に乗らないなら無くてもいいんですが、突然の雨に降られてしまった際に、雨水が背中にはねる、という最悪の事態を避けたいので付けています。

もの自体は GP FI-115FR フェンダーセット で、MATE.BIKE TOKYO で本体と同時購入して納車の時点で付けてもらいました。

初めてのお高い自転車ということで、鍵をどうすればいいのか悩んだのですが、人に聞いたりネットで調べたりした結果、 ブレードロックと呼ばれるタイプの鍵がセキュリティ的には良いだろうとのことで、 ABUS の BORDO 6000K/120 SH を購入して、自転車側面に付けています。

頑丈な分、重量も 1.5kg とだいぶ重いですが、そもそも自転車本体が重いのでそこは割り切っています。

ベル

ベルなんて鳴らすことはほぼ無いのですが、道交法上、"警笛鳴らせ" の道路標識がある場所では鳴らさないといけない。とのことなので、 knog の Oi CLASSIC SMALL を付けています。 サイズは SMALL でぴったりでした。

スマホホルダー

せっかく遠い距離でも楽に移動できるようになったので、Google MAP や自転車NAVITIMEなどを使って遠出するときのためにスマホホルダーがあったほうが便利。というわけで、 Bone BikeTie ConnectKit 2 を使っています。

スマホホルダーはとくになんでもよかったのですが、自分の場合はスマホの背面にリングを付けている関係上、プラスチックのものだとうまく取り付けられないので、シリコン製のものにしています。

かご代わりのステムポーチ

かごは便利だけど見た目が、、と思いつつあったほうが便利なのは間違いないので、間を取ってステムにつけるポーチを購入しました。 買ったのは POTA BIKE ハンドルステムポーチ2 なんですが、収納力もそこそこあり、見た目も結構気に入っています。

写真がボケてますが、右からベル、スマホホルダー、サイクルコンピューター(これは備え付きのもの)、ステムポーチです。

そんなわけで

4月の頭くらいに購入して、約2ヶ月弱で230kmくらいは走ってるので、ガチ自転車乗りに比べたら全然大した走行距離ではないですが、個人的には久々にいい買い物でした。

ICEで優先順位付けするための Google スプレッドシート を作ってみた

タイトルの通り。

ICE - Google スプレッドシート

もし使いたいという奇特な人がいたらコピーしてカスタマイズして使ってください。

下記は使用イメージです。 f:id:kalibora:20181201225854p:plain

ICEについて詳しく知りたい方は下記の記事や参考リンクを参照してください。

プロダクトマネジメントにおける優先順位付けとそれを助けるツールについて - kalibora.log

参考リンク

プロダクトマネジメントにおける優先順位付けとそれを助けるツールについて

我々の時間は有限である。
すべての機能は有用であるようにも思えるし、みんなの言い分もそれぞれだ。

さて、僕はプロダクトマネージャーではないが、何事においても優先順位付けは必要だ。
無意識で出来る人もいるだろうが、僕にはあいにくそのような能力はあまり持ち合わせていなかった。

hygger.io

hygger.io というサービスをご存知だろうか?

いや、きっと知らないと思う。僕もつい最近まで知らなかった。

でも Trello というサービスなら知っている方も多いと思う。

知らない人のためにも説明しておくと、いわゆるカンバン形式でタスク管理出来るツールが Trello だ。

そしてこの Trello に優先順位付けの機能を強化させたものが hygger.io と言えそうだ。
もちろん、細かい機能の差異はあると思うが、自分が少し使った感覚としてはそうだった。

hygger.io にも Trello ライクなカンバンViewはあるが、それぞれのタスクに対してスコアリングができる。
スコアリング方式は下記の4種類から選べる。

  • Value vs Effort(価値vs労力)
  • Weighted Scoring(加重スコアリング)
  • ICE(Impact, Confidence, Ease)
  • RICE(Reach, Impact, Confidence, Effort)

Value vs Effort(価値vs労力)

それぞれのタスクに Value(価値) と Effort(労力)を設定し、4つの枠のマトリックスから優先順位をつける。

f:id:kalibora:20181117155346p:plain

Quick Wins は少ない労力で高い価値をもたらすもの。これを最初にやるべき。
Big Bets は価値も高いが、労力も多い。2番めにやるべきかもしれないが、小さな機能に分割してもいいかもしれない。
Maybes は価値も労力も低い。大きな機能実装の合間にやるのに最適。
Time Sinks は労力の割に価値が低い。優先付けすべきではない。

Weighted Scoring(加重スコアリング)

Value(価値) と Effort(労力)にそれぞれ独自の基準を設けてスコアリングする。
項目と加重をあらかじめ設定しておき、最終的なスコアを計算して算出する。

f:id:kalibora:20181117161919p:plain

上記の例では Value として

  • Revenue Increase(収益)
  • Customer Value(顧客価値)
  • Strategic Fit(戦略の適合性)

Effort として

  • Development Costs(開発コスト)
  • Marketing & Sales Costs(マーケティングと営業コスト)
  • Maintenance Costs(保守コスト)

を基準として設定している。(キャプチャ画像では一部幅が足りずで見切れています)

ICE(Impact, Confidence, Ease)

スコアの計算式は Impact * Confidence * Ease

基本的には Value(これはImpactとほぼ同義) vs Effort(これはEaseとほぼ同義) と同じだが、 Confidence が加わっている。

f:id:kalibora:20181117163009p:plain

労力は過小評価されがちで、価値は過大評価されがちという認知バイアスがあるため、
Confidence(信頼性)で、労力や価値にどれだけの信頼性があるのかを加味している。

RICE(Reach, Impact, Confidence, Effort)

スコアの計算式は (Reach * Impact * Confidence) / Effort

Reach は特定の期間内にどれだけの人に影響するか?

Impact はこの機能がどのように貢献するか?どのようにエンドユーザーに影響を与えるか?
この価値はサービスごとに違うのであらかじめ決めておく必要があるし、
これを測るのは容易ではないので、あらかじめ 3: 大規模なインパクト, 2: 高, 1: 中, 0.5:, 0.25: 最小 などと決めておくのが良い。

Confidence は Impact と Effort に対する信頼性。

Effort は 人月などのいわゆる工数

f:id:kalibora:20181117164851p:plain

monday.com

さて、ここまで hygger.io というサービスに備わった優先順位付けを見てきたが、他のサービスはどうしているのか少し気になった。

monday.com というプロダクト/プロジェクトマネジメントに使えるサービスがあるので、これもちょっと試してみた。

このツールでは優先順位付けのためのあらかじめ決められた機能というものはなさそうだったが、
デフォルトで用意されているテンプレートの中から Feature Backlog というものがあったのでそれを試してみた。

f:id:kalibora:20181117171036p:plain

左から4番目の Effort はいわゆる工数で、
5番目の Impact は価値
6番目の Effort も労力なので、Scrumのストーリーポイント的なものなのかもしれないが、ちょっとよく分からなかった。 どちらかを使えっていうことなんだろうか。
7番目の Impact AreaImpact がどこに効くか?ということだろうか。
8番目の Epic# はタスクをまとめるためのタグみたいなもの。
9番目の Vote は投票。

ただし、あくまでこれはテンプレートなので、自分でエクセルの様にカラムを追加することもできる。
例えば計算式用のカラムを追加し、上述のICEやRICEの計算式を定義しておけば、それらのスコアを表示する事もできる。

まとめ

ツールに実装されているものを参考にどのような優先順位の付け方があるのかを調べてみたが、
結局の所、価値や労力をどのように算出するかは難しい。

しかし、そのためにより細分化したり、どのような要因があるのかを知るきっかけになったり、
ツールとしてあらかじめ枠を定義しておくことで、必ずそれらの機能が、どのような価値や労力があるのかを考えねばならず、 それらは非常に有用だと思った。

参考にした記事

1on1やOKRなど人事評価やキャリア形成に使えるwebサービス

とりあえず列挙。

あとは Best Performance Appraisal Software | 2018 Reviews of the Most Popular Systems このへんとか。死ぬほどあるからまとめるのは諦める。

10万14回フェスに行った私が教えるフェスに本当に必要なものランキングベスト3

第一位: 体力

元気があれば何でもできる。とはよく言ったもので、元気が無いと何にもできない。

山道登ったり雨降ったりいろいろあるので体力作りはしておきましょう。

あと全部回って元取ろうみたいな考えは20代までで十分です。

自分のペースで楽しみましょう。

第二位: 友達

一人フェス何回かやったことあるけどマジで結構精神的にやられるタイミングあるからね。

踊ったりなんだりしてるときはいいの。疲れて休んでるときとか、移動中とかね。

しかもバスツアーで行った日なんかほんと周りのキャッキャウフフ声にこちとらどんよりですよ。

第三位: 金

ゴールドのほうじゃないです。日本銀行券の方です。

最近は電子マネー使える所も多いのでそこらへんは調べてくれ。

番外編: チケット

そうだった。チケットないと入れないや。

あと自分がほんとに使ってるチェックリストも一応おいときますね。 女性はこれプラス化粧品やらなんやらそういうやつなんじゃない知らないけど。

  • ベーシック
    • チケット
    • お金
    • 携帯
    • 携帯充電ケーブル
    • 携帯予備バッテリー
    • デジカメ
    • 小さめのバッグ(サコッシュ的なのとか移動するのに便利)
    • タオル
    • ティッシュ
    • ウェットティッシュ(アルコール無しもあるとコンタクトレンズはめるときにしみなくて便利)
    • 日焼け止め
    • 虫除け
    • バンドエイド
    • 帽子
    • サングラス
    • 羽織るもの(防寒)
    • レインコート(雨具)
  • 泊まる場合
    • 歯ブラシ
    • シャンプーなど(お風呂)
    • コンタクト
    • 目薬
    • メガネ
    • ゴミ袋
    • タンブラー(なんかお茶とか入れとくと水分補給に便利)
    • 替えのTシャツ
    • 替えの靴下
    • 替えの靴
    • テント
    • 寝袋
    • ランタン
    • 電池
    • 折りたたみイス
    • 折りたたみテーブル
    • ガムテープ(あると何かと便利なんすよ)
    • ペグ
    • ペグハンマー
    • まくら
    • テントシート
    • レジャーシート
    • 懐中電灯
    • 紙コップ・紙皿
    • 酒(基本現地で買うけど買いに行くのめんどくさい時用)
    • つまみ(基本現地で買うけど、乾き物ほしくなったりして)
  • 荷物送る場合
    • 荷物受取伝票
    • 荷物発送伝票

ハンドルネームの由来

最近ハンドルネームの由来を聞かれることがあった。

そもそもハンドルネームと最近は言うのだろうか、ともかくインターネット上で活動する際の名前のことだ。

私の場合それは kalibora である。

確かに何語でもないし、よくわからない名前だ。というか造語なのでググラビリティが高い。

その時は確か、

「何語でもない、どこの国かよくわからない名前が良かったのです。なにかアフリカっぽいじゃないですか?」

と答え、

「じゃあどこの国かわかってるじゃないですか」

とツッコまれたような気がする。

気がする。というのは私がその時すでにひどく酔っていて記憶が曖昧だからである。

すべては妄想かもしれない。

さて、その時は説明するのも面倒くさいし、中二病感満載なので黙っていたのだが、本当はもう少しちゃんと由来がある。

だけども問題はおれの城/部屋がない

話は私の小学生時代まで遡る。

当時小学校6年生だったぼくには、自分の部屋がなかった。

小学校6年生の男の子ともなればみな自分の部屋が欲しいものである。

思春期である。まっさかりである。自分の部屋が欲しいものである。

長屋のような作りの都営住宅に住んでいたわりと貧乏な家庭に育った私だが、幸いにもそこには小さな庭が付いていた。

そこにプレハブの部屋をこしらえたのだ。

夏は暑い。冬は寒いでお馴染みの仮設住宅。プレハブ住宅。

プレハブといえどもそこは城。人は城。人は石垣。

こうして私は一国一城の主となった。

籠城

私はそこでよく遊び、よく籠もった。

テレビゲームをやったり、パソコンをいじったり、曲のようなものを作ったり、

すべてはプレハブの中で完結していた。

まるでプレハブ中毒である。

プレハブ中毒・・。

仕事中毒はたしか work-a-holic と言うな。

それならば私は prefab-a-holic (プレファバホリック)だ。

そしてプレハブの正式名称は prefabric(プレファブリック)

であれば prefabolic(プレファボリック)が語感がいい。

ということで私が一番最初に取ったドメイン名は prefabolic.com である。

愛に飢える研究室

と、ここまでが前段。前置き。すでに結構長い。

prefabolic はサイト名として使うことになった。

問題はハンドルネームである。

それまで私は別のハンドルネームを使っていた。この話とは関係ないので何とは言わないが、別の名前を使っていた。

しかし飽きた。別の名前が欲しくなった。

でもこの -holic -olic で終わる感じは案外気に入っていた。

そして当時好きだった(今も好きだが)moon というゲームを作っていた会社が LOVEdeLIC という名前である。

ここからラヴをいただいた。当時愛に飢えていたのかもしれない。

これで loveolic

しかしこのままではちょっと恥ずかしすぎる。

laboratorylab にしてしまうのはどうだろう?

これならちょっとかっこいいっぽいぞ。

labolic (ラボリック)

もうちょっとおしゃれに

labolica (ラボリカ)

うん。語感もいいし、ラボだし理科だし、なんか頭いいっぽいぞ。(発想はかぎりなくあたまがわるい

蘇る逆転

しかし、ちょっと待った。この読みを逆にしてみたらどうだろう。

カリボラ。

響きがなんかいい。どこかの民族っぽい。どこかは知らんけど。

よし、これにしよう。これを適当なアルファベットに当てはめよう。

そうして出来たハンドルネームが

kalibora

だったとさ。

ソフトウェアに関連する散文

ソフトウェアとは何なんだろうか?

曖昧な要件を矛盾のない仕様に落とし、さらに自然言語だと曖昧さが残るので、

曖昧さを許さないプログラミング言語に翻訳する段階で、なにが曖昧であるかに気づき、

その曖昧さをなくし、完全に曖昧さも矛盾もない仕様に落とし込むこと。

なのだろうか。

要するにそれらはすべて仕様だ。

Howも多く含むが、Whatの塊でもある。

ソフトウェアの規模が大きくなることは良いことだろうか?

コード行数が増える。複雑さが増す。バグが増える。保守に多くの時間と人員がかかるようになる。

そして、できることが増える。

リターンはコストに見合っているのだろうか。

ドメインエキスパートなんてほんとにいるの?

ビジネスは変わり続ける。やりたいことは変わっていく。

自分がエキスパートに成り代わってドメインに忠実なコードを書いたとて、それがいつまで有効であるのか?

とはいえドメインの語彙が無いコードは不安

究極的に言えばインプットとアウトプットが合っているシステム。

どこぞの外注会社に発注したとして、インプットとアウトプットが要件通りであればそれは満足行くシステム。

でもソースコード中にドメインの語彙が存在していないとすれば、それは今後の保守に大分不安が残る。