Zenn
📖

Flutterの技術メモが書籍になるまで

2023/06/04に公開
Flutter
初心者
ポエム
メモ
書籍化
idea

概要

ZennでFlutterのことをまとめて、Flutter実践入門を執筆したところ、動かして学ぶ!Flutter開発入門として書籍化して頂きました。

本記事は、書籍化の経緯を公開し、Zennでノウハウを公開することのメリットや、書籍化でどんな良かったことや大変なことがあったのかをお伝えするものです。

なお、本記事では、Flutterの良し悪しや堅苦しいエンジニア成長論などは深掘りせず、本書がどのような背景でZennで公開され、その後出版に至ったか、その過程でそのようなメリット/デメリットがあったかを中心にお伝えするものです。

箇条書きベースのメモに近いもので恐縮ですが、興味があるかたはご覧頂けると幸いです。
(語尾などもキレイに統一/推敲されておりませんが、ポエム/メモのため、細部は気にしないで頂けるとありがたいです)

以下のような方に、活用して頂けるかと思います。

  • 情報を公開してみたいが躊躇している方
  • 情報公開のメリットを確認したい方
  • 技術書(自分用/社内用なども含む)を書いてみたいという方
  • 書籍の出版ではどのようなことが行われるのかを知りたい方

タイムライン

本書に関連するターニングポイントは、下記のようになっています。

  1. 2020年7月：Flutterを知る
  2. 2021年4月：Zennで公開
  3. 2022年3月：書籍化のお話を頂く
  4. 2022年9月：原稿提出
  5. 2023年4月：執筆完了(5/17出版)

今回は、このターニングポイント前後でどんなことがあったのかを順番に記載していきます。

  • Part0:筆者のバックグラウンド
    • 1より前：Flutterを知る前
  • Part1:なぜZennの書籍で公開をしようと思ったか
    • 1と2の間：Flutterを知ってから、Zennで公開するまで
  • Part2:公開後のアップデート
    • 2と3の間：Flutterで公開してから、書籍化のご連絡を頂くまで
  • Part3:書籍化の決断と原稿作成
    • 3と4の間：書籍化のご連絡を頂いてから、原稿提出まで
  • Part4:推敲の日々
    • 4と5の間：原稿提出から、執筆完了まで
  • Part5:今後の展望
    • 5の後：今後やってみたいこと

Part0:筆者のバックグラウンド

経歴

  • 工業高校、大学、大学院、社会人と全て情報系

    • 良く言えば情報工学特化型、悪く言えば幅が無い

  • 基本的に技術系だが、最近は、テクニカルだけでなく育成や社間調整などを行うことも多々

    • 技術組織の運営などもしています

業務経験

  1. ソースコード解析/セキュリティ診断などの技術系の支援系業務
  2. 社内プロジェクト向けの内製プロジェクトマネジメントツールの開発
  3. ApacheKafkaなどの新技術検証
  4. 不動産業者や設備企業とコラボして、スマートマンションの実証実験
  5. 大規模なレガシー案件の1プロジェクトの移行、性能、構成管理担当
  6. 図面のデジタル化/3D化検証
  7. スマートライフ系のアジャイル開発
  8. 組織的なアジャイルを行うための人材育成/組織改革

興味がある事

  • ChatGPT/NovelAI/StableDiffusion
  • PlayToEarn
  • IFTTT、Node-Red
  • IoT
  • FinTech
  • プログラミング全般
  • パブリッククラウド
  • IaC。CICD。自動化
  • 数学/情報工学
  • 知識を体系的にまとめること

技術記事の執筆のきっかけ

  • 複雑なものを構造化/体系化/整理するのが、大好きで得意

    • 人にわかりやすく説明するのが得意

  • 大学時代に勉強が楽しく、なおかつ、ノウハウ間のつながりを整理するのが楽しかった

  • 社会人になってからもWebサイトやQiitaなどで情報を発信する

    • 業務で携われないことをプライベートで補う事が多い

Part1:なぜZennの書籍で公開をしようと思ったか

Flutterにたどり着いた経緯

  • 2018年ぐらいからFinTechをしており、Webでもスマホでも資産やレートが見れるアプリが欲しかった
    • 画面だけならレスポンシブなWebサイトでも良かったが、ログインや設定変更などの機能的なものも欲しくなった
    • 最初は、ノーコード/ローコードのサービスで良いと思っていたが、痒いところに手が届かない
    • 調べていったらFlutterという便利なものがあるのを知った(2020年の6,7月ぐらい)
      • この時、スマホアプリとWebアプリが同時に作れるクロスプラットフォームという概念も初めて知る

