Posts for: #Event

イベント登壇のススメ

1時に寝て7時に起きた。今日も雨。雨降りの日が増えると春が来たなって感じがしてきた。

cfp のススメ

先日、過去に私が jjug ccc に登壇した資料を紹介していて、そう言えば jjug ccc とかいまぐらいの時期かな?と思って調べたら、ちょうど3月27日が cfp の締め切りになる。「ぼくのかんがえたさいきょうのでぷろい」は java アプリケーション開発の基本には沿っていないやり方なので発表したらおもしろいかもしれないと、slack に軽く書き込んだらわりといいねが付いたので社員さんに cfp 送ったら?と勧めた。その社員さんは島根県在住なのでリモートで登壇できるならいいかも?という話しになってイベントの要項を確認したらオンライン開催なので大丈夫そう。

今日がスクラムのプランニングだったのでチームに共有して業務として cfp を送るための工数も確保した。私が発表してもよいのだけど、なるべく若い人がイベントに登壇すべきだし、業務でやったことはその会社の人が発表すべきだろうというのもあって、私はバックアップにまわって発表は社員さんに任せようと思う。今月末に事例紹介させてほしいという交渉をする予定なので、それがうまくいったら、技術協力として当社のクレジットだけスライドに入れてもらえればみたいところが私の狙い。いずれにしても cfp が採択されないとその展望もないので cfp 作りにも協力していきたい。

組織系のイベントにはもう参加しない

0時に寝て3時40分に起きてそれからの記憶があまりないけど、6時半には起きてた。昼間は久しぶりにシェルスクリプトに熱中してて夜にイベントがあって、それを聞きながらも日付が変わるぐらいまではずっとシェルスクリプトを書いていた。

よくわからないイベント参加

【デブサミ再演】10年後もエンジニアが成長し続けるためにできることを、20年続く組織の中から考える に参加した。なにかの機会でたまたまみかけて中堅社員のキャリア論かなと思って参加したけど、なんかいまいちだった。シェルスクリプトを書きながら聞いてたから大事な話しもしていたかもしれないけど、miro でプレゼン資料が作られていて、参加者が付箋などに書いたコメントをみながら主催者が回答したりもしつつ、スライドで説明したりもしつつ、発表と雑談が混ざった進行で私からはコミュニティの内輪感にみえたし、何が言いたいのかよくわからないイベントだった。コミュニティのメンバー数をみるとそこそこ大きいようにもみえるので、単純に私がコミュニティの対象とする参加者ではなかったんだと思う。パワーポイントなどのスライド資料でプレゼンするのではなく、miro でプレゼンするというスタイルが新鮮で私からはそれがもっとも参考になった点だった。

組織論やキャリアの悩みは私の中では決着がついてしまったのかもしれない。変なことは言っていないし、5年前ぐらいの自分なら関心をもって聞いていたかもしれないけど、自分で会社を作ってみて、組織の論理に振り回されることがなくなって、自分のやりたいことに集中できるようになったからかもしれない。

シェルスクリプトも進化する

23時に寝て2時に起きて6時に起きた。

シェルスクリプト再考

久しぶりにシュルスクリプトを書いていて、ユーティリティ関数をうまいこと実装できないかを調べていたら nameref という仕組みが bash 4.3 以降で使えるらしい。私の bash 環境は 5.0.17 なので、bash 5 以上という制約にしてしまってもよいだろうと思う。例えば、こんなことができる。シェルスクリプトで split を実装するの面倒よね。

function split() {
    local -n arr="$1"
    local values="$2"
    local sep="${3:-,}"
    IFS="${sep}"
    read -a arr <<< $(echo "$values" | tr -d '[:space:]')
}

function test() {
    split mylist "a, b, c"
    echo "'${mylist[0]}'"
    echo "'${mylist[1]}'"
    echo "'${mylist[2]}'"
}

実行結果。ちょっと感動した。

