Releases: azu/book-review
給料―あなたの価値はまだ上がる/Fair Pay を読んだ
給料―あなたの価値はまだ上がるを読んだ。
原著はFair Pay: How to Get a Raise, Close the Wage Gap, and Build Stronger Businessesという書籍。
日本語のタイトルは給与交渉の話(個人)に見えるけど、実際に面白かった部分は報酬哲学や公平な給与をどう実現するかという話(組織)だった感覚がある。
なので、読んだ後に原著がFair Payというタイトルだったのみて納得した。
給料はあなたの価値なのかと合わせて読むと面白い本だと思う。
透明性が上がると結果的に格差は減ることが知られているが、透明性だけでは説明力が足りないなーと前から思ってた。
この本ではそこに"誠意ある給与(Pay Sincerity)"という概念を出していた。この概念の話が良かった。
賃金を増加させた時の試算
アメリカで最低賃金を$15に上げるという運動があってその話から始まる。
このときに$1賃金を上げるとどういうコストがかかるかの計算式が面白かった。
２０１９年にはアメリカに約８５００店舗を展開していたとあるので … スターバックスが、各バリスタの時給をきっかり１ドル上げるためには、以下のコストがかかる。
（１ドル）×（週25時間）×（年52週）×（バリスタ15 人）×（８５００店舗）＝１億６５００万ドル
一方で、最低賃金に変動があったからといって失業率が上がったり、物価が上がったりはしないという話。
実際の$15の戦いでもそういう結果になっていた。
あとになってみれば、最低賃金に現代史上最大の変動があったにもかかわらず、（パンデミック前の）失業率は低下し、物価は暴騰せず、ロボットがあらゆる雇用増大を阻むこともなかった。
誠意ある給与(Pay Sincerity)
この書籍で一番興味深いところだったかも。
給料はあなたの価値なのかでは、給与の透明性があると給料の格差(ジェンダーや色々な問題による格差)が減るという話があった。
一方で、透明性という言葉は開示だけで終わることがあり、そこに説明責任までは含まれないので、ガラスの天井のような問題は透明性があっても存在はすることがある。
これに対して、透明性を包含してるような概念として誠意ある給与(Pay Sincerity)という話が出てきた。
誠意ある給与とは、公平で透明性のある給与をひたすら追求し、人間らしい生活に必要なものを提供して、人々が自分の貢献と潜在能力に充分な報酬を求められるようにする手段のことだ。
理想的な誠意ある給与は、ブランド戦略のための試みや、１回試しただけで「完了」の印をつけて獲得できるような資格とはまったく違う。それは、企業が重要な給与情報の共有を歓迎し、時間をかけた改善と信頼構築に継続的で誠実な投資を行えるような環境をつくり、維持していく積極的な選択なのだ。会社の給与の支払いかたが間違っている、少なくとも給与決定が明確に伝えられていないと従業員が主張したときには、企業は忌憚のない対話の機会をもうけ、必要なら変更に応じなくてはならない。
誠意ある給与は、給与の透明性を超えるものだ。給与の透明性とはたいてい、給与範囲や公正に支払われた給与の集計結果など、企業のブラックボックスから取り出した基本的な情報を、きれいに整えて一方的に開示することをいう。給与の透明性は重要で、本書でも頻繁に取り上げるが、改善のための説明責任を課しはしない。給与情報が公開されたなら、見つけた問題にどう対処するかを学ばなくてはならない。情報があれば、人は自分の意志でよりよい会社や役割を選べるのだから、自然によりよい決定がなされるはずだという考えかたがある。そんなに簡単ならいいのだが──情報が何を意味するのかや、給与制度自体がうまく機能していない場合どうすればそれを操作したり改善したりできるのかを理解するには、手助けをしてくれるガイドが必要になる。
なぜ「誠意」という言葉を使うのか？
…
企業は、特に男女間や人種間の格差に対して、真剣に給与を評価することを意図的に避ける。なぜなら、評価作業をすれば法的に格差を見つけることが可能になり、賃金の問題が発覚した時点で変更しなければ責任を問われることを知っているからだ。しかし給与は、労働生活のなかで最もわかりやすく改善の余地がある部分なのだから、「尋ねない、言わない」という立場を受け入れてはいけない。
給与は一回きりの問題ではない(一度あげてそこで終わりではない)ため、継続的に話し合える環境そのものが大事だよねって話。
これ読んでいて、デュアルキャリア・カップルを思い出した。
デュアルキャリア・カップル――仕事と人生の３つの転換期を対話で乗り越えるでは、カップルの人生には次の3つの転換点があるという話が出てくる。
- 第一の転換期──どうしたらうまくいく？ 結婚数年後の転居や子供の誕生
- 第二の転換期──ほんとうに望むものは何か？ マンネリ化から生じる変化への衝動を感じる30代後半～40代
- 第三の転換期──いまのわたしたちは何者なのか？ 子供が巣立ち、仕事でもベテランとされる50代以降
第一の転換期は、子供 or キャリアチャンスで訪れることが多い。
このとき、短期的な経済基準で移住や離職などをすると片方の将来性に負荷がかかるため、経済バランスが崩れて戻すのが難しくなる。
復職しても37パーセントの収入減が待っている。子育ての真っ只中にいるときには、乳幼児期はひどく長いように感じられるが、40余年のキャリア全体からすればその割合はほんのわずかだ。一方、離職することによる経済的な損失の合計は生涯で１００万ドル以上にのぼると、さまざまな研究で算出されている。
-- デュアルキャリア・カップル――仕事と人生の３つの転換期を対話で乗り越える
短期的に処理すると取り返しがつかないので、長期的な合意にいたるまで話し合い、大きなライフイベントに慎重に対応する。
そうすることで、第二の転換期まで二人でたどれる道をつくる。
この話と “理想的な誠意ある給与” の話が結構似てるなーと思った。
報酬哲学
わたしが思うに、報酬哲学を持つことのあまり目立たないが重要な理由は、企業が競合他社の給与決定にどう対応するかを公に示すことだ。これをはっきり口にする企業はないが、報酬哲学は、自由市場に参加する企業の意欲に制限を設ける。企業は給与で他社と競争することに戦略的なメリットを感じていないことを忘れてはならない。
上場企業は、報酬哲学を公開している。あなたの会社が上場企業（つまり誰でも株式を買える）だとして、もし報酬哲学を公開していないのなら、この本をいったん置いて、「（あなたの会社名）proxy （直近の終了した年）」で検索してみよう。… 会社の報酬哲学が見つからなかったら、上司か人事部に訊いてみよう。こういう基本的なことさえ人事部に訊きづらいとすれば、転職を考え始めることをお勧めする
この報酬哲学の話面白かった
<会社名> Proxy <年数>で検索というやつで、Proxy Statementは日本だと株主総会招集のやつ。
これの取締役の報酬等の内容に係る決定方針あたりに書いてあるのでまず読んでみようねって話。
たとえば、株主総会招集 Yahoo - Google 検索で検索してみるとZ Holdingの2023年定時株主総会招集ご通知が出てくる
このPDFには”報酬ポリシー”という項目があって、ここに報酬哲学が書かれている。
大抵は役員報酬のポリシーになっている。
ここで、現存の報酬哲学すべてを要約してみる。会社の哲学をざっと読むと、表現は少し違うかもしれないが、次のような文章が見つかるだろう。「当社の報酬哲学は、戦略目標を達成するのに必要な人材を誘致し、つなぎ留めるために存在する」。
実際読むと大したことは書いてないんだけど、誠意ある給与(Pay Sincerity)を実現するには、これを公開するだけじゃなくて、知ってもらう状態にすることが大事という話が良かった。
他社のまねをして安全策を取るという現在のモデルでは、独創的な考え、進歩、説明責任という面から見て、多くのものを取りこぼしている。表現をくふうするうえで、企業によって多少の違いが出てくるだろうが、手始めとして、標準的なモデルを誠意ある給与を表す言葉と組み合わせてみた。
「当社の報酬哲学は、すべての従業員が生活に必要なものを手に入れ、公平で透明性のある給与の情報を得て、自らの貢献と潜在能力に対して充分な報酬を受け取れるようにすることによって、当社の戦略的目標を達成するのに必要な人材を誘致し、つなぎ留めるために存在する」。
法律が決まってるから公開されているんだろうけど、大体の人はそれすら知らないかもしれないので、知ってもらう状態になってより具体的な議論や行動が進む。
先ほども書かれていたけど誠意ある給与(Pay Sincerity)は一度きりのものじゃないので、継続的にやるにはトレーニングも必要という話があって、そのアイデアの話も面白かった。
全従業員を対象とした公正な給与のトレーニングプログラムをつくり、管理職や人事部用の上級モジュールも用意する。
・共通のガイドラインの範囲内で、必要に応じて管理職や人事部リーダーに給与を調整する権限を与える。
・給与範囲を公開し、従業員が自分の本当の同等集団と比べてどのくらいの位置にいるのかわかるようにする。
・賃金平等分析の数字だけでなく、賃金格差分析の結果も公表する。
・雇用方針や契約に含まれる時代遅れの（そしてたいていは違法な）給与の秘密保持条項を廃止する。
・社内の後援プログラムに、給与に関わる指導の責任を負わせる。
・ネットワークのセキュリティーホールを発見するためのチームと同じように、プロセスの偏りを根絶するための〝レッドチーム〟を編成する。
・差別や報復を心配する従業員のために、秘密にできる手段を用意する。
・厄介な倹約家の管理職を回避するために、中央での資金プール管理によって積極的に給与調整のための資金を調達する。
一度きりじゃないのは、維持しようと思って維持しないといつの間にか簡単に変化してしまうことがあるという理由がありそう。
たとえば、企業を買収した場合は大体はその企業が元々も持っていた給与体系を継承してしまうだろうし、給料はあなたの価値なのかでいうところの”模倣”や”惰性”が働くので、いつの間にか影響を受けてしまうことがある。
その辺の公正な給与のトレーニングを実際やってるところってどれぐらいあるのか気になる。
ノルウェー
ノルウェーは納税申告書が情報公開されているため、給与の透明性という視点での先行研究となってるケースが多くて面白かった。
ソフトウェアエンジニアの友人が、あるアイデアを持ってあなたのところへ来たとしよう。「給与のフェイスブック」のようなものを使うことに人々が興味を持つかどうか試してみたいらしい。… そして、他の人と比べて自分の仕事にどのくらいの価値があるのかがわかれば──つまり給与の完全な透明性があれば──賃金停滞と賃金格差というふたつの問題は解決すると思うだろうか？
ノルウェーは、似たようなことを試した。そして、どちらの問題も解決しなかった。
少なくとも１８８２年以来、ノルウェーの納税申告書は情報公開されていた。２００１年まで、ノルウェー人なら誰でも、地元の税務署を訪れて他人の公的な所得を見ることを正式に要請できた。２００１年以降は、オンラインで検索できるデータベースが登場したことで手続きがとても簡単になり、給与をのぞき見するのに税務署まで寒い思いをして自転車で行く必要がなくなった。短期間だが、サードパーティーの開発者が、フェイスブックのようなサイトで、そういうデータベースからの情報をまとめて、友人たちの収入ランキングを作成することもできた。ピーク時には、それらのサイトはユーチューブよりも人気があり、ノルウェー人は天気よりも納税申告書を検索しているようだった。
現在は匿名では見れなくなったり、商用利用はできなくなったりとか色々制限が入ったので、完全に自由には見れなくなってる。
けど、この自由に見れた時期でも賃金格差は完全にはなくなるわけじゃないという話(でも他の国に比べると格差がだいぶ小さい)
OECDが収集したデータによると、ノルウェーの男女間の賃金格差は７％だ。
これは公開してるだけであるので、透明性があるだけの状態と言える。
誠意ある給与(Pay Sincerity)を実現するには、この透明性に加えて、公平な給与のためにはどういう修正が必要かという維持する体制も必要になるというのはこの辺から来てるのかなーと思った。
絶対値ではなく相対値の給与での満足
このノルウェーで面白かった研究。
ノルウェーの税制についての研究によると、給与が人間の基本的要求を満たすのに充分である場合、同等者と比較した場合の給与額のほうが、給与自体の額よりも満足度を高める重要な要因になることがわかった。簡単に言えば、同等者と見なした人たちより自分の給与が高ければ満足で、低ければ不満を感じるということだ。この研究では、経済的に恵まれていない家庭のほうが、恵まれている家庭よりも、収入の透明化に反対する傾向が強かった。未払いの請求書や叶わぬ夢への思いなど、自分が他人と比べてうまくいっていないことを毎日思い知らされていれば、みんなに自分の給与のことを訊かれたくはないだろう。
- American Economic Association
- The Effects of Income Transparency on Well-Being: Evidence from a Natural Experiment - American Economic Association
この研究が色々面白い。
同等者と比較した結果に対しての満足度があるという話は、給与交渉というアクションに繋げるときに、自分が同等者のどのレベルでどのぐらいの給与をもらうのが一般的かという自身の位置を把握することの重要さとも繋がってる。
もう一方の経済的に不利な立場であるほど、給与の透明化には反対する傾向が強いという話も面白い。
これは書籍の最後にも出てきてたアーティストの話ともなんか似ている気がする。
「アーティストは自分の収入額を、観客に対しては少なめに言うが、友人に対しては多めに言う傾向がある
質問することで改善する
情報の非対称が雇用主と従業員には発生するので、質問をしようという話が良かった。
複雑さは常に、権力を持つほうに有利だからだ。賢い質問をされれば簡単にするしかなくなり、明瞭性と透明性、そして公正さへ向かう道の基礎が築かれる。
この賢い質問というのが日本語訳のタイトルにきてるところなのかなー
原著はFair Pay: How to Get a Raise, Close the Wage Gap, and Build Stronger Businessesというタイトルで、自分が読んだ感想はどっちかというこのタイトルだった。
交渉
これからやってくる世界で、給与の透明性が高まるのは避けがたいことだ。その世界では、賃金格差も許されないだろう。グーグルやマイクロソフトなど、とりわけ給与の高い多くの企業の従業員は、自ら行動を起こし、密かに自分たちの給与明細を集めて公開している。この傾向は今後も続くはずだ。「Blind」のような匿名で給料情報の交換ができるアプリや、「Levels.fyi」、「Salary.com」、「Glassdoor」のような公開サイトは、当初はデータの質が低いので報酬の専門家には敬遠されていたが、かなり精度が上がっている。企業は、説明責任が増して給与に関するきびしい会話が求められる新しい常識を受け入れる必要がある。
具体的にどう交渉するのかという話が結構書かれてた。
簡潔にまとめると自分の位置を知る、質問するという話だったと思う。
この位置の見つけ方が具体的に色々書かれて面白かった。
企業ベースのものと個人の申告ベースのサイトの違いとか、最近はLevels.fyiとかもデータとしての信頼性がだいぶ上がってるんだなーとか。
日本でもそういうのは増えていってる。
要約すると、必要になるまでＭＶＰの金額を教えてはならないということだ。
この辺の給与交渉のよくあるテクニック的な話もあった。
けど、そういうテクニック的な話の本として読むのはあんまり向いてない印象はある。
その交渉については4つの要素(Process/Permission/Priority/Power)があって、その戦略についても整理されている。
Contributors
Assets 2
情報セキュリティの敗北史 を読んだ
情報セキュリティの敗北史 by @azu #42
1950年ぐらいのセキュリティの歴史の話から始まって、1970年には「大規模なソフトウェアシステムにおいては、エラーや異常が完全にないことを検証するのは事実上不可能」という話があったのが面白い。
あと1970年にＰＲＯＳ（Provably Secure Operating System：証明可能な安全性を持つＯＳ）という形式的証明みたいなことやってたのも面白い。
科学では反証可能性で担保するが、セキュリティではそうなってない。
あるシステムは安全ではないと言うことはできるが、あるシステムは安全であると言うことは難しい(バグがないシステムは存在しない)。セキュリティでは、完璧に安全というものはないため、セキュリティの専門家でも反証可能性がない。
つまり何か絶対の正しさを持ったものはないので、セキュリティを実現する絶対的なものはない。
そのためリスク評価といった間接的な指標を使って意思決定している。(リスクが低い = セキュリティが高いだろうと)
ここを理解するのには経済学の逆インセンティブ、心理学的なものが重要という話よかった。
セキュリティは特定の問題を扱っても解決はできないので、システム全体の問題として見る必要がある。
セキュリティの技術的な部分は確かに技術だけど、セキュリティ対策という全体感で見ると必ずしも技術が得意じゃない人の方がリスク評価からの対策が上手いとかは普通にありそうだなーと思った。
これは、いわゆるセキュリティ対策を何から始めたらいいかわからない問題とも繋がっていそう。
何か絶対のものがあるわけじゃないので、これ対策しておけば良いわけじゃなくて、やるべきことは無限に出てきてしまう。
(やり方もボトムアップ、トップダウンどちらもある)
これを全部並べるとコストがリスクを上回って、本でも出てきたように逆インセンティブの問題が発生して対策を諦めてしまう。
これの考え方としてリスクマネジメント的な優先度を、リスク評価から決定していくのが良くある方法。
- エンジニアのためのリスクマネジメント入門：書籍案内｜技術評論社
- 「今日からセキュリティ担当、よろしくね」と言われたら、何から始める？ 何を重視する？――freee CISO 茂岩祐樹氏：ITmedia エグゼクティブセミナーリポート（1/2 ページ） - ITmedia エグゼクティブ
この絶対的なものじゃなくて、相対的なもの/間接的なものとしてセキュリティを評価していく話は実際そうだなーと思って読んでて面白かった。(9章)
売上高の「0.5%以上」、人の「0.5%以上」をセキュリティの予算とするという話もこういった間接的な評価から決めているのだと思う。
よかった章
- ６. ユーザブルセキュリティ、経済学、心理学
- ９.情報セキュリティの厄介な本質
が特によかったなー
フルディスクロージャーからレスポンシブル・ディスクロージャへの変化とか
インパクト投資 社会を良くする資本主義を目指して を読んだ
Amazon.co.jp: インパクト投資 社会を良くする資本主義を目指して (日本経済新聞出版) eBook : ロナルド・コーエン, 斎藤聖美: Kindleストアを読んだ。
インパクト投資入門は、そういう企業の紹介的な本だったけど、こちらの方は実践の仕方についての本だった。インパクト投資 = 計測という印象が強かったけど、まさにその話が多くて、パフォーマンス計測とかそういう話が好きな人は読むと面白いと思う。
なぜ測定するか
なぜ測定するのかという話が良かった。
次の3つの目的に大体集約されるという話。
- ●学びのための測定（Measure for Learning）
- 結果を知るため
- 経験のみに頼らないため
- ●行動のための測定（Measure for Action）
- 結果の性質がわかったら、それを改善する行動が取れる
- 意見を一致させるために
- ●説明責任のための測定（Measure for Accountability）
- 外部に対して説明
- 参加を継続してやるために
また測定対象は
❶測定は実行可能であるべきだ
❷測定は管理可能であるべきだ
❸測定は比較可能であるべきだ
というのもよかった。
これ自体は、パフォーマンス計測とか他の話でも結構利用できる概念。
何かを改善するときに、まずは計測から入るのがよくあることだけど(推測するな、計測せよ)、それを説明する感じになっててよかった。
ウェブサイトのパフォーマンス改善とかは、まさに測定対象をかなり意識するところからスタートしたりすることが多い。
遅いと感覚ではわかっていても、それが測定可能じゃない場合は改善が難しいという感覚がある。
測定とプロセス
社会的インパクト測定の実際的な狙いを説明する前に、測定のもっとも基本的かつ貴重な役割の１つを認識しておこう。すなわち、戦略や行動の指針となる共通のビジョンを作り出すという役割だ。測定プロセスは、インパクトについての考え方に問いを投げかけ、精査することでその役割を果たす。どの測定方法が測定内容をもっともうまく表せるかについて意見の一致を見るためには、まず、測定内容そのものをどのように理解するかについて合意しなければならない。有益な測定は、何が測定されているかという明確な理解を前提としている。組織が測定システムを構築しようとしたときに初めて、測定によって表される現実世界について関係者の考え方が異なることがわかったという例もあるのだ。
たとえば、女児に教育を受けさせる活動をしている組織の理事全員が、組織の第一目標は「エンパワーメント」であることに合意したとする。だがそのエンパワーメントをどのように測定するかについて意見を求めると、何をもってエンパワーメントとするかについて理事一人ひとりの考え方が大きく異なることが判明する。教育を修了する女児の数と言う理事もいれば、妊娠や結婚の年齢が上がることと言う理事もおり、また別の理事は家以外の場所で働くことを重視し、さらに別の理事は家庭内の意思決定への参加が最高の測定基準だと言うかもしれない。
インパクト測定システムの構築プロセスは、こうした考え方や価値観の違いを浮き彫りにし、その違いを乗り越えて組織のインパクト目標に向けた共通のビジョンを作り出す機会を与えてくれる。実際、このプロセスが測定そのものよりも貴重な機会にさえなり得るのだ
- 測定プロセスそのものが行動に影響するというのはかなり面白い
- 実際にJavaScript Primer 改訂2版をリリースしました！/JavaScript Primerはなぜ更新され続けるのか？ | Web Scratch書いてて、測定について考えていてたけど、目的とかを改めて考え直す機会になってた。
ゴールを明確にする
セオリーオブチェンジの話はちょっと難しくてよくわからなかったけど、分析手法に出てきたロジックモデルの手法は参考になった
基本的なロジックモデルは５つの要素で構成される。
●インプット（投入）はプログラムに対するリソースと制約の両方を含む。リソースはプログラムが活動にあたって使うもので、人材や資金、物、文化などが含まれる。制約は組織の内外の制約であり、活動地域の法規制や資金不足もここに含まれる。プログラムはリソースを活用し、制約の範囲内で最大限のインパクトを生み出そうとする。
●アクティビティ（活動）はプログラムまたは取り組みを実施するために取る行為で、プロセスや事象、行動が含まれる。プログラムはリソースを使ってアクティビティを実施し、目標とする成果を達成しようとする。アクティビティは、プログラムのために計画された作業だ。
●アウトプット（結果）は組織の活動による直接の結果であり、成果物だ。アウトプットには受益者に提供される製品やサービス、投資対象やその他完了したプロジェクトへの継続的支援も含まれる。
●アウトカム（成果）は投資対象に直接およぶ効果で、インパクト目標を達成するために必要なものを指す。これは投資対象の行動、態度、能力、または特定の社会的・環境的変動要素に対してプログラムが直接的におよぼす影響だ。成果は１年から３年で達成される短期的成果と、４年から６年で達成できる長期的成果に分けられることもある。 ●インパクト（社会経済的変化／波及効果）は社会的組織の最終目標であり、社会問題に対する体系的かつ基本的な進歩だ。インパクトは、そもそも組織がなぜ存在するかというその理由の根幹を成す。
- JavaScript Primer 改訂2版をリリースしました！/JavaScript Primerはなぜ更新され続けるのか？ | Web Scratch
- この記事を書きながら、ロジックモデルを書きながら、目的とアウトカムを整理していくと、何を測定しないといけないのかが少し出てきて面白かった
- 具体的には、コードの実行回数というメトリクスを取るとは、この整理をするまで思いつかなかった
- ロジックモデルの書き方は次を参考にした
- https://simi.or.jp/tool/logic_model
- https://www.jica.go.jp/priv_partner/announce/ku57pq00002avzzc-att/ve9qi8000000f7sz.pdf
- 文字よりフロー図の方が向いてたので、図には https://www.mermaidflow.app/ を使った
測定手法の分類
測定手法は、４つの基本的な区分に分けられる。専門家の判断、定性的調査、定量化、そして貨幣化だ
●専門家の判断──経験豊富な専門家によるプログラムについての議論や観察。
●定性的調査──社会的インパクトについての体系的かつ徹底的な調査で、現場視察や構造化インタビュー調査、フォーカスグループなどを含む。
●定量化──数値の形でのデータおよび報告。直接測定だけでなく、インタビューへの回答も含む。
●貨幣化──測定されたインパクトの一部またはすべてを貨幣価値に換算する定量的評価
- 評価の測定手法についてはかなり専門的
- 統計統計してた(ランダム化比較試験とかデータ分析とか)
- NPOとかでもかなり専門的な知識がいる感じがした。
- この辺の専門性が増えてくるのはBill Draytonの言っていたsocial entrepreneurshipにおける社会的企業的な話とも一致するので面白かった
- 寄付研究や慈善活動について研究するために色々な書籍や論文を読んだメモ書き | Web Scratch
- 社会的投資収益率（SROI）という貨幣化での評価手法を知れたのがよかった
社会的投資収益率（ＳＲＯＩ）
社会的投資収益率（ＳＲＯＩ：Social Return on Investment）はよく知られた貨幣化技術の１つで、この手法を最初に取り入れたのはアメリカのベンチャーフィランソロピー《ロバーツ・エンタープライズ開発ファンド》（ＲＥＤＦ）だ。ＳＲＯＩの狙いは社会的投資が生み出せるリターンを評価するところにある。企業投資により期待される、あるいは実現する金銭的利益を評価するために用いられる投資収益率（ＲＯＩ）と概念的には似たものだ。ＳＲＯＩの計算方法はいろいろあるが、一般的にはプロジェクトが生み出すインパクトを、投資された金額で割る方法で算出される。ＳＲＯＩが大きければ多いほど、１ドル当たりのインパクトは大きい。ＲＥＤＦのＳＲＯＩフレームワークは、構築された当初には６つの主要な測定基準で構成されていた。企業価値、社会目的の価値、複合的価値、企業収益指数、社会目的指数、複合的収益指数（※８）。それぞれの価値が算出され、10年という期間について割り引かれる
- JavaScript Primer 改訂2版をリリースしました！/JavaScript Primerはなぜ更新され続けるのか？ | Web Scratchで、インプットである時間をお金に変換して必要なリソースを計算するアイデアもここからきてる
- 何かの本でCSRとかCSVを測定して投資にあってるかを公表してる会社があって面白かったなーという記憶があったけど、これがSROIという手法なんだなーと理解した
- 決算書ナゾトキトレーニング 7つのストーリーで学ぶファイナンス入門 (PHPビジネス新書) | 村上 茂久 | 実践経営・リーダーシップ | Kindleストア | Amazon この本だったらしい
- 国内初、環境保全プログラムにおける社会的価値の算出～「ＳＡＶＥ ＪＡＰＡＮ プロジェクト」の3年間の活動成果を見える化～ | 【公式】損保ジャパン
- 多分これだったんだと思う(なんの本で紹介されてたのかは思い出せない)
インパクト投資とリターン
投資に対するリターンは、ざっくり４つのカテゴリーに分けられる。アイデンティティのリターン、プロセスのリターン、金銭的リターン、そして社会的インパクトだ。
- インパクト投資は、一応金銭的なリターンを目的とすることもできるけど、そのリターンは普通の株式などに比べれば時間がかかるし金額も大きくはない傾向はある。
- それでもなぜ投資するのか?という話
インパクト投資の旅路を進むなかでつい見過ごされがちだが実は重要な要素が、投資の動機を理解するということだ。これこそ、意図に合った成果を確実に得るための第一歩だ。自分は何者なのか？ 何を一番大事に思っているのか？ 何をもってすれば、自分の投資は成功したと言えるのか？ そして何を投資するのか？
- 金以外のリターンがあるからで、それが見える形 = 測定されたものじゃないと、投資側も何に投資していいのかわからないという話は結構納得した。
- ロックフェラー回顧録でも、何に投資(寄付)するべきかというのは実際専門家がいて、普通の仕事以上の労力がかかってる感じだった
- なので、測定にはコストはかかるけど、測定する価値はあるし、実際測定しようと思うと目的とかを結構整理する機会になって面白い。
- Release Working in Public を読んだ - azu/book-review で書いてたけど、オープンソースもかなり近い文脈を持ってるので、色々と学びがあった
Working in Public を読んだ
Working in Public
Working in Publicは、オープンソースの開発とメンテナンス、資金についてよく調べられた書籍です。
ここでのオープンソースは主に GitHub 以後に焦点を当てて書かれていた気はします。
オープンソースのアマチュア化
GitHub から始めた世代は、Open Source と Free Software のような違いのような部分に強い問題意識を持ってるわけではなく、ただ作りたいものがあって GitHub が便利だったから使ってるという話。
これを「オープンソースのアマチュア化」と呼んでるのが面白かったです。
特に JavaScript は、npm の小さなモジュールが多いため、この「オープンソースのアマチュア化」が進んでいるという話もありました。
JavaScript で有名な開発者は、Linux の Linus のように有名なプロダクトを紐づけて知られているのではないケースも多い。
たとえば、Sindre Sorhus や Kent C. Dodds のように特定のプロダクトというよりも、その人自体で有名になっているケースが多いという話。
オープンソース 「プロジェクト」
オープンソースコードじゃなくてオープンソースプロジェクトと呼ぶのは、コードだけではなく、コミュニティ、コード、コミュニケーションツール、開発者ツールの組み合わせ全体を指すという話。
これは確かにと思った。自分が OSS じゃなくてオープンソースと言うようにもなったもの少しにた感覚から来てます。多分扱う範囲が広がっているんだと思います。
オープンソース
タイトルを OSS からオープンソースに変更したのは、Software じゃないこともオープンソースでやることが増えているというのもあります。
-- 今年のオープンソース活動振り返り @ 2020 | Web Scratch
オープンソースプロジェクトの分類
Node.jsを例にして、オープンソースの成熟への段階として次の3つがあるという話がありました。
- CREATION
- EVANGELISM
- GROWTH
Growthまでくるとアクティブユーザーが多くなり、プロジェクトはユーザー支援に時間がかかるようになるという話。
また、ユーザーの増え方とコントリビューターの増え方によって、オープンソースプロジェクトを次の4つのモデル分類できるという話もありました。
| High User Growth | Low User Growth | |
|---|---|---|
| High Contributor Growth | Federations(e.g. Rust) | Clubs(e.g. Astropy) |
| Low Contributor Growth | Stadiums(e.g. Babel) | Toys(e.g. ssh-cat) |
これがだいぶ面白い感じで、それぞれのモデルで次のような特徴がある。
- Federations: ユーザーも多く、コントリビューターも多い
- RustやNode.jsなどの言語に近いレイヤーに多いモデル
- n:nの構造になってる
- Stadiums: ユーザーは多いが、コントリビューターは少ない
- webpack、Babel、Bundler、RSpecなどユーザーは多いが、開発者は少ないモデル
- 1:nの構造になってる
- ユーザーからコントリビューターになるときのコストが高い(そもそものユーザーが多い)ため、コントリビューターが増えにくいという問題があります
- また、知識を外部化せずに長く続けるほど、新規参入が難しくなります
- Clubs: ユーザーとコントリビューターが重複してる
- ニッチな分野のツールに多く、ユーザーがコントリビューターであるケース
- ユーザーの増加率が高くないが、コントリビューターが多い(相対的に)
- Toys: おもちゃ的なもの
この4つのモデル間での行き来はできるので、ClubsだったものがStadiumsになったりもする。
コンセンサス
コンセンサスという言葉はオープンソースプロジェクトでよく見るようになったけど、これが機能するにはコントリビューターがある程度いないと機能していないという指摘が良かった。
具体的な例としてはLernaのICEライセンス問題で、スタジアムモデルだと「コンセンサス」はあってないようなものであるという話
コンセンサスを求める モデルは、連合であろうとクラブであろうと、より大きな貢献者コミュニティを持つプロジェクトで機能します。これらのコミュニティでは、メンバーシップの強い感覚を育むことが依然として可能であり、それは社会的規範、規則、および新規参入者が黙認することが期待される制裁につながります.
しかし、スタジアムなどの集中型コミュニティには、分散型 コミュニティ のようにアクティブな「メンバー」がいません。積極的に関与する人が少ないことを考えると、スタジアムはコンセンサスを求めるものよりも「慈悲深い独裁者」の統治モデルに適しています。
これは確かに、少人数だとコンセンサスはコンセンサスでもないなーとは思った。
メンテナンスとコスト
オープンソース開発者の仕事は、作成の初期費用を超えています。開発者はものを作り、作ったものを共有せずにはいられないかもしれませんが、そうするたび に、そして成功を見つけるたび に、小さな目に見えない時計が 動き始め、彼らはケアと給餌を管理する任務を負っています。永久に。
ソフトウェアの配布はzero marginal costなので、いくら利用者が増えてもほとんど無料で配布できるという特徴がある。
そのため配布したら、そこからは初期費用よりずっと上がり続ける特徴を持っているという話。
大規模なオープンソースプロジェクトが 成長するにつれてモジュール化される傾向があるのは、メンテナンスのコストと、メンテナンスに対する本質的な動機の欠如が相まって
この対応として、オープンソースプロジェクトはモジュール化される傾向がある。
RailsとMerbの統合やBabelのプラグインなどはこれにあたるとおもう。
静的コードは時間の経過とともに変化しませんが、アクティブな状態のコードは依存関係、つまり一緒に実行される他のコードと密接に絡み合っています。
……
時間が経つにつれて、コードはその依存関係と同期しなくなり、それらの依存関係の新しいバージョンと互換性がなくなります。コードが変わらなくても、その周りのすべてが変わります。 5年間 触れられていないコードは、開発者がコンテナーやエミュレーターなどのツールを使用して正確な状況(開発者の環境とも呼ばれます)を再現しない限り、最新のマシンでは更新なしでは実行できません。 開発者は依存関係の古いバージョンを使い続けることを選択するかもしれませんが、それらの依存関係を更新すると、何かが壊れて、すべてを一緒に実行するために変更が必要になる可能性があります。
これ結構好きな話。ソフトウェアのコード自体は変化なくても依存関係があると勝手に壊れることがある。
そのため、依存関係があると脆くなるが、一方で依存がモジュール化されていると交換がしやすいという特性を持つようになる。
あるプロジェクトをやっていると評判という形で外因性の報酬を受け取ることがあるが、プロジェクトが成熟すると評判のメリットが横ばいになり、義務感やコミュニティの側面が強くなっていく。メンテナーはそこに新たな価値を発見/分散/タスクを減らす必要がある。困難な場合、辞任か代わりを見つける
成長段階ではプロジェクトのメンテナーとしての名声はあるが、成熟してくるとそこが一定になっていく。
一方でユーザーは増え続けるため、コストは上がっていくという構造の問題についての話。
また、メンテナーが利用可能なattentionは有限なので、それをどうやって管理するかというパターンの話も良かった。
- 初期費用を減らす: CI/Bot/Lint/Check List
- 利用可能なattentionを制限する: Issueを閉じる
- コストの分配: モデレーション、ユーザーサポートを任せる
- 利用可能なattentionの総量を増やす: コントリビューターを増やす、収益を増やす
オープンソースにおけるお金の役割
この本を読もうと思った理由でもあり、この本が書かれた理由でもある。
cURLの話、Trivagoがwebpackのスポンサーしたら何故かそれを理由に求人への応募が増えた話など色々。
Homebrew の主任開発者で あるMike McQuaid が 「ステッカーマネー」 の問題と呼ぶものにつながります。つまり、開発者が熱心に消費するステッカーなど のマーケティングスワッグに支払うには十分なお金ですが、仕事を辞めて仕事を辞めるには十分なお金ではありません
この話が特に面白かった。
個々の開発者は、企業とは異なり、オープンソースコード に直接お金を払うのではなく、コード の背後にいる人々に資金を提供する可能性が高いようです。これは、プロジェクトの依存関係ではなく、メンテナーの評判によるものです。長期的には、1人のメンテナが プロジェクトから降りない場合 ( これは今日よくあることです )、継続的なメンテナンスを価値あるものにするために別の報酬が 必要です。コンテンツクリエーターの典型的な報酬は評判の向上であり、それを注目 (つまり視聴者)に変えることができます。クリエイターが 何かを作り続けたいので あれば、その関心をお金に変える方法を見つけます。スポンサーは、今日のオンラインクリエイター向けの新たな資金調達システムですが、「寄付」 の概念と混同されることがよくあります。スポンサーは利他主義によって動機付けられるのではなく、現在の評判に基づいて、クリエイターの将来の仕事をフォローすることに関心が あることによって動機付けられます。寄付というより、サブスクリプションのようなものです。個人が オープンソース開発者のスポンサーになる場合、理想的にはコードにお金を払うのではなく、コードを書いている人をより身近に感じることができます。
コードやライブラリといったオープンソースのプロジェクトに対してお金を払うというよりも、そのメンテナーに対して支払うという傾向があるという話。
先ほどもあったけど、プロジェクトのユーザーが多くなると、評判は一定になるけど、プロジェクトメンテナンスのコストは上がっていく。
なので、そのプロジェクトのメンテナーが新しい評判を作るのが難しくなって、止まってしまうという問題が指摘されていた。
このサブスクリプション的にその人を支援する形式だと、支援された人が新しいものを作るインセンティブ(より評判を集めるため)になるので、より創造的なものを継続的に作る仕組みになって良いのではないかという話。
これは、最初のアマチュア化とも関係しているなーと読んでて思った。
特定のプロジェクトではなく、特定の人のファンが増えているという現象とも繋がっている感じがした。
📝 NAISTのGitHub Sponsorsの利用を調査したレポートによると、GitHub Sponsors利用者のうち約80%の人は1か2人をスポンサーしている
プロジェクトベースじゃなくて人ベースであるのは、プロジェクトに縛られないという点で、メンテナーにとってはいい点も多いとは思う。
プロジェクトベースだとメンテナンスが強くなりがちだけど、人ベースなら新しいものを作ってみるとかもやりやすくなる。
自分もプロジェクトに縛られすぎないようなことは考えてGitHub Sponsorsやってるのでこの辺の話はだいぶ面白かった。
一方で、誰でもこの状態になるのは難しいよねって話もあった。
また、あまりにもオープンソースプロジェクトは多すぎて、だれを支援すればいいのかわからないという問題もある。
資金提供者が オープンソースに資金を配分するという考えを受け入れたとしても、すぐにその機会に圧倒されてしまう可能性が あります。1回の依存関係チェックで、何百ものオープンソースプロジェクトを取り込むことができます。機関投資家であろうと個人投資家であろうと、資金提供者はどこに努力を集中すべきかをどのように知っているのでしょうか?
これが読もうと思ったきっかけのcore-jsの話とも似ていて、特にJavaScriptは依存関係が膨大で誰を支援するべきかわからなくなるような問題がある。
自分が依存してるライブラリのメンテナーのSponsorできる選択肢をhttps://github.com/sponsors/exploreで見れるが、膨大な数が出てくる。
なので、実際にスポンサーできる選択肢が多すぎると、どれをサポートすればいいのかわからなくなってしまうという問題は実際にあると思う。
この問題に対しては、「ハイコンテキスト、ローディスカウントレート」を取るのがいいのではという話だった。
オープンソースの資金調達の機会を精査することになると、「ハイコンテキスト、ローディスカウントレート」の機会を求めるという Ostrom の原則がうまく機能します。使用するすべてのオープンソースプロジェクトに資金を提供するのは、企業や個人の仕事ではありません。(…省略…)1 人の開発者が 毎日何千ものオープンソースプロジェクトに依存して仕事をしているのに、それぞれの給与を個人的に賄っていないことは問題ありません(気が遠くなるようなことですが)。しかし、彼らが たまたま気に入った特定のプロジェクトがあれば、それを追求すべきです。同様に、オープンソース開発者の仕事は、大海を沸騰させるのではなく、対象となる一連の資金提供者の頭に浮かぶようにすることです。
一つ例として出していたのは、無料で公開してる本のアクセスを調べてみたら、特定のサイトからのアクセスが多かったので、そのサイトの読者に向けて本を売るという話だった。
Practical Typography という人気の本を書いた Matthew Butterick も、一部の読者をターゲットにすることで 成功を収めました。マシューは自分の本をオンラインで 無料で 提供していますが、お金を求めて「絶え間なく物乞いをする」ことで 本を塗りつぶしたくはありませんでした。365 彼の無料トラフィックの多くが わずか 15 から 20 の Web サイトからのものであることに気づいた後、彼はそれらの Web サイトからの訪問者のみをターゲットにすることに決め、彼らが 本にお金を払うことを提案しました。その結果、その年に直接支払いの数が 2 倍になり、年間60 万人以上の読者に無料で 本を提供し続けることが できました 。
core-jsやferossがかつてやっていたターミナルに広告を出すという手法は「ハイコンテキスト、ローディスカウントレート」ではなかったのが、うまくいかなかった理由なのかもと思った(ハイタッチな人を選んで出す仕組みになっていれば、フラストレーションはもっと低くしつつうまくできたのかもしれない)。
または、core-jsのような依存の依存のようなライブラリだと、そもそも使ってることを意識しないのでハイコンテキストとするのが難しいのかしれないと思った。
長々書いてしまって色々飛んだけど、詳細はStripe Press — Working in Publicを読みましょう。
大きく分けて、いわゆるプロジェクトのメンテナー的な深く専門的な方向(プロジェクトとして支援される) と もっとカジュアルで新しいものを創造する方向(人として支援される)の2つがあるよねって感じ。
これをダンベルというのが面白かった。(凹 みたいな形になるからだと思うけど。)
(これと同じような話は、ジャーナリズムなどのニュース業界でも起きていたりするという話も面白かった。)
どちらの場合でも、普通の仕事と同じ金額を稼いでも同じではないという問題はある。
普通の仕事とは違って、保険がなかったり、税金的な部分が異なるので、同じ金額を得ても同じ負担にはならないという問題。
そのため、フルタイムのオープンソースメンテナーになるには、色々ハードルがある。
けど、最近Open Source Collectiveが、プロジェクトの資金を使ってメンテナーを雇用できる仕組みを実装したので、この辺の雇用的なハードルも変わってくるかもしれない。
内部告発のケーススタディから読み解く組織の現実 改正公益通報者保護法で何が変わるのか を読んだ
内部告発のケーススタディから読み解く組織の現実 改正公益通報者保護法で何が変わるのか by @azu #35
Amazon.co.jp: 内部告発のケーススタディから読み解く組織の現実 改正公益通報者保護法で何が変わるのか eBook : 奥山 俊宏: 本
公益通報者保護法を抜本的に改正する新しい法律が２０２０年６月に制定され、２０２２年６月１日に施行されるのを機に、この法律を含む日本の内部告発者保護法制とその背景にある考え方、いわばその理念や思想について、具体例に照らしつつ明らかにしていこうと意図してこの本をとりまとめた。
新しい公益通報者保護法のバックグランドについて詳しく解説してる書籍。
いろんな国の事例とか、過去の日本で起きた問題を汲み取っていて面白かった。
- 内部告発の事例を紹介してから、実際の法案とケースの対応を見る感じだった
- ケースが長いかなと思ったけど、法案との対応の話は面白かった
- オリンパスは内部告発の問題を大量に含んでいてすごかった
今まで、通報者の特定を漏らしても結局罰則はなかったので、これを漏らしてしまう事例が過去にたくさんあった。
改正されたものだと、通報者を特定させる情報の守秘を義務づけられ、違反すると個人として刑事罰に処せられるという形になってる。とにかく過去の事例がすごくて、それを汲み取った法案なんだなーというのがわかって面白かった。
常時使用する労働者の数が300人を超える事業者は、本法第11条により、内部公益通報に応じ、適切に対応するために必要な体制(内部公益通報対応体制)の整備その他の必要な措置をとることが義務付けられました。
https://www.caa.go.jp/policies/policy/consumer_partnerships/whisleblower_protection_system/faq/faq_001/
あと300人より多いの会社は、内部通報の体制を整備することが義務になってるの知らなかった。
(300人以下は努力義務)
伴走型支援: 新しい支援と社会のカタチ を読んだ。
伴走型支援: 新しい支援と社会のカタチを読んだ。
『生活困窮者自立支援のための中高年齢化するひきこもり者とその家族への支援ハンドブック』の"本人の「生きる」と, 支援者の「わたし」"という明石さんのコラムがすごくよかった。
このコラムは「ひきこもり」の話ではあるけど、他の状況でもよく起きる現象だと思う。
支援する人はソリューションを提供して、実際にその問題は解決する可能性はあるけど、支援された人は同じような問題に対処できないという状況をみる。
また、ソリューションだけ提供しても、実際に手を動かす人が別だと手を動かすところまで行かなくて、結局問題を解決できてないという状況もある。
たとえば、あるチームで開発するサービスでNode.js 12はEOL(End Of Life)でサポートが切れるので、Node.js 14へアップデートしないという問題があったとする。
この時に、Node.js 14にアップデートする解決方法を力を少し入れればできる人（「わたし」のような人)はできて、そこで問題は解決したように見える。
けど、Node.js 14のEOLが近づいてきた時に、次のバージョンへアップデートできてなかったという同じ問題がまた発生するという状況。
この時に「問題」を「解決」したい「わたし」は、その問題解決の方法や段取りなどの仕組みばかり見てしまって、
そもそもなんでそのチームでアップデートできなかったのかとかが置いて行きぼりになりやすい。
これは、問題を解決するというソリューション型のアプローチの成果が問題の解決となっているため、問題が複雑化するほどこのアプローチをとる「わたし = 支援者」に負荷が集中していく。
その結果、支援者のバーンアウトリスクが高くなりやすい。
一方の伴走型支援における「成果」は、つながり続けることでもあり、「問題は解決しなかったがつながっている」は成果でもという違いがある。
支援者はソリューション型と伴走型の両方の支援方法を組み合わせるのがいいんじゃないという話。
この話は書籍だと"第７章 日本における伴走型支援の展開（原田正樹）"が描かれてる図がわかりやすいやつ。
同じ話は、次の動画で話されてる。
このNode.jsのアップデートの例でいえば、支援者がNode.jsのアップデートの仕組みを作るというのはソリューション型のアプローチ、
一方で、支援者がNode.jsのアップデートについての相談にのるといった繋がりが伴走型のアプローチ。
どっちがいいという話ではないけど、両方とも目的としてはそれぞれのチームが自分たちでNode.jsのアップデートができるようになることというのは同じだと思う。あと、この話になるとカルチャーを作るみたいな話になることもある気がするけど、カルチャーって本人が不在になりやすいのかなとは思った。
バーンアウト関係で、もう一つ面白い話としてあったのは"第６章 越境する伴走型支援（大原裕介）"であった伴走する人を伴走するという話。
ソリューション型の方が負荷が集中しやすいとは思ったけど、伴走型も負荷はあるわけだしずっとは続かない。
そのため、伴走する人を伴走するみたいなややメタっぽいのは現実的にいるんだろうなーとは思った。
"第10章 伴走型支援がつくる未来（村木厚子）"のここがよかった。
私は，中央大学の須藤修先生から「ゼロを1にするのは現場の仕事、必要に気づいて最初に対応するサービスを生みだす。1を10にするのは学者の仕事。新しく生まれたサービスの理論武装をする。10を50にするのは企業の仕事。ニーズに応えて，ペイする範囲でサービスを供給する。50を100にするのは行政の仕事。もし，本当に必要なサービスならばペイしなくても，誰もが使えるよう制度化する」と教えられました
これは、寄付研究や慈善活動について研究するために色々な書籍や論文を読んだメモ書きとか誰も断らない こちら神奈川県座間市生活援護課とかでも断片的に出てきた話ではあったけど、それを繋いだ感じがしてよかった。
この文だと0から100の一方向に見えるけど、実際には100の次にはまた新しい0があるので、100の隣には0があるイメージなのかなとは思った。
伴走型支援: 新しい支援と社会のカタチは物理本しかないので、久々に物理本で読んだけど面白かった。電子版が欲しい。
Open SourceでもContributorを増やすためのContributorを増やす(Contributor for Contributorと呼んでる)にはどうすればいいのだろう?と考えることが多いので、結構参考になる話が多くてよかった。(Open Sourceも0-100ならどの立ち位置なんだろなーとかも考えていた)
Maintainer MonthもContributorを増やすためのイベントだと解釈してMaintainer Month: オープンソースをメンテナンスするコツ | Web Scratchとかを書いていた。1Password for Open Source Projectsの申請をしたとかも、メンテナーを支援する何かがあるときに結局それが使われないと意味ないので、こういうのは積極的に使ってるというのもある。
誰も断らない こちら神奈川県座間市生活援護課
神奈川県座間市の生活援護課を舞台にした書籍。
めちゃくちゃ面白かった。
健康で文化的な最低限度の生活とかも似た話である。
社会的な問題と未知の問題は重なり合う
コミュニティ・オーガナイジングとかでも、社会問題は往々にして社会的にパワーのない人のところに集まると話があった。
これと同じように、市場的なニーズがまだはっきりしてない部分 かつ 政府がまだ扱ってない部分 には社会的な問題が多く存在している。
その問題領域には、何かはっきりとした解決方法(プロダクトや専門領域)があるわけでも、法律のような制度がないような未知の問題が集まる部分がある。
この本でも、まさにそういう間の領域にある社会的な問題が多く出てきなーという感じでそこが面白かった。
言葉を選ばずに言えば、武藤や吉野が関わる困窮者には〝面倒な人〟が少なくない。第１章の志村やペドロのように、自立の意思があり、その実現に向けて前に進める人はそれほど多いわけではない。中には、意思疎通に苦労するような相談者もいる。その中で、武藤が自立相談支援を続けているのは、困窮者支援がＡでもＢでもない「新しい領域」だから
とか
第２章で触れた大島も、相談者に心ない言葉を投げかけられて、月に一度は落ち込むという。それでも続けているのは、困窮者支援がゴールのない仕事だからだ。 「一般的な仕事であれば、経験を積めば積むほど知らないことはなくなっていきますが、この仕事では、相談が来るたびに新しい課題が次々に出てくる。
とか
はたらっく・ざまの岡田も、初めて会った時の林の一言を覚えている。 「制度を作り、仕様書の通りに運用しても、必ずこぼれる人が出てしまう。そういう人を救うために、制度を柔軟に運用しなければダメだと考えています」
あらゆる制度がそうだが、制度はその制度ができた瞬間に、条件に当てはまらない人が生まれてしまう。もちろん、制度は必要不可欠なものだ。生活保護の利用について、所得や資産で区切らなければ制度として機能しない。身体障がいや精神障がいの障がい等級がなければ、誰にどれだけの年金を支払えばいいのかもわからないだろう。制度の利用条件や範囲を決めなければ、行政サービスを提供することはできない。 ただ、現実を見れば、ある制度の利用条件に当てはまらなくても、その制度を必要としている人は存在する。法律や制度を作った時と、目の前の現実にずれが生じることもよくある話だ。
といった話が出てきて、実際にその領域で出てきた事例を見れたのがよかった。
コミュニティの力： 市場経済における非営利組織（NPO）の機能という論文では、この未知の領域を扱うのがコミュニティであり、NPOなどがここに当たるという話だった。
この書籍は、座間市役所の生活援護課が舞台の話であるけど、こういった問題を市が全て解決できるわけでもない。
なぜなら、衣食住だけじゃなくて仕事とか孤立とか死後とかかなり幅広い問題が重なり合ったのがものが問題として出てくるので、全ての問題を1つの団体で解決するのは相当難しい感じがする。
そのため、NPO法人ワンエイドとかはたらっく・ざまなどのNPO法人と連携して問題の解決に当たるという窓口の役割をちゃんとしていてすごくよかった。
自治体直営の場合、外部連携に慣れていない自治体が多いため、市役所以外の組織との連携が弱くなりがちだ。一方、すべてを外部の組織に委託してしまうと、生活保護との連携が取りにくくなるというデメリットがある。 座間市は外部連携を進めながら直営で制度を運用している 希有 な存在だが、それが可能なのは、林の仲間づくりが秀逸なのに加えて、市の大きさが５㎞四方で収まるほどにコンパクトで、原付バイクに乗れば、 15 分で市境に行けるという地形的なメリットも
この辺の連携がうまくできている点が、この書籍が書かれた理由なんだろなーと思った
生活困窮者自立支援法と生活保護法
生活困窮者自立支援法と生活保護法という2つの違いをあんまり知らなかった。
- 生活保護: 収入が基準以下の人に生活保護費を出して、最低限度の生活の保障を支援
- 生活困窮者自立支援法: 経済的な困窮状態の人に、住居確保給付金の支給、相談支援や就労支援によって自立を促進するための支援
生活保護は収入自体が一定以下じゃない受けられないなど色々な制限があって、実際に収入はあるけど生活に困ってるような人もいる。
なので、生活保護の前段のレイヤーとして生活困窮者自立支援法というのが2015年にできたという話らしい。
自立を促進するための法というのが結構面白い視点で、この本でもこの話が結構できてた。
リーマンショックあたりの影響で作られた法で、まだどう扱えばいいのかわかってない部分もある感じもしたけど、解釈次第で色々できるみたいな感じの使い方をしてるのかなーと思った。
関連する話として、自立が孤立につながるという話もあって、日本伴走型支援協会というところの動画がかなり分かりやすかった。
お金とか住居的な支援だけして自立させたつもりになるけど、コミュニティ的に孤立するので別の問題が起きたり根本の問題が解決しなかったり。
たとえば、座間市でも18%ぐらいが生活保護を受けている計算になるけど、高齢者が多い。
これは被保護者調査見ても高齢者の割合は多い。
前述したように、座間市の生活保護利用者は２０２１年 11 月時点の速報値で２３５３人と全人口の 17・88‰に上る。最近は単身高齢者が増えており、病院や介護施設との連携は以前にもまして重要になっている。
なので、単純に自立させただけだと、「その人の死は誰が看取るのか」問題が出てくる。なので、自立が孤立につながると根本の問題が解決しないという話だった。
書籍中でも、ケースワーカーの人が訪問して最後を看取る話とかもあったので、この辺が難しい問題なんだろなーと思った。
寄付の文脈でも、Charityだと根本的な問題は解決しないので、Philanthropyという言い方をしてるとかも同じような話なのかなーと思った。
チャリティ(Charity) = 問題を軽減する = 魚を与える
慈善活動(Philanthropy) = 問題を解決する = 魚の釣り方を教える
この書籍は4-5コぐらいの実際のケースを紹介しながら書かれてるんだけど、200-300ページなのですごい内容が詰まっている感じがしてよかった。
「Software Architecture Metrics」を読んだ
Software Architecture Metrics #29
章ごとに著者が異なる、メトリクスについてエッセイ集見たいな感じの書籍。
CI/CD、テスト、技術的負債、アーキテクチャ、DevOps、メトリクスの測定そのもの、保守性とかテーマごとに色々感じだった。
(アカデミックなものも混じっている感じ)
Building Evolutionary Architecturesで出てきた適応度関数(Fitness functions)が、この書籍では想像以上に出てきた。
まさにこの図のように、いろんなところでFitness functionsが出てきた。
Chapter 2. The Fitness Function Testing Pyramid: An Analogy for Architectural Tests and Metricsの、適応度関数とテストピラミッドの話が面白かった。
- 適応度関数は、部分的なもの? 全体的なもの?
- これは両方あって、それぞれ検証できるものが異なる
- 適応度関数は、一時的ですか? それとも永続的ですか？
- 有効性が設定によって制限されてるものは一時的、そうじゃないものは永続的(未期限)
- 適応度関数は、静的なもの? 動的なもの?
- コードカバレッジとかは静的
- アクティブユーザー数に関係して動くような応答時間目標とかも扱う
- これは動的。複雑ではあるけど、役たつケースあるので、ケースバイケース
この辺の適応度関数の具体的な話とかあんまり覚えてなかったので、面白かった。
進化的アーキテクチャは翻訳の方読んでなかったのでもう一度読み返そうかな。
Chapter 7. The Role of Measurement in Software Architectureは測定についての章。
そもそもなんで測定するかというと、継続的なアーキテクチャなどの難しい点が、時間を費やしたけど十分な作業ができたかが分からないことにある。
この解決方法として測定が使われる。
アーキテクチャのお作法をまねるよりも、測定をちゃんとしたほうが現在地がわかるよという話が良かった。
あと、測定の落とし穴という話が良かった。
- 測定ではなくメカニズムにフォーカスしてしまう
- 測定しやすいものだけ測定してしまう
- ビジネス観点より技術にフォーカスしてしまう
- 行動を起こさない
- 有用性よりも精度を優先してしまう
- 測定しすぎてしまう
Chapter 9. Using Software Metrics to Ensure Maintainabilityは、コードレベルの複雑性の測定の話。
- LoC
- Cyclomatic Complexity
- Indent Depth
- 変更頻度(Author)
- Code Churn
- Number of Author
- Component Rank
- LCOM4
とか色々なメトリクスの話が出てた。
その中でも循環依存の毒性とか循環参照(Circular dependency)は結構文字数あった気がする。
循環依存によって侵食されて全体が泥だんごになるような事例とかがあったのかなとか考えてた。
まあ、実際に改善する時のボトルネックになりやすい(いろんなツールが壊れたりとか並列実行を難しくしたりとか)ので、取り除くのがいいとは感覚的には分かってたけど、実際に複雑性を強くすることがわかって良かった。
「デュアルキャリア・カップル」を読んだ
デュアルキャリア・カップル #27
デュアルキャリア・カップル読んだ。
共働きのカップルには3つの転換点が存在するという調査内容についての書籍。
著者自体が調査してるので、結構内容が濃い感じで面白かった。
第一の転換期は、子供 or キャリアチャンスで訪れることが多い。
このとき、短期的な経済基準で移住や離職などをすると片方の将来性に負荷がかかるため、経済バランスが崩れて戻すのが難しくなる。
復職しても37パーセントの収入減が待っている（４）。子育ての真っ只中にいるときには、乳幼児期はひどく長いように感じられるが、40余年のキャリア全体からすればその割合はほんのわずかだ。一方、離職することによる経済的な損失の合計は生涯で１００万ドル以上にのぼると、さまざまな研究で算出されている。
カップルでどちらキャリアを優先するかが問題になるけど(これが一つ目の転換点)、
- 一番手・二番手モデル(最初にどっちが優先なのかを決める)
- 交代制モデル(途中で役割を交代する)
- 二人とも一番手モデル(両方とも一番優先度が高い!)
という3つのモデルだと、両方とも同じ優先度の二人とも一番手モデルが一番満足度が高いという調査結果になったという話。
これは簡単ではないけど、二人とも一番手モデルをできているところは、オープンに話し合っていけるプロセスの存在がこの調査結果につながっているんじゃないという話とか面白かった。(大事なのは結果じゃなくて過程だよって話がちょこちょこあった)
キャリア<->カップルには依存関係にあるため、そこの依存関係を認めて整理しないと、いずれ問題が起きる(第一の転換点)。
また、第一の転換点で決めたバランスは時間で変化するため、それを放置すると依存関係が崩壊する(第二の転換点)。
時が経過して依存関係が崩れた時(定年、子供の巣立ち)に目標を見失うことがあり、自己発見と刷新に取り組む必要が出てくる(第三の転換期)。
少しサンプルに偏りを感じた(全員大卒みたいな所)けど、まだメタアナリシスできるほど研究が進んでない分野なんだろなと思った。
(ちょっと意外ではあるけど、二人とも一番手モデルが実際に行われるようになったのは近年だからなんだろなー)
著者自身がインタビュー調査してるので、研究手法についても最後の方に書かれて面白かった。
- 無作為抽出はできないので、「理論的サンプリング」を原則としている
- インタビューデータの分析は、「継続的比較法」でグラウンデッド・セオリー・アプローチを使ってる
- サンプルがデュアルキャリアかどうかは履歴書でリファレンスを取っている
グラウンデッド・セオリー・アプローチ 改訂版を読んだことあったので、実際の研究はこんな感じでやってるのかーとわかってよかった。
「プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける」を読んだ
O'Reilly Japan - プロダクトマネジメント
Issue: #25
ハードシングスへの突入と脱出｜鈴木大貴 / HiCustomer｜noteを読んでてて、そういえばビルドトラップの本読んでないことを思い出したので読んだ。
プロダクトマネージャー向けではあるけど、プロダクトを開発するときにプロダクトとして提供する以上誰にとっても共通の話が結構あって面白かった。
- プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
- Learning Oreillyでも日本語版がある
日本語はメインタイトルからは消えてるけど、原題はEscaping the Build Trapなので、ビルドトラップという言葉についての本(この著者が作った言葉)。
ビルドトラップとは
組織がアウトカムではなくアウトプットで成功を計測しようとして、行き詰まっている状況
実際に生み出された価値ではなく、機能の開発とリリースに集中してしまっている状況
サンプルストーリーと共にビルドトラップにハマってしまわないようにプロダクトを作っていくにはどうするべきかみたいなお話。
例となっていた仮企業はUdemyみたいなオンライン講座を提供するProduct-Led Growth(PLG)なプロダクト。
視聴者は見たい講座がなくなって解約するためリテンションが低くて、その原因は講座の作成者が講座に時間がかかっていて、その原因は投稿用のUIだったり動画編集そのものが難しいみたいな実際にありそうな話だった。
論理的に正しいものを作っても実際にそれが使われないと意味がないし、ビルドトラップというのはただのアウトプットにフォーカスしてしまって、実際に使われることにフォーカスしてない現象だと解釈した。
作っても使われないと意味がない(出典が思い出せないけどWebKitで見た気がする、W3CとWHATWGの仕様の話だったかも?)という言葉は結構好きなので、読んでて面白かった。
これ書きながら思い出したのはRethinkDBはなぜ失敗してMongoDBが勝ったのかという話。
何からやるべきかの優先度の付けの話で、価値 x 緊急性のマトリクスからなる遅延コストの評価を使いましょうとか。
これは、バグとかセキュリティIssueのトリアージ基準とかと使うメトリクスが異なるだけでやり方は同じだなーとか思った。
本筋とはちょっと違うけど、この本で一番良かったところは、内部プロダクトもアウトカムを目標にするべきですか?というコラムみたいなところ。
内部プロダクトでの実験
「こういったテクニックを内部向けツールにも使う必要がありますか？」という質問をよく耳にします。答えは間違いなくイエスです。
...
社内ユーザーの満足度が高くなって、以前は仕事をうまくこなすのが難しいと思われていたこのポジションの従業員の離職率が下がったのです。ユーザーは多くの仕事をこなせるようになり、信じられないペースで採用を続ける必要もなくなった結果、事業コストが下がりました。
内部ツールは軽視されることが多いですが、それでも企業にとって重要です。ほかのプロダクトと同じように扱わなければいけません。方向性を理解し、問題を明らかにして、その問題を詳しく知り、何が適切なソリューションかを学習しなければいけません。価値を実証する実験が終われば、最初のバージョンの作成と最適化に集中できるのです。
内部ツールも外部ツールと同じように体験を良くすることで、色々よくなるよという話。
使い勝手の悪い社内ツールは、特定の箇所に負荷が高くなってしまって、その負荷を人間が受ける形(ヘルプとか手動操作)になってると離職率にそのまま直結するのでその通りだなーと思った。
開発ツールとか社内ツールをまともじゃない状態で開発してても楽しくないし、色々クオリティが落ちやすい。
たとえば、開発環境が悪かったりCI/CDが遅いとリリース回数も減るし、トライアンドエラーが減ると品質が落ちる。
なので、いつも最初に直しに行くこと多くて、直感と一致してる感覚があった。
企業がプロダクト主導かどうかを判断する6つの質問
最後にあった質問が面白かった。
- 最後に作った機能のアイデアを思いついたのは誰?
- オーナーシップの問題があるか分かる
- 最後に廃止したプロダクトは?
- 権限があるか
- アウトカムじゃなくてアウトプットを見ている可能性が高い
- 最後に顧客と話したのはいつ?
- フィードバックを取り入れてない
- 目標は何ですか?
- アウトプット or アウトカムのどっちを目指しているかを判断できる
- 現在何に取り組んでいますか?
- 問題解決に何をするかという文脈理解
- プロダクトマネージャーはどんな人ですか？
関係ないけど、廃止したプロダクトの話でWHATWGでは結構色々消してたなーとか思い出した。