ノートで「問う力」を鍛えよう -AI時代の思考整理術

関連するソリューション

業務改革

ITインフラ事業本部　ITS第3部
テクニカルスペシャリスト　秦　拓郎

はじめに

進捗どうですか。テクニカルスペシャリストの秦です。

改めていうまでもなく、ここ数年のAIの進化によってシステム開発の現場は大きく変わりつつあります。

AIで調べれば情報が見つかり、ある程度の仕事もこなせる時代になりました。この変化の中で重要になってきたのが技術者自身の「問う力」です。

同じAIを使っていても、適切な「問い」を投げられる人は本質的な答えに辿り着き、「問い」が曖昧な人は「それっぽい情報」に振り回される。そのような差が見られるようになってきました。

さて、システム開発に携わっていてこんな経験をしたことはないでしょうか。

• 「なんでこうしたの？」と聞かれると、理由を説明するのに詰まる
• 作業時間はかけているのに、成果の質が上がらない
• 前提を確認しないまま考え始めて、あとから全部ひっくり返る

日々の業務の中で、しっかり考えているつもりなのに…。かつて私自身も同じようにつまずいていました。経験の浅いメンバーを見ていても同じような場面によく遭遇します。

こうした状況に陥るのは個人の能力の問題ではなく、「問い」が整理されないまま作業を進めているためです。

そこで今回は、ノートに書くというプロセスを通じて「問いを整理しながら考える方法」を説明していきます。

「ノート」とは何か

ここでいうノートとは、あるテーマについて考えたことを整理しながら書き出したものです。

一時的かつ個人的なメモではなく、関係者間で共有し、長期間参照されることを前提として作成します。

なぜノートを書くのか

「問う力」と「考える力」を鍛える

ITエンジニアの仕事は、知的労働そのものです。つまり、仕事の多くは考えることに費やされています。

ただし、ここで重要なのは「何を問うか」と「その問いにどう答えるか」です。どれだけ時間をかけても問いが曖昧なまま進めている、前提が整理されていない、といった状態では単に悩んでいるだけで、理路整然とした結論にはつながりません。

そして、その問いに対して答えを導くのが「考える力」です。「問う力」と「考える力」がそろって思考は機能します。

ノートを書くことで、自分がどんな問いを持っているのかを明確にし、その問いを整理しながら検討していくことができるようになります。その結果、「なんとなく考える」状態から、「問いを起点にして考えられる」状態へと変わっていきます。

これを繰り返すことで、自分なりの思考の「型」が身につき、「問う力」と「考える力」が鍛えられていきます。

ワーキングメモリを解放する

人間の脳には「ワーキングメモリ（作業記憶）」という一時的に情報を保持する領域があります。ワーキングメモリがいっぱいになると認知負荷が高まり、情報の理解が遅くなる、判断を誤りやすくなる、といった問題が起きます。

例えば複雑なかけ算を暗算で解こうとすると難しいですが、筆算であれば解くことができます。これは、計算の途中経過をワーキングメモリの外に書き出し、今必要な計算にだけ脳のリソースを集中させることができるからです。

ノートは、思考におけるこの「筆算」の役割を果たします。

暗黙知を追体験できる

ノートを書くと、本来「暗黙知」である思考のプロセスが明文化され、読み手はその思考の流れを追体験できます。結論だけの単なる知識でなく、結論を導く過程も共有することができます。

成果物の補足資料として

設計書や手順書をレビューすると、「なぜこうしたのか？」と問われることがあります。

こうしたとき、ノートがあれば、意思決定の背景、検討の過程、制約などの前提を補足できます。

成果物には書きにくい内容も含めて説明できるため、納得感のあるレビューにつながります。

報告・連絡・相談のツールとして

ノートは報連相にも使えます。こんな状況です、といってノートをもとに説明してもいいですし、ノートを書くことで自分自身が状況の整理と理解ができているため、口頭での説明もしやすくなっていることでしょう。

また、リモートワークなどで非同期コミュニケーションが増えた今、ノートをそのまま共有するだけでも報連相の役に立つ場面があると思います。

資料の下書きとして