$ test
'a'
'b'
'c'

bizpy 勉強会

Python で機械学習の前処理をやってみる勉強会 を開催した。今回も講師をわたなべさんにお願いした。私が余裕なくて全くなにもできていない。運営が2人いるとすごく助かる。今回は機械学習の前処理に着目して pandas や scikit-learn を使って実際にどういったプログラミングをするかを解説してもらった。Colab を使ってデモするのがいまどきのやり方なのかな?私は全く触ったことがないけど、そういうやり方の違いも含めて関心をもてた。Colab 上で普通に git コマンドも使えるのでリポジトリのクローンなんかもできる。次回は私もなにかしら発表をしたいなとは思う。いまのお仕事が一段落ついたら。

mysql のデータ移行

23時に寝て2時前に起きて5時に起きて8時に起きた。あんまり眠れなくなってきた。

もくもく会

【三宮.dev】もくもく会 に参加した。もともとオフラインの予定だったけど、オミクロン株の流行でオンラインに変更された。

お仕事である開発環境の構築をしていて docker-compose を使って mysql の環境構築や共有の開発環境にある db2 に接続するために clpplus のインストール方法などを wiki にまとめてた。コンテナにある mysqldump や mysql コマンドを使ってこんな風にデータ移行もできた。

共有の開発環境からデータをエクスポート。

$ docker-compose exec -T mydb mysqldump -h $DB_HOST -C --set-gtid-purged=OFF --skip-triggers $DB > dump.sql

ローカルの mysql にデータをインポート。

$ docker-compose exec -T mydb mysql -h localhost -u root -proot $DB < dump.sql

ストレッチ

いつもは11時からなんやけど、今日は17時40分からだった。カレンダーの予定を変更し忘れてて11時に行って間違えた。今週は2日間ぐらいストレッチしたかな。今日の開脚幅は開始前164cmで、ストレッチ後168cmだった。いつも時間帯が違うので数値も変わる。今日は右太ももの内転筋や内側やらがすごく張ってた。あまり調子はよくない。

レビュー待ちのストレス

0時に寝て6時に起きた。6時半頃に動くバッチ処理がエラーになって朝から原因を調べてた。

ユニットバイアスとツァイガルニク効果

いまのお仕事は火曜日にリリースして水曜日にプランニングしているため、1週間のうちの火曜日と水曜日がだらけがちになっている。火曜日に作成したリリースしない開発途中の PR が保留され、水曜日もプランニングやその後の調整にだらけていると PR が滞留しやすいからだ。昨日と今日で作成した PR が7つレビュー待ちで溜まっていて、他の作業を並行して進めるやる気をなくしてしまった。ここでなぜ作業を中断していると、自分の中でストレスが溜まったり、他の作業のやる気が削がれるのかを考えてみた。私が知っている認知心理学の知見からだと次の2つになる。

  • ユニットバイアス
    • 量や大きさに関係なく、やり終えることに満足を感じる
    • チケットやタスクを小さく分割することで小さな課題に集中して作業できる
  • ツァイガルニク効果
    • 途中で挫折したり中断してしまったことの方がよく記憶に残る
    • 心理的リアクタンスが高いほどこの効果が発生しやすくなる
      • 他人から行動を制限される反発して自分のやりたい欲求が高まる
    • レビュー待ちが多いと中断している課題のことが気になって集中力を削がれる

普通の開発者は1日3-5個ぐらいのチケットを fix するんじゃないかと思うけど、レビューが止まっているせいでそれが阻害されてストレスを感じる。しかも、レビューが有意義であれば待つ価値もあるが、レビューのほとんどがノーコメントで approve されるだけだと待ち時間だけが積み上がる。

普通のプログラマの普通の設計