ノウハウをZennの書籍で整理しようと考えた理由

  • アウトプットを作りながら勉強をするスタイルを持っていた

    • 人に教えることは教わること
      • 人のためというよりも、自分が学ぶためのもので、一番の読者は自分
    • Flutterの勉強を、アウトプット(メモ/記事)を残しながら整理していた
    • このときのレベルは決して高いものではなく、入門や調査のレベルだった

  • 書籍にした経緯

    • そもそもFlutterって何？なんでみんな使っているの？ということろから始まり、環境構築やHelloWorldを出す方法などを、単発の記事として週に1個程度書いていた
      • このときは、記事を書くことは副次的であり、Flutterで作りたいアプリがあり、その機能を実装するために調べたことを記事化していくという状況
    • 一定数記事が溜まっていくと、記事と記事の関係を作るのに苦労するようになった
    • なにか別の方法が無いかと考えていたときに、Zennであれば書籍の形式で情報を整理できることを知った
    • ブログやQiitaは単発(タグやカテゴリが同じ)の記事を書くのには向いているが、シリーズモノや構造を持った記事を書くのには向いていない
      • タグには順序がない
      • まとめページは更新が面倒

  • 最初に書籍にした際の構造整理

    • 書籍にする際に、カテゴリを整理し「初級編」「中級編」「上級編」「リリース編」「Fireabase編」などを作成
    • 変更履歴や本書の読み方などのメタ情報も追加していた

Part2:公開後のアップデート

書籍にしたことで見えてきた、ノウハウのスキマ

  • カテゴリを整理していくうちに、AがあるならばBの情報もあったほうが良いことに気づく

    • 各編のコンテンツを増やしていった

  • 書籍の形式が、情報を体系的に整理するのに向いていた

    • 網羅性や別の機能はないのか？という観点で、記事を書いているうちにスキマに気がつくようになった
      • 例えば、スマートフォン機能で、GPSがあればカメラあったほうが良い。STTがあればTTSもあったほうが良いなど
    • 記事を書いた後にこれもできるのでは？が連鎖的に見つかるのが、書籍による構造化の良い点

  • リリースをしてから、1日1本記事を書くチャレンジをしていた

    • 業務の休憩時間などにネタを考え、終業後に執筆する
      • Flutterはこれぐらいの気軽さで1ネタ増やせるぐらい簡単とも言える
      • 「使いたい機能→パッケージを探す→実装例→動作イメージ→応用」を基本パターンとして執筆
    • (重たいものは複数日かかるものもありましたが)1ヶ月で30記事ぐらい増えた
      • この時点での1記事の品質はそこまで高くなく、文量やイメージも少なく、なんとかなっていた
    • イベント/カンファレンスの動画から記事を書いた物も多い

  • 書きたいコンテンツがある程度出尽くした頃に、一旦最新バージョンで動くかなどを確認

コンテンツや文章の質を上げるモチベーション

  • 一番の読者は自分

    • 未来の自分があとから見てわからない情報にしない
    • 今はすべてを覚えているが、数年間Flutterに触らないかもしれない。その後で教えてよと言われて使えるものにしたかった。
    • 性格的に、一度ハマると、真面目・こだわる・細かい・・・かもしれない
      • こうやったらどうなるんだろうというエンジニア気質があり、Try&Errorを色々やってみて記録することを繰り返した

  • いつの日かFlutterを離れる日がやってくる

    • Flutterを嫌いになるという意味ではなく、相対的に別のものに興味が移って行くので、後からすぐに帰ってこれるようにしたかった
    • すべての技術はつながっているので、Flutterに戻ってくる日はかならず来る
      • 将来の自分に、なにこれ？と言われないようにしたいと思った

読んで下さる方への配慮

  • せっかく公開するので、日本語的な意味やイメージが伝わらなくて、役に立たないのはもったいないので、読者の方に正しく伝わるように気を使うようになった

    • 大学の授業などは、正しく最適だが、伝わらないということがよくあったので、伝えることも内容と同じぐらい大事だとこの頃から思っていた
    • 本書は入門書なので、あまりノウハウの階段を高くしないように気をつけた

  • どんどん新しい物が出るので、アップデートされていくものは仕方がないが、この時点のものについては、これだけを見ればわかるようにしたかった

実装例と動作イメージの最適化

  • 実装例と動作イメージは、直感が合うように作成した
    • 本質を見極め、不要な部分を極力削ぎ落とす努力をした

Part3:書籍化の決断と原稿作成

書籍化のお話を頂いてから決断するまで

  • 2022/3月頃にご連絡を頂き、その後、頭出し/キックオフを実施させて頂いた

  • 正直、書籍化をするかどうかはかなり悩んだ

    • 一番の悩みは「自分のノウハウは書籍にしてお金をもらうに値するのか？」という点でした
      • これに対しては、声をかけて頂くぐらいならなんとかなる。ZennでNo1になれたので、挑戦してみてもいいかなという2点が支えになった
    • 二番目の悩みは「出版業界のノウハウが一切ないのに単独執筆を仕事をしながらできるのか？」でした
      • こちらは、執筆期間を長めに設定していただくのと、自分の行動が無駄になるぐらいなら全然OKで、誰かに迷惑や損害をかけないようにだけすれば良いやという考えで、挑戦してみることにした
      • 自分の経験としても面白いかな・やってみたほうがいいかなと思った

