スタディサプリ開発メンバーでSoftware DesignのGraphQL特集を執筆しました！

はじめに

こんにちは。スタディサプリでプロダクトプラットフォームの開発を行っている @highwide です。

この度、スタディサプリの開発メンバーで技術評論社様の「Software Design 2024年9月号」の第一特集「実例から学ぶ！GraphQLでアプリケーション開発現場における使いこなし方を徹底チェック」を執筆しましたので、紹介させていただきます。

gihyo.jp

記事の内容について

全5章の構成で、下記のような章立てとなっています。

第1章「GraphQLとは - 利点・注意点を整理して輪郭をつかむ」(@ywada526)
第2章「GraphQL導入 - クエリを書いてデータ取得を試してみよう」(@YutaUra)
第3章「サーバサイドの実装 - TypeScript＋Apollo Serverでサーバを構築する」(@y-kaanai)
第4章「クライアントアプリケーションの実装 - GraphQLならではの設計と実装を押さえる」(@highwide)
第5章「GraphQLアプリケーションの実運用 - パフォーマンス改善，セキュリティ対策，APIの進化戦略のプラクティスを押さえる」(@indigolain)

1章ではGraphQLという技術の歴史や概説、2章ではGraphQLという技術の仕様、3章と4章で実際にGraphQLを利用したアプリケーションの実装、5章では実際に運用していてのTips...という流れで執筆を分担しました。また、内容のレビューにあたっては、現在進行系でスタディサプリのGraphQLプロジェクトに携わっているメンバーだけでなく、GraphQLを触ったことがないからこその目線でレビューをしてくれた人や、すでにスタディサプリを離任している人など、多数の協力を得て上梓にこぎつけることができました。(ありがとうございました...！)

サンプルコードはこちらで確認していただけます。

github.com

記事のオススメポイント

雑誌の1つの特集の中で、「GraphQLとは」から始まり、実際のアプリケーションコードの実装例まで説明しているので、GraphQLを聞いたことはあっても触ってきたことがなかった方が、2024年にGraphQLを学び始める教材となるのではないかと思います。

また、スタディサプリとしてGraphQLを利用してきたうえでの知見に基づいて記事を書いていますので、単に「GraphQL導入してみた」にとどまらない現場の使いこなし方や考え方を学べることを企図しました。GraphQLを業務レベルで実践的に利用していきたい方や、既に運用している方にも刺さる内容になっているといいな...と考えています。

記事を書くに至った経緯

今回スタディサプリメンバーで執筆に至った経緯ですが、以前に私がイベントで利用した以下の発表スライドを見てくださった編集部の方が声をかけてくださったからでした。

「社内で分担して40〜50ページの執筆は可能か」と声をかけていただいたのですが、自分は商業出版にせよ同人出版にせよ技術記事の執筆の経験がなく、不安を感じて社内の random-tech-talk というchannelに相談を持ちかけて、集ってくれたのが上述のメンバーです。

また、社内には技術イベントでの登壇を多数行っている @chaspy や、「つくって、壊して、直して学ぶ Kubernetes入門」という書籍の商業出版を経験している @aoi1 らをはじめとした心強いメンバーたちが多数レビューを申し出てくれて、執筆に挑むこととなりました。

www.shoeisha.co.jp

執筆、大変だったこと

ここからは、どんなことが今回の記事の執筆において個人的に大変だったか、軽く振り返ってみたいと思います。

「原稿」と向き合う

ダメな人間であることを吐露するようですが、自分は締め切りに追われないとなかなか動き出せないタイプです。ですので、「締め切りまではまだちょっと時間あるけど、とはいえ、それなりに進捗を出しておかないとダメな期間」は全然原稿に向き合えないことで自己嫌悪気味になったり、「いよいよ進捗がヤバい」という期間においては泣きながら(誇張表現)キーボードを叩き続けなくてはいけなくなったりと、シンプルに、原稿と向き合い続けることの大変さを体感しました。

shippitsu-random というchannelが最近できたので、原稿と向き合うためのドーパミンコントロールに「水シャワー」が有効という話を1章担当の @ywada526 としていました。

業務とのバランス

今回の執筆業務は「業務」として取り組んでいい旨を早い段階から会社に了承してもらっていました。ですので、所属するチームのスプリントプランニングにおいては「highwideは雑誌の原稿執筆に時間を割く」といったことを織り込んでもらいました。ありがたいことです。

一方で、わがままを言うようではありますが、もともと共有していたチームの目標に対して自分が貢献できないことに対してフラストレーションを覚えたのも事実です。会社や上司やチームメイトに応援していてもらってもなお、どこかで感じてしまう後ろめたさと上手に向き合うことはメンタルヘルスの上で大切だなぁと感じました。

また、1章担当の @ywada526、2章担当の @YutaUra、5章担当の @indigolainは同じチームに所属しているので、同じタイミングで業務がしにくくなるのは難しさがあったかと思います。プロダクト開発という業務を抱えながら、商業誌の編集スケジュールに合わせたアウトプット業務を行う難しさに直面した期間でした。

紙媒体ならではの制約

我々Web開発者にとって「1ページの大きさ」を「無限」と考えてもいいことは決して少なくありませんが、当然紙媒体ではそうはいきません。

特に苦労したのはコードサンプルです。当初は「誌面のコードをコピー&ペーストすれば動くアプリケーションがステップバイステップで完成する！」という構成を考えていましたが、限られた誌面ではむしろ「最低限ここだけ載せれば説明が成り立つ」というかたちでコードを削ることになりました。コードフォーマッターによる改行だと横幅を使いすぎてしまうかもしれない...といった悩みも新鮮なものでした。

自分の担当箇所については、当初は10ページくらい書いたつもりだったのに、全体の流れを簡潔にする、誌面に載せるコードを削る、レイアウトを考慮して文章を削る...といったことをしているうちに最終的に6ページになってしまったのには驚きました。

長ければいいわけではないとわかりつつも、「えっ、これだけ頑張ったつもりだったのに、6ページにしかならなかったんだ...」という気持ちは今も心のどこかにあって、自分が普段読ませてもらっている技術書のページ数のことを考えると、著者や編集者の皆様にあらためて畏敬の念を抱くのでした。