2024-12-10

JSを使ってみる

先日、LangChainというLLM用ライブラリについての記事を読みました。

blog.pokutuna.com

記事の内容自体とは関係ないんですが、本文中で以下のような、テキストアニメーションを使用している部分があったのが気になりました。

こちらのブログははてなブログのようですが、本文内でHTMLやJSを書いてそうです。このブログもはてなブログなのできっと同じことができるはず。どんなことができるのか軽く試してみました。

コードを見てみる

前述のブログにて、アニメーションが行われている箇所のHTMLを開発者ツールで見てみると以下のような感じ。

<p class="streaming-text" data-text="例えばこういうような感じでテキストをユーザに表示するやつです。"></p>

<p>タグにstreaming-textというクラスを付与している。 streaming-textでコード内を検索してみると、<script>タグ内にstreaming-textクラスに対してアニメーションを適用するJavaScriptが書かれていました。

なるほど、本文内に任意のHTMLタグを埋め込んだり、<script>タグを使ってJavaScriptのコードを埋め込んだりできるのか。

色々試してみる

試しに記事の本文内で色々HTMLを書いてみます。いつもこのブログ執筆時はMarkdownで書いてますが、このMarkdownの中にHTMLを直接書きこんでみます。

まずはHTMLタグを書いてみる

<p>細字</p>
<p><strong>太字</strong></p>

↓描画結果

細字

太字

おお、HTMLとして解釈されている。

CSSを付けてみる

<p>細字</p>
<p class="bold">太字</p>

<style>
.bold {
  font-weight: bold;
}
</style>

↓描画結果

細字

太字

<style>タグも効いている。

JSも使ってみる

<p id="text" style="font-weight: bold;">太字</p>

<script>
  const textElement = document.getElementById('text');

  const toggleFontWeight = () => {
    const isBold = textElement.style.fontWeight === 'bold';
    textElement.style.fontWeight = isBold ? 'normal' : 'bold';
    textElement.textContent = isBold ? '細字' : '太字';
  }
  setInterval(toggleFontWeight, 1000);
</script>

↓描画結果

太字

JSも動いた。

JSライブラリをCDN経由で読み込んでみる

Featherというアイコンライブラリを読み込んでみる。

<i data-feather="share"></i>
<i data-feather="user" />
<i data-feather="github" />

<script src="https://unpkg.com/feather-icons"></script>
<script>
  feather.replace(); // featherを有効化
</script>

↓描画結果

入力フォームを置いてみる

<p>入力した値: <span id="output"></span></p>
<input type="text" id="input" />


<script>
  const input = document.getElementById('input');
  const output = document.getElementById('output');

  input.addEventListener('input', e => output.textContent = e.target.value);
</script>

↓描画結果

入力した値:

ボタンを置いたり、ダイアログを出したりしてみる

<button id="showButton">ダイアログを表示</button>

<div id="popup">
  <p>ボタンがクリックされました！</p>
  <button id="closeButton">閉じる</button>
</div>

<style>
  #popup {
    display: none;
    position: fixed;
    top: 10%;
    left: 50%;
    transform: translateX(-50%);
    padding: 20px;
    background-color: #f0f0f0;
    text-align: center;
  }
</style>

<script>
  const popup = document.getElementById('popup');
  const showButton = document.getElementById('showButton');
  const closeButton = document.getElementById('closeButton');

  showButton.onclick = () => popup.style.display = 'block';
  closeButton.onclick = () => popup.style.display = 'none';
</script>

↓描画結果

おお、結構いろいろできる

いろいろ書けた

他にも色々できそうですが、一旦今回はここまで。 Markdownの機能以上の装飾をしたい場合は直接HTMLを書くことができることを知りました。

HTML/CSS/JSの挙動を記事内で紹介するような場合は、CodePen等のツールを使わずとも本文内で直接書いてしまうこともできそうです。（とはいえ、当然エディタ内でシンタックスハイライトや構文チェックは行われないので書きにくい）

ちなみに今回Markdownモードで試しましたが、はてなブログには他に「はてな記法モード」、「見たままモード」という編集方法があり、軽く試したところいずれのモードでも同じようなことができそうです。

2024-12-09

育休を半年取った話

この記事は子育てエンジニアAdvent Calendar 2024 9日目の記事です。

半年の育休が明け、仕事復帰して1ヶ月経ちました。早いものだ。
育休についての話を社内で喋る機会があったので、その際の発表メモをベースに公開できる部分を記事にしました。

育休を半年取ることにした理由
妊娠がわかってから現在までのスケジュール
育休に入る前の業務調整
育休中の生活
育休復帰後
育休とって良かった？
おわりに

育休を半年取ることにした理由

