Sassにたどり着くまで（２）

最初にSaasの使用例を見たのはDITA Open Toolkit搭載のHTML5変換プラグインでした．これは以下から見ることができます．

https://github.com/dita-ot/dita-ot/tree/develop/src/main/plugins/org.dita.html5/sass

ここには各種の.scssファイルが格納されているのですが、これらはDITA-OTそのものをビルドするときにコンパイルされて.cssファイルに落ちる仕組みになっています．DITA-OTをビルドするなんていうことは普通の使用者ではやることはまずないでしょうから、このsassフォルダはプラグインを実行する際には使用することはありません．つまり元々動的に.cssを生成する仕組みにはなっていませんでした．

さらにこの.scssファイルの構成からは最終的に[DITA-OT]/plugins/org.dita.html5/cssフォルダに、

• commonltr.css
• commonrtl.css

が生成されます．これ自身は従来の考え方ではやむを得ないものですが、元の.scssファイルの作り方に特徴があります．それは[DITA-OT]/plugins/org.dita.html5/sassフォルダのcommonltr.scssとcommonrtl.scssファイルの作り方です．中を見てみるとわかりますが

• commonltr.scssで大方のスタイルを作ってしまってから
• commonrtl.scssはcommonltr.scssを@importでインポートして、RTLで必要な差分のみを記述する

という構造であることです．

https://github.com/dita-ot/dita-ot/blob/develop/src/main/plugins/org.dita.html5/sass/commonltr.scss

https://github.com/dita-ot/dita-ot/blob/develop/src/main/plugins/org.dita.html5/sass/commonrtl.scss

最初はなんの疑問もなくこの方式を踏襲していたのですが、これは本当にSassの本質的な使い方なのか？という疑問が日々湧いてきました．それはなぜかと言いますと、現実の課題として私が受け持っているのはフロントエンドの担当の方が作り出す結構な量のCSSを受け取ってSVNで管理する．更にLTRの言語だけでなくRTLの言語もサポートできるように「なんとかする」であったからです．

日々アップデートされる.cssを見ながら、「RTLとLTRの差分」を抽出して管理するのはあまりCSSを知らない私にとってはちょっと重荷でした．

そこで考え出したのは、LTRとRTLを統一する.scssファイルを作成して管理し、そこからパブリッシュの際に動的に.cssを生成するというものでした．ここでLTRとRTLを統一する.scssファイルの書き方とはなんぞや？ということになりますが、CSSは御存知のように物理的なleft/rightの世界で、行の進行方向の開始位置/終了位置という概念がありません．このためleft/rightを

• LTRではleftが行の進行方向の開始位置、rightが終了位置
• RTLではrightが行の進行方向の開始位置、leftが終了位置

ととらえ直してやることにします．こうすると、

［LTR：_variables-bidi-ltr.scss］

$inlineStart:left;

$inlineEnd:right;

［RTL：_variables-bidi-rtl.scss］

$inlineStart:right;

$inlineEnd:left;

という変数をLTRとRTLで別々に作っておき、肝心の.scssでは例えば

#footer-nav ul li { width: 100%; text-align: $inlineStart; }

などと書くことができます．コンパイル時に動的に

• アラビア語、ヘブライ語ならば_variables-bidi-rtl.scss
• その他の言語は_variables-bidi-ltr.scss

を選択して適用してやれば良い訳です．実際にやってみると、変数だけでなく、ミックスインや関数などいろいろ作る必要があることがわかりました．例えばmarginも次のようなミックスインが有効です．

［LTR：_variables-bidi-ltr.scss］

@mixin margin ($top, $right, $bottom, $left){

    margin: $top $right $bottom $left;

}

［RTL：_variables-bidi-rtl.scss］

@mixin margin ($top, $right, $bottom, $left){

    margin: $top $left $bottom $right;

}