提案資料や設計書、手順書などをいきなり作ろうとすると、書いては消してを繰り返す→書式が崩れていく→直す、といったことで時間をとられがちです。これは内容を考えることと、書式に沿って記述することを同時にやっているからです。

予めノートに内容を整理しておくことで、「何を書くか（中身）」と「どう書くか（書式）」を分けて考えることができます。

ノートの書き方

見出しをつける

ノートを書く上で最も重要なのは、本文の前に必ず見出しをつけることです。

見出しを付けることで、今、何について考えているのかが明確になり、思考の範囲が区切られるようになります。

また、同じ粒度の内容は同じレベルの見出しにそろえることで、ノート全体が自然と構造化されていきます。

構造化されることで、抜け漏れや違和感に気づきやすくなります。

基本構造

ノートの基本構造は「目的」「前提」「検討」「結論」とします。それぞれに何を書き出すかはこの後で説明します。

扱うテーマや好みによって名前を変えたり細分化したりしてもよいですが、順番は変えないようにしてください。

ノートにタイトルをつける

テーマをもとにタイトルをつけます。後で探すときに困らないタイトルにしましょう。

最初は「○○について」などといった仮のタイトルでも問題ないです。内容が整理される過程で適切なタイトルに変えればよいです。

①目的

このノートで扱う「問い」を明確にします。

何を明らかにしたいのか、これが曖昧なままでは思考は進みません。

また、ここでいう「問い」は必ずしも疑問文である必要はありません。重要なのは、思考の出発点になっていることです。

【例】

• ○○要件を設計に落とすとどうなるか
• ○○方式の検討
• ○○設計の検討
• ①案と②案のどちらを採用するか
• この設計で性能要件を満たせるか
• エラーの発生原因は何か
• ボトルネックの調査
• 認証パターンの整理

②前提

既に決まっていること、分かっていることを整理します。

可能な限り全ての材料を出して、論点がズレたり、あとからひっくり返ったりすることを防ぎます。

また、前提を書き出すだけで結論が見えてくることもあります。

【例】

• 対象・範囲

  何をやるか／やらないか、対象にするもの／しないもの、1回やればいいのか／繰り返しやるスキームとして考えるのか、など

• 制約条件

  やらないといけないこと／やってはいけないこと、など

• 背景

  提案活動、依頼によるもの、技術検証、改善活動、障害対応、など

• ねらい

  目的を達成することで得たいもの、得られるもの

• 関連資料

  仕様書、説明資料、ログファイル、Webサイト、関連するチャットへのリンクなど

③検討

「問い」に対する答えを導いていくプロセスです。

まずは「前提」を読み込み、そこから気づいたことや思いついたことを書き出していきます。

違和感や疑問をそのままにせず、言葉にして外に出すことが重要です。

次に、それらをもとにさらに踏み込んで調査したり、複数の情報を組み合わせてみたり、技術的なことであれば実際に試してみたりしながら検証を進めていきます。

そして、その結果を改めて書き出します。試行錯誤の過程も残しておくことが重要です。

結果的に見当違いだった内容や、採用しなかった案も、「なぜ違ったのか」という知見として価値があります。

また、ここまで進めることで「目的」と「前提」も整理された状態になります。そのため、AIから得られる情報の質も高くなっていきます。

④結論

最後に、ここまでの検討から分かったことをまとめます。

現時点で分かったことや判断した内容が整理できていればそれで十分です。

唯一無二の完璧な答えである必要はありません。

重要なのは、なぜその結論に至ったのか、どのような前提で判断したのか、を説明できる状態であることです。

また、ここまで検討しても分からなかったことがあれば、それも含めて書き出しておきましょう。

分からなかったことは、次に検討すべき「問い」になるかもしれません。

ノートを書くツール選びについて

ノートを書くにあたって、まず「どのツールを使うか」を決める必要があります。ただし重要なのは、ツールそのものではなく「問いを整理できるかどうか」です。

まずは手元にあるもので書き始めてみて、そこから自分に合うツールを見つけていくのがよいと思います。

ツール選びのポイント

あまり難しく考える必要はありませんが、次のいくつかの点ができれば使いやすいのではないかと思います。

