ふりかえりとむきなおり

23時に寝て何度か起きながら7時に起きた。なんか体調が悪い。

ふりかえりとむきなおり

毎週火曜日はふりかえりの日。今週もスプリントゴールは未達に終わったわけだけど、未達が普通で稀に達成できるのが常態化しつつある。悪く言えば ゾンビスクラム 状態と言えるのかもしれない。サービスインのゴタゴタも解消したので PO からもツッコミがあってスプリントゴール達成できない問題が再燃した。私からみたらこんなところか。

  • スプリント初期は前スプリントの残タスクをやるのが常態化している
  • メンバーにやる気と実力がない
  • コミュニケーションコストが高くてオーバーヘッドが大きい (スクラムイベント、確認や待ち時間など)
  • フルタイムで働いていないメンバーがいる (ちょくちょくメンバーも休暇をとる)
  • スプリントが1週間と短過ぎる

その議論をしている中でスクラムマスターが むきなおり をしようといった結論になった。私は用語を知らなかったので調べてみた。

この3点を満たしながら、事業をふりかえって、行きたい方向へとむきなおることが今回の合宿の狙いでした。ただふりかえるだけではなく、あるべき姿との差から、今後の方向性を決めることを、特に「むきなおり」と名前付けしています。ふりかえり、むきなおる。今回の合宿はギルドワークスの今後の方針と向き合うための機会としました。

事業をふりかえって、行きたい方向へむきなおる

ふりかえりの結果から方向性を変えることを呼ぶらしい。私はまったく理解できていないのだけど、普通のふりかえりをして改善するときは何と呼ぶのだろうか。ただの言葉遊びじゃない?という気もする。また後日、そのためのイベントをするそうなのでそのときに理解を深めてみる。

孔明の史実を読み始めた

0時に寝て7時に起きた。

正史 諸葛亮孔明

パリピ孔明 がおもしろかったので孔明の記事などを読んだりしていた。

私、姓は諸葛、名は亮、字を孔明と申します。

作品中のこの挨拶が印象に残っている。キャッチフレーズのようなものが挨拶というのも珍しい?そんなこんなもふくめて孔明の本も読んでみることにした。

「第十一章 第一次北伐」を読んだ。

孔明が軍事で手腕を振るうようになるのは劉備の死後になる。北伐は第一次から第五次まである。そのうちの第一次北伐の失敗は 泣いて馬謖を斬る の故事で有名である。wikipedia の説明では正史と演義でこの故事に関する記述は異なっていることが書かれている。本書では、馬謖が副将の王平の諫言に従わず、山頂に布陣したことそのものは悪い策ではなかったと擁護されている。山頂から地の利をとって一刻も早く要衝を通過したい敵の張郃の軍にとって厄介な配置と考えることもできる。馬謖の失敗は実戦経験が乏しかったことで水源の確保を怠っていたことだという。かたや敵将の張郃は歴戦の名将であることから水源の確保ができていないことを看破して馬謖が布陣する近くの川や水源を確保してしまった。水源を確保することなど軍事に限らず当たり前の話しであり、戦術書に「水源を断て」などと記述しているものはないという。馬謖軍の布陣をみただけでそのことを見抜いた張郃の応用戦術を褒めている。さらに戦争に敗れただけであればまだよかったが、馬謖は敗北の責任を逃れるために逃亡したらしい。その承認欲求とプライドのために自分が負けた事実を受け入れられなかった。本書では、孔明の任命責任も大きいと締め括られている。馬謖が孔明の愛弟子であるから、実績のある諸将よりも私情を優先して実績をつけさせてあげようと抜擢した。その結果、馬謖もより大きな実績を挙げようと行動して失敗してしまった。どういう思いで涙を流したかは本書では書かれていなかった。

久しぶりにブログを書いた

2時過ぎに寝て7時に起きて9時まで寝てた。

もてなしだけではもう食えない

読み進めておもしろかったし学びにもなったので書評を書いた。

backlog-github-integration-action v1.0.1 リリース

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時というのは始業が遅過ぎる。

  • 平日: 9:00 - 22:00
  • 土日祝: 10:00 - 20:00

顧問のはらさんとも相談して懸念がなければ、審査を受けるだけ受けてみてもよいかもしれない。但し、三井住友銀行の拠点ビルとも言えるところにあるコワーキングスペースなのでうちみたいなマイクロ法人は審査が通らない可能性も高いと思われる。過去に三井住友銀行で法人口座開設の申請を出してお断りされた実績もあるのでそれを思い出してた。