このようにして最初の段階ではまったく日本語しか考えていなかったはずのCSSをSass化してこのようなインラインの方向を抽象化することにより、思いのほか簡単にアラビア語のCSSを自動生成することができました．

この抽象化のための.scssのサンプルは以下のGitHubのリポジトリで公開しています．

https://github.com/AntennaHouse/ah-html5/blob/master/com.antennahouse.html5/sass/modules/_variable-ltr.scss

https://github.com/AntennaHouse/ah-html5/blob/master/com.antennahouse.html5/sass/modules/_variable-rtl.scss

よろしければ参考にしていただければと思います．

Sassにたどり着くまで

この業界に入ってから一貫して嫌いなのがHTMLとCSSでした．HTMLは私が入った当時はバージョン4.01でブラウザ戦争より前で、IEすらまだ初期版が出たころだった覚えています．仕事上リーダーとしてHTMLに関わらざるを得なかったのですが、製品検査の女性からHTMLを知らないことをボコボコに批判され、以来トラウマになってしまい仕事で見るのもイヤになりました．

CSSは表記は軽易なのですが、その名の通りいくつも指定すると、非常に複雑な適用規則でブラウザが実行時にスタイルを選択する仕組みです．しかもそれは（ChromeやEdgeで）F12キーを押して、開発ウィンドウでデバッグせざるを得ないというのもいまいちでした．私がやっていたXSL－FO→PDFという世界では、こんな無法なことはありえなくて、せいぜい属性の継承だけ考えていれば済んだからです．

ところが昨年からこのブラウザでF12キーを押すのが日常的な仕事になってしまいました．そうHTMLを否が応でも担当しなければならなくなってしまったのです．

ただ、一般的なWebの仕事と違う点は、ページを機械的に生成することが必須要件であることです．いわゆる日本のWeb屋さんの仕事は対象が日本国内になっていることが多いのではないかと想像されるのですが、私の仕事ではターゲットは世界で

• 言語によってインラインの進行方向を切り替える．アラビア語、ヘブライ語は右から左（RTL）、その他のラテン系やCJKの言語は左から右（LTR）
• お客さんのターゲットとする製品系列やブランドにより、スタイルを切り替える．
• 更に世界展開を考えると、拠点ごとにフォントのアサインを変える．

などが変動要素として現れます．これをフロントエンドの技術者の方が、作成してくれたCSSを横目でにらみながら、自動的に生成する仕組みを作るのが仕事です．

こういう変動要素に対応するためには、CSSをいちいち組み合わせ毎に手作業で作っていたのでは到底間に合いません．自動的に条件に合ったCSSを生成できなければ使い物にならないのです．

そんな時にSassという素晴らしい仕組みがあることを知りました．CSSでもその上位に位置するSass（.scssファイルが一般的）を作っておいて、変数や関数、ミックスインというような仕組みを使って、動的にCSSを生成できることを知ったのです．

Sass

https://ja.wikipedia.org/wiki/Sass

ところが先人の例で、私が直面しているような課題を整理してくれるSassの作り方（？）というか、構築の仕方がいまいちよくわかりません．わからなければStackoverflowで聞いてみるのが一番という安直な考えで聞いてみたのが以下のリンクです．

Sassに複数の条件を適用する方法は？

https://ja.stackoverflow.com/questions/62623/sass%e3%81%ab%e8%a4%87%e6%95%b0%e3%81%ae%e6%9d%a1%e4%bb%b6%e3%82%92%e9%81%a9%e7%94%a8%e3%81%99%e3%82%8b%e6%96%b9%e6%b3%95%e3%81%af

これは2020年1月29日に投稿してそれなりの（現在：60件）の閲覧数があるのですが、どなたも回答を書いてくれません．といいますか、なぜかStackoverflowにログインすると、レピュテーションが上がっていて、何かなとクリックしてみると、この質問に「いいね」をしてくれた方が増えているのです．