タイムラインでたまたまみかけて 普通のプログラマの普通の設計 に参加した。設計の話しはコンテキストやコードがないと抽象的過ぎてふわふわして勉強会で扱うには難しいテーマだけど、その懸念通り、ふわふわした内容だったと思う。おもしろくなかったわけではなく、発表者それぞれの考え方や大事にしている価値観などを知ることで多様性を認めるというか、他人のやり方を受け入れることにもつながるのかなとは思えた。

コードのない設計の話しは言葉から連想される概念が広過ぎてあまりよくわからない。現実の設計でも言葉でやり取りして同意していたのにコードは全然違うみたいなことはたまに発生する。だから言葉で設計のやり取りするよりも、2-3日でプロトタイプを実装できるならコードを先にみせてもらった方がよいとすら私は考えているところがある。あと一度設計をやったら終わりと考える開発者も多い。設計とは運用してからのフィードバックを受けてさらに改善していくことも含まれる。だから開発を継続している限り、設計したということはなくてずっと設計しているという考え方が正しい。matz もコードとは設計であると話していたと思う。

仕事納め

0時に寝て6時に起きた。今日は仕事納めだー。

ミステリと言う勿れ 10巻

読んだのは昨日の夜なんだけど、ミステリと言う勿れの10巻 の電子版があることにたまたま気付いて購入した。そして、読みふけった。第9巻から発生した事件の続きで第10巻で進展して犯人が判明して解決した。もうね。ちょっとこの巻はすごかった。この漫画に出てくる犯人は普通の人間の常識や感覚からちょっとズレた変な人が犯人みたいなところはあった。今回はさらにそれが斜め上にズレて何一つ犯人が語る理屈や動機を理解できなくて、犯人が分かってから解決編をやっている途中でこの漫画の著者はまともな精神状態でこの漫画を描いているの?と著者の健康を心配をしてしまうぐらい、犯人の人間像に私は理解ができなかった。もちろん娯楽作品としては十分におもしろいのだけど、私にとっては理屈がわからんというのは苦痛でもあるのでわかるために読み直そうと思ってしまうので何回か読み直すことになると思う。

仕事納め

対外的には今日が仕事納め。内部的には28-29日は自社のお仕事をして30日に実家に帰るかどうか、まだ決めてない。天気次第でもいいかな。去年はうまくいかなくて31日までお仕事していたことを思うと今年は27日で締められて余裕があるように感じる。ちょうど帰省したおかださんがうちのオフィスまで訪ねて来てくれた。去年はコロナ禍で帰省されなかったので2年ぶり。オフィスの会議室を使ったことなくて、お試しも含めて軽く課題管理のビジネスアイディアについて共有した。とくに反応はなかったけれど、ちゃんと準備もしていないので気軽に雑談した。その後、近くの焼き鳥屋さんとワインバーで飲んでた。ある意味、納会の代わりにもなった。近況、昔話、技術動向、最近読んだ本などの話しをした。1人だったらほぼ100%納会はやらないので最終日に飲み会があって納会のような気分にはなった。今後は仕事納めの日に飲み会を入れるようにしていこうと思った。

traceparent の生成

1時半に寝て7時半に起きた。ちょっと疲れてて寝坊した。

W3C Trace Context の traceparent ヘッダーの生成

前にお仕事で dapr の分散トレーシングを検証している ことについて書いた。

dapr の分散トレーシングは W3C Trace Context に準拠していて、dapr 経由のリクエストは自動的にこの情報が付与されるが、そうじゃないリクエストもトレーシングできるようにするためには http ヘッダーの traceparent をセットしないといけない。試しにサーバー側に traceparent を生成するのはどうやるのかを調べてみた。Implementations of Trace Context にある java ライブラリを調べていて、Jaeger クライアントは OpenTelemetry に移行したと書いてあって、OpenTracing と OpenCensus は OpenTelemetry に統合されたと書いてあって、どうやら OpenTelemetry を使うのがよさそうだとわかった。

