なぜQiitaで「ポエム」が書かれるのか
そもそも一般的な意味でのポエムとは、当たり前ですが「詩」であり、形式を縛られない自由詩のことらしいですね。
「ポエム」という言葉で思い出す話となると、日本のIT関連のこととしては、その昔にP2Pファイル共有ソフトがポエムを共有するために使われようとしたことを思い出します。
そういったこともあるのか、全く関係ないのか定かではありませんが、このQiitaでも5000以上もの記事についているタグになっています。
記事の多くは、いわゆるプログラミングなどの直接的な技術ではなく、その周辺の事柄が多いようです。
経験談やそこから考えたこと、教訓、ソフトウェア開発の体制や人間関係の話、などですね。
過去の考察
この「ポエム」の問題は過去にも考えられたようです。
とても良い定義だと思ったので、引用します。
ポエムとは日本語で言うと「詩」ですが、ソフトウェア開発の分野ではより狭義に「表現の厳密性や定性・定量データを必ずしも重視せず、個人の思いや価値観をその人自身が適していると思った表現でそのまま文章化したもの」といった意味合いで使われます。
ソフトウェア開発は、少人数での開発も多く、そういう場合は個々の「人」の影響が大きくなります。
また、技術選定などは、変化が速い分野だと先が読めないことも多く、長く考えている間に変化してしまうこともあり、個人の情熱にかけるほうが有効な場合もあるかと思います。
チームのメンバーを鼓舞することが、成果に繋がる場面もあるでしょう。
そういったことから、ソフトウェア開発における文書とはいえ、即興的に書かれた感情的な要素のほうが重要になってくるかと思います。
更に、以下の記事は「ポエム」と呼ぶことの問題をよく整理できていて素晴らしいと思います。
たぶん「エッセイ」と呼び方だけを変えたとしても、これらの問題は解決しないでしょう。
問題が解決しないのであれば、ただ手間をかけるだけになるので、それはむしろ良くないことです。
Qiitaの中で「エッセイ」は、現時点で50弱程度のしか記事がありません。
Qiitaで記事を書いている人に限っても、多くの人がエッセイよりもポエムが適切だと判断していることの表れでしょう。
もちろん、ただの慣習としてタグを付けていることのほうが多いとは思うのですが。
つまり、ソフトウェア開発において感情は重要なものだから
ポエムは感情表現であり、ソフトウェア開発においてはもちろん技術は重要な要素ですが、開発者自身は人間であり、その要素を無視することはできません。
むしろ、感情的な問題が、プロジェクトやプロダクト、ソフトウェアを使ったビジネスを破綻させることもあるでしょう。
また、変化の速い業界では、論理性も重要ですが即興的に動けることも大事です。
そういった要素を勘案すると、落ち着いたイメージのあるエッセイというよりは、より感情的な表現を重視する「ポエム」という呼称のほうが、名前・タグ付けとして妥当ということになります。
古典的なエッセイの著作を3つほど
ソフトウェア業界ではその昔から、純粋にコンピュータやプログラミング、コーディングのことではない、人間関係やプロジェクト運営の問題を考えた名エッセイがたくさんあります。
これらはポエムというよりは、達人たちがその長年の豊富な経験を文章として練り上げて残してくれたものです。
いつかこんなエッセイが書ければ良いな、と思いつつ、読むだけでも楽しく役にも立つので、なかなか悩ましいところです。
人月の神話
「ポエム」は「エッセイ」のほうが正確じゃない？と思いついたのは、この本を読んでいるときでした。
初版の序文の部分に以下のような記述があります。
本書はエッセイであって教科書とは違うから、参考文献と注記はすべて巻末にまとめてある。
本人がこの本はエッセイだと書いているので、この本はエッセイ集です。
この「人月の神話」という本は、2章に「人月の神話」、16章に「銀の弾丸などない」という、IT業界ではとても有名なエッセイを含んでいる、古典的名著なのです。
とても残念なことに著者は故人となられました。
しかし、本書は全く古びていません。未読の方はぜひ一度目を通してみてください。
こんな昔から今と同じようなことで苦しんでいたんだと思えるでしょう。
そしてソフトウェア開発にある難しさの本質的な部分について考察されています。先達の考察を受け継ぎ、更に発展できれば理想的ですね。
アドレナリンジャンキー
エッセイ集というよりは、ソフトウェアを運営する上での人に関するパターン集です。
この本は共著ですが、メインの著者であるトム・デマルコは、他にも「ピープルウェア」や「デッドライン」、「熊とワルツを」といった名著があります。
技術的なパターン集だと、これも既に古典になっているGoFのデザインパターンや、エンタープライズアプリケーションアーキテクチャパターンなどが思い浮かぶと思いますが、この本は人にフォーカスしています。
ソフトウェア、特にプログラミングでは名前が重要です。その抽象的な概念を適切に名付けることで、私達は対象を表現し、理解し、更に共通の認識を持つことで適切にコミュニケーションできます。
むしろ、同じ言葉を別の対象だと思いあっていたり、別の対象を同じ言葉で示してしまっていることが往々にして問題を引き起こします。
そもそもは建築分野でのパタン・ランゲージから派生したソフトウェアのパターン集ですが、名付けの重要性を体感するのに良い著作だと思います。目次でパターンの名前を見るだけでも楽しめる本です。面白そうなところだけ拾い読みするだけでも良いと思います。
Joel on Software
ソフトウェアを開発するだけでなく、ブロガーやソフトウェア企業の経営者としても有名なジョエル・スポルスキのブログをまとめた著作です。
国内で有名なところでは、Stack OverflowやPivotal Trackerを作り、更にその昔はExcelの仕様を書いていた、という人物です。
この本の記述はユーモアと知見に富んでいて、当時を知る人であればとても面白く読めると思います。
過去には記事の翻訳が公開されていましたが、今はありません（インターネット・アーカイブには残っているようです）。紙の本も絶版のようです。
しかし、Kindleで買えるようになっています。素晴らしいですね。
この本も２０００年頃のブログ記事を集めたものになっているので、少々話題は古いですが、ソフトウェア開発とそのビジネスの難しさは変わっていないと思うので、参考になる部分は大きいと思います。
まとめ
変化が速いソフトウェア・IT業界ですが、まだ人間がその重要な要素になっています。
そして人間と感情は切り離せません。
むしろ今年流行したLLMによるコード生成が今後も順調に発展していくのであれば、人間の感情をもっと尊重・重要視するべきなのかもしれません。
古典となったエッセイ集は、達人たちがその長い経験から練り上げたものですが、ポエムはもっと即興的です。その即興性が「詠う」ことに繋がり、すなわちポエムとなって世に現れるのかもしれません。
ポエム力を上げるならルールの少ない短歌から初めてみるのが良いのでは
いきなり自由詩はハードルが高いです。人は真の自由に戸惑うものです。
しかし、季語を使うなどルールの多い俳句もなかなか厄介なものです。
そんなときは、比較的簡単に始められる短歌がオススメです。
プログラマは言葉に気を使うものですし、七五調は日本語として口当たりが良くなるので、ポエムを書く際の感情表現も高まるものと思われます。
以下の本は、短歌を始めるにあたって、とても参考になるのでオススメです。
ではここで一句1
ポエムより 古典に倣い エッセイと 考えたけど やはりポエムだ
-
ChatGPTで添削を頼んだところ、この短歌がなぜ重要なのかという説明がないので削除すべきだ、という指摘を受けました。AIにはまだまだ成長の余地があるようですね。 ↩