逆を返すとこのようなことにやはり直面して悩んでおられる方はいらっしゃるのでしょうけれども、解がないというか．定石みたいなことがないのかな？と読み取れました．

しかし納期は待ってくれません．この質問にあるように、一般的なSassの使い手方では、N個の条件があると個々の条件が取りえる値によって、例えばRTL/LTRは2種類、製品系列がったらその系列数という具合に生成するCSSが増えていってしまいたぶん収拾がとれなくなります．そして最終的には、そのなかから1個のCSSを選べばよい．話としては分かりますが、選ぶだけでも大変な気がします．

ならば、条件に合致した形で、入力のSass（.scss）を動的に生成して、最適な一個のCSSを生成するのが最も自然に思えます．

そもそもWebは素人の私ですが、XSL-FOをやっていたおかげでCSS2レベルでは両者の共通性というのはそれなりによくわかります．

まだ現在進行形なのですが、CSS大嫌い人間の私が惚れ込んだSassという素晴らしい技術を生かすための方法について考えたことをこの次から紹介したいと思います．

すこしまとまりましたら、上記のStackoverflowにも自己RESが書けるかもしれません．

なぜ弱さを見せあえる組織が強いのか

なぜ弱さを見せあえる組織が強いのか ロバート キーガン, リサ ラスコウ レイヒー 英治出版

この本はちょっと高いのですが、いわゆる怪しげな自己啓発モノとはまったく異なります．この本を手に取った私が持っていた問題意識は次のようなものでした．

• 職場はたぶんフルタイムなら8時間は拘束され、人生にとって睡眠と同様に大きなウェイトを占める場です．
• その職場でどのように仕事に向き合って過ごせるのかはとても大切です．
• しかし現実の職場の姿は、弱肉強食、上意下達、下手をすればパワハラのオンパレードで、人は如何に自分をよく見せ、守ろうと必死になっています．
• いかにも仕事をやっているように業務報告を書き、人に助けてもらってもあたかも自分がやり遂げたがごとく報告する．問題があっても中国語で言うところの「没問題!」（大丈夫、問題ありません!）で真実を共有しようとしない．
• 結果として、会社という組織でみれば極めて不要な領域にエネルギーが使われており、下手をすればそれが手痛い失敗として跳ね返ってくることもあるのに、誰もそれを直そうとしない．

そのような中で、私はこの本の表題「なぜ弱さを見せあえる組織が強いのか」に強く共感するものがありました．それはまずもって自分自身が弱いから．でも誰もが自分の弱さを明らかにしても、それが評価と査定を下げる原因となるのではなく、それを共有し、克服するチャンスを与えられるバックグラウンドが組織にあれば、どれほど人と組織は成長できるのか？に期待するところがあったからです．

この本では冒頭で次のように述べられています．

「実は組織に属しているほとんどの人が、本来の仕事とは別の「もう一つの仕事」に精を出している．お金ももらえないのに、その仕事はいたるところで発生している．大企業でも中小企業でも、役所でも学校でも病院でも、営利企業でも非営利団体でも、そして世界中のどの国でも、大半の人が「自分の弱さを隠す」ことに時間とエネルギーを費やしている．まわりの人から見える自分の印象を操作し、なるべく優秀に見せようとする．駆け引きをし、欠点を隠し、不安を隠し、限界を隠す．自分を隠すことにいそしんでいるのだ．思うに組織でこれほど無駄を生んでいる要素はほかにない、もっと価値あることにエネルギーを費やすべきではないのか？この無駄が生み出す弊害ははっきりしている．組織とそこで働く人たちが潜在能力を十分に発揮できなくなってしまう、ということだ．その損失はあまりにも大きい」

この本の筆者は有力3社の実例と大人でも発達できるとの分析をもとにして「発達志向型組織（DDO=Deliberately Developmental Organization）」と呼ばれる組織文化を作ってゆくための道筋を紹介しています．