やりたいことは traceparent を生成したいだけだが、OpenTelemetry の Manual Instrumentation を読んでも直接的なやり方は書いてなくて、open-telemetry/opentelemetry-java のテストコードなどもみながら実装した。細かいところの仕様をまだ理解できていないけど、ひとまずこれで生成できたので検証はできると思う。

public class W3cContextUtil {

    private static final String TRACE_PARENT_VERSION = "00";
    private static final OpenTelemetrySdk openTelemetry = OpenTelemetrySdk.builder()
            .setTracerProvider(SdkTracerProvider.builder().build())
            .setPropagators(ContextPropagators.create(W3CTraceContextPropagator.getInstance()))
            .buildAndRegisterGlobal();
    private static final Tracer tracer = openTelemetry.getTracer(
            "my-tracer", "1.0.0");

    public static String generateTraceParent() {
        Span span = tracer.spanBuilder("parent").startSpan();
        try {
            SpanContext sc = span.getSpanContext();
            return String.format("%s-%s-%s-%s",
                    TRACE_PARENT_VERSION,
                    sc.getTraceId(),
                    sc.getSpanId(),
                    sc.getTraceFlags().asHex());
        } finally {
            span.end();
        }
    }
}

大阪Python もくもく会

大阪Python もくもく会 #66 にオンライン参加した。コロナ禍前に大阪へ通勤していた頃はオフライン勉強会に何回か参加したことがある。主催者のやぎさんは一度 bizpy に参加してくれたこともある。11月からオフライン勉強会を再開したとのこと。久しぶりに参加してやぎさんと話していたら neosvr にも関心をもっているとのこと。私も少し前に oculus quest 2 を購入して触ってみた程度なのでメタバース関連で一緒に勉強会をしてもよいかもしれない。もくもく会では「アジャイル開発とスクラム 第2版」を読んでいて昨日の日記の記事がまさにその成果物。せっかくなので成果発表でこの本の紹介などをした。

ワーケーションの思いつき

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

朝活: アジャイル開発とスクラム 第2版

金朝ツメトギ 2021-12-10 AM 6 金曜朝6時開催のもくもく会 に参加した。今回はてらださんも来られていた。第9章を読んだ。KDDI さんの事例紹介で2013年から取り組みしているらしい。フラクタルスプリント を実際の業務で実践している稀な事例としておもしろかった。1週間のスプリントの中に1日のスプリントが4回あるといったフラクタル構造のスプリント。また金曜日は「仕事をしない日」としてレトロスペクティブと OST (オープンスペーステクノロジー、自由な発表と議論の時間) に割当てている。20%ルールに近いものと言えるかもしれないが、自己研鑽のための時間をスプリントの中に組み込むという、組織の理解があってこそできる取り組みを実践していてすごいなと感心した。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。スクラムの話題として だいくしーのスクラム Bar #1Scrum Masters Night! Online 〜第10夜〜 に参加してやり取りした内容や考察したことなどをいろいろ話してた。そのうちの話題の1つに、スクラムマスターの役割とは何だろうかがある。スクラムマスターはプロダクトをよくすることに責任をもち、メンバーが働きやすいように支えるような役割である。ここまでは共通認識として、その範囲がどこまでかは人によって意見が異なるように思えた。あくまでプロダクトやチームの範囲内で行動するスクラムマスターと、スクラムを組織全体に広めたり、人事・評価制度や経営にも参加していくスクラムマスターがある。スクラムマスターは社外の人間でもできるという考え方があるが、必然的に後者の役割も担うなら社内の人間に限定される。後者の役割は越権行為ではないか、いやいや、チームのために働いたメンバーの評価が下がってしまえば現場でよりよいプロダクト開発はできないから大事ではないかという意見も出た。便宜上、前者を (普通の) スクラムマスター、後者を「意識の高い」スクラムマスターと呼ぶ。私の考えでは、意識の高いスクラムマスターの言わんとしていることはわかるが、それをやりたいなら部長や役員などになってから職責とともに改善すべきであり、スクラムマスターという組織におけるラインではない人が経営に口出ししたりすることによる、組織の歪みはまた別の問題を引き起こすのではないかとも思えた。私も経営をやっていて経営側の視点でみるとやはりおかしい。

