  |
はてなキーワード: 例外処理とは
理想は、どんな例外発生も想定して、きちんと処理を書いておくこと。
その扱いについて同僚と意見が分かれた。
例えば、「入力ファイルを読もうとしたら、ファイルが存在していなかった」ために、例外が発生するような場合。
【自分の考え：システムが出す例外メッセージ出力処理（エラーダイアログ）は、そのまま残しておくべき】
【同僚の考え：システムが出す例外メッセージ出力は、上位の関数でまとめて catch して いい感じに表示するべき】
【上司の考え：ファイルを開く前に存在チェックすればいいでしょ。なんでしないの】
b:entry:twitter.com:sahoobb:status:1047061214176661504
データの紛失と配付資料コピーの件は（マンガの主張の通りなら）相手（Ｍ山氏）がクソだね、で終わりだけど、肝心の会場キャンセル料のギャラからの天引き埋め合わせについてどうしても公務員として引っかかる部分があるので。
役所の支払いとして絶対にありえないんですよ。公務員やってたら冗談でも思いつかない発想なんです。
①すべてＭ山氏の冗談で最初からギャラは全額払うつもりだった。
②Ｍ山氏は区の職員だが、マンガ教室は区の事業ではなく、区職員Ｍ山氏個人の資金による個人事業だった。
③Ｍ山氏は区の職員ではく、ギャラの支払いも区役所からではなかった。((M山氏は役所から教室開催を委託された業者・団体の従業員で、「役所の事業でマンガ教室をやります」と言うのをさほ氏が「役所職員なのでそう言っている」と勘違いした。))
のいずれかしかあり得ない。個人的には③の可能性が高いと思います。
①はそんな冗談を言っても相手を不快にさせるだけで実行不能で意味がないし、②は役所職員がそんな資金豊富だとは思えないので。
役所（に限らず県庁や省庁でも基本は同じ）の何の創造みもない予算執行・契約業務の説明なので面白くもなんともありません。①～⑤は飛ばして⑥だけで結構です。いや全部読まなくてもいいんだけど。
役所の中ではこんな事やってんだな、こんな世界があるんだなってことで。
そのために確保しておくお金の枠を「予算」と言います。（マンガでもこの言葉が出てきますね）
役所がやりたい事業の計画を立てて、必要経費の見積もりをとって足し上げたものが「予算」額になります。
ちなみに「予算」は使途ごとに「費目」が決まっていて、費目ごとに金額を決めて予算を作らなければならず、今回の場合は「マンガを子どもに教える」事を役場から個人・団体に委託するので、「委託料」になります。
委託料として確保した予算は、委託する事以外には使えません。（たとえば会場借用料とかキャンセル料とかには使えません。「使用料」とか「補填・賠償金」になります。）
縛りガチガチですね。公金ですから好き勝手に使えたら困りますからね。
（費目間流用という例外処理もありますが、非常に面倒な手続きが必要だし、事前手続きが必須で「当日現場でいきなり」できることではないので省略します。）
事業を執行する部署（今回でいうと文化振興課かこども育成課か）が好き勝手に予算額を決めることはできず、まずは役所内で「（予算を決定する部署である）財政課による査定」を受けます。
財政課は常に「財政赤字を減らさねば。予算を削減せねば、部署に節約させねば。」と考えてますので、事業や経費の必要性を説明しても根拠資料不足だと差し戻しされたり、事業全部が不要だと却下されたりして、何度も査定室に足を運び、ようやく認められたものが「予算案」になります。
「案」です。
（財政課内でも査定担当ＶＳ上司のバトルがあるんですが省略します）
議会の予算決算委員会で委員から細かく審議されたあと、問題なければ本会議にかけられて可決されたら正式な「来年度予算」として成立します。（これは首長と議会が激しく対立してない限り、否決されることはまずありません。委員会で審査されるのも事業そのものの必要性で、積算まで見られることはありません。良くありませんね。でも議員さんが役所の全部署全事業の予算案を積算レベルまで細かく分析するのは現実的ではないでしょう。）
（事業に関わる予算要求～支払までの文書は公文書であり公開請求すれば見られるので、オンブズマンがチェックしてる部分もあります。）
さあ、新年度になりました。さっそく予算を使って事業を始めましょう。
これも事業担当職員で好き勝手にはできません。なんせ使うのは公金ですからね。
まずは「予算執行伺」の決済を取らなければなりません。「こんな感じの事業でこのくらいの金額を、この予算のこの費目から使いたいんですが、いいですか」という伺いを文書化して、契約書の案（印鑑が押して無いだけで実際の契約書と同じ）を添付して、担当→係長→課長と審査をうけて決済をもらいます。だいたい文書を回すだけですが、目新しい事業や大きな事業だとデスクの前に呼ばれて口頭説明も必要になります。（金額によっては部長とか首長レベルまで決済をもらわないといけないが、だいたいは課長決裁。）
まあ前年度に予算案を作る段階で課内でも財政課でも厳しくチェックされてるので、今更なんですが。
次は、事業のためお金を出す人・団体と契約します。今回でいうと、さほ氏や会場店ガリレオですね。
契約相手はどうやって選ぶ？なるべく費用を抑えるために原則は入札。
だけど細かい契約まで入札・開札作業してたら大変なので、限定された使途と一定以下の金額に限り、担当職員が契約相手を選ぶ随意契約をして良いことになっています。
その場合は相見積もりと言って、複数の相手から複数の見積書をもらって最も安い相手を選ばないといけません。
「この付近にはこの会場しかない」とか「この技能を持つのはこの人しかいない」と合理的な理由がある場合には一業者・一人だけ選んで見積もりを取っても良いことになっていますが、これは例外処理なので本当にその相手しかいないのか起案文書できちんと説明しておかないといけないし、上司からも細かくチェックされます。
次はまた決済です。今度は「支出負担行為」の文書を回さないといけません。
使う予算の費目（今回なら使用料と委託料）、使途、実行月日、円単位の金額、支払い相手先名、振込口座情報（役所の支払いは原則口座振込です。研修参加費を現地受付で払うとかでない限り、職員から現金払いする事はありません。）を記載した上で、イベント関係書類と見積書を添付して、また職員→係長→課長と決済を回します。今回は課長で終わりません。
課長から決裁印をもらったら、今度は役所の対外支払機能を一手に担う会計課からも決済をもらわないといけません。
首長から独立した「会計管理者」が役所の資金口座を握っていて、会計管理者の部下である会計課職員が役所のお金の出入りの全てを行っているんです。
会計管理者は「部長」並みの偉い人なので大きい金額の契約を見ていて、今回会計課に持ち込んだ「支出負担行為書」は、会計課担当→係長→会計課長で決済されたのでしょう。（会計課にいたことがないので細かい内部処理は不明）
そうやって初めて、相手と契約できます。「依頼」ではありません。「契約」です。
役所の契約行為は極一部に限定された例外（職員が出張で使うＪＲきっぷとか航空券とかの購入）を除いて、必ず文書契約です。口頭での契約は絶対にできません。（お金を出す証拠が残らないので不正支出になる。）
契約書はだいたいテンプレートが決まっていて、支払い相手、金額がきっちり明記されています。
これを２部用意して、２部ともさほ氏に渡して押印してもらい受け取って、役所では総務課に行って総務課員のチェックを受けたうえで公印（首長印）を押印し、１部をさほ氏に渡して１部は役所で保管して契約成立です。
そうして無事契約が成立して、ようやく「役所から依頼された」ことになります。
契約を結んではじめて役所はさほ氏に「教室で子どもにマンガを教える債務」を負わせることができます。
そして教室開催当日を迎えました。
ん？担当者が会場を２カ所抑えていて、キャンセル料が必要になった？一カ所は有料のところ（ガリレオ）で、もう一カ所は無料のところ（公民館とか）だったのかな。
キャンセル料は「費目・使用料」では払えないので、帰庁して急ぎキャンセル料の支払いのため「費目・補填賠償金」の支出手続きをしないといけません。
でも、一店だけ予約していたのが講師の都合で急に開催できなくなってキャンセル、なら支払う理由も成り立つんですが、担当者個人のミスで２会場予約していて、しかも当日までキャンセルしてなかったからキャンセル料が必要になった、なんて理由は上司や会計課に説明しづらいし、公金の支出としても市民からツッこまれそうです。（自分だったら、ダブルブッキングは無かったことにして自分の財布から出します。それが一番簡単なので）
ここでＭ山氏が言った「さほ氏へのギャラからキャンセル料を差し引いて払いますね」は可能でしょうか。
まず「決まった報酬（委託料）から急に発生した別費用を差し引く」というのは不適切な支出です。相手に委託する業務内容に対してこの金額で委託すると一度決めたのですから、業務内容が変わらないのに減額するなんて役所内の決済で絶対に認められません。
これまで支出するために役所内で行った支出負担行為書には支払相手・支払口座・支払金額が明記されています。契約書にも相手・金額が記載されています。
後から支出負担行為書を二重線で消して訂正印を押して見え消し修正する・・・無理です。訂正が効くのは誤字脱字くらいで、支払金額とか支払相手先とかの重要項目の修正はどの役所でも認められてません。契約書の訂正も必要です。
役所保管の契約書を担当者が首長印をコッソリ使って勝手に訂正したとしても（今はどこも公印の管理は厳重になってるので難しいけど）、会計課はそれによる支払を認めないし、さほ氏の持っている契約書には修正前の金額が記載されている（双方の合意に基づいてない）ので、奇跡的に会計課チェックをスルーして（ありえない）減額した金額でのギャラ払いが成功したとしても、後からさほ氏保管の契約書を提示されて不足分の支払請求をされたら、口座振込による支払金額記録が残ってますから、役所は追加払いしなければなりません。
追加払いするためにはまた一連の予算執行手続きがイチから必要になりますし、Ｍ山氏はいずれにせよこの段階で不正支出・公文書偽造により懲戒処分です。金額という重要項目の訂正・契約書の片方印だけによる訂正を見逃して支払ってしまった会計課の担当や上司も処分を受けるでしょう。（まあ会計課はどこも細かいのであり得ないけど）
教室が無事に終わりました。
相手が債務を履行したのを会計担当が確認してからでないと支払えません。（例外もあるけど省略）
帰庁後、担当者は会計課にお金を支出してもらうための書類「支出調書」を作ります。文書仕事ばかりでウンザリですか？公金だから仕方ないんです。
ここでもまた、予算の種類、費目、支払相手名、支払金額、支払口座、支払予定日、債務発生日（教室実行日）、支払内容、等を記載して、（システム化されてて支出負担行為と紐付けられてるので、ほぼ自動入力）
先に決済済みの予算執行伺・支出負担行為書・役所保管分の契約書原本・相手が委託内容を実行した証拠（マンガ教室の写真等）と検査調書を添付して、
課内で担当→係長→課長と決済をもらって、会計課に持ち込んで会計課内でもまた会計課担当→係長→会計課長と決済を経て、
はれて会計課が銀行に口座振替依頼データを送信して、さほ氏の口座にギャラが振り込まれることになります。
もちろん課内でも会計課でも、事前に決済を受けた支出負担行為書や契約書に記載された金額・相手名と、支出調書に記載された金額・相手名は照合されますので、「こっそり減額した金額で支払い」しようとしても「書類間不一致」でハネられます。
まあ、減額したとしてもガリレオさんへのキャンセル料の支払い手続きはされて無いので、予算が余るだけで意味ないんですけどね。
これで「事業」としては終わり、なんですが、担当の仕事はまだあります。
年度末の決算作業。決算書ができたら決算特別委員会の想定問答の作成。
翌年度に行われる部内監査((事業執行課の総括課が行う))、定期監査((外部から任命された弁護士や有識者の監査委員会の下部機関である監査事務局による、昨年度に誤った処理がなかったかの検査。支払関係は特に細かくチェックされる。こっそり書類書き換えとかしてもここでまずバレる。))、監査委員自らによる委員監査の監査資料作成や当日の対応。
もし予算に国庫補助金が入っていたら、補助金の実績報告書提出や受け入れ手続き、国の会計検査院による検査の受検((非常に細かく厳しい。ここで不適切な支出とされたら国庫補助金返還となり、返還金の予算確保のために予算流用手続や補正予算編成作業や議会対応が出てきて死ぬ))。来年度の補助金の事業計画や交付申請、等々・・・
と長々と説明してきましたが、帰宅してからずっと書いてて誰が読むんだこんなの。
役所の担当が持ってる事業は1つではありません。複数分野を担当していて分野ごとに複数の事業があります。
教室も１回で終わりではなく年間に何回かやるんでしょう。
教室開催ごとに講師をやってくれそうなマンガ家を探して、コンタクトを取って、ギャラ交渉して、日程調整して、契約して・・・
広さと場所が適した会場を探して、見積もりとって、後払い振込払いの了解もらって、予約（契約）して・・・
講師から教材データをもらって内容チェックして、コピー製本して必要部数を用意して、当日会場に教材持ち込んで様子を写真撮影して・・・
そして毎回ごとに講師と会場に②～④の予算執行・契約・支払手続きもせにゃいかんわけです。
ということで、役所がこの手のイベントをやる場合、教室・講師の手配などイベント開催をまるごと民間業者やNPO団体などに「業務委託」 Permalink | 記事への反応(0) | 21:42
原因の解明と対処こそが必要、というのは同意なので、そこに至るまでの文章のうち、育て方や躾に関する記述をもう少し減らせば、誤読する人が減るのではないか。それらの記述が読む人を感情的にさせてしまって、読者が筆者の言いたい所に到達することを難しくさせていると思う。
第4,5,6段落で犬の躾の話に対比させて、人間の子供も諭せば理解できるという話
10段落中、7段落で躾や育て方に原因を直接的に求めるもの、もしくは想起させるような記載をされているので、これが読者の感情を煽ってしまっていると思う。
第7段落で虐待や障害については躾で対応できる範囲を超えているという話が出てくる。
第10段落がおそらく筆者が一番言いたいことなので、これらと同じ主張をする文が冒頭にあると、他の躾に関する話題から例外を除いたうえで主張を読めるので、良いと思う。
主張は理解できるし、感情的になっているコメントに対して辟易としているとは思う。確かに良く読めば書いてある。しかし、煽るのが目的ではなくて原因の解明と対処が必要という主張を伝えたいのであれば、少し書き方を変えたほうが変に感情を煽らずに伝わりやすいのではないかという感想を持った。
第2段落で太字になっている文や、全体的に（第7段落で例外処理をしているものの）親の躾に原因を求めるような文章の割合が多く、それはせっかくの主張を補足する意見ではないように感じられたので、そのような表現になった理由を知りたい。
会社でどんな影響がでるのか調べてみたので、メモしておきます。
・チャイム
40年ものの機材。始業と昼休みと終業を告げるチャイムを車内に鳴らす。放っておいても1か月に5分進む微妙な精度。サマータイムボタンはもちろん付いていないので、手動で調整する必要がある。
・FAX
時計が入っていて、タイムスタンプが入るよね。あれはあまりいじったことないけど、サマータイム機能とかなさそう。海外展開していたら、ありそうだけど、日本仕様は機能をデチューンしてそう。
UTC時を基準に動いているので、対応は可能。現在の日本ではサマータイムがないので、タイムゾーンを東京・大阪あたりを選ぶとサマータイム機能がオフになるようになっている。正式にサマータイムが決定して、windowsアップデート後にサマータイム機能が利用可能になる。
・携帯電話
いわゆるガラケー（ガラパゴス携帯）は、一応、電波で時計の調整がかかっているので、キャリアが対応すれば、勝手に変わりそうな気がする。スマホもOS自体は対応してそう。アプリは開発者ごとに国際化対応を考えていたかどうかなんだろう。
電波の元が調整したら勝手に変わるのか。テストしたことなないだろうから、実際に発動させたら大変そう。
サマータイムボタンはもちろん付いていないので、手動で調整する必要がある。
これが厄介。開始時間にバーコードを読み、さらに終了時間にバーコードを読むようなプログラムの場合、通常時間からサマータイムに変更されるタイミングにかかったときに正しい経過時間が記録されない恐れがある。多分、夜中に行うのであれば、いまのところ影響は回避できそう。24時間操業のところだと困りそう。サーバーは、そのまま放っておくというのも手のような気がした。記録を引きだす必要があるときに変換するとか、解釈するというのが現実解かも。
・予定表プログラム
同じ時間が2回くるタイミングと2時間飛ぶタイミングはどう表現しようか。深夜のことなので、寝ているだろうからスルーしていいのだろうか。切り替えタイミングのときに例外処理をいれたほうが親切かな。現時点では同じ数え方で時間が経過することを前提に描画しているので、サマータイムによる時刻の変更は想定していない。実際にない制度のことを想定してコストをかけても誰もお金を払ってくれないよね。
サマータイムの初日は、夜勤の後の朝の交代の人は2時間早くくるのか。サマータイムの終わりの日は、2時間残業しないと次の交代の人がこないのか。
まじな話をすると、N予備校のプログラミング入門コースやるのがオススメ。
一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。
月額1000円だけどしっかり勉強すれば一ヶ月の無料期間中に終わると思う。
もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラムで講師曰く去年はこれで二人エンジニア就職を決めたらしい。
内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職に必要な環境構築やセキュリティまでみっちりやる。
で講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。
↓みたいなことが学べる
----
Web ブラウザとは (Chrome, デベロッパーコンソール, alert)
はじめてのHTML (VSCode, HTML, Emmet)
さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)
HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)
はじめてのJavaScript (JS, ES6, エラー)
JavaScriptでの計算 (値, 算術演算子, 変数, 代入)
JavaScriptで論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)
JavaScriptのループ (ループ, for)
JavaScriptのコレクション (コレクション, 配列, 添字, undefined)
JavaScriptの関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)
JavaScriptのオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)
はじめてのCSS (CSS, セレクタ, background-color, border)
CSSを使ったプログラミング (transform, id, class)
Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)
診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)
診断機能の組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)
ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)
LinuxというOS (VirtualBox, Vagrant, Ubuntuのインストール, OS, CUIの大切さ)
コンピューターの構成要素 (ノイマン型コンピューター, プロセス, lshw, man, ps, dfの使い方)
ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)
標準出力 (標準入力、標準出力、標準エラー出力、パイプ、grep)
vi (vimtutor)
シェルプログラミング (シバン, echo, read, 変数, if)
通信とネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)
サーバーとクライアント (tmux, nc, telnet)
HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)
GitHubでウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)
イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)
GitとGitHubと連携 (git, ssh, clone, pull)
GitHubへのpush (init, add, status, インデックス, commit, push, tag)
Gitのブランチ (branch, checkout, merge, gh-pages)
Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)
集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)
アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)
ライブラリ (ライブラリ, パッケージマネージャー, npm)
Slackのボット開発 (slack, mention, bot)
HubotとSlackアダプタ (hubot, yo)
モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)
ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)
同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)
例外処理 (try, catch, finally, throw)
HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsのイベントループ, リスナー)
HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)
HTMLのフォーム (フォームの仕組み, form, input)
HerokuでWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)
認証で利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)
Cookie を使った秘密の匿名掲示板 (Cookie, Set-Cookie, expire)
UI、URI、モジュールの設計 (モジュール設計, フォームのメソッド制限, リダイレクト, 302)
フォームによる投稿機能の実装 (モジュール性, textarea, 303)
認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)
データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)
トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)
削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)
管理者機能の実装 (Web サービスの管理責任, 管理者機能の重要性)
デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)
脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)
XSS脆弱性の対策 (XSS, 適切なエスケープ処理, リグレッション)
パスワードの脆弱性の対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)
セッション固定化攻撃脆弱性の対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)
より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)
安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)
Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)
ExpressのAPI (app, Properties, Request, Response, Router)
GitHubを使った外部認証 (Passport, OAuth)
テスティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)
継続的インテグレーション (CircleCI)
クライアントのフレームワーク (Webpack, Chrome 以外のブラウザでもES6)
DOM操作のフレームワーク (jQuery, jQueryアニメーション, this)
AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)
WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)
RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)
テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)
インデックス (インデックス, 複合インデックス, Bツリー)
集計とソート (SUM, COUNT, ORDER BY, GROUP BY)
「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計、モジュール設計、MVC)
認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)
予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)
予定とユーザーの一覧の表示 (非同期処理, Promise, then)
出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)
出欠とコメントの更新 (Promiseチェイン, リファクタリング)
とりあえず、近場にいる色んな夫婦の生活を密かに観察してみることにした。
「離婚しちゃったのか」
捜索開始から、いきなり出鼻をくじかれた。
だがシロクロは意外にも喜んでいる。
自信満々にそう言ったシロクロを見ながら、俺たちはため息を吐いた。
「タオナケの言うとおりだ。その結論だと、離婚するために結婚していることになってしまう」
「シロクロには難しい話かもしれないけど、離婚ってのはしないに越したことはないものだから。そんなものをゴールに据える位なら、最初から結婚なんてしなければいいって話になっちゃう」
「つまりシロクロの結論は破綻しているってこと。それに結婚した後の生活もあるなら、離婚したってその後の生活もあるだろ。だから離婚はゴールじゃないよ」
「うーん、それもそうか」
ミミセンの話をシロクロが理解できたとは思えないが、納得はしているようだ。
「次だ！ 次いってみよう！」
「あそこの人たち」
「いわゆるホームレスってやつだね」
「私、聞いたことがあるんだけど、ああいう人たちを“人生終わってる”とか言ってる人もいるらしいわ」
生きているのに人生終わってるって、よっぽどのことだ。
「そうか、つまりアレがゴールだ！」
「うーん、でも皆がみんなああいった風になるわけじゃないでしょ」
それもそうか。
一見すると人生終わっているように見えるが、あれでも生きていることには変わらない。
ホームレスが例外処理できれば、ここで結論を出してしまってもよかったのになあ。
「……ひょっとして、ゴールなんてないんじゃないかな」
こういう時、割と核心をついたことを言うのがドッペルだ。
俺も何だかそんな気はしていた。
その気持ちはみんな同じだった。
けど、いつまでも見えそうで見えないゴールラインに、みんなヤキモキしていたんだ。
「そんなこと言っても、こんなに探しているのに、まるで見つからないじゃないか」
「ゴールのないレースなんて走りたくない！」
「シロクロ、僕たちはレースの話なんてしていないよ」
だが、意外にも一理ある考えだ。
シロクロは何も考えずに言ったのかもしれないが。
ゴールもなしに人は走り続けられない。
ペース配分できないからな。
「うーん……」
この時の俺たちはさしずめランナーズハイで、いつまでも走れるような心地だった。
だがそれは、そう遠くないうちに息切れすることを意味していた。
それまでに、何とか結論を欲しい。
「なんか、あそこ騒ぎが大きくなってるな」
ホームレスの溜まり場で、やたらと人が集まっている場所があった。
変装が得意なドッペルに様子を見てもらう。
服をどこで用意していたかは知らないが、たちまち風景に馴染んだ見た目になる。
しばらくすると、俺たちが思っていた以上の成果報告をもって帰ってきた。
「……どうやらホームレスの人が誰か死んだらしい。原因は分からないけれども」
死。
「となると、ゴールは死ぬってことか」
「うーん、確かにもう先はなさそうだよね」
「それとも天国とか地獄とかが実在するなら、死ぬこともゴールじゃないのかな」
「とは言っても、それは実在するか分からないしなあ。それに、もし輪廻転生とかいうのがあったりしたら、ゴールどころかスタートに戻ってるよ」
「うーん……」
俺たちは走る体力も気力もなくなっていたんだ。
皆でしばらく唸っていると、ドッペルが何かに気づいたそぶりを見せる。
自信はなさそうで、恐る恐るその可能性を口にした。
「……なんだか“ゴール”って、候補含めてロクなものじゃないよね」
発想の転換に感動した一同は、まさに答えを見つけたといわんばかりに喜ぶ。
実際は何も導けていないんだけど。
「なるほど。そう考えると、結婚をゴール扱いされるのは確かに不服かもしれない」
「私、女だけど、その考えに賛成するわ」
「カンコン！ ソウサイ！」
皆も迎合する。
「きっと、このまま探し続けても有るかどうかすら分からないし、あったとしてロクなものじゃないよ。そんなものを無理して暴いても、誰も得しない」
こうして、俺たちのゴール探しは、ゴールかどうかはともかく終着には向かったのである。