たぶんこの本はまちがいなく私のような平社員でなく、管理職や経営クラスの人が読んだ方がよいでしょう．でも、たった一人であっても、どのように自分の実践を通じてDDOという組織への共感を得てゆくのかもちゃんと述べられています．（p.323）

「あなたが組織の正式な権限をもっておらず、DDOでない組織で働いていたとする．そのような環境で、どうすれば日々成長しつづけられるのか？以下の慣行を試してみよう．」

• 一緒に成長する「相棒」をつくる．
• 自分の能力の限界（エッジ）について情報を求める．
  「あなたは私のことをよく知っていて、私を成長させ続けたいと考えてくれていると思います．私はどのよな点で行動を変えればもっと大きな成果を上げられそうだと思いますか？」
• 信頼できる同僚から、有意義なフィードバックを、日常的に少しづつ受け取る．
• 成長に向けた取り組みに上司を引き込む．
• お手本にできる人を探す．

私の思いだと、自分の弱さをさらけ出し、しかしそれを同僚がバックアップしてくれることを信頼する．そして、同じような人に対しては全面的な協力を惜しまない、という日々の実践なのか？と思いました．

TortoiseSVNのエラー

もうずっとSVN＋TortoiseSVNにお世話になっています．毎日これがないと仕事になりません．なのですが2016年のあるときからTortoiseSVNのバージョンを上げられなくなってしまいました．そのバージョンは1.9.5です．なぜ上げられないかというと、サーバーとはsvn+sshで接続している訳なんですが、1.9.5から以降の後継のバージョンを使うと少し規模の大きなチェックアウトの時にいきなり以下のエラーになってしまうからです．

TortoisePlink.exeのエラー

この「Remote side unexpectedly closed network connection」というエラーメッセージ、Webであたると山ほど情報がありますが、では一体何をどうすれば良いのかというとさっぱりわかりません．しかしTortoiseSVNが使えないとおまんまの食い上げ状態になってしまうので、やむなく延々と1.9.5を使ってきました．しかし今年はもう2020年、いまだに2016年のバージョンを使い続けなければならないのはあまりにもおかしいので、ネットワークの担当者に問題提起して、調べていただきました．

すぐわかったのは、最新の1.13.1と1.9.5ではこのエラーダイアログを出している、付属するTortoisePlink.exeのバージョンが違うという事、1.9.5はバージョン0.67で、1.13.1ではバージョン0.73です．で、最新の1.13.1をインストールして、TortoisePlink.exeを古い0.67に入れ替えてしまうと、なんの問題もなく動いてくれるのです．しかし、これもいささか気持ちが悪いので、仕事をしているみんながどんなバージョンを使っているかを聞き取り調査したところ、一番古いので1.8.6、最も新しくとも1.9.5でした．なので、私のようにTortoisePlink.exeのエラーになるべくもないのです．

最終的にネットワーク担当者が、TortoisePlink.exeのオプションの違いに着目して問題を解決してくれました．0.67と最新の0.73では次のように相当違うのです．

TortoisePlink.exe 0.67コマンドラインオプション

TortoisePlink.exe 0.73のコマンドラインオプション

 TortoiseSVNのネットワーク設定には、

"C:\Program Files\TortoiseSVN\bin\TortoisePlink.exe" -l tmakita -i "C:\Program Files\TortoiseSVN\key\id_rsa.ppk"

のようにTortoisePlinkを指定していたのですが、なんとここに0.73のオプションの-shareを加えるだけで、完全にエラーなしで動いてくれるようになりました．

"C:\Program Files\TortoiseSVN\bin\TortoisePlink.exe" -l tmakita -i "C:\Program Files\TortoiseSVN\key\id_rsa.ppk" -share

-shareはsvn+sshでファイル/フォルダ単位で細かくセッションがやりとりされるのですが、そのセッションで鍵を共有するか否かの指定との事だそうです．