外部の人を招いて無償の勉強会を開催してよいかどうかを確認したところ、会議室の予約さえとれれば開催してよいとのこと。さらに会議室の利用料は無料とのこと。会議室は定員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時に起きた。

ストーリーポイント再考

スクラムのふりかえりイベントでストーリーポイントの見直しをしようという話題が出た。この半年ほどストーリーポイントを使って実際に開発をやった事実から整理してみる。

  • 開発者のタスクも非開発者のタスクも同じ尺度のストーリーポイントを設定していた
  • あるチケットのタスクをやっていてチケット分割すると、最低でもストーリーポイントが1増えていた
    • 元チケットと分割したチケットのストーリーポイントの総数が同じであれば問題はないが、ストーリーポイント1が設定されたチケットを2つに分割するとそれぞれにストーリーポイント1をセットしても2倍になってしまう。タスク分割したのにストーリーポイントをゼロにセットするのもなんか違う
  • ストーリーポイントの数値からバーンダウンチャートを生成した (みえる化)
    • このバーンダウンチャートで運用して実際に2回の延期が発生し精度が低いことがわかった
      • 納期の2週間前に延期することがわかった
      • シニア開発者の勘と経験の方が精度が高かった

これらの事実から私の所感をまとめてみる。

  • 開発者と非開発者 (プロダクトオーナー) の業務を同じ数値で表して合算するのは論理的におかしい
  • 複雑な業務の開発プロジェクトでストーリーポイントの数値を設定するのは難しい
    • 複数のマイクロサービスを担当
    • 複数の技術領域を担当 (インフラ、フロントエンド、バックエンド、要件定義)
  • チケット駆動開発と相性が悪い
    • チケット分割は担当者がタスクを完了させやすい粒度や内容で分割すればよかったのがストーリーポイントを考慮すると複雑さが増す
    • チケットの粒度はチームで統一されているのが理想的ではあるが、現実的にそのような運用の統制が取れているのを私はみたことがない
      • チケットの粒度とストーリーポイントの合計に相関が出てしまい、それは個人差 (属人化) が生じやすい
  • 安易なみえる化による弊害がある
    • ストーリーポイントは開発の状況を表す指標の1つではあるが、現実をすべて表しているわけではない
    • 多次元的なパラメーターからストーリーポイントというただ1つの指標を用いて2次元にすることで他の情報が欠落する
      • 偏ったデータによる意思決定に使われる懸念がある (その情報を外部に発信していればとくに)

ストーリーポイントによる運用をうまくまわすにはいくつか制約があるように私からは思えた。

  • 開発プロジェクトのスコープや業務内容が一定の複雑さにおさめられる
    • 一定の制約や制限がないと論理的に説明可能な適切な数値を割り当てられない
    • 例) 外部要因に影響をうけない1つのマイクロサービスを開発する
    • 例) 開発者はフロントエンドだけの開発をする
  • 開発者と非開発者のタスクは別で管理する (合算しない)

メンテンナンス切り替えの設計

0時に寝て6時に起きた。

waf のカスタムレスポンス

メンテンナンス時にエンドユーザーがアプリケーションにアクセスできないようにしたい。いろんなやり方があるけど、どういった手段で対応するのが最もシンプルで運用も容易かを少し前から頭を悩ませていた。

当初は 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時に起きた。

もてなしだけではもう食えない

読み終えた。あとで総評を書く。

第10章 不動産屋の悪知恵

2000年に改正された借地借家法38条の「定期借家」の条項から賃貸契約には2種類あるらしい。

  • 普通借家
  • 定期借家

普通借家は契約期間更新の概念があり、借り主が契約更新を拒否するには「正当な事由」が必要になる。一般的な賃貸マンションなどの契約も多くのケースでこちらの契約になる。ここでいう正当な事由とは、建物が老朽化して立て直す必要があるとか、貸し主がそこに住むといったものらしい。一方で定期借家は契約期間が終了すれば、一旦契約は終了してから新たに再契約するといった段取りになる。この定期賃貸借契約の条件を満たすには、契約期間更新の定めがないことを説明した書面を交付する必要がある。その書面がない場合はすべて普通借家とみなされるという。その是非を巡って争った最高裁の判例があるらしくググるとすぐに出てくる。当事者同士で双方の合意があったとしても説明書面がない場合は無効とするような判例となっている。これを逆手に取れば、普通借家として契約更新を主張できるというストーリー展開になっている。

あとは PDCA サイクルのうち、日本の会社で一番弱いところはどこ?という話題が出てくる。Check だろう?という主人公の答えに、アドバイザーは Plan じゃないかと返す。Plan が曖昧だから Check できないという背景になっているのではないかと。一理あるかもしれない。日本人は気質として誰か1人が責任を担うのを嫌う文化があるように思う。個人の責任にしたくない・されたくないという空気から Check を曖昧にしたがる傾向があると私は考えている。

