Kindle出版における「try-catch-finally構文」を用いた文章術

こんにちは、Hibikiです。

本記事は、「ITエンジニア×Kindle出版の体系化」シリーズです。
その名も「Chi. （チ。）」プロジェクト。
なぜ「Chi.」なんて名前を付けているのかは、第1回の記事をご覧ください。

「Chi.」プロジェクトは、私たちITエンジニアが「体験したこと、考えたこと、感じたこと」という実践知を1冊の書籍にまとめ、本当に価値あるものを次世代につなぐ活動です。

初回の記事で、「ITエンジニア×Kindle出版」の体系は大きく分けて、以下の4つがあると説明しました。

1️⃣技術トレンドからテーマを決める
2️⃣テーマ内で比較検討する
3️⃣比較結果を基に深堀りする
4️⃣比較・深堀りを発信する

本記事では「4️⃣比較・深堀りを発信する」を具体化していきます。

前回の記事では、「例外処理」をキーワードに私たちが経験した問題とその解決へのアプローチについて深堀りする方法を見てきました。

しかし、深堀りしたといっても、まだそれは私たちの頭の中にあるスパゲティコードの一部でしかありません。

ITエンジニアを長く経験していると、様々な経験をします。

大炎上案件に入ったり、原因不明の障害に悩まされたり、重要な本番データを消してしまったり、振り返ると恥ずかしいコードを書いてしまったり。

私たちの実践知は、それら多くの経験から学んだツギハギだらけのスパゲティコードからなるレガシーシステムと同じです。

きちんと機能していたとしても、他の誰もメンテできない属人化した知識になっているのではないでしょうか。

「Chi.」プロジェクトを通して私たちが実現したいことは、そのスパゲティコードという「技術負債」を次世代に押し付けることではなく、APIというモダンなアーキテクチャにリファクタリングして「技術資産」として残していくことです。

プログラミングのリファクタリング方法は分かっていても、私たちの経験・考え・感情をどうリファクタリングして、読み手に伝えれば良いでしょうか？

そのヒントも私たちの知識の中にあります。

モダンなプログラミング言語での例外処理というとtry-catch-finally構文がありますが、これを私たちの経験のリファクタリングに応用します。

try-catch-finally構文を型として文章に応用すれば、日頃、仕様書という無機質な文書しか書いていない人でも、問題が発生したときのあの空気感を読み手に伝えることができます。

try, catch, finallyの各ブロックを使った文章構成は次の通りです。

1️⃣tryブロック：ハッピーパスの裏にある設計思想を説く
2️⃣catchブロック：例外の根本原因を紐解く
3️⃣finallyブロック：実践知のアンチパターン化

モダンな言語でのプログラミングを学んだことがない人には、try-catch-finally構文は初見かもしれませんが、順番に説明していきますので、ご安心ください。

1つずつ見ていきましょう。

1️⃣tryブロック：ハッピーパスの裏にある設計思想を説く

実際のプログラミングにおけるtryブロックは、正常系ロジックを記述する場所です。

例外が発生する可能性のあるコードをtryブロックの中に書くことで、実際に例外が発生した時にその例外をcatchブロックで捕捉することが出来ます。

これを書籍に当てはめてみると、tryブロックは「ハッピーパス」を書くことになります。

ハッピーパスとは、エラーがなく、理想的なルートのこと。

なぜそのルートが自分にとって理想的だったのかという、そのルートの設計意図を書くことで、問題発生の背景というコンテキストを読み手と共有することができます。

最終的に伝えたい内容は、どういう問題が発生し、どう解消できるのかというアンチパターンです。

その背景には必ず私たち人間が「何を考えて、どう行動したのか」という不安定な変数が存在します。

その変数の説明を加えることで、読み手による追体験を容易にします。

ハッピーパスという正解だけならAIで書けます。

だからこそ、tryブロックの骨子はAIを使って下書きし、そこに私たちの意図・考えを加えるという分担を行うことで、限られたリソースを有効に活用することができます。