その後にワーケーションについて相談した。城崎温泉にある きのいえ でワーケーションをやってみようかと考えている。参加のお誘いややり方についていくつか相談しながら前向きに検討しようということになった。

忘年会

【初参加大歓迎】三宮.dev&bizpy 合同忘年会 に参加してきた。忘年会の前に運営に入ってもらった、わたなべさんと軽く bizpy の運営について話してきた。1月はわたなべさんに機械学習の勉強会をやってもらう。私は昨年も三宮.devの忘年会に出てた。昨年は3人だったのが今年は4人になった。名物の大きなポークカツレツ。4人とも勉強会の常連みたいな人たちなのでお酒を飲みながらわいわいやって、コロナ禍になる前のコミュニティの勉強会の飲み会を思い出したりしてた。ワーケーションの話をしたら2人は興味を示してくれて、メンバーが4人集まったので開発合宿の企画をしてみることに決めた。

辞めるときの余裕

2時半に寝て6時半に起きた。なぜか眠れなくて鬼滅の刃をみてた。本当は夜に bizpy の資料作りをしようと思っていたけど、前日にあまり寝てなかったせいかバテてそのまま寝てしまった。

お仕事の辞め方

たまたまお手伝いしているところである開発メンバーが今月いっぱいで辞めますという連絡があった。その方は今日お休みだったので明日で辞めますみたいな急な連絡となった。もちろん上司や関係者には前々から話しは伝わっていて、引き止めや調整をしていたのだろうけど、チームとして働くにおいてメンバーはショックを受けるというか驚くというのが普通の感覚だろう。私も少なからず組織を退職してきた。私の場合、有給休暇が余っていたので辞めると言い出すのは実際に辞める3ヶ月ぐらい前で、有給消化が1ヶ月、引き継ぎに1ヶ月、引き止めや調整に2週間、2週間ぐらいはバッファみたいな感じで辞めてきた気がする。組織の規模によるけど、大きい組織は順番に引き止めの打ち合わせがくるので時間がかかる。組織にもよるけど、私の場合は3-4ぐらい、上長、課長、部長、その上の偉い人みたいな感じか。少なくともメンバーが退職を知ってから1ヶ月以内に辞めるということはない。私は過程の記録が課題管理システムに残っているし、ドキュメントも普段からそこそこ書く方なので辞めるときにドタバタすることはほぼない。ドキュメントなくても課題管理システムにやったことはすべて残ってますからと説明できる。上長からも引き継ぎに困るという心配をされたこともない。

辞め方というのはその人の信義を表すように私は思っていて、どういう背景や事情があるにしろ、ひどい辞め方をするのは本人にとって百害あって一利なしだと思う。余裕のない辞め方というのはあまり推奨しない。

忘年会

【初参加大歓迎】三宮.dev&bizpy 合同忘年会 の日程を12月10日に決定した。オミクロン株の不安などが出てきたところだけど、水際対策をがんばっているのでまだ大丈夫かなといましかできない飲み会をこのまま行うことにする。言うても参加してくれるメンバーは限定的なのでいつも人たちで労をねぎらうみたいな飲み会になりそう。

まる一日喋り続けた日

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

ストレッチ

先週に引き続き、今週もお仕事でバテてストレッチは2日/週とあまりできなかった。ウォーキングもほとんどできなかった。とはいえ、先週の土日に観光案内でいつもよりかなり歩いたのでその休息と考えればそれほど悲観的にならなくてもよいかもしれない。ウォーキングしなかった背景は寒くなってきて21時頃に帰ってきて、また外に出掛けるのが億劫になってしまった。お仕事を早めに切り上げて早めに帰って来た方がよいかもしれない。