出版を決めてから原稿を納めるまでの4周

ベースはZennにあるものの、書籍化をするにあたって再チェックや構造を見直す必要があり、かなり大変でした。

  • 1週目：章構成 / どの項目をいれるか
    • 今まで初級、中級、上級としていたものを、Flutterアプリを作る上で絶対に知っておかないといけない情報と高度化するために必要な情報などに分ける
      • 基本編とスマートフォン編、Firebase編とリリース編までを読めば、ひとまずアプリをリリースできるように1区切りとした
      • その後ろに、高度な使い方をのせ、上からスムーズに読めるように組み換えた
  • 2週目：最新バージョンで動作確認・情報更新/画像の取り直し
    • 執筆のタイングではFlutter2やベータ版で動作させていた部分があったため、Flutter3の最新版で一から全て動かし直しつつ、スクリーンショットを取り、省略されている情報を付与するなどの対応を行った
  • 3週目：相互関係や対応性をチェック
    • 見出しを「本節では、XXXを解説します。」に統一したり、Firebaseの目次の構成を「概要→有効化手順→パッケージのインストール→実装例」にするなどの大きな項目での統一
    • その他にも、箇条書きの表現を統一したり、Google社とGoogleが混ざらないようにするなど、気が付いた単語のゆらぎなどの解消した
  • 4週目：「てにおは」など日本語のチェック
    • RedpenやJustRightで文章の確認を行った
    • 30万文字以上あり、なおかつ文章遂行ツールも全ての指摘が妥当とは限らないので、全部を直すことは不可能だったため、ある程度ルールを決め打ちをして、直せる範囲で修正した

特に力をいれて書いた点やこだわった点

  1. わかりやすさ
  • 前述の通り、将来の自分が役に立つと言ってくれるものを残したいという思いが強かった
    • 近しい内容を書いている人がいない場合は、調査結果をわかりやすくする
    • 近しい内容を書いている人がいる場合は、よりわかりやすく、より再現しやすくする
  1. 本当に使う人/エンジニア目線
  • 机上でこういうものがありますではなくて、本当に使うことで気をつけないといけない点や、設定する具体的な項目を明らかにして、整理して掲載すること
  • アプリ開発者が常識的に気にするポイントなどは、どうなっているんだろうを調べて載せる
  1. 本質・そもそも・最小限へのこだわり
  • 本質論的に、この機能の核はなんだろうというのを常に意識して、サンプルや解説を作成
  • 自分が使いたい機能を実現するための、必要最低限の過不足のない美しいコードを書く

Part4:推敲の日々

レビュー方法

  • 原稿を提出してからは、PDFで組版と呼ばれる形態で、確認作業を行いました
    • 4,5回レビューと修正をしました
    • レビューには、筆者自身のレビュー以外にも、出版社側で実施して頂ける文章レビューや技術検証のレビューもありました
  • PDFへのコメントつけなので、意図が伝わらなかったり、修正漏れなどがあり、少しやり取りが大変でした
    • できるだけ修正箇所/修正内容に意識連れが起きないように試行錯誤をしました

1校

  • 原稿からのコピペミス、目次レベルのミス、画像の挿入ミスなどが無いかを、Zenn版と見比べて確認しました
    • Zennのインラインコードブロックや+,-の差分表記ができるか相談し、実現していただきました。
  • 文章の修正、画像の確認、文章の推敲などをしました
    • Firebaseやリリース手順などは頻繁に変わるので、追従が大変でした
  • 図やリストのキャプションを入れていない原稿だったので、キャプションの文章をすべて作成しました
  • 文章レビューでは、日本語の表現や句読点、語順など1000件以上コメントを頂きました
    • ただし、取り入れるかどうかは選ばせて頂くことができました

2校

  • まずは、1校の修正が正しく行われているから始まりました
    • 仕方がないのですが、直してほしいところが直っていない/直さなくて良いところが修正されてしまっている点があるため、突き合わせを行う必要がありました
  • 次に、検証レビューの取り込みを行い、初見の人が戸惑うポイントを修正していきました
    • 検証レビューでは、実際に動作確認をして頂けますが、説明不足やバージョンアップによって動かない部分があり、問い合わせ頂く事象の再現や確認が大変でした
      • 本書の再現性に関わる部分でとても大切なので、一つ一つ確認しました