第11章 エピローグ

タイトルのままの章でホテル経営についてのアドバイスがあるわけではなく、ストーリ仕立てで展開してきた物語の結末や登場人物たちのその後のキャリアや展望などを紹介している。総じてハッピーエンドと言えるし、総じて人生の中のスナップショットとしてこんなもんとも言える。区切りがきてなんらかの結果が出たとしても、さらに人生は続くので日常が少し変わっていくだけといった展開になっていた。

あとがき

著名なホテルの総支配人と著者との対談がある。読んでいて関心をもてたところは Job Description (職務分掌記述書) の重要性が説かれている。適正な評価、公平な人事、採用にも必要とされる。この考え方はメンバーシップ雇用を長く続けてきた日本の会社の年功序列とは大きな違いがあるため、制度設計の見直しは時間がかかるのだろうと思える。過去のしがらみがない新興企業が新たに制度設計して台頭していくのがよいのだろう。

また外資系という言葉に抵抗感のあるスタッフに対して「トヨタやファーストリテイリングは外資系ですか?日系ですか?」と尋ねるという話題も出てくる。そうすると、外資系や日系というグルーピングに意味がないことに気付く。その違いを対談の中ではグローバルかノングローバルかの違いでしかないと説明されている。ビジネスの規模や競合をグローバルの視野で考える必要があるかどうかによって変わってくるという。

勝てる能力があってもその素地となる基礎体力がないと発揮できない。野球でも基礎体力があるから速い球を投げられる。

これもホテル経営に限った話しではないなと思えた。私自身、昨今の開発チームをみていて感じることでもある。クラウドでアプリケーション開発が簡単になったがために基礎がなく、スキルが低い開発者もメンバーの一員として働けるようになった。もちろん最初は誰もがそうだけど、適切な指導や教育を受けないとそのまま経験年数だけが経ってしまう。さらにそんな人が偶然リーダーになってしまうと 許される無知の範囲は開発経験年数に反比例する という現象が起きる。一定の水準を超えていない開発者がなにを作ってもうまくいかないのではないかと私は感じるようになってきた。私はそういったプロダクトを「ただ動くだけ」と呼んでいる。その後の拡張や保守に必要以上にコストがかかり、それが原因で将来の開発計画に支障をきたすこともある。そして、多くのケースでその状況を作った人はその後いないことが多い。

コーポレートファイナンスの入門

0時に寝て6時に起きて7時半に起きた。

ストレッチ

今日の開脚幅は開始前158cmで、ストレッチ後162cmだった。まだ右腰と右股関節、両腕の張りは少し残っているものの、先週末の田んぼ仕事の疲労はかなり抜けた。今週は暑くて家に帰ってきたらエアコンをつけてだらだらしていたのであまり数値はよくならないんじゃないかと思っていて、実際に開始前の数値はいま一つだったんだけど、ストレッチを受けたらいつも通りに戻った。トレーナーさんと雑談しているときにふと「毎日パソコンを使いますか?」と質問を受けた。トレーナーさんからプログラマーの自分にとってそんな質問をされるとは予想外で思わず吹き出して笑ってしまった。その質問は「毎日水を飲みますか?」と私にとっては同じですよと答えた。トレーナーさんも愚問だったと理解して一緒に笑ってた。

もてなしだけではもう食えない

第7章 ホテルが客を動かせ

ホテル側が自分たちの問題を解決するために客の行動を制御するといった展開になっている。米国のスーパーマーケットでは Express Lane という、購入品目が少ない客向けに手早く決済するためのレジが設けられているらしい。日本にはないのかな?この運用には客に学習コストを強いるのが欠点となる。キャパシティ問題の問題解決のアプローチは次の3つになる。

  1. キャパシティを増やす
  2. 供給を変える
  3. 需要を変える

本章の展開としては3番目の客側の導線や行動を変えてしまう方法で需要を変える手法が説明されている。本題ではないけど、さらっと出てくる説明にも納得感がある。ダメなホテルの共通点として、他社でうまくいった改善策、ベストプラクティスに飛びつき、それ以上考えようとせず、問題の本質を理解しようとしない。そういうホテルはコンサルタントが去ってしまうといずれでダメな経営に陥るとある。ホテルに限らず、ダメな会社の特徴だと思う。

客にピーク時の利用を避けてもらうための施策として次の2つがある。

  • 混雑することをあらかじめ伝えておく
  • 混雑を避けることのインセンティブをつける