おかげさまで、なんの心配もなく最新のバージョンが使えるようになりましたが、 TortoiseSVNもオプションが加わったなら、従来通りのコマンドライン指定が問題なく動くように互換のあるバージョンアップをしてくれたらたすかるのにな？と思った次第です．（と言ってもdonateもしてないので、あまり大きな口はたたけませんが⇒donateしているのはWikiPediaとchange.orgくらい...）

Microsoft WordとLibre OfficeのWriter

Libre Officeというソフトをご存知の方がいらっしゃるかもしれません？オープンソースのオフイスソフトで誰でも無料でダウンロードして使用できるものです．昨年から興味があって、時間を見ながらいろいろ調べていました．特に興味があるのはWriterというワードプロセッサのフォーマットです．今時ワードプロセッサというと、Microsoft Wordが当たり前かもしれません．でもLibre Officeの採用している保存フォーマットと、Wordの保存フォーマットは実は両方とも世界規格準拠のXMLフォーマットです．

• Microsoft Wordは、Office Open XML (OpenXML、OOXML) ISO/IEC 29500
• Libre Office Writer（またはOpen Office Writer）は、OpenDocument ISO/IEC 26300

私が記憶している限りでも、世界規格になる際にはいろいろ議論がありました．特にMicrosoftの作ったファイルフォーマットの仕様が世界標準になってしまうことについては、反対する意見も多くありました．一方Libre Officeのフォーマットは、OASIS（Organization for the Advancement of Structured Information Standards：構造化情報標準促進協会）という非営利の標準化団体が中心となって、様々な標準規格の上に構築されたもので、Wordのそれとは経緯がまったく異なります．

今ソフトウェア技術者から見ると、OpenXMLの方がお金の元になっているように思えます．「オープン」と言っても実際にそれを忠実に実装できるのはMicrosoftからライセンスされた有料のWordだけで、有料ということはすなわち商売の元があることを意味するからです．一方Writerの方は無料で手に入るソフトウェアなので、よほどの要求がない限り、そこに商売は成立しがたいのではないかと思います．

実は3年前にDITAからWordの.docxを生成するDITA Open Toolkitのプラグインを開発して「地獄」を見ました．何故地獄なのかというと、簡単に言えばXMLであるにもかかわらず、それはそのひとつ前のWordのバイナリーフォーマットの.docの仕様を忠実に再現したもので、極端に言えば90年代後半の構造から進歩していないものに変換しなければならなかったからです．

例えば非常に簡単な例ですが、番号付きリストを見てみるとわかります．番号付きリストはDITAならば

<ol>
    <li>りんご</li>
    <li>みかん</li>
    <li>バナナ</li>
</ol>

と表現できます．これをWriterでやってみると、次のような実に元の構造に沿ったXMLが書き込まれているのを確認できます．

<text:list xml:id="list2243974010" text:style-name="Numbering_20_123">
    <text:list-item>
        <text:p text:style-name="P1">りんご</text:p>
        </text:list-item>
        <text:list-item>
        <text:p text:style-name="P1">みかん</text:p>
        </text:list-item>
        <text:list-item>
        <text:p text:style-name="P1">バナナ</text:p>
    </text:list-item>
</text:list>

しかしこれをWordでやってみると、実に冗長なのです．この3行のリストだけでこうなります．（余計な属性は削ってあります）

<w:p>
    <w:pPr>
        <w:pStyle w:val="a3"/>
        <w:numPr>
            <w:ilvl w:val="0"/>
            <w:numId w:val="1"/>
        </w:numPr>
        <w:ind w:leftChars="0"/>
    </w:pPr>
    <w:r>
        <w:rPr>
            <w:rFonts w:hint="eastAsia"/>
        </w:rPr>
        <w:t>りんご</w:t>
    </w:r>