育休の期間を半年に決めた理由としては、以下のような感じです。

周囲の子供が産まれた友人や同僚が、3ヶ月〜6ヶ月程度の育休を取得していた
- →私も自然と「子供が生まれたらそのくらいの育休を取ろうかな〜」と考えていました。
育児の負担をできるだけ夫婦で分担したく、ゆっくり休んで育児に向き合う時間を作りたいと思っていた
- お金の余裕よりも時間の余裕を優先したかった
- 妻も同じような考えだった
とはいえお金も大事で、育休手当が181日目以降は減額されるので、180日程度 = 半年休むことにした

妊娠がわかってから現在までのスケジュール

妊娠がわかって、育休に入って、仕事復帰するまでのスケジュールはざっくりこんな感じ。

時期	やったこと
2023/08	妻の妊娠がわかる
2023/12	妻が安定期に入る。チーム内・上司・総務に妊娠と、育休取得したい意向を伝える
2024/01	育休期間を半年とりたいと総務に伝える
2024/04	育休開始
2024/05	娘が生まれる
2024/11	育休終了・仕事復帰

育休に入る前の業務調整

出産予定日前1ヶ月くらいから、工数少なめ、かつ緊急度低めのタスクをこなすようにして、いつ突然休むことになっても困らないよう調整させてもらってました。

それまで、大きな機能開発の都度ドキュメントを残していたので、特に育休が決まってから「この引き継ぎドキュメント作っとかなきゃ〜」みたいなバタバタは特にありませんでした。ドキュメントのメンテ、大事だなあ。

育休中の生活

最初の1ヶ月がとにかく大変でした。

初めての育児ということもあり、新生児から目が離すのが怖く、夜は交代制で24時間監視。

だんだん昼夜の感覚も薄れてくるこの時期は結構しんどかったです。

1ヶ月を過ぎた頃からは、子供がいる生活にも慣れて、夜は3人で寝室で寝られるようになりました。月齢が1ヶ月〜6ヶ月くらいの期間はまだ、歩きだしたりとか話しだしたりみたいな大きな機能追加はないので、日を追うごとに生活に余裕が出てきた感じがあります。3人でお出かけをするようになったり、夫婦でドラマを見る時間ができたり、一人でブログを書いたり本を読む時間ができたり。

育休中の話はしずかなインターネットのほうにいろいろ書いているので、もしよければ読んでみてください。

sizu.me

育休復帰後

半年の育休を終えてみると、びっくりするほど仕事のことを何も覚えてなくてびっくりしました。

毎日のように叩いていたはずのコマンドも思い出せないので手順書を見ながら作業し、自分が担当して開発した機能についての問い合わせも、ドキュメントやコードを漁って「そう言えばこういう仕様だったなあ」と思い出しながら回答しています。

仕事復帰して改めて思いますが、フルリモート&フレックス勤務なのがめちゃめちゃ助かってます。

子供がいない時も「通勤しなくていいのはサイコーだなあ」くらいには思っていましたが、子供がいると改めてありがたみを実感しています。長めにお昼をとって離乳食をあげたり、夜泣き対応で妻が眠れていない日に、朝早く起きて朝会直前まで私が子供を見ておいたり、早め退勤&子供を風呂に入れてから飲み会にいけたり。

ちょっと悲しいなと思っているのは、夜の寝るのが早くなったので、社外の勉強会に（オフライン/オンライン問わず）参加しにくいこと。18時19時開始とかが多いですが、そのあたりはご飯食べて風呂に入って寝かしつけの準備をしたいタイミングなので、なかなか時間を作れてないです。

育休とって良かった？

改めて、半年の育休は取ってよかったと思ってます。

意思疎通の取れない赤ちゃんをずっと1人で見ているのってなかなかしんどくて、その負担を分担できたのはすごく大きいです。

「育休を半年取ることにした理由」の章にも書いた、「育児は妻の担当」という状態にならないように、という点も達成できていると思ってます。とはいえ授乳はできないのと（我が家は完全母乳）、夜泣き対応は妻しかできません。なぜか夜中はなぜかパパの抱っこじゃ泣き止まないんだよなあ。

それから、ゆっくり自分の時間を取れたのも良かったと思ってます。初めての育児で右も左もわからん中で、昼間は仕事もして、それ以外の時間は一生懸命慣れない育児をして、余暇もなく毎日が過ぎていって……はメンタル的にしんどかったんじゃないかなと。

半年育児を経験した今は、仕事をしながら育児をして、その他に夫婦の時間や自分の時間を取る余裕も多少ながらできました。（その分妻が日中ワンオペで頑張ってくれているということでもあります。ありがたい。）

おわりに

というわけで育休を取った話でした。