3校

  • 基本的に、2校と同じ流れで、2校修正の漏れの確認を最初に行いました
  • 加えて、文章レビューと検証レビューの再確認などの対応も行いました
  • 残りの時間は、文章推敲と気になるポイントの確認にあてました

4校以降

  • このタイミングで機能を誤解している部分があり、慌てて修正しました
  • また、この頃から、文章推敲の沼にはまり始めました
    • 大変でしたが、確実に良い方向に文章を直せたので、頑張って良かったと思います

エンドレス文章推敲

日本語は、表現や語順の自由度が高く、いくらでも修正ができるので、10-15周したあたりから、どこまでやったら十分かを見失い、かなり時間を消費しました。

  • 一つの文章を何回も読みながら、ブツブツ独り言を言いながら文章を遂行していく日々となりました

    • 「てにおは」「主語がない」「文章に曖昧さがある」「イメージ画像と用語が同じ表現になっていない」「一文が長くて読みづらい」「表現の統一」などを確認しました
    • 「テスト結果の確認」なのか「テストの結果確認」なのか、のような非常に細かい部分までより意図が近い方を模索し続けました

  • 対応する部分の文章の統一

    • 「各節のリード文」と「まとめ」を対応させ、同じ文章にする
    • 「はじめにのChapter概要」と「Chapter扉文の1段落目」と「まとめのページの次へ」を対応させ、同じ文章にする

  • ある意味で、マニュアルのようなよみやすさ

    • カメラとギャラリーの節の場合は、写真の部分と動画の部分で、文章の形態や表現を揃えるなど、構造が同じものは、同じような表現やリズムにして、読みやすくしました

Part5:今後の展望

今後、書いてみたい記事や書籍など

  • Flutter関係
    • Flutter4(リリースされたら)
    • Flutterのゲーム領域
  • その他
    • ChatGPTなど生成系AIのノウハウ
    • 生成系AIと別の技術を組み合わせたときの実装例
    • ノウハウの少ない先端技術

所感/まとめ

メリット/楽しかったこと/モチベーションになったこと

  • なによりFlutterの勉強になった

    • 業務で使ったこともなく、1年程度しか触ったことがないのに、書籍を出せるレベルまで学ぶことができた

  • 「教えることは教わること」を実践できた

  • 人にわかりやすく伝えるための、構造化や表現を自分の中で推敲できた

  • ZennでのLikesがすごく高かったので、様々な方に読んで頂けているんだなという実感があった。

    • フィードバックのコメントや、アクセス数などもモチベーションにつながった
      • GoogleAnalyticsでアクセス解析もしました
        • 仕組みを提供してくれたZennに感謝
      • コメントも非常に優しく丁寧な方ばかりだった
        • どうしても、所々間違った情報を掲載してしまったところもあるが、コメント反映で品質をあげられた
        • ご指摘から学びになったものも多い

  • 書籍化という貴重な経験ができた

    • わずかでも、エンジニアとして社会に貢献できた
    • 書籍化のプロセスを学ぶことができた
    • 自分の本が出版できたというステータスになった

デメリット/辛かったこと/困ったこと/次回があるなら工夫したいこと

  • モチベーション管理

    • 出版するまでは、誰からもフィードバックをもらえない
    • 作業時間に見合うほどのお金にはならない
      • (大量に売れれば別ですが)私の場合は、初回に頂く印税と作業時間のコスパはそこまで高くないものでした
      • 本になるということをモチベーションに頑張っていました

  • スケジュールの確保

    • 本業とのタスクの棲み分け
      • 年単位で稼働がかかるので大変でした
      • 無限に修正ができるので、時間の管理が難しかったです
      • 業務が忙しくなっても、書籍側の納期もあるので大変でした

  • 書籍として販売されることの責任とリスク

    • 間違った情報や賠償などになった時に、責任取れるのかという不安がありました
    • そのために何度も内容を見直しました

  • 協力者やレビューアがいなかったので、全部一人でやるのが大変でした

  • 検証レビューへの対応や文章推敲時には、クロスチェックしてくれる人がほしかったです

気をつけたこと

  • 段取りや必要なものがわからず、出版社の方に都度確認をしました

    • 経験やノウハウが無いので、これっていつまでにやらないといけないんだろうを先回りして質問する必要ありました

  • 気負わないこと

    • 自分は運が良かっただけの一発屋で、狙ってヒットした訳では無いと思うこと
    • 自分が整理したものがたまたま、目に止まっただけ。むしろすごいのはFlutterの方と考える
    • まずいことが起きたら、本の公開をやめれば良いだけ
    • 読者を増やすことを目的にしない
      • エンジニアとしての自分の技術メモであることを忘れない

  • 出版契約の確認

    • 大手の企業様なので問題ないと思いつつも、勉強も兼ねてかなり細かいところまで解釈の仕方など確認しました。

Discussion