</w:p>
<w:p>
    <w:pPr>
        <w:pStyle w:val="a3"/>
        <w:numPr>
            <w:ilvl w:val="0"/>
            <w:numId w:val="1"/>
        </w:numPr>
        <w:ind w:leftChars="0"/>
    </w:pPr>
    <w:r>
        <w:rPr>
            <w:rFonts w:hint="eastAsia"/>
        </w:rPr>
        <w:t>みかん</w:t>
    </w:r>
</w:p>
<w:p>
    <w:pPr>
        <w:pStyle w:val="a3"/>
        <w:numPr>
            <w:ilvl w:val="0"/>
            <w:numId w:val="1"/>
        </w:numPr>
        <w:ind w:leftChars="0"/>
        <w:rPr>
            <w:rFonts w:hint="eastAsia"/>
        </w:rPr>
    </w:pPr>
    <w:r>
        <w:rPr>
            <w:rFonts w:hint="eastAsia"/>
        </w:rPr>
        <w:t>バナナ</w:t>
    </w:r>
</w:p>

何がどう違うのかといいますと、大まかに次の２点になります．

Wordはコンテンツとスタイルが分離していません．リストの各段落はコンテンツとスタイルの情報とがごちゃまぜです．これに対してWriterはコンテンツとスタイルがきれいに分離しています．
Wordでは番号付きリストは、段落の「変種」として表現されます．簡単に言えば<w:numPr>があればその変種にあたります．これに対して、Writerは、DITAやHTMLと同じようなリストの構造を素直に表現しています．

どちらが構造上優れているかといえば、明らかにWriterの方です．XMLの特徴がその本来の意味で発揮されています．これに対してWordはせっかくのXMLという構造を活かせていません．これは先にも書いたようにバイナリの.docフォーマットとの互換が一義とされたからではないかと考えられます．

もう少し入り込んだ議論になると、Wordでは、「りんご」「みかん」「バナナ」の各行は独立していて、一体のリストと「見做す」にはW:numPrの情報が必要です．実際w:numPrの行き着く先には、文書全体のリストを管理するテーブルがあって、そこを見て初めて同じリストのインスタンスと「認識」できます．ところがWriterでは初めから<text:list>という要素のくくりで、「りんご」「みかん」「バナナ」の各行は一体のものとしての「リストのインスタンス」として文書中に存在しています．

このためDITAから変換を実装しようとすれば、明らかにWriterの方が相性が良いのです．Wordは「DITAの構造的なXML」から、わざわざその構造をバラバラにして「平坦なXML」を生成し、かつ別途の場所に文書全体のリストを管理するテーブルを正確に作り出す必要があります．しかし、これは開発者にとっては「相手がWordだからやってやらねばならない悩ましい苦痛」の種となります．

Wordが本格的に.docxというフォーマットを提供しだしたのはWord 2007のバージョンからです．その前にはWord 2003で単体のXMLのフォーマットがありWordMLという呼び名で存在していました．しかしWriterのフォーマットは、それを更にさかのぼる2002年、当時のSun Micro SystemsのStar Officeから寄贈されたフォーマットとして今でも当時の仕様がベースになっています．これは以下のOpen OfficeのWebページからダウンロードできます．

OpenOffice.org XML File Format
https://www.openoffice.org/xml/general.html
https://www.openoffice.org/xml/xml_specification.pdf

今は時代ももはや2020年となりました．しかし仕様というものが20年近い年月を経ても持ちこたえることができ、かつ発展しているということは実に興味深いものがあるように思えます．OASISのWebページを見ると、OpenDocumentの仕様は、2015年6月にバージョン1.2がISO標準となり、2019年9月付でバージョン1.3がパブリックレビューの段階になっています．移り変わりの激しい今日にあって、よく練られた仕様というものはやはり価値があるものだし、勉強する意味があると思いました．

構造化文書とXSLTと...

少し前にお客様が出張で会社に見えられて、食事を一緒にさせていただいたときに話に出たのですが、XMLマスターという技術者認定試験です．