今日の開脚幅は開始前168cmで、ストレッチ後170.5cmだった。また170cmを超えるようになったのでよいサイクルに入ってきた。2週間に渡った中殿筋の張りはおさまった気がする。代わりに腰の筋肉に張りがあって、トレーナーさんも念入りにそこをストレッチしてくれた。生活していると、そのときどきで調子の悪い箇所は移動していて、ストレッチするとそのことに気付くので体調管理を意識する意図でもストレッチは役に立っている。

もくもく会

【三宮.dev】もくもく会 に参加した。今回はオフラインのもくもく会だった。私は bizpy の勉強会の資料作成の準備をしていた。ここ数回は主催者と私の2人だけしかオフラインに来ないといったことが多かったのだけど、今回は8人も参加していて、その8人中5人が勉強会コミュニティに主催者だったりしてちょっとおもしろかった。

コミュニティの主催者は、コミュニティ運営の苦労がわかるから他のコミュニティのよき参加者になり得る。私は 三宮.dev の運営には関わっていないが、コミュニティを盛り上げることに寄与する振る舞いはしていて、それは自分のコミュニティでもこういったやり取りが増えるといいなという願望を他のコミュニティで参加者としてやっていたりする。今回のオフラインの参加者が多かったのも、他の勉強会コミュニティでもオフラインでやりたいよねと思う人たちが集ったのではないかとか考えたりしていた。

ぷち飲み会

終わってからわたなべさんと立ち飲みに行ってきた。最近あまり行ってない はんなりPythonの会 の勉強会で (オンラインで) なんどか話したことがある方で、ずっと京都に住んでいると思っていた方がめっちゃご近所さんだった。わたなべさんは私より1つ学年が上で、世代における価値観に共感するところは多く、自身もマイクロ法人を営んでいた。研究者としてキャリアを積み重ねてこられて昨年、独立したようだ。はんなりPythonの会の運営にも最近入ったそうで、ついでというわけではないが、話していて気が合うなと思ったので bizpy の運営に入ってくれません?と尋ねたら快く了承してくれた。

bizpy の最大の懸念は運営が私1人で、私がお仕事で忙しくなったら休業してしまうという問題があった。なかなか勉強会のコミュニティの運営をできそうなメンバー (スキル、価値観、時間的余裕) をみつけるのは難しいので了承してくれてとても嬉しかった。わたなべさんは博士で研究者のキャリアをもっていて、いまは機械学習などに取り組んでいるのかな?私のキャリアとは全く重なりがないのでお互いに学ぶところがあってよい関係を築けるのではないかと思う。ビジネスパーソン向け機械学習入門みたいな勉強会をしてもよいと思う。

リーンキャンバスレビュー (後半)

前回 の続き。残りの半分を進めるのかなと考えていたけど、前回のおさらいから始めて、私の意図するプロダクトの価値やサービスの特徴の話しをしていたら、このサービスはすぐに顧客に価値が伝わるものでもなければ、急成長するようなビジネスでもないということが伝わって、リーンキャンバスをやる意味はあまりないねという話しで後半戦をやらずに終わったw。どうも新規事業=急成長やスケールするビジネスという考えでリーンキャンバスを持ち出したところがあって、私は最初からそんなことは一言も言ってないし、私が作った資料にもそういった懸念や展望は書いてあったんだけど、リーンキャンバスを通して話しているうちにその意図を理解してもらえたといった様子だった。

そういう意味でリーンキャンバスは急成長やスケールするビジネスを取り扱うときに投資家や顧客にわかりやすく訴求するためのフレームワークと言えるのかもしれない。仮にビジネスがうまくいったとしても、合同会社は投資を受けるのが難しいのでそのときは株式会社を別途作ってやるのかなぁみたいな、取らぬ狸の皮算用みたいな話も知った。

今年は忘年会やる