人に「育休を半年取った」と話すと、「いい会社だね〜」と言ってもらうことがあります。弊社がいい会社なのは間違いないんですが、そういう反応が来るということは、まとまった育休が取りたくても取れない会社も世の中にはあるということ。

取りたい人がちゃんと育休を取れる世の中であってほしいな〜。

2024-10-31

Raycastを使い始めた

最近MacにRaycastというランチャーツールを入れました。

www.raycast.com

ランチャーツールとは？

設定したホットキーを入力することでいつでも画面に検索窓が現れて、Mac内のアプリの検索やWeb検索ができるツールのこと。

この手のツールについては、今までMac標準のSpotlight検索すらほとんど使ってませんでしたが、使ってみると便利で気に入ってます。特にRaycastは検索機能以外にも色々とお役立ち機能があり、それらをサクッと呼び出せるのが魅力です。

ちなみにRaycastを起動するホットキーは、デフォルトでは「command + space」ですが、私は「command + .」にしてます。今使っている分割キーボードの設定では、スペースキーが左手側にしかないので。

以下、何日か使ってみた感想です。

気に入っている点

アプリの検索
- メインの機能。これはSpotlightでもできるが、今まで活用してなかった
- アプリごとにホットキーを設定して、検索せずとも一発で起動させることもできる。今のところ設定してないけど、よく使うものは設定しておくとよさそう。
Quicklink機能
- よくアクセスするURLを登録しておける。この機能が一番よく使ってる機能だと思います。
Chromeタブ検索
- Chrome用の拡張機能を入れて、タブ検索をしています。これもよく使うので、ホットキーを設定して一発で起動できるようにしています。
クリップボード履歴
- この手のツールはClipyなどの専用ツールもあるが、使ったことがなかった。便利。
- 複数項目コピーしたい時とかに助かる
- コードを書いていて、「一旦ここの一連のコードを何処かに退避しておきたい」という時にコピーだけしておけば後から取り出せたりする
スニペット機能
- メールアドレスや、よく使うおまじない的なコード、メールの定型文を登録している。設定したコマンドでサクッと呼び出せる

困っている点・気になっている点

Quicklinkでサイトにアクセスする際、Chromeのプロファイルを指定したい
- 仕事用のリンクをプライベートのプロファイルで開いてしまって、リンクコピーして別プロファイル開いて……という作業が発生する
Quicklinkでサイトにアクセスする際、すでに同じタブを開いていたらそのタブを開いてほしい
- Chromeのアドレスバーの検索機能だと、開いているタブも候補に表示してくれて「このタブに切り替え」ボタンが出ますが、Raycastでの検索機能でもそうなってほしい
- すでに開いていることがわかっているタブは前述のタブ検索で開けるが、開いていないタブを検索しても「No Results」と言われてしまう。「開いていたら既存のタブを開き、開いてなければ新規タブを開く」となってほしい
ウィンドウ位置管理の機能（ウィンドウを右半分・左半分表示したり）があるが、今まで使っていたRectangleと挙動が違う
- Raycastは左半分→左1/3→左2/3と変わる挙動になっている
- Rectangleは右ウィンドウ左→左ウィンドウ右→左ウィンドウ左→と移動していく
- Rectangle側の動きをしてほしいので、ウィンドウ管理はRectangleを引き続き使っている
拡張機能はあんまり使いこなせてない
- GitHubとかNotionの拡張機能を入れるとRaycast上でそれらを検索できたりするらしいので入れてみたけど、Webで見たほうが見やすい。
- これは慣れの問題だと思ってます。これらも使いこなせるようになりたい。

終わりに

Raycastの紹介記事を眺めていると、Raycastを使うような人は効率化好きが多いので、Raycast以外にもいろいろと知らないアプリを知ることができます。

今気になってるのが、Arcというブラウザ。

arc.net

複数プロファイルを1ウィンドウで管理できたり、お気に入りタブを固定しておけるのが便利そう。GmailとかGoogleカレンダーとか固定で開いておきたいサイトを固定しておけたら良さそう。

とはいえあまり一気にいろいろ変えたくないので、もう少しRaycastが手に馴染んできたら導入してみようかな。

2024-10-25

FLEXBOX FROGGYをやってみた

ゲーム形式でFlexboxを学べるFLEXBOX FROGGYというコンテンツを見つけたので取り組んでました。

flexboxfroggy.com

内容としては、flex関連のCSSを記述して、カエルくんたちを蓮の葉の上にうまく持っていってあげる、というもの。パズル感覚で取り組めて面白いです。

ステージ数としては24問で、所要時間としては以下のメモを取りながら取り組んで30分かからない程度でした。

以下、学習メモ