これはすなわち、AIとのペアプログラミングです。

tryブロックはAIの力を最大限活用できるパートです。有効活用していきましょう。

2️⃣catchブロック：例外の根本原因を紐解く

catchブロックは、発生した例外のハンドリングを行う場所です。

実際のプログラミングでは、エラーログを出力したり、例外に関する追加情報を付加したりします。

捕捉した例外を加工してユーザに情報を伝えたり、問題の解消に関する処理を入れたりします。

書籍に当てはめてみると、発生した問題の説明や、その解決へのアプローチを書くことになります。

このパートこそが私たちの実践知を伝えるセンターコートです。

tryブロックで説明した内容をベースとしつつ、なぜ問題が発生したのかという根本原因を紐解いていきます。

システムが根本原因を生み出しているケースもゼロではありませんが、人間という不安定な変数が問題を引き起こしているケースが多いでしょう。

時間がない中で焦って修正したプログラムが他の障害を引き起こしたり、チーム間でお見合いしたために十分なケースがテストできないまま本番リリースされてしまったり、と。

通常、論理的に考えれば発生しないような問題が現場ではよく発生します。

AIは色々考えて回答してくれているように見えますが、人間のような不安定な変数の扱いはまだ長けていません。

デザインパターンという正解ロジックはAIに任せてしまえばいい。

一方で、人間という不安定な変数が引き起こす問題への対応は、アンチパターンとして私たち人間が書き残していくものです。

だからこそ、私たちの泥臭い経験が実践知として活きてくるのです。

現実世界は様々な事情が絡まり合っており、全く同じケースが発生することは稀でしょう。

エラーの原因が同じであったとしても、そのエラーが発生するコンテキストが異なるからこそ、問題点をあらかじめ検知して、問題が顕在化しないように対処することができず、現場では日々、様々な問題が発生するのです。

どうせ問題が発生するのだから、そのコンテキストを共有しても意味がない、などとはプロフェッショナルな私たちは思わないはずです。

私たちに出来ることは、毎回事情が異なるコンテキストの情報を1つずつ地道に積み重ね、次世代の人たちが現場で生き残る確率を少しでも上げることです。

これこそが、「Chi.」プロジェクトが目指すべき道です。

3️⃣finallyブロック：実践知のアンチパターン化

最後はfinallyブロックです。finallyブロックは、後片付けを行う場所です。

実際のプログラミングであれば、DB接続をクローズする等、主にリソースの解放を行います。

書籍に当てはめてみると、問題解決の知恵を再利用可能なAPIにリファクタリングすることになります。

ほとんどのケースにおいて、問題は人間という不安定な変数により引き起こされます。

私たちの実践知は、その不安定な変数をどう扱い、どう問題を乗り越えるかという点に重きを置いているはずです。その内容を、形式知へと変換していきましょう。

では、人間という不安定な変数をどう扱うのか？

問題は、往々にして大変な状況の時に発生します。

「なぜ、このタイミング？」と思うことも多いでしょう。

だからこそ、私たちが伝えていく実践知も、一番大変な状況で、読み手が一番不安定な時に活用できるものになっているべきです。

一番不安定な時でも、人間が間違えずに対応できるようにする術を私たちは現場で数多く見てきているはずです。

それはチェックリスト等の表形式、フローチャート等の図解です。

不安定な状態の時に、人に冷静な判断を期待しても実行することはできません。

私たちが伝える実践知を、頭に叩き込んでおいて、一番大変な時にも間違えずに思い出せる人なんていません。私たちですら、焦っていれば忘れてしまったり、正しく実践できないでしょう。

だからこそ、脳に負荷をかけずに理解することが出来、冷静な自分に戻れるフォーマットであることが大事です。

長い文章では不安定な時に理解を誤ってしまう恐れがあります。

一方、チェックリストやフローチャートであれば、ボリュームを絞り込める分、脳の負荷を下げられます。