1時に寝て3時に起きて2度寝して6時に起きた。起き上がれなくて6時半までだらだらしてから起きた。

リポジトリの改行コード指定

git のリポジトリ設定で .gitattributes という設定方法がある。ざっくり理解するには .gitattributesによる改行コードの変換設定 を読むのが早い。とりあえずこんな設定にしてみた。すでに crlf の改行コードでコミットされたファイルがあるため、それらを lf に変換しないといけない。eol=lf にすると crlf でコミットされている既存ファイルも変換してくれるみたい。おそらくチェックアウトしたときにそうなるのかな?

*       text=auto eol=lf
*.jar   binary

ここ数年は Windows マシンを開発に使っている開発者と一緒に働いたことがなかったけど、OS 混在環境だとリポジトリ設定が必要だということに気付いた。多様性は大事。

忘年会

三宮.dev&bizpy 合同忘年会 に参加登録した。bizpy だけだと、忘年会の参加者を集めるのは厳しそうなので三ノ宮.devと共同でやる。これなら最低でも2人は確定しているのでイベントがなくなることはない。日程は参加者の希望を聞きながら水曜か金曜でやるみたい。いましか飲み会できないだろうからいいと思う。

ミクロ経済学入門の入門

第9章の公共財を読んだ。市場を考察するときに扱う財は一般論として 私的財 を想定している。私的財は次の2つの性質を満たす。

  • 競合的: 複数の人々が同時に利用できない
  • 排除的: 拠出に貢献した特定のメンバーしか利用できない

一方で私的財と対偶の関係にある競合的でも排除的でもない財を 公共財 と呼ぶ。例えば、国防サービスや一般道路などが相当する。侵攻してくる敵国から自国を防衛するときにすべての国民、納税していない人であっても国防の利益にあずかれる。非競合的だが、排除的である財を クラブ財 と呼ぶ。高速道路などが相当する。みんなが利用できるが、利用料金を収めないと利用できない。競合的だが非排除的な財を コモンプール財 と呼ぶ。漁場などが相当する。どの漁師が魚を獲るかは競合しているが、漁業権をもっている限り漁そのものは制限されない。

これをまとめると、財は次の4つの分類になる。

競合的非競合的
排除的私的財クラブ財
非排除的コモンプール財公共財

公共財の自発的供給の問いとして、排除的でも競合的でもない公共財が人々の自発的な行動で十分に供給できるかを考える。自分のお金を寄付する・寄付しないの2択でマトリクスを作成する。自分は寄付せず、他人の寄付から利益を得ることを フリーライド と呼ぶ。みんながフリーライドをしようとすると公共財はまったく供給されない。A と B の2者間における利得表を表すと次のようになる。相手が寄付して、自分が寄付しないときに最大の利益となり、どちらも寄付しないよりは両者が寄付した方が利益が大きくなる。

A \ B寄付する寄付しない
寄付する4, 42, 5
寄付しない5, 23, 3

A が寄付するか・しないかの選択は、B の寄付の有無に関係なく、A は寄付しない方が寄付したよりもトクすることになる。相手がどういった選択をしても自分にとって一番トクな選択肢が同じときにその選択肢を 支配戦略 という。この話は B からみても同じになる。A も B も寄付しないがトクする状態のことを 支配戦略均衡 という。この状態が最善かと言えば、そうではなく、両者が寄付した方が両者が寄付しないよりもトクする状態になる。このように公共財の供給を個々のプレイヤーに任せていては パレート劣位 な結果となってしまう。この状態からどうやって両者が寄付する パレート優位 な状態に移行できるかを考えるのが、政府の徴税の方策と言える。

政府が誰にいくらの税を課して、どの程度の量の公共財を適切と決めるのかは難しい問題である。放っておいて上手くいかないものの、政府に任せて上手くいくことも保証されない。このようなゲーム理論を制度設計に活用する メカニズムデザイン という専門分野がある。