ホテル側が客の行動をコントロールするのは構わないが、客にとってそれが不利益にならないように配慮する必要がある。人間の心理として混雑することがあらかじめわかっていればクレームにならず許容できたりする。人は不意に混雑に出くわして不満をもつことが多いという。そういった人の心理を利用して人の行動を制御して経営に生かすという考え方は比較的新しい研究領域である。行動経済学などもその分野の1つで、古典経済学では人は合理的に行動するとされてきた。しかし、現実では必ずしもそうではないことも行動経済学によってわかってきた。

第8章 リスクを知らないリスク

親会社の不動産会社からリスク管理報告書を提出しろという業務に沿ってリスクマネジメントについての話題が出てくる。契約の話しだったり、建築に関する話しだったり、あまり一般的な経営とは異なる内容にみえる。余談だけど、過去にうちの会社で業務内容が変わったにも関わらず、契約内容を更新せずに更新された新たな業務を継続してうまくいかなかった経験がある。うまくいかなかったときに原点に立ち戻る場所が契約であり、契約を曖昧に扱うと後でしっぺ返しがあるという失敗をまさに経験した。ふりかえりをするときにそもそもの基準が適切でないとその反省や改善点も曖昧になってしまうという話し。

さて、リスク管理報告書のアウトラインとして次の用語が出てくる。

  • ハザードコントロール
    • ハザードとは危険を生じさせるもののこと
    • ホテル経営だと、食中毒を防ぐ施策とか、横領できないように決済承認に2名以上必要とか
  • ペリルコントロール
    • ペリルとは事件・事故のこと
    • 起きてしまった事件・事故から最小限の損害・被害に食い止める施策
  • ロスコントロール
    • ロスとは事故発生時に発生してしまった経済的損失のこと
    • 具体的には保険購入であり、どんな保険にどのぐらいの補償額で加入するかになるが、これがなかなか難しい

peril という英単語の辞書を引くと、差し迫った危険という意味が出てくる。リスク管理の文脈の用語と英語の意味はやや違うのかもしれない。

第9章 タイムバリューを理解せよ

親会社に投資ファンドからホテルの買収提案があり、ホテルの事業価値を測るコーポレートファイナンスの話題が出てくる。上場企業であれば株価 x 発行済株式数で時価総額がすぐにわかるが、未上場企業の価値を査定するのは難しいという説明からその手法が紹介される。

  • 類似業種比準方式
    • 上場している同業者の株価を参考にする
    • 但し、ビジネスモデルを無視して業種だけで比較しようとしても単純比較はできない

不動産を所有しているかどうかで株式評価は大きく異なる。単純に不動産をもっていればよいというわけでもなく、資産と負債のバランスが取れているかが大事。「また貸し」のことを業界用語で転貸 (サブリース) と呼ぶ。

  • 純資産方式
    • 会社のもっているものを全部売って借金を返した残りのお金という評価方法
    • 貸借対照表の資本がマイナスになっているとすべてを換金しても負債が残る = 債務超過

株価の利回りを株価収益率 (Price Earnings Ratio: PER) と呼ぶ。時価総額 / 純利益で計算される。この計算式から時価総額を知りたければ、純利益 x PER で計算できる。比較可能な会社の PER がわかれば未上場会社の株価を計算できる。但し、PER は会社が未来永劫事業を継続させることを前提としている。会社の継続性に疑義があると PER を用いる根拠がなくなる。株主に説明するときの利益とは、正式には 税引き後当期利益 になる。この金額から配当がなされる。うちの会社だとざっくり粗利から20-30%ほど (法人税 + 消費税) 引いたものが税引き後当期利益になる。会社が予定する配当額は同じだが、株価をディスカウントすることで配当の利回りをよくするという考え方を リスクプレミアム と呼ぶ。会社の展望や事業の不確実性を数値化したとみなすことができる。

  • 株価1000円で配当額が20円だと、利回りは2.0%
  • 株価500円で配当額が20円だと、利回りは4.0% (この 2.0% の差がリスクプレミアム)

いま現在もらえる現金の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万円になる。本文の中ではこの金額が投資ファンドが提示している金額だとだいたい一致していることから、これ以上の精度の高いモデルを作らないといけないみたいなストーリー展開になっている。いずれにしてもパラメーターの変数の精度が高くないと適切なモデルとは言えない。割引率を用いた現在価値を計算する考え方を タイムバリュー (時間の価値) と呼ぶ。意思決定が遅れるほどプロジェクトの収益化も遅れるため、割引率を計算する現在価値が小さくなっていくという考え方ができる。