justify-content: space-evenly: 各要素を等間隔に並べる。左右の余白は各要素間の間隔と同じ大きさ。
- 結構使いどころありそうな気もするけど、知らなかった
- space-aroundと似てるけど、space-aroundの方は左端・右端の余白の大きさが各要素間の間隔の半分の大きさになる。
  - この記事の図がわかりやすかった。
    - 代表的なjustify-contentと、特徴。 | Qiita
    - 各要素が左右に同じ大きさの余白をあるイメージ
flex-directionにcolumnを指定すると、justify-contentやalign-itemsなどの方向も変わる
- これは「主軸（Main Axis）」が横方向から縦方向に変わるため
  - 参考: フレックスコンテナー内のアイテムの配置#主軸の変更 | MDN
  - justify-contentは主軸方向の間隔を制御、align-items,align-self,align-contentは交差軸方向の間隔や位置を制御
    - 交差軸: 主軸と交差する軸。主軸が横方向なら交差軸は縦方向だし、主軸が縦方向なら交差軸は横方向
align-self: 縦方向位置の個別指定。これも使ったことがなかった。どういうユースケースがあるんだろう。
flex-flow: flex-directionとflex-wrap（折り返しの指定）のショートハンド記法。
- 例: flex-flow: column wrap

自分でカエルくんを動かしてみることで各プロパティの挙動を理解できました。終盤のステージになると各プロパティや値の名前もスラスラ書けるようになりました。
少し経ったらまた忘れるだろうから、また気が向いたときに取り組んでみよう。

flex周りでちゃんとわかりきってないのがflexプロパティ。FLEXBOX FROGGYでは登場しなかったけど、これも↓のページなんかで勉強しておこう。

主軸方向のフレックスアイテムの比率の制御 - CSS: カスケーディングスタイルシート | MDN

こういう記事も見つけました。別のFlexboxの教材や、CSS セレクタが学べる教材があるみたい。あとでやってみよう。ゲーム感覚でプログラミング学べるサービス集 #AWS - Qiita

2024-09-06

「CSS設計のキホンと王道パターン（前半）」を聞いた雑メモ

「CSS設計」の話題については、設計手法の名前（BEM, OOCSS, ……）が色々登場するややこしそうな話題、というイメージがあってとっつきにくさを感じていたんですが、Youtubeで見つけたこの動画の中の「CSS設計 8つのポイント」という話が入口として良さそうだったのでメモを残しておきます。

【前半】『CSS設計完全ガイド』の著者による「CSS設計のキホンと王道パターン」／半田惇志（100／パンセ）

CSS設計完全ガイドという本を書いている方による、オンライン勉強会での発表の録画動画です。本も読んでみよう。

CSS設計 8つのポイント

動画ではCSS設計で考えるべきポイントを8つ紹介しています。

特性に応じてCSSを分類する
HTMLとスタイリングが疎結合である
影響範囲がみだりに広すぎない
特定のコンテキストにみだりに依存していない
詳細度がみだりに高くない
クラス名から影響範囲が想像できる
クラス名から見た目・機能・役割が想像できる
拡張しやすい

これらは各設計手法に共通する考え方とのこと。まずはこれらのポイントを押さえた上で、各手法を学ぶのが良さそう。

特性に応じてCSSを分類する

コードの役割・責任を明確にし、整理する。

分類の例:

リセットCSSやサイト全体に適用するスタイル→「ベースグループ」
ヘッダーやフッター、コンテンツエリアなど特定のエリアに適用するスタイル→「レイアウトグループ」
- 設計手法によってはl- とか ly_ とか接頭辞を付ける
モジュール（再利用可能な要素）に関わるスタイル →「モジュールグループ」

HTMLタグに対して直接スタイルを適用しない

例えばh2タグに対して直接スタイリングを記述してしまうと、「こっちのページでは、同じスタイルをh3に適用したい」となった場合に困るよね、という話。

スタイルを記述するクラスを定義して、そのクラスを要素に付与するのがいい。

ただし別タグと置換しにくいimgなどは許容する場合も。

影響範囲がみだりに広すぎない

CSSは多くの積み重ねの上に見た目が決定される（カスケード・詳細度・継承……）。

不必要に影響範囲が広いコードがあると、変更のために上書きが必要になり、詳細度を高めたり!importantを使い始めたりとカオスになりかねない。

カオスを生まないために、

影響範囲の広いCSSに含めるスタイリングは最小限に
スコープを絞り、影響範囲を狭くする

特定のコンテキストにみだりに依存していない

1つ前の話と逆で、スコープを狭めすぎても良くない、という話

例:

<div class="main_module">
  <h2 class="title">コンテンツタイトル</h2>
