【Kindle出版】例外処理の思考で書く。経験を「次世代の道標」に変える設計
こんにちは、Hibikiです。
本記事は、「ITエンジニア×Kindle出版の体系化」シリーズです。
その名も「Chi. （チ。）」プロジェクト。
なぜ「Chi.」なんて名前を付けているのかは、第1回の記事をご覧ください。
「Chi.」プロジェクトは、私たちITエンジニアが「体験したこと、考えたこと、感じたこと」という実践知を1冊の書籍にまとめ、本当に価値あるものを次世代につなぐ活動です。
初回の記事で、「ITエンジニア×Kindle出版」の体系は大きく分けて、以下の4つがあると説明しました。
1️⃣技術トレンドからテーマを決める
2️⃣テーマ内で比較検討する
3️⃣比較結果を基に深堀りする
4️⃣比較・深堀りを発信する
今回は、「3️⃣比較結果を基に深堀りする」を具体化していきます。
「3️⃣比較結果を基に深堀りする」に関しては、以前次の記事で深掘りの方向性、深堀りのレベル、深掘りの方法について考察しました。
今回は、私たちの実践知の中でよりフォーカスすべきものについてどう深掘りしていくかを見ていきます。
「よりフォーカスすべきもの」とは何でしょうか？
それは「私たちがシステム開発・導入プロジェクトの中で直面した問題と、その問題に対するアプローチ」です。
「どうするべきか」という正解、少なくとも正解っぽい内容は、きっとAIが教えてくれます。
しかし、「なぜ、あの時プロジェクトは大炎上してしまったのか」という泥臭い問題点は、あのピリピリとした緊張感の中に身を置いた人間にしか語ることができません。
だからこそ、私たちが経験してきた問題が重要な意味を持つのです。
これは、「デザインパターンとアンチパターンの関係」に似ています。
デザインパターンは、今までの実績を基にベストプラクティスを抽出したパターンであり、これはAIが得意とする分野でしょう。
一方、アンチパターンは失敗事例の集合であり、私たち人間が、時には感情と言う移ろいやすいものにより引き起こす問題とその特徴を示したパターンです。
デザインパターンは思い切ってAIに任せてしまえばいい。
「あの時、何が私たちの焦りを生み出し、ミスにつながったのか」
私たち人間は感情という不安定な変数を持つシステムと捉えることができます。その変数がどのようなトリガーで変わり、どのような結果を引き起こすのか。
私たち人間が作り出す問題の根本原因をまとめた「アンチパターン」こそ、AI時代に私たち人間が次世代に残す価値を持つと思いませんか。
ITの仕事を長く経験していれば、成功ばかりではなかったはずです。ちょっとしたミスでお客様の信頼を損なってしまったり、大炎上プロジェクトで四苦八苦した経験もあるでしょう。
その経験をまとめ、アンチパターンとすることで、私たちの今までの苦労は次世代に引き継ぐ価値に昇華できます。
では、私たちが直面した問題をどのように深掘りしていくのが良いでしょうか？
その拠りどころは、私たちが仕事の中で活用してきた「設計思考」です。
システムを構築する時、その設計の半分は例外処理であることを私たちは知っています。
書籍の執筆も同じです。読み手が未来の現場で直面する問題を先回りして解決する「例外処理の物理設計」。
本記事では例外処理の設計を行う流れを参考に、問題の深掘り方法を見ていきましょう。
1️⃣例外処理のポリシー設計
2️⃣障害復旧のトレーサビリティ
3️⃣例外ハンドリングの最適化
1つずつ見ていきましょう。
1️⃣例外処理のポリシー設計
システム開発において、例外処理の設計を行う場合、発生した例外をどのようにユーザに伝えるかという全体の設計を行います。
通常、プログラムは何層にも分かれており、下の層で発生した例外を、いきなりユーザインタフェース層まで送ることは稀です。
プログラムの奥の方で発生した例外は、技術的バックグランドの無い人には理解できない情報であり、そんな情報を素のままユーザに見せても、ユーザはどうしたら良いか路頭に迷うでしょう。
通常は、中間の層で例外をキャッチし、ユーザがエラーの回復に動けるような情報を付加して、ユーザにエラー情報を伝えます。
書籍に当てはめて考えてみるとどうなるでしょうか？
私たちが仕事の中で体験した様々な障害は、それ自体有益なものですが、体験をそのまま読み手に伝えることは、プログラムの奥の方で発生したエラーをそのままユーザに届けるようなものです。
プログラムの場合は、ユーザが自らエラー解消に向けて動き出せるような情報を付加するように、書籍の場合も、読み手が読書後に動き出せる情報を載せる必要があります。
つまり、体験という情報を伝えるだけでなく、読み手にどのように動いてほしいかまでイメージする必要があります。
そのような、読み手の動きまで含めた全体を設計することで、私たちの実践知が真に有用な情報として読み手に届くようになります。
2️⃣障害復旧のトレーサビリティ
プログラムにおいて、例外の情報はなにもユーザだけに必要なものではありません。ユーザから問い合わせを受けて、保守担当者が原因の解析を行うこともあります。
たとえば、ユーザの入力値に誤りがあり、例外が発生してしまったとしましょう。
この例外について、「入力値の処理でエラーが発生したこと」「エラーが発生した場所」しか記録されていなかったら、どうでしょうか？
入力値の処理で例外が発生してるのだから、入力値が分からなければ原因がわからないのは明白です。
つまり、記録しておく例外情報は、例外発生時に保守担当者がどういう情報を必要とするのか想像し、必要な情報が残るように設計しておく必要があります。
これを書籍に当てはめたらどうなるでしょうか？
書き手＝開発者、読み手＝保守担当者と位置づけると、将来読み手が直面するであろう問題の解決に必要な情報を載せておくことになります。
開発者と保守担当者の間に情報格差があるように、書き手と読み手には当然ながら情報格差があり、書き手にとっての当たり前が読み手にとっての未知であることは、往々にしてあります。
技術系の書籍にありがちなのは、
ある設定値に「1」という値をセットする
とだけ書いてあること。
「1」が何を意味するのか、なぜ「1」をセットしなければいけないのかの説明が省略され、重要性を理解できない読み手がその設定を飛ばしてしまったり、異なる値をセットしてしまい、想定と異なる動きになることです。
何日も悩んだ障害の原因が、設定値1つだったなんてことは現場ではよくあることです。
私たちが伝えたいことばかりに焦点を当ててしまい、私たちにとっての「暗黙の前提」を読み手にも押し付けてしまう。これは避けなくてはいけません。
私たちにとっての「暗黙の前提」を丁寧に説明しておくことで、私たちの実践知のトレーサビリティが向上します。
これは単なる「優しさ」ではなく、読み手が直面するであろう問題を先回りし、自力で解決できるようにする、書き手のプロフェッショナリズムです。
プログラムのバグをゼロにできないように、読者の躓きもゼロにはできない。だからこそ、復旧のための情報を戦略的に置いておくのです 。
3️⃣例外ハンドリングの最適化
何かシステムを利用していてエラーが発生した時に「システム管理者にお問い合わせください」というエラーメッセージを見たことがあるでしょう。
詳細は書いておらず、ただ管理者に問い合わせるように、と。
ユーザでは回復不可能な原因のエラーが発生したり、全く想定外のエラーが発生した場合には、ユーザに何が起こったかを説明しても対処のしようがないので、管理者に問い合わせるようにとだけ、伝えることはよくあります。
書籍に関しても、1冊にすべてを詰め込もうとするのは、システムで言えばすべての運用、保守をユーザにやらせようとすることと同じです。
その書籍で注力すべき本筋というものがあり、その本筋を進めるにあたって読み手が躓くポイントに絞った解説をすべきです。
私たちの主目的は実践知を読み手に深く理解してもらい、今後の仕事に活かし、さらに発展させてもらうこと。
説明しすぎることで、読み手が本筋を見失ってしまっては本末転倒です。
実践知を伝えるにあたって何が本筋かを見極め、その道を妨げる例外が何であるかを詳細に特定し、先回りして例外の対処方法を載せておく。これが理想の設計です。
では、本筋以外で躓きそうなポイントはどうしたら良いでしょうか。
書籍ではなく、別に用意するという方法があります。
プログラミングに関する書籍でよくある方法は、Githubでソースコードを公開すること。
詳細は直接ソースコードを参照してもらうことで、書籍では本筋の説明に注力できるというメリットがあります。
これは役割を分離し、疎結合のインタフェースを持つことと同じです。
書籍は私たちの実践知の本筋に焦点をあて、本筋を邪魔するものはGithub等の別リソースにて表現する。
「Chi.」プロジェクトは、私たちの実践知を書籍にまとめる活動ですが、書籍以外を否定する必要はありません。
実際のサービスも複数のシステムの集合で構成されるように、書籍＋別リソースで構成し、私たちの実践知をより効率的に伝えるアーキテクチャを採用しましょう。
📚️まとめ
本記事では、例外処理の考え方を活用した「深堀り」する方法について解説しました。
1️⃣例外処理のポリシー設計
私たちの体験をそのまま伝えるのは、プログラムの奥深くで発生したエラーの情報をユーザにぶつけるようなもの。
読み手が読了後に迷わず次のステップへ踏み出せるよう、「情報のユーザーインターフェース」を設計しましょう。
単なる事実の羅列ではなく、読み手の動きを深堀りし、読み手をリードする全体設計こそが、私たちの実践知を真に有用なバトンへと変えます 。
2️⃣障害復旧のトレーサビリティ
ベテランが陥りがちな「暗黙の前提」を排除し、「なぜその判断をしたのか」というコンテキストを丁寧に記述します。
これは、読み手が現場で直面する問題を自力で解決可能にするための、書き手としてのプロフェッショナリズムであり、実践知のトレーサビリティを確保する物理設計です 。
3️⃣例外ハンドリングの最適化
一冊の書籍にすべてを詰め込む「モノリス」な構成を避け、役割の分離を行いましょう 。
書籍は実践知の本筋にフォーカスし、枝葉の技術詳細はGitHubなどの外部リソースへと切り出します。
書籍と外部リソースを疎結合なインターフェースで繋ぐ「知のアーキテクチャ」を採用することで、読者の認知負荷を下げつつ、最も伝えたいメッセージをダイレクトに届けることができます 。
会社で責任ある立場にある人にとって、自身の失敗体験を公にすることは恥ずかしさもあるでしょう。
しかし、私たちが語るアンチパターンこそ、AIには生み出せない、血が通った実践知です。
その実践知を独り占めせず、次世代に共有すること。それこそ、私たちが果たすべきプロフェッショナリズムではないでしょうか。
アニメ「チ。」の登場人物であるフベルトも
「不正解は無意味を意味しない」
と言っていましたね。
私たちが経験した不正解を隠してしまっては、それこそその経験は無意味になってしまいます。
私たちが経験した不正解を徹底的に解析し、アンチパターンとして昇華してこそ、次世代が躓かないための道標としての意味が生まれてくるのです。
さあ、私たちの実践知を形にする時です。私も一緒に、挑戦を続けます。
「Chi.」プロジェクトを応援していただける方、一緒に挑戦していきたい方はぜひフォロー、スキ、コメントをお願いします。
皆さんのリアクションが、この挑戦を続ける大きな力になります。
「ITエンジニア×Kindle出版」のシリーズをマガジンにまとめていきます。
マガジンもフォローいただけると、漏れなく更新を確認できます！
#Kindle出版
#Kindle作家
#プログラマ
#ITエンジニア
#実践知
#例外処理
#障害復旧
#Chi
#Hibiki