Zenn
Open4

日頃の行い

アイデア
業務
日常
生活
lndexlndex

聞く/訊く

分からないことがあったとき、できる行いは次の2つです：

  1. ウェブや書籍を検索する
  2. 誰かに訊く

ソフトウェア開発などの場ではこれらに、次の2つをつけくわえてもよいでしょう：

  1. 自分で実験してみる
  2. 誰かに手伝ってもらう

何かで検索するにせよ、誰かに質問するにせよ、調べたいことや訊きたいことが何であるか整理することは大事です。

  • それは公開の情報でしょうか、それとも担当プロジェクトや社内で通用する、非公開の情報でしょうか？　非公開の情報を検索してはいけません。プロジェクトメンバーなど、関係者に訊ねましょう。
  • それは（小さなコードを実行するなどして）実験可能なことでしょうか？　実験可能なら先に動かしてみましょう。ただし、可能性の判断は客観的には行わず、主観に基づいてしましょう。客観的判断はしばしば実装にかかるコストや実装者の能力を見落としがちです。
  • それについて詳しいですか？　あまり詳しくない状態でウェブ検索したり書籍を購入したりしても効果は小さいです。詳しくないことは他人に頼むか教えてもらうほうがよいです。
lndexlndex

調べる・整理する

何かについて調べることがあります。それは社内用語かもしれませんし、通信技術などにおける一般的な概念かもしれません。
たいていの場合は調べることそのものは本来の目的ではなく、何かの作業をする際に必要あって調べるものです。

何かを調べる際にすることを細分化すると以下のようになります：

  • 参考にした一次資料および二次資料へのリンクを作成する
    • 例："RFC 9110: HTTP Semantics", https://www.rfc-editor.org/rfc/rfc9110.html[1]
  • 資料のどの記述を参照したか、該当箇所がわかるよう引用するかページ番号や章題などを示す
    • 例：RFC 9110, §9.2.1 Safe Methods
  • 参考資料の記述に基づいて、どのような結論が得られるか概略を述べる
    • 例：「[RFC 9110 §X.Y.Z] によれば xxx なリクエストに対しては yyy 応答を返す必要があるが、クライアント側は zzz 応答を期待しているため、クライアント側でエラーが生じている」

調べた結果をどうするかは派生元の作業の性質に依存します。例えば、

  • （同僚を含む）ユーザからの問い合わせに回答する場合
    • メール/チケットでの問い合わせの場合、回答のために作成したメール/チケットの返信がそのまま資料（あるいは資料の草稿）になります
    • 口頭/チャットでの問い合わせの場合、ログが流れるため、資料を別途まとめなおす必要があります
  • コードに反映する場合
    • 該当箇所にコメントとして残したり、コミットメッセージに書き込むようにします

その際、作成した資料は次のことを満たしている必要があるでしょう：

  • 関係者のみ閲覧できる
  • 関係者に資料の存在と保存先を周知してある

しかしなぜ資料を作るのでしょうか？　それには次の理由があります：

  • 他の関係者（特に後から配属された人々）が改めて調査する手間を省く
  • 後々に問題が発生したり、過去の経緯について問い合わせが生じたりした際、後から検証可能な状態にしておく
  • 作業内容やサービスやソフトフェアの仕様などに根拠を与える

何らかの根拠を示したり、検証可能性を担保したりするためには、参照する資料の正当性が問題になります。資料の正当性は次の要素[2]からなります（網羅的ではありません）：

  • 資料の発行元
    • 例：標準化団体が発行している
    • 例：ライブラリの作者が公開している
    • 例：公的機関が発行している
  • 不揮発性
    • 例：URLが永続的に有効
    • 例：URLの示す内容が頻繁には変更されない
    • 例：URLのドメインの管理団体と資料の発行元が一致している
  • 有効性
    • 例：使用しているバージョンと参照している資料のバージョンが一致している
    • 例：多くの実装が参照している

結局、正当性が求められる状況では、公式ドキュメントのような一次資料を参照できるようにする必要があります。ただし、どの一次資料を参照するか、どういった結論が与えられるかについては二次資料を大いに活用してよいと思います。

脚注

  1. 余計なリンクを作らないため例では URL をインラインコードとして書いています。たいていの場合はリンクを埋め込んでおいたほうが親切だと思います。 ↩︎

  2. ここで挙げる分類は便宜的なもので、名称もその場限りの用語です。 ↩︎

lndexlndex

答える

文脈やコミュニケーションの手段によって、質問に対してかけられる時間は異なります。原則として、返答はなるべく早くするべきで、返答の内容はなるべく手短にすべきです。

では実際にはどれくらい時間をかけられるでしょうか？

  • 期限が指定されている場合、その期限の前日か半日前くらいまでに回答するようにします
    • 当日に回答すると、追加の質問に対応する時間をとれなくなるので避けましょう
    • 第三者を経由して回答する場合、転送や翻訳によって期限までに回答が届かない可能性があります
  • 他の作業を止めている場合、速やかに回答しましょう
  • 口頭の質問に答える場合、数秒以内に回答を始めましょう。
    • 会話の中断は一体感や居心地の良さを損ねるため、人間は不快感をおぼえるようです。[1]
    • 発話の内容は3〜5個ほどの短文（数単語からなるチャンク）に留めるとよいようです。[2]
脚注

  1. https://doi.org/10.1016/j.jesp.2010.12.006 ↩︎

  2. https://pmc.ncbi.nlm.nih.gov/articles/PMC2864034/ ↩︎

lndexlndex

検索する

Web検索すると二次的な資料や偶然の一致による無関係なページがヒットしがちです。Google検索[1]などでは検索結果をフィルタするための構文が利用できるため、それを利用しましょう。

比較的使用頻度の高い構文（演算子）は以下です:

  • -除外する条件
    • 指定した条件に一致しないページのみ検索します
  • site:検索結果に含めるドメイン名
    • 指定したドメインとそのサブドメインのページのみ検索します
    • - と組み合わせて -site:検索結果から除外するドメイン名 とすることで特定のドメインを結果に含めないようにもできます
    • 例: 粗大ごみ site:lg.jp（粗大ごみに関する自治体のページのみを検索する）
    • 例: C言語 文法 -site:obsolete.docs.example（C言語の文法について、古い情報を載せているページを除外する）
  • after:検索結果に含める公開日の下限/ before:検索結果に含める公開日の上限
    • 検索結果に含めるページの公開日の範囲を指定します
脚注

  1. Daniel M. Russell, "Advanced Search Operators", (2024-02-08), https://docs.google.com/document/u/0/d/1ydVaJJeL1EYbWtlfj9TPfBTE5IBADkQfZrQaBZxqXGs ↩︎