いざとなった時に安全装置のように機能するフォーマットこそ、私たちの実践知を表現するのにふさわしいものと言えます。

そして、現場特有のものは削ぎ落とし、汎化させ、生み出されたチェックリストやフローチャートは、もはやオリジナルのアンチパターンです。

これこそ、AIには生み出せない、現場での苦悩から生み出された私たちの独自の価値になります。

次世代に貢献するアンチパターンを数多く、生み出していきましょう。

こうして整理されたアンチパターンは、私たちの仕事にも役立ちます。

今まで頭の中に断片化された状態で保存されていた実践知が、書籍というデータベースに落とし込まれています。いざとなった時に書籍を見れば良いという安心感は、脳という貴重なリソースの解放を促します。

このリソース解放は、次の一手を打つための「攻めのクリーンアップ」です。

空いたバッファを使い、新しい技術に学び、挑戦する楽しみに変える。

これこそが、「Chi.」プロジェクトを通して、私たちが手に入れる真の生存戦略ではないでしょうか。

📚️まとめ

本記事では、try-catch-finally構文を応用した実践知の表現方法について解説しました。

1️⃣tryブロック：ハッピーパスの裏にある設計思想を説く

• 理想的なルートの言語化：エラーのない理想的な「ハッピーパス」を記述し、なぜその設計が最善だったのかという「設計思想」を明らかにします 。

• 人間固有のコンテキスト共有：AIが得意とする「正解」の記述に、私たちが何を考えどう行動したかという「意図」を乗せることで、読み手との深い共感を生みます 。

2️⃣catchブロック：例外の根本原因を紐解く

• 例外発生のコンテキスト共有：問題が発生する現場の状況は様々。どういう状況が問題発生につながったのかを明らかにします。

• 「不安定な変数」への対処：論理だけでは割り切れない「人間という不安定な変数」が引き起こす問題と、その問題へのアプローチを説明します。

3️⃣finallyブロック：実践知のアンチパターン化

• 再利用可能なAPIへの変換：チェックリストやフローチャートなど、有事の際でも脳に負荷をかけずに活用できる「知恵のAPI」へリファクタリングします 。

• 脳のリソース解放：実践知を書籍という外部データベースに落とし込むことで、ベテランの貴重な脳メモリを解放します 。

• 未来のための「攻めのクリーンアップ」: 解放されたバッファを次の技術習得や挑戦に充てることで、AI時代を生き抜く「真の生存戦略」を確立します 。

これは、「チ。」の初期の重要人物「フベルト」が残した言葉ですが、現場での問題という不正解を放置したままでは、やはり意味がありません。

私たちが現場で苦労して乗り越えた炎上案件、時間をかけて解析した原因不明のエラー、これらを乗り越えた知恵を書籍という形で残し、そこに意味を与えるのは私たちです。

私たちITエンジニアは普段、仕様書という無個性なドキュメントの作成に浸かってしまっています。そのため、読み手を引き込む文章に苦手意識を持っている人は、私だけではないでしょう。

しかし、本記事で紹介したように、私たちに馴染みの深いtry-catch-finally構文を応用し、私たちの実践知をアンチパターンにリファクタリングすることが可能です。

そして、私たちにとっての真の生存戦略は、書籍化によりクリーンアップされた脳という貴重なリソースの活用です。どんどん進化するAIをフル活用し、さらなる価値を生み出す好循環を生み出していきましょう。

さあ、私たちの実践知を形にする時です。私も一緒に、挑戦を続けます。

「Chi.」プロジェクトを応援していただける方、一緒に挑戦していきたい方はぜひフォロー、スキ、コメントをお願いします。

皆さんのリアクションが、この挑戦を続ける大きな力になります。

「ITエンジニア×Kindle出版」のシリーズをマガジンにまとめていきます。

マガジンもフォローいただけると、漏れなく更新を確認できます！

#Kindle出版
#Kindle作家
#プログラマ
#ITエンジニア
#try
#catch
#finally
#アンチパターン
#実践知
#Chi
#Hibiki