</div>

.main_module .title {
  font-size: 16px;
  font-weight: bold;
}

このHTML部分を見ると、titleクラスは他のパーツでも使えそうに見えてしまう。しかしこのCSS実装では、main_moduleクラスの範囲内でしか使用できない。

コンテンツのタイトル部分のような使いまわしたいスタイリングは、コンテキストを絞らずに記述する必要がある。

詳細度がみだりに高くない

詳細度が高いと以下のようなデメリットが。

セレクターの見通しが悪くなる
他の要素に対する依存が多くなる
- 密結合になり、特定のコンテキストへの依存も発生しがち

不必要に詳細度を高くしていないか気をつける。

例:

<div class="media main_module">
  <h2 class="title">コンテンツタイトル</h2>
</div>

.media.main_module .title {
  font-size: 16px;
  font-weight: bold;
}

mediaとmain_moduleの両方を指定しているが、（上書き等の理由がなければ）1つでいい。可能な限り詳細度は下げる。

改善例:

.media .title {
  font-size: 16px;
  font-weight: bold;
}

クラス名から影響範囲が想像できる

ここからはクラス名の話。

先ほども出した例ですが、今度はこのtitleクラスをこのmain_moduleクラスの範囲内でだけ使いたい場合にどうすべきか。

<div class="main_module">
  <h2 class="title">コンテンツタイトル</h2>
</div>

.main_module .title {
  font-size: 16px;
  font-weight: bold;
}

先ほども書いたように、このクラス名では他のモジュールでも使いまわせそうな命名になっており混乱を招きます。

この場合、main_module内でのみ使えるクラスとわかる命名にすべき。

<div id="main_module">
  <h2 class="main_module_title">コンテンツタイトル</h2>
</div>

.main_module_title {
  font-size: 16px;
  font-weight: bold;
}

個人的には、この場合.main_module.main_module_titleとしたほうが、意図に反して他のモジュールで.main_module_titleを使われる心配がなくなり良さそうに思うんですが、どうだろう。

ともあれ、機能が伝わる変数名にしよう、という話はCSSに限らずプログラミング全般で大事にすべき話ですね。

クラス名から見た目・機能・役割が想像できる

これも命名の話で、title1, title2, title3のようなクラス名ではなく、page-title, section-title, sub-titleのような機能を示す名前をつけよう、という話。

拡張しやすい

シングルクラス設計ではなく、マルチクラス設計がいいよ、とのこと。

HTML要素ありきで、要素に対して1つのクラスをを当てていくのではなくて、スタイリングの役割ごとにクラスを分割していこう、という話。

BootstrapやTailwindなどのCSS フレームワークが用意しているクラスのように、機能ごとにクラスを作っていく方法、と理解してます。

これは確かに大事そうだなあと思う反面、しっかり設計思想をチーム内で共有した上で進める必要がありそう。場当たり的にそれっぽいことをやりはじめてしまうと、それはそれでカオスを生みそうです。

感想

いや〜、既存コードのCSSの修正の際に、意図したスタイリングが上手くできずに詳細度を高めたり!importantをつけてその場しのぎで対応した記憶が呼び起こされて、聞いててツラくなるお話でした……。

今回いくつか例に出したシンプルなコードだけ見ると「そうはならんやろ」と思っても、コードが複雑になってくると同じような良くないCSSを書いてしまうことが往々にしてあると思ってます。

カオスを生み出さないためにも、プロジェクトが小さい段階でCSS設計を検討すること、また設計を大きく変えられないような大きくなったプロジェクトでも、今回のようなポイントを押さえて「良くないCSS」を書かないようにすることが大事なんだろうなあと思いました。

ところで、VueやReactなど、コンポーネントに分割されたコードの場合はまたCSS設計の考え方が変わってきそうだと思ってます。そのあたりの関係性も勉強しておきたい。

2024-05-01

「全然 + 肯定」の話

少し前にこんなツイートを見ました。

なんだろう、20年前のニュースのような印象を覚えます。 https://t.co/HE3K424YVH
— 飯間浩明 (@IIMA_Hiroaki) 2024年4月8日

このような「全然 + 肯定」の形式の文に関する話は、テレビやSNSでときどき目にする話題です。「20年前の記事のよう」と言われるくらいには、昔から良く取り上げられる話題のようですね。

この手の話は、この記事のように

「明治期の文豪が使っている例があり、昔からある用法だ」
「俗な使い方なので畏まった場では控えたほうがいいだろう」

という説明がされることが多いイメージがあります。

「俗な使い方なので」についてはその通りだと思いますが、「昔からある使い方だ」には違和感を持っています。これに関して、文学部時代に授業で以下のような話を聞いた記憶があります。