http://it.prometric-jp.com/testlist/xml/

2000年代の前半、XMLが大きく持ち上げられた時期に、日本でもベンダーインディペンデントな試験を！ということでXMLのスキルを測る試験として登場しました．そして、驚くことにこの来社されたお客様の部署は自分たちで自主的に受験され、最低でも皆さんMXLマスターのベーシックは取得しておられます．中にはプロフェッショナルを持っておられる方もおられます．

私も一時期奮起して、試験勉強をし、松本まで電車に受験しにでかけました．まだベーシックでしたが、試験の合否は受験のあとすぐわかるので聞いてみたらなんとか合格でした．

時代が過ぎてもはや2019年、当時は出ていたいわゆる受験本も本屋を見てもほとんど見かけなくなり、今やこの試験は風前の灯のように見えます．

それにもましてXML：構造化文書というものすらが、今の時代ではあまり顧みられないものとして、わきへ追いやられている感じがします．社長が言っていましたが、XMLというだけで何かしら嫌がられる傾向があるとのこと．時代の変化を感じます．

例えば会社でもXSLTのスキルは必要な場面は多々あるにせよ、メインストリームからは完全に外されています．必須じゃないけどできるようにしておけばいつかは役に立つかも...というレベルです．ただし勉強しても本業をおろそかにしない程度にね．という感じでしょうか？

私は逆にXSLT＆XML一筋です．最近感じるんですが、C++やWeb技術ばかりやっている人たちがいざXSLTでやればこんなに簡単じゃないか？というときに、ほとんどなすすべがないことがしばしばあります．私はXSLTをやっているので、逆にXSLTから呼び出すようなJavaのライブラリも作りますし、VB.NETでXMLをハンドリングするようなこともわかります．例えば、 XSLTで.docxを生成することをやっていたので、Open XML SDKを使用して、VB.NETでWord 文書を生成するようなこともそれほど苦労なく理解出来ました．

例えばDTDなんていうと、今はまずこれがわかるような教科書すらありません．しかし、DITAのCMSはいずれもいまだにDTDを使用しています．（XML Schemaや　RelaxNGはサポートしない）このため、DITAをやる人にとっては、あの忌まわしきDTDを触れなければならないし、いざお客様が特殊化したい場合は、特殊化DTDを書けなければなりません．

XMLをめぐる技術の基盤を知っていれば役立つこと満杯と思うのですが、いまはWeb、CSSや JSがもてはやされていて、何か進み方が奇形な感じを受けます．まあ今時こんなことを言うと変なおじさんと言い返されるのが落ちなんでしょう．

秋の一日

先週の日曜から今週の月曜にかけて、大学時代の同窓会の集まりがあり山梨県の下部温泉まで出かけてきました．私は学生時代を山梨県甲府市で過ごしましたが、県内をめぐる機会はほとんどなく下部町も初めてです．その日は本栖湖に上がりましたが、そこから見える富士山に感激！恥ずかしながら、こんなに間近でみたのは今まで初めてでした．

本栖湖から望む富士山

普段は父母の介護でなかなか外に出る機会がありません．宴会のあとの二次会は話が弾んで話しても話しても話題が尽きませんでした．

学生の頃はアルバイトで新聞配達をやっていて、かつ勉強せず2年も留年するありさまでした．これもあって、その後30年近く同じような２つの夢をずっと見ていました．

一つは新聞配達で、ホンダのスーパーカブで山ほど朝刊を積んで出かけるのは良いのですが、どうしてもどうしても読者の家を忘れてしまい立ち往生する夢．

二つ目は大学の授業にあまり出ていなかったので、単位を取るのに四苦八苦したんですが、せっかく卒論を取っても、残りの単位がどうしても取れなくて卒業できなくなった夢．

見なくなるようになったのはつい最近ですが、逆にさびしい気もします．