すべてを満たすツールはありませんので、自分が何を重視するかを軸に選ぶのがよいと思います。

• 他の人と共有できること
  • 関係者が標準的に使えるアプリやサービスであること
• 構造化できること
  • 見出しやリストなどで意味づけしながら整理できること
• 表が作成できること
  • 条件整理や比較がしやすくなる
• 画像が扱えること
  • 図解によって理解を助けられる

ちなみにAIで再利用するなら

ノートをAIに読ませて再利用する場合は、Markdown形式が人にもAIにも読みやすく、構造が扱える点で適しています。

Markdown形式で出力できるかどうかを確認するとよいでしょう。

主なツール

ちなみに私は主にOneNoteを使っていますが、Markdown形式で出力できないため乗り換えを検討中です。

• 紙
• メモ帳（Windowsアプリ）
• Microsoft Excel
• Microsoft Word
• Microsoft OneNote
• VS Code
• Obsidian
• Notion

ノートの実例①：提案のアイデア作り

過去に作成したノートを紹介します。このコラムのためにかなり簡略化・抽象化をしている点はご了承ください。実際はもっとごちゃごちゃしています。

タイトル

「A社×IDコラボ提案アイデア出し」

目的

A社とコラボレーションして実現できる提案のアイデアを考える

前提

対象

• A社のIT事業部門、IDのITインフラ事業部門

ねらい

• A社はIDの販路を利用した外販の拡大
• IDはA社グループへの深耕

ねらわない

• 目先の売上

参考資料

• A社のとある取り組みに関するレポート
• A社のメディアインタビュー記事や動画

検討

調査結果の整理

• A社の強み・弱み
• IDの強み・弱み

考察

• A社の課題・IDの課題
• お互いの課題にお互いの強みを生かせる部分がある。
• A社は課題に対する取り組みを行っているものの、インタビューなどで読み取れる成果が小さかったため、課題は引き続き抱えているものだと推測できました。

仮説

• A社の持つ視座や方法論と、IDの持つ技術力や現場対応力がシナジーを生むのではないか？

結論

提案アイデア①

提案アイデア②

ノートの実例②：技術的な検討

こちらは案件のメンバーに作ってもらったノートです。

タイトル

「DBMSのログ出力レベル検討」

目的

• 開発環境のデータベース管理システム（以下、DBMS）における適切なログ出力レベルを決定する

前提

• 現状の問題
  • DBMSのログファイルが肥大化し、空き領域を圧迫する一因となっている
• 背景
  • 重大度に関わらずすべてのログを出力する設定になっている（不要なログが出力される）
  • 有識者Bさんからも、ログの出力レベルを下げてもいいのではないかと既に意見をもらっている
• 現状の設定
  • 本件に関連しそうなDBMSの設定項目を列挙

検討

• 該当しそうな設定項目とパラメータを発見
  • 設定項目とパラメータの概要
• ログ出力レベルの検討

• 2、3に変更しても不要なログ出力はなくならず、現状の問題点がほとんど解消されない。
• 1に設定すれば現状の問題点が解消される。エラーログなどは別の設定項目で出力を制御しているため、ここの設定に関わらず重要なログの出力は維持される。

結論

• ログ出力レベルを以下の通りに変更する
  • ログ出力の設定項目名 = 1

おわりに

AIによって答えに辿り着くこと自体は、以前よりもずっと簡単になりました。その一方で、「何を問うか」によって結果の質が大きく変わる時代になっています。

今回紹介したノートは、特別なテクニックではありません。ただ、問いを整理しながら考えるというシンプルで本質的な方法です。

最初は上手く書けないかもしれませんが、大切なのは、問いを持ち、書き出し、整理しながら考えることを繰り返すことです。

やがて、辿り着く結論の質が変わっていくことを実感できるはずです。

まずは小さい「問い」から、試しにノートを書いてみてください。

当サイトの内容、テキスト、画像等の転載・転記・使用する場合は問い合わせよりご連絡下さい。

エンジニアによるコラムやIDグループからのお知らせなどを
メルマガでお届けしています。