旧来の「全然 + 肯定」は、「完全に」「ことごとく」という意味だった
現代の「全然 + 肯定」はそれとは異なり、「話し手・聞き手の想定の否定」を表す機能がある

※「話し手・聞き手の想定の否定」は存在する用語ではなく、私が勝手に言っています。授業でどんな表現で説明していたかは記憶が曖昧です。

以下、この話について書いていきます。

「全然 + 肯定」の旧用法
現代語の「全然 + 肯定」の用法
「全然 + 肯定」は「想定の否定」の機能を持つ
全然の用法は戦後変化したらしい
まとめ
おまけ - 「全然」に関する研究を見てみる -
おわりに

「`全然` + 肯定」の旧用法

明治・大正期の全然の用例として、以下のようなものがあります。

老婆の生死が、全然、自分の意志に支配されていると云う事を意識した。

芥川龍之介『羅生門』青空文庫より

羅生門は1915年（大正4年）の作品ですが、この全然は「完全に」というニュアンスで使われていて、「老婆の生死が、完全に、自分の意志に支配されている」という意味になりそうです。

これは、現代語の感覚からすると違和感のある表現で、現代では使われていない用法と言って良さそうだと思っています。

現代語の「`全然` + 肯定」の用法

現代で使われる「全然 + 肯定」の例を見てみます。冒頭のツイートのツリーにいくつか例文が書かれたツイートがあったので引用します。

あと、「全然」には肯定・否定のどちらが続くかという問題以外に、種々の用法の広がりがあります。「（参加していいかと聞かれ）全然来てください」「（ないと思ったが）全然あるじゃん」など、微妙なニュアンスを伝えます。これは一体「何を誤用した」のでしょうか。何かの誤用でなく、新用法です。
— 飯間浩明 (@IIMA_Hiroaki) 2024年4月8日

これらの全然について、ツイートでは「微妙なニュアンス」と表現されていますが、この「ニュアンス」が、「話し手・聞き手の想定の否定」だと考えています。

例えば、「全然来てください」は「参加してはいけないのではないか」という聞き手の想定を否定していると言えそうです。また、「全然あるじゃん」は「もうないのではないか」という話し手自身の想定を否定していそうです。

以下で、この「話し手・聞き手の想定の否定」（以下、長いので単に「想定の否定」とします）についてもう少し見ていきます。

「`全然` + 肯定」は「想定の否定」の機能を持つ

突然ですが、

私は全然食欲があります。

という文で文章を書きはじめるのは自然でしょうか。私には不自然に感じます。*1

私の直感としては、「全然 + 肯定」の形が、その場に存在する何らかの想定を否定する機能を持つためと考えられそうですが、いかがでしょうか。

例えば以下のような会話を想定すると、自然さの度合いが上がりそうです。

「体調悪そうだね。食欲ある？」 - 「全然食欲はあります」

これは、聞き手の質問に含まれる「食欲がないんじゃないか」という想定を否定する文となっているため、と考えられそうです。

つまり、「全然 + 肯定」は、話し手もしくは聞き手が持つ何らかの「想定」を否定していないと不自然な文となりそうです。そのため、冒頭で「全然 + 肯定」の機能を「話し手・聞き手の想定の否定」と書きました。

言い換えると、「全然 + 肯定」が自然な文となるには、否定される対象となる何らかの「想定」がその場に存在する必要がある、とも言えそうです。

`全然`の用法は戦後変化したらしい

ここまで、「全然 + 肯定」の用法が昔と今で違うことを見てきましたが、この用法の変化が起きたのは戦後（昭和20年代）の頃のようです。

三省堂国語辞典第八版*2で「全然」を引いてみると、項目の末尾に以下のような注釈があります。

「『全然』の下には、本来、否定が来る」というのは、戦後に広まった誤解。戦前から①と②の用法があったが、戦後、①が特に広まったため、これだけが本来という誤解が生まれた。

なお、①、②はいずれも用法の番号です。①は「全然 + 否定（もしくは「違う・別だ」など）」の用法、②は「完全に・すっかり」を表す旧来の「全然 + 肯定」の用法です。*3

以下の記事でも「本来否定を伴う」と言った規範意識は昭和20年代後半に広がったという紹介されています。

www.nikkei.com

まとめると、全然の用法は以下のような変遷を辿っていそうです。

「全然 + 否定」の用法は戦前から戦後を通じて変わっていない
「戦前 + 肯定」の用法は以下のように変化した
- 戦前は「完全に」を表す用法があった
- 戦後、「全然 + 否定」の形で使うべき、という規範が生まれて「全然 + 肯定」使用は減っていった
- その後、「全然 + 否定」の用法から派生した（？）「想定の否定」の機能を持つ新しい用法が発生した

