2時過ぎに寝て7時に起きて9時まで寝てた。
読み進めておもしろかったし学びにもなったので書評を書いた。
backlog-github-integration-action のバグ修正 した変更を v1.0.1 としてリリースした。2週間ほど検証環境でリグレッションがないかをみていた。問題なさそうなので v1 ブランチにマージして docker イメージを push して v1.0.1 タグを付けてリリース成果物を作成した。久しぶりにやると手順を忘れていてドキュメントを書かないといけないなとか思ったりした。
23時に寝て7時に起きた。今週は不規則な生活をしたのでバテた。
今日の開脚幅は開始前156cmで、ストレッチ後160cmだった。先週よりちょっと数値が悪くなった。自覚症状はなかったけど、ストレッチをしてみると右腰の張りがそこそこあることに気付いた。自覚症状のない疲労に気付けるのがストレッチのよいところの1つでもある。
たまたま 起業プラザひょうご さんのスモールオフィスに空きがあるのをみつけたので内覧に行ってきた。電話したらとくに予約は取らなくてよいのでいつでも来てくださいと言われたのでアポなしで17時頃に行くことにした。現地のビルに行ってみたが、ビルが工事していて入れる状態ではない。なんかおかしいと思って調べたら地図には全然違う場所が示されていた。後で知ったことだが、2020年8月に移転していた 。前に起業プラザひょうごさんに2-3回行ったことがあったけど、それは移転前だった。その後、移転したことを全く知らなかった。
このコワーキングスペース兼レンタルオフィスが三井住友銀行神戸本部ビルという旧居留地の真ん中に18F建ていう、この付近ではトップレベルの高層ビルと言える。そんなビルの2Fという「ん？」という場所にある。おそらくビルの名前から三井住友銀行の自社ビルだろう。1Fには銀行の窓口があり、窓口の前を横切る形でエスカレーターを上がると起業プラザひょうごさんのコワーキングスペースがあった。入り口には警備員さんが立っていて入ろうとすると「会員証をみせて」と止められた。内覧にきた旨を伝えると通してくれた。銀行のビルなので休日でも警備員さんが控えている。
2Fにエスカレーターで上がり、受付で内覧にきたことを伝えるとそのまま (おそらくアルバイトの) 若いお兄さんがあちこち案内してくれた。興味本位で「素朴な疑問なんだけど、どういう経緯で銀行の自社ビルの2Fの空きスペースみたいな場所を間借りできたんですか？」と聞いみたら、さすがにそれは分かりませんと返ってきたw
普通のオフィス (5.6㎡) と広いオフィス (8.4㎡) の2つに空きがある。
空きスペースをパーティションで区切っただけの簡易的なオフィスではあるけど、家賃は税込でそれぞれ 23,595 円と 33,275 円になる。登記さえできれば、オフィスの体裁は私にとってそこまで重要ではない。物理的なセキュリティの懸念として壁の上によじ登ることができるのはあるけれど、扉には鍵がかかる。床面積から比較するとレンタルオフィスとしては周りの平均よりも半額から1/4ぐらいの破格の価格設定と言える。一通り話しを聞いてみて引越し先として検討できるかどうかを確認していた。私にとっての一番の課題はこのビルに入れる時間帯が制限されていること。私は平日は7時台にはオフィスにいるし、夜も遅かったら3時ぐらいまで作業をするときもある。外的要因で時間の制約を課せられるのが私にとってはストレスとなる。22時をまわることは月に数回程度しかないからまだ譲歩できても朝9時というのは始業が遅過ぎる。
顧問のはらさんとも相談して懸念がなければ、審査を受けるだけ受けてみてもよいかもしれない。但し、三井住友銀行の拠点ビルとも言えるところにあるコワーキングスペースなのでうちみたいなマイクロ法人は審査が通らない可能性も高いと思われる。過去に三井住友銀行で法人口座開設の申請を出してお断りされた実績もあるのでそれを思い出してた。
外部の人を招いて無償の勉強会を開催してよいかどうかを確認したところ、会議室の予約さえとれれば開催してよいとのこと。さらに会議室の利用料は無料とのこと。会議室は定員6名が2部屋、10名が1部屋、20名は1部屋の合計で4部屋ある。定員20名の会議室と聞くと「はぁ？」って感じでそこもみせてもらった。広い部屋のスペースを贅沢に浪費した構成だった。「こんな広い部屋の会議室って普段使うんですかね？」と質問したら使っているところをみたことないと返ってきて笑ってしまった。定員20名の会議室でどんな会議をやるねん？オフラインの外部勉強会をやるとしたらスペースが広くて快適そうな場所ではあった。あと後ろの方はモニターみえないよね、おそらく。
3時に寝て7時に起きた。一昨日からやっているリファクタリングが佳境なので1時ぐらいまでコードを書いてた。コミットするときにソースコードを自動整形したらリファクタリングと関係ないところに diff がたくさん出てしまって、数十箇所は diff と突き合わせながらフォーマットを手で直さないといけない状況になった。量が多かったので不満が溜まってコミットしたときに課題管理にこんなコメントをした。
ソースコードがフォーマットされてないから自動フォーマットするとリファクタリングと関係ないところに差分が出るからそれを元のフォーマットに手作業で戻す作業を1時間ぐらいしてた。帰りたい。
2022/07/29 00:33:45
翌朝に来た PO がたまたまコメントをみかけてデイリースクラムで質問を受けて恥ずかしかった。変なコメントしてごめんなさい。
導入前からもいまもずっと私は一貫してこのプロジェクトでストーリーポイントの運用は不向きではないかという姿勢をとっている。ストーリーポイントを嫌っているわけではなく、論理的にうまくいかない課題をどうやって解決して運用にのせるかの施策が何もないのに盲目的に運用しているところに懸念をもっている。私の懸念を解決する施策を誰かが責任をもって進めるなら反対することない。2時間という時間を設けていたのでストーリーポイントの是非も含めての見直し大会だと私は考えていた。しかし、そうではなかった。始まって30分ぐらいは見直し大会をどう進めるかの会議の進め方を議論していた。この時点では私はこの会議にやる気をなくした。誰もなにも準備してなく、ただ2時間という時間をとっただけの会議だった。次の1時間で直近の実際のチケットをもってきて、内容を説明してみんなでポイントを付けていく作業をしていた。その後の30分はプランニングポーカーやって遊んでただけ。ストーリーポイントの運用の見直しという視点は何もなくて、いまの数値はデタラメだから正しい数値がつくリファレンスストーリーを作り直せばいいというだけだった。誰も責任をもってないので時間を潰すだけの会議だったと思う。
ちょうど10月末でお手伝いを終了することを伝えたのもあって、プロジェクトから去る開発者があれこれ大勢側に疑義を申し上げるのもどうかという思いもあって、これ以上はストーリーポイントの運用に口出ししないことに決めた。おそらくチームというよりは組織としてどうしてもストーリーポイントを運用したい動機が別の理由からあるようにみえた。ストーリーポイントさえ付けておけば、プロジェクトのスケジュールがどうなっても誰も責任を追求されなくて責任者は楽なんだろうと推測する。
一方で、協力会社の若い開発者がチケットの内容を説明していて、何度か「コピペしただけ」という説明の仕方をした。私は違和感があって気になっていた。本人は悪気なく大した工数ではなかったと伝えたかったのだと思う。開発作業の説明でコピペしただけと発言して恥ずかしいという感覚もない。仮にコピペしたコードを扱うとしても、そのコードの拡張性や保守性を考慮して抽象化することはあるだろうし、論理にあわせて修正するからまったく完全なコピペなどあり得ない。この発言をプロの料理人に例えたら「既成品をレンジでチンしただけ」と言っているに等しい。推測だが、プロの料理人は仮に既成品を使ってもそのまま客に出すことはなく、必ずプロとしての付加価値をつけていると私は思う。プロの開発者として開発の姿勢に問題があることがわかってしまうのに加えて、ビジネスパーソンとしても適切な発言ではないことに気付いていないのが不憫に思えた。まともな会社で働いていれば、先輩に叱られたり指導を受けたりできるのが、そんなことすら知らずにキャリアを歩んでしまう懸念がある。このまま中堅になったときにどこかで失言して信頼をなくしてしまうのではないかと心配になった。
2時に寝て7時に起きた。前日はリファクタリングで0時過ぎぐらいまでコードを書いてた気がする。
窓付きオフィスの空き をみつけて内覧依頼をしていた。昨日入居者が退去したということで日程調整して今日の13時から内覧を申し込みしていた。朝起きて楽しみにしていたら、午前中に電話が掛かってきて昨日たまたま申し込みがあって成約してしまったとのこと。もちろん内覧前に成約があることは承知しているのでそれ自体は仕方ないことだと理解している。タイミングがよすぎて陰謀論のように妄想していた。本当はもっと事前に決まっていたのに連絡するのを忘れてたとか、私の場合は同じ施設間の移動になるので利益だけを考えると外部からのご新規さんを優先されたとか、いくつかパターンは考えられる。妄想遊びはともかく、最低でも1ヶ月前には空き情報がサイトに掲載されるので十分な時間があるので他のお客さんが申し込む可能性は高い。私はそれも含めて縁があるかどうかを試していたところはあった。これは縁がなかったということで受け入れた。契約はできないけど、今後のために内覧だけさせてほしいとお願いして行ってきた。普通に内覧してよい部屋だった。空いていれば内覧後にすぐ申し込みをしていたので1日の差で希望が叶わなかった。とはいえ、すでに内覧したので次に空きが出ているのをみつけたら内覧せずに申し込みできる状態になったとも言える。もしかしたら、昨日申し込みした人も私と同じように事前に内覧はしていたが、なんらかの理由で申し込みできなくて今回は縁があったのではないかとも考えられる。いずれにしても、また次の縁があるときを待つ。
サービスインが落ち着いたのでお手伝いしている開発プロジェクトの大きなふりかえりイベントがあった。スクラムのスプリントが1週間単位なのでふりかえり自体は毎週やっている。ホストがスクラムマスターで、どんな風に数ヶ月分の大きなふりかえりをするのか興味があったんだけど、とくに目新しいことはなく、総論として期待はずれだった。毎週のふりかえりイベントの延長でしかなく、区切りとしての総括もなければ、次の開発に向けての改善や展望もほとんどなかったと思う。スクラムマスターは業務を理解していないのでまともにファシリテーションできなかったとも言える。みんながんばった、サービスインできてよかった、これからもがんばっていこうのレベル。
スクラムマスターがこのプロジェクトに参加したのは昨年の10月で、私が11月からお手伝いしているのでほぼ同期だということもわかった。その開発プロジェクト自体はその1年前ぐらいからやっていたのかな？現時点で2年ぐらい経っているのだと推測する。私がイニシアティブをとったところで評判のよかった項目はこれら。コメントを求められたので、開発者が開発しやすい環境を作った方が開発のサイクルが早くなって結果的にプロダクトの品質が上がるという当たり前のことを話した。
1つがっかりしたのが、ストーリーポイントを用いたバーンダウンチャートの実績 のふりかえり。ネガティブな結果が出ているのに、そのバーンダウンチャートがあったから間に合わないということがわかって納期を延期できたみたいなことを話していて呆れてしまった。導入当初、納期が守れなくて五月雨式に延期してしまう課題への対応として導入したはずだった。導入時に私は2回スクラムマスターにストーリーポイントで納期を見積もるのは誤った運用だと指摘した。しかし、スクラムマスターが他プロジェクトでうまくいっているからと強引に導入した経緯がある。そして納期をまったく守ってもいないのにその事実を真剣に総括しようとしない姿勢が不誠実だった。また翌日ストーリーポイント見直し大会をするという話しがあったからこの場は丸くおさめた。
スクラムマスターはポジティブな内容とネガティブな内容を交互にふりかえるようにファシリテーションしていた。あとネガティブ内容の厳しい指摘は意図的に避けているようにもみえた。おそらく担当者の心情を慮ったのだろう。人を責めるわけではなく、ネガティブな事実や結果と向き合って、組織として仕組みで次の改善につなげるというのは、私が言うほど簡単ではないのかもしれない。私は sier 時代にお客さんからも社内からも怒られるのが日常だったからいまの若い人たちよりはネガティブな事実に対する耐性が高くてギャップに映るだけかもしれない。
0時に寝て6時に起きた。
サービスイン のバタバタによって毎週の定例リリースを先週はやらなかった。そのため、今回は2週間分の変更をまとめてリリースすることになった。インフラの変更が複数あったので私も万全の準備をして作業に備えた。
他にもいくつか本番のマスターデータの更新など、箇条書きにした作業項目は15個になった。今回はインフラとアプリケーションが相互に依存する変更を加えているので意図した順番で作業しないといけない。ノードグループ導入による k8s の作業内容は wiki にすべて作業方法を書いていたのでその通りに作業してもらった。メンテナンスモードに切り替える初動もうまくいったので現場の運用担当者が間違って使うこともない。意図した作業内容と順番でうまくリリース作業もできた。メンテナンス時間を2時間もらっていて、宿泊業だとその時間帯が12-14時になる。宿泊客のチェックアウト後、チェックイン前の空き時間だ。メンテナンス後に運用担当者にすぐ確認もしてもらえるし、リリース作業の時間帯としては深夜早朝にしなくてよいのは助かる。私が想定した通りに作業は進み、1時間でリリース作業を終えた。障害も一切なかった。インフラ担当者は想定外の障害に備えて、切り戻しやリスク管理をする。まったく問題なく想定内だったので晴れ晴れしい気持ちになった。こういう気持ちはインフラ担当者にしかわからないと思う。
0時に寝て6時に起きた。
スクラムのふりかえりイベントでストーリーポイントの見直しをしようという話題が出た。この半年ほどストーリーポイントを使って実際に開発をやった事実から整理してみる。
これらの事実から私の所感をまとめてみる。
ストーリーポイントによる運用をうまくまわすにはいくつか制約があるように私からは思えた。
0時に寝て6時に起きた。
メンテンナンス時にエンドユーザーがアプリケーションにアクセスできないようにしたい。いろんなやり方があるけど、どういった手段で対応するのが最もシンプルで運用も容易かを少し前から頭を悩ませていた。
当初は cloudfront のディストリビューションをアプリケーションの assets とメンテナンスページの html の2つを作って、cdk のデプロイで切り替えできないかと考えた。cloudfront はドメイン名と密接に紐付いていて、同じドメイン名を2つのディストリビューションに設定することはできないようにみえる。あらかじめそれぞれのディストリビューションを2つ作っておいて route53 で必要に応じて向き先を切り替えるといった構成はできなかった。その次に waf について調べていたら waf がルールでカスタムレスポンスを返すことができることに気付いた。
ちょうどいまエンドユーザーからのアクセスは ipSet で許可し、それ以外のネットワークからのアクセスをブロックしていた。そのルールを更新して、メンテナンス時はエンドユーザーからのリクエストのみをブロックに変更してカスタムレスポンスを返せることに気付いた。waf を管理するスタックなら cdk デプロイで1分ぐらいで更新できた。このやり方のよいところの1つに開発者の ip アドレスを許可することで開発者だけはアクセスできるようにもできる。あと具体的に cdk でカスタムレスポンスをどう実装するかのドキュメントがわかりにくい。サンプルとしてはこんな感じ。
const acl = new wafv2.CfnWebACL(this, 'MyAcl', {
defaultAction: { block: {} },
name: 'my-acl',
scope: 'CLOUDFRONT',
customResponseBodies: {
maintenanceInProgress: {
content: '<html lang="en">Maintenance in progress</html>',
contentType: 'TEXT_HTML',
},
},
rules: [{
action: {
block: {
customResponse: {
responseCode: 503,
customResponseBodyKey: 'maintenanceInProgress',
},
},
},
statement: {
ipSetReferenceStatement: {
arn: ipSet.attrArn,
},
}
}],
});
0時に寝て7時に起きた。
読み終えた。あとで総評を書く。
2000年に改正された借地借家法38条の「定期借家」の条項から賃貸契約には2種類あるらしい。
普通借家は契約期間更新の概念があり、借り主が契約更新を拒否するには「正当な事由」が必要になる。一般的な賃貸マンションなどの契約も多くのケースでこちらの契約になる。ここでいう正当な事由とは、建物が老朽化して立て直す必要があるとか、貸し主がそこに住むといったものらしい。一方で定期借家は契約期間が終了すれば、一旦契約は終了してから新たに再契約するといった段取りになる。この定期賃貸借契約の条件を満たすには、契約期間更新の定めがないことを説明した書面を交付する必要がある。その書面がない場合はすべて普通借家とみなされるという。その是非を巡って争った最高裁の判例があるらしくググるとすぐに出てくる。当事者同士で双方の合意があったとしても説明書面がない場合は無効とするような判例となっている。これを逆手に取れば、普通借家として契約更新を主張できるというストーリー展開になっている。
あとは PDCA サイクルのうち、日本の会社で一番弱いところはどこ？という話題が出てくる。Check だろう？という主人公の答えに、アドバイザーは Plan じゃないかと返す。Plan が曖昧だから Check できないという背景になっているのではないかと。一理あるかもしれない。日本人は気質として誰か1人が責任を担うのを嫌う文化があるように思う。個人の責任にしたくない・されたくないという空気から Check を曖昧にしたがる傾向があると私は考えている。
タイトルのままの章でホテル経営についてのアドバイスがあるわけではなく、ストーリ仕立てで展開してきた物語の結末や登場人物たちのその後のキャリアや展望などを紹介している。総じてハッピーエンドと言えるし、総じて人生の中のスナップショットとしてこんなもんとも言える。区切りがきてなんらかの結果が出たとしても、さらに人生は続くので日常が少し変わっていくだけといった展開になっていた。
著名なホテルの総支配人と著者との対談がある。読んでいて関心をもてたところは Job Description (職務分掌記述書) の重要性が説かれている。適正な評価、公平な人事、採用にも必要とされる。この考え方はメンバーシップ雇用を長く続けてきた日本の会社の年功序列とは大きな違いがあるため、制度設計の見直しは時間がかかるのだろうと思える。過去のしがらみがない新興企業が新たに制度設計して台頭していくのがよいのだろう。
また外資系という言葉に抵抗感のあるスタッフに対して「トヨタやファーストリテイリングは外資系ですか？日系ですか？」と尋ねるという話題も出てくる。そうすると、外資系や日系というグルーピングに意味がないことに気付く。その違いを対談の中ではグローバルかノングローバルかの違いでしかないと説明されている。ビジネスの規模や競合をグローバルの視野で考える必要があるかどうかによって変わってくるという。
勝てる能力があってもその素地となる基礎体力がないと発揮できない。野球でも基礎体力があるから速い球を投げられる。
これもホテル経営に限った話しではないなと思えた。私自身、昨今の開発チームをみていて感じることでもある。クラウドでアプリケーション開発が簡単になったがために基礎がなく、スキルが低い開発者もメンバーの一員として働けるようになった。もちろん最初は誰もがそうだけど、適切な指導や教育を受けないとそのまま経験年数だけが経ってしまう。さらにそんな人が偶然リーダーになってしまうと 許される無知の範囲は開発経験年数に反比例する という現象が起きる。一定の水準を超えていない開発者がなにを作ってもうまくいかないのではないかと私は感じるようになってきた。私はそういったプロダクトを「ただ動くだけ」と呼んでいる。その後の拡張や保守に必要以上にコストがかかり、それが原因で将来の開発計画に支障をきたすこともある。そして、多くのケースでその状況を作った人はその後いないことが多い。
0時に寝て6時に起きて7時半に起きた。
今日の開脚幅は開始前158cmで、ストレッチ後162cmだった。まだ右腰と右股関節、両腕の張りは少し残っているものの、先週末の田んぼ仕事の疲労はかなり抜けた。今週は暑くて家に帰ってきたらエアコンをつけてだらだらしていたのであまり数値はよくならないんじゃないかと思っていて、実際に開始前の数値はいま一つだったんだけど、ストレッチを受けたらいつも通りに戻った。トレーナーさんと雑談しているときにふと「毎日パソコンを使いますか？」と質問を受けた。トレーナーさんからプログラマーの自分にとってそんな質問をされるとは予想外で思わず吹き出して笑ってしまった。その質問は「毎日水を飲みますか？」と私にとっては同じですよと答えた。トレーナーさんも愚問だったと理解して一緒に笑ってた。
ホテル側が自分たちの問題を解決するために客の行動を制御するといった展開になっている。米国のスーパーマーケットでは Express Lane という、購入品目が少ない客向けに手早く決済するためのレジが設けられているらしい。日本にはないのかな？この運用には客に学習コストを強いるのが欠点となる。キャパシティ問題の問題解決のアプローチは次の3つになる。
本章の展開としては3番目の客側の導線や行動を変えてしまう方法で需要を変える手法が説明されている。本題ではないけど、さらっと出てくる説明にも納得感がある。ダメなホテルの共通点として、他社でうまくいった改善策、ベストプラクティスに飛びつき、それ以上考えようとせず、問題の本質を理解しようとしない。そういうホテルはコンサルタントが去ってしまうといずれでダメな経営に陥るとある。ホテルに限らず、ダメな会社の特徴だと思う。
客にピーク時の利用を避けてもらうための施策として次の2つがある。
ホテル側が客の行動をコントロールするのは構わないが、客にとってそれが不利益にならないように配慮する必要がある。人間の心理として混雑することがあらかじめわかっていればクレームにならず許容できたりする。人は不意に混雑に出くわして不満をもつことが多いという。そういった人の心理を利用して人の行動を制御して経営に生かすという考え方は比較的新しい研究領域である。行動経済学などもその分野の1つで、古典経済学では人は合理的に行動するとされてきた。しかし、現実では必ずしもそうではないことも行動経済学によってわかってきた。
親会社の不動産会社からリスク管理報告書を提出しろという業務に沿ってリスクマネジメントについての話題が出てくる。契約の話しだったり、建築に関する話しだったり、あまり一般的な経営とは異なる内容にみえる。余談だけど、過去にうちの会社で業務内容が変わったにも関わらず、契約内容を更新せずに更新された新たな業務を継続してうまくいかなかった経験がある。うまくいかなかったときに原点に立ち戻る場所が契約であり、契約を曖昧に扱うと後でしっぺ返しがあるという失敗をまさに経験した。ふりかえりをするときにそもそもの基準が適切でないとその反省や改善点も曖昧になってしまうという話し。
さて、リスク管理報告書のアウトラインとして次の用語が出てくる。
peril という英単語の辞書を引くと、差し迫った危険という意味が出てくる。リスク管理の文脈の用語と英語の意味はやや違うのかもしれない。
親会社に投資ファンドからホテルの買収提案があり、ホテルの事業価値を測るコーポレートファイナンスの話題が出てくる。上場企業であれば株価 x 発行済株式数で時価総額がすぐにわかるが、未上場企業の価値を査定するのは難しいという説明からその手法が紹介される。
不動産を所有しているかどうかで株式評価は大きく異なる。単純に不動産をもっていればよいというわけでもなく、資産と負債のバランスが取れているかが大事。「また貸し」のことを業界用語で転貸 (サブリース) と呼ぶ。
株価の利回りを株価収益率 (Price Earnings Ratio: PER) と呼ぶ。時価総額 / 純利益で計算される。この計算式から時価総額を知りたければ、純利益 x PER で計算できる。比較可能な会社の PER がわかれば未上場会社の株価を計算できる。但し、PER は会社が未来永劫事業を継続させることを前提としている。会社の継続性に疑義があると PER を用いる根拠がなくなる。株主に説明するときの利益とは、正式には 税引き後当期利益 になる。この金額から配当がなされる。うちの会社だとざっくり粗利から20-30%ほど (法人税 + 消費税) 引いたものが税引き後当期利益になる。会社が予定する配当額は同じだが、株価をディスカウントすることで配当の利回りをよくするという考え方を リスクプレミアム と呼ぶ。会社の展望や事業の不確実性を数値化したとみなすことができる。
いま現在もらえる現金の1万円は1年後もらえる1万円よりも価値が高いと言える。それは1年後にはもらえないかもしれないリスクや運用機会損失リスクが含まれるから。その価値をどの程度低く見積もるかを 割引率 と言う。この割引率を用いて将来の現金をいまの現金価値に置き換える評価方法を DCF (Discounted Cash Flow) 法 と呼ぶ。仮に割引率を10%とすると、1年後の100万円をいまの価値にすると、100 / (1 + 0.1) = 90.9 万円になる。2年後の100万円だと 100 / (1 + 0.1)^2 = 82.6 万円になる。
本文中ではこの計算式を使って年間の利益と割引率を考慮した現在価値をエクセルでモデル化している。python で書くと次のようになる。
>>> def f(profit, discount_rate, year):
... return profit / pow((1 + discount_rate), year)
>>> for i, profit in enumerate([100, 120, 125, 130, 135, 140, 145, 150, 155, 160, 165], 1): i, round(f(profit, 0.1, i), 1)
...
(1, 90.9)
(2, 99.2)
(3, 93.9)
(4, 88.8)
(5, 83.8)
(6, 79.0)
(7, 74.4)
(8, 70.0)
(9, 65.7)
(10, 61.7)
(11, 57.8)
例えば、割引率が10%で5年後の利益が135万円ならば、その現在価値は83.8万円になる。本文の中ではこの金額が投資ファンドが提示している金額だとだいたい一致していることから、これ以上の精度の高いモデルを作らないといけないみたいなストーリー展開になっている。いずれにしてもパラメーターの変数の精度が高くないと適切なモデルとは言えない。割引率を用いた現在価値を計算する考え方を タイムバリュー (時間の価値) と呼ぶ。意思決定が遅れるほどプロジェクトの収益化も遅れるため、割引率を計算する現在価値が小さくなっていくという考え方ができる。
0時に寝て6時に起きた。金曜日は非稼働日だけど、今週は月曜日が祝日だったから普通に働いてた。
たまたま api client 周りを触っている。それらは spring の WebClient で実装されている。WebClient は spring-webflux プロジェクトが提供している http リクエストを扱うためのクライアントでリアクティブプログラミングを用いた設計になっている。リアクティブという言葉がピンとこなければ非同期フレームワークを用いた http クライアントと言い換えても大枠ではあっているのではないかと思う。spring-webflux プロジェクトそのものはノンブロッキング、バックプレッシャーといった機能をサポートする web アプリケーションフレームワークを提供するもの。
Reactor というコアライブラリを使って spring-webflux のフレームワークは実装されている。このデータ構造の1つに Mono と Flux が出てくる。初見の開発者はこの名前のデータ構造がよくわからんというところから始まる。私がそうだった。ドキュメントの説明によると、Mono は0から1、Flux は0からNまでのデータ列の概念を扱うという。おそらく json のようなレスポンスを返す場合は Mono を使い、ストリームを返すレスポンスは Flux を使えばいいんじゃないかと思う。
Reactor is the reactive library of choice for Spring WebFlux. It provides the Mono and Flux API types to work on data sequences of 0..1 (Mono) and 0..N (Flux) through a rich set of operators aligned with the ReactiveX vocabulary of operators. Reactor is a Reactive Streams library and, therefore, all of its operators support non-blocking back pressure. Reactor has a strong focus on server-side Java. It is developed in close collaboration with Spring.
WebFlux requires Reactor as a core dependency but it is interoperable with other reactive libraries via Reactive Streams. As a general rule, a WebFlux API accepts a plain Publisher as input, adapts it to a Reactor type internally, uses that, and returns either a Flux or a Mono as output. So, you can pass any Publisher as input and you can apply operations on the output, but you need to adapt the output for use with another reactive library. Whenever feasible (for example, annotated controllers), WebFlux adapts transparently to the use of RxJava or another reactive library. See Reactive Libraries for more details.
いまローカルの開発環境では vpn 接続をしてプロキシ経由でアクセスするサーバーがいる。WebClient のプロキシ経由で通信できないという問題があることを同僚から教えてもらった。プロキシ経由でアクセスしようとすると認可エラーになってしまう。なにかしらプロキシ経由の接続に問題がある。
Caused by: io.netty.handler.proxy.HttpProxyHandler$HttpProxyConnectException: http, none, /10.100.101.10:8080 => /192.168.201.35:18980, status: 403 Forbidden
同僚は WebClient のデフォルトでは http の CONNECT メソッドを使って通信しようとするが、それを squid がサポートしていないか、設定を変更しないとダメなんじゃないかと話していた。その内容が正しいかどうか、私は未検証だけどデフォルト設定では通信できないことがわかった。ここで WebClient の設定の1つに ClientHttpConnector があり、任意の http client ライブラリに置き換えられる。ソースをみると次の4つの ClientHttpConnector が使えるらしい。デフォルトが ReactorClientHttpConnector になる。
private ClientHttpConnector initConnector() {
if (reactorClientPresent) {
return new ReactorClientHttpConnector();
}
else if (jettyClientPresent) {
return new JettyClientHttpConnector();
}
else if (httpComponentsClientPresent) {
return new HttpComponentsClientHttpConnector();
}
else {
return new JdkClientHttpConnector();
}
}
試しに jetty-reactive-httpclient を使って JettyClientHttpConnector に置き換えてみたところ、プロキシサーバー経由のアクセスができるようになった。
public WebClient create(String proxyIp, int proxyPort) {
var httpClient = new HttpClient();
httpClient.setFollowRedirects(true);
httpClient.getProxyConfiguration().getProxies().add(new HttpProxy(proxyIp, proxyPort));
var connector = new JettyClientHttpConnector(httpClient);
return WebClient.builder().clientConnector(connector).build();
}
23時に寝て6時に起きた。今日は淡々と web api の実装をしてた。
少し前に誤った書類を裁断していて用紙を3-4枚を一度にやろうとして力いっぱいまわしたら空回りするようになってしまった。メーカーのために取説には1-2枚とあるのでキャパシティ以上の負荷をかけた私が悪い。シュレッダーの刃は頑強だと実感していた分だけ別のところに弱点があることを失念していた。分解して歯車の部分をみてみると、歯車の一部が欠けていることがわかった。刃は頑強だが、どうやら歯車はそうではなかった。こんな小さい歯車が欠けるんだということがわかった。
このシュレッダーは2020年1月25日に購入してもう2年以上使っていて、手動で手回ししながら裁断する。ぷちぷちをやるような気持ちになるのでちょっとしたストレス解消にもなってた。購入時に amazon の悪いレビューには空回りするようになるみたいなコメントもあったんだけど、私はこれまで2年以上問題なく使えてきた。裁断するものの量と負荷が蓄積していくうちに歯車が壊れて空回りするようになるのだろうなと、今回の失敗から理解できた。