新しい用法の発生が「全然 + 否定の派生」かどうかは明確ではないですが……。

まとめ

ここまでの話のまとめです。

「全然 + 肯定」は、戦前/戦後で異なる2つの用法がある
- 語形として「全然 + 肯定」という形が昔から存在する、という話は間違いでないが、「昔からある用法」と両者をひとまとめにしていいかは怪しい。
現代語の「全然 + 肯定」は「話し手・聞き手の想定を否定」する機能を持つ
- 「否定する対象となる想定」がない場合、「全然 + 肯定」は不自然な文になる

ただし、「全然」に関する論文を見てみると、そもそも「全然 + 肯定」に限らず全然自体に「想定の否定」に相当する機能があるとしているものも多いようです。このあたりは奥が深そうですが、長くなるのでこの記事はここでやめておきます。

以下で、いくつか見かけた論文を紹介します。

おまけ - 「全然」に関する研究を見てみる -

全然についての既存の研究を見てみると、「想定を否定」する機能は、「全然 + 肯定」に限らず全然自体の機能と見る見方があるようです。

全体に、「全然」が冒頭語となっている例は（中略）質問者の懸念を打ち消す回答が多いようである。服部匡（2007）大規模コーパスを用いた副詞「全然」の共起特性の調査 : 朝日新聞とYahoo!知恵袋の比較

これはコーパス（用例集）を基に全然とともに現れる言葉の特性を調査した研究です。全然には「質問者の懸念を打ち消す」というのがこの記事での「想定の否定」に当たりそうです。

相手の心的状況であるとか、話し手の以前から持っていたイメージなどに対して「訂正」をするであるとか「意義を申し立てる」と言った発話において「全然」が用いられているということである有光奈美（2002）否定的文脈と否定極性項目に関する一考察--"not at all" vs. 「全然」を中心に--

こちらは、英語のnot at allと比較しつつ全然を概観した研究です。4.2の述語の話や4.3全然の現れる文脈の話や、4.7の全然単体で使われたときの振る舞いがアクセントによって変わる話など、なるほどと思う観点ばかりで面白いです。

また、孫引きになりますが、以下の記事によると全然の機能について「否定の想定を打ち消す配慮の機能」や「文脈想定の否定」という説明をしている研究があるようです。

higonosuke.hatenablog.com

その他、全然を扱った既存の研究はたくさんあるようです。主要な研究については国立国語研究所という日本語学・言語学の研究機関が目録を公開しています。

近現代日本語における新語・新用法の研究 | 国立国語研究所

おわりに

学生時代に聞いた「全然 + 肯定」の話を軽く書くつもりが、色々考え始めると「意外と奥が深いぞ」、となり、この何日か暇を見ては全然について悩む日々を過ごしていました。

「全然 + 否定」とも絡めた細かい用例の比較にも若干足を踏み入れたのですが、「これは真面目に考えだしたらキリがないな」と思い、一旦この記事は明治期と現代での用法の違いを簡単にまとめるにとどめました。（簡単に、のつもりがまあまあ長い記事となってしまいましたが。）

他にも、述語のタイプによる自然さの度合いの違いや、「全然 + 肯定」、「全然 + 否定」、単体の「全然」と言ったそれぞれの形の出現する環境の違いや意味の違い、全くとの比較などをしてみても面白そうかなと思っています。

また用例を見る中で、文脈に存在する「想定」を否定する全然と、1文の中で直後の述語を修飾する全然のように、同じ全然でも影響を及ぼすスコープが異なるものがあるような気がしていて、そのあたりも気になっています。このあたりも、ちゃんと探せば既存の研究が何かしらありそうな気がしています。

これらはまたいつか別記事を書くかもしれないし、老後の楽しみに取っておくことなるかもしれません。

*1:逆に、その不自然さを利用した修辞的なテクニックとして、小説等でこういった書き出しがされることはあるかもしれません。

*2:冒頭でツイートを引用した飯間さんは、三省堂国語辞典の編集委員の方です

*3:③、④の用法には、「いつもの授業と違って断然楽しかった」「全然かわいいよ」といった、この記事で言う「想定の否定」にあたる用法が並んでいます。これらは別個の用法として説明がありましたが、私には「想定の否定」が根底にある類似の用法に思えました

2024-04-17

副業を始めた

今月から副業として、知り合いの方の会社で開発のお手伝いをするようになりました。

私が副業を始める前、「副業をしている人が、どうやって生活の中に副業を取り入れているのだろう」とか、「どうやって副業を見つけたんだろう」と気になっていたので、私はこうやっています、という話を書いてみます。

副業をしたくなったきっかけ

会社の人の副業話を聞いて、興味を持ったのがきっかけです。本業以外の会社も開発の仕事をすることでスキルの幅も広がりそうだなと思いました。

それと、単に収入を増やしたかったのも理由です。何かで「会社で月5万昇給するのは時間がかかるけど、副業で月5万稼ぐ事はすぐできる」というような話を何かで読んで、「副業最高じゃん」と思った記憶があります。

副業先の見つけ方

私の場合は、知り合いの方の会社で開発に関わらせてもらってます。以前仕事でお世話になった方からたまたま連絡をもらった折に、「副業を探してるんですが……」とダメ元で聞いてみたところOKをもらい、その次の月から参画させていただく形となりました。ありがたい……！

それ以外にも、フリーランス向けの案件サイトでもWeb開発の副業案件を探したんですが、なかなか見つからず。私のスキルセット的にPythonのサーバーサイド開発案件に限られる、という理由もありそうですが、そうでなくても週1程度の案件の募集は数が少なかったです。

案件サイトにも副業案件が全く無いわけではないので、タイミングによっては仕事が見つかるんだろうなとは思っています。私は2ヶ月程度しか見ていなかったので、条件に合う案件は見つけられませんでした。

勤務時間

勤務は水〜金の夕方と土曜の朝の時間に少しずつ、週の合計で8時間程度稼働しています。

副業がある日もない日も、本業&副業合わせてだいたい8:00~18:00の時間で働くようにしています。

これは、「◯曜日は長く働くから憂鬱」みたいな曜日を作りたくなかったからです。

月・火は本業の方で残業気味に働いて、その分水〜金で早めに退勤&副業、という感じで働いています。

どちらの会社もイレギュラーな勤務時間となることを許していただき、感謝しています……！

仕事内容

仕事内容としては、UI改善や開発ツール改善など、優先度の高くないタスクを消化していく小人さん的に使ってもらっています。

作業時間が限られるため、新規機能追加等にガンガン参加していくことは副業では難しそうです。

とはいえ、本業とは業界も仕事の進め方も技術スタックも異なるので、いい刺激をもらいながら楽しく作業させてもらってます。

契約

業務委託契約として、稼働した時間単位で委託料をもらう契約をしています。（いわゆる準委任契約というやつだと思う）

契約書には「月◯時間程度」とありますが、明確な稼働時間の上限・下限はありません。稼働した時間分だけ委託料を請求する*1形の契約となっています。

準委任契約だと「◯時間〜◯時間」といった時間幅での契約をするイメージでしたが、そうではないです。これは委託元の会社によって違いそうですね。

まとめ

私の副業の仕方を書いてみました。副業をしている人の1例として参考になると嬉しいです。

副業の探し方についてはあまり参考になる話は書けませんでしたが、知人の会社で働かせてもらう、という選択肢が取れそうなら、ダメ元でも頼んでみるといいのかなとは思います。

仕事を頼む側からしても、特に稼働時間の短い契約では、見ず知らずの人を呼ぶよりも素性の知れている人のほうが依頼しやすそうですよね。

*1:契約期間ごとに請求書を作成して先方に送付しています。確定申告のために登録したfreeeを使って請求書を作っています

コードを見てみる

色々試してみる

まずはHTMLタグを書いてみる

CSSを付けてみる

JSも使ってみる

JSライブラリをCDN経由で読み込んでみる

入力フォームを置いてみる

ボタンを置いたり、ダイアログを出したりしてみる

いろいろ書けた

育休を半年取ることにした理由

妊娠がわかってから現在までのスケジュール

育休に入る前の業務調整

育休中の生活

育休復帰後

育休とって良かった？

おわりに

ランチャーツールとは？

気に入っている点

困っている点・気になっている点

終わりに

CSS設計 8つのポイント

特性に応じてCSSを分類する

HTMLタグに対して直接スタイルを適用しない

影響範囲がみだりに広すぎない

特定のコンテキストにみだりに依存していない

詳細度がみだりに高くない

クラス名から影響範囲が想像できる

クラス名から見た目・機能・役割が想像できる

拡張しやすい

感想

「全然 + 肯定」の旧用法

現代語の「全然 + 肯定」の用法

「全然 + 肯定」は「想定の否定」の機能を持つ

全然の用法は戦後変化したらしい

まとめ

おまけ - 「全然」に関する研究を見てみる -

おわりに

副業をしたくなったきっかけ

副業先の見つけ方

勤務時間

仕事内容

契約

まとめ

「`全然` + 肯定」の旧用法

現代語の「`全然` + 肯定」の用法

「`全然` + 肯定」は「想定の否定」の機能を持つ

`全然`の用法は戦後変化したらしい