Upgrade to Pro — share decks privately, control downloads, hide ads and more …

執筆の種蒔き用にしているインプットでの心掛け

Fumiya Sakai
February 15, 2024

 執筆の種蒔き用にしているインプットでの心掛け

執筆の技術を勉強する会 #2での登壇資料になります。

今回は私自身が取り組んでいる事で、執筆の種蒔き用にしているインプットでの心掛けに関する事を昨年んのインプット事例を交えてご紹介しています。

小さな調べ物を自分の言葉で言語化してみたり、普段から実装や知識の簡単にまとめて図式化してみる事から執筆のためのアウトプットへ繋がっていく事が多かった様に思いました。

最初からいきなり大きなアウトプットを試みようとすると敷居が高く感じてしまう事も多いと思います。
ですので、最初は記事単位でなくとも自分の言葉で細かくまとめる所から始める例や、業務で取り組んだ実装やコードレビューを実施した内容で興味・関心を持った部分をもう一度復習する様なイメージで図解やドキュメントでまとめる例をピックアップしています。

Fumiya Sakai

February 15, 2024
Tweet

More Decks by Fumiya Sakai

Other Decks in Technology

Transcript

  1. 自己紹介 ・Fumiya Sakai ・Mobile Application Engineer アカウント: ・Twitter: https://twitter.com/fumiyasac ・Facebook:

    https://www.facebook.com/fumiya.sakai.37 ・Github: https://github.com/fumiyasac ・Qiita: https://qiita.com/fumiyasac@github 発表者: ・Born on September 21, 1984 これまでの歩み: Web Designer 2008 ~ 2010 Web Engineer 2012 ~ 2016 App Engineer 2017 ~ Now iOS / Android / sometimes Flutter
  2. 今回のスライドにつきまして いつかの執筆活動や寄稿等に繋げるためのアウトプットに関する工夫をご紹介 これまで自分がしてきた取り組み事例の紹介になりますが、お付き合い頂けると嬉しいです。 1. 小さな調べ物を自分の言葉で言語化してみる: 平素の業務内や個人的な開発のためにインプットのために「小さな調べ物をする機会」から始まると思います。 小さな調べ物を繰り返して試行錯誤をした過程を自分の言葉で表してみる事がアウトプットの第1歩目になるはずです。 2. 普段から実装や知識の簡単にまとめて図式化してみる: 言葉だけで説明しようとするとイメージが伝えにくい場合や必要以上に説明が長くなる場合もあるかと思います。

    自分がよく実践している事ですが、画面遷移や全体概略図をはじめ図解にしてまとめた事例を交えてお話しできれば幸いです。 3. コミュニティ活動や社内部活動などの活動に身を置いてみる: 昨年からは「技術書同人誌博覧会でのデザイン協力スタッフ」としての活動や「社内の部活動」等の機会で寄稿やアウトプット をする事ができました。その中で皆様の執筆活動を支援する活動をするモチベーションについても触れられればと思います。
  3. インプットした内容を自分の言葉で言語化するメリット 本当に理解ができているか?を確認する事ができる指標にもなり得る 未知のタスクに着手する 前にまず始めること 日頃のタスクをこなす中にもドラマ有り: コードと共に周辺技術の理解を広げる 関係性を繋げていく際に言語化する コードを読んで理解を深めていく事は前提ではあるが、コードを取り 巻く環境(インフラ・ミドルウェア・CI・ツール等)についても基礎 知識をインプットする様にすると有機的に理解するヒントになる。

    得られた知識を関連づけて能動的に理解を深める 知識整理を脳内で実施するためにまずは自分の言葉で表現してみる 個々の事象が言葉によってうまく繋がった時に理解が深まる。そうす る事で最初は「なぜ?」となっている部分が明確になる。 ・専門用語や名称の理解 ・現在状態の仕様把握 ・インフラ/ミドルウェア構成 ・影響を受ける範囲調査 タスク完了・理解に必要なものを整理 現状把握に必要な材料 ・業務やドメイン理解 ・技術に関する理解 改修内容の設計 ・影響範囲と詳細の見極め ・かかり得る工数の算出 ・必要性の理解 ・コード&周辺技術調査
  4. 僕が個人的に考えている理想的なサイクル この様なサイクルができればドキュメントもアウトプットも楽しくなるはず 1. 業務内で必要そうなドキュメントをまとめる: 2. ドキュメントの前段情報をストックする: 最近はなかなか自分も実践できずじまいで申し訳なく思っています…すみません View要素から実行された Actionを発行する 知識をインプットする際

    はまずは雑でもノートへ ・コードレビューの記録 ・会議中の内容のサマリ ・複雑な機能の予習 まずはInternalな資料と して要点をまとめていく できるだけ業務時間内に インプットの機会を作る 社内Wiki・公開情報 として知見を公開する ツールやスタイルは使い慣れたものを利用 アウトプットの第1歩が平素のインプットになる事が多いです インプットからアウトプットへ昇華していく段階に途中をはさむ事に よって書きやすくしている。文章だけでは説明しにくい点をいかに図 解としてまとめるかも考える様にしています。 ・業務ではNotionと手書きノートを利用する ・ツールによって棲み分けをすると良い ・ある程度まとまれば記事やブログへ
  5. 私の場合は良く自分のノートを活用しています(4) 直感で正しいと思える解答と論理的に正しい解答が異なってしまう例 iOSDC Japan 2022パンフレット原稿 : https://github.com/fumiyasac/iosdc2022_pamphlet_manuscript 残りのカードを良く切ってから3枚抜き出した ところ、3枚ともダイヤであった。 1つ選んだ後に抜き出したカードの枚数とその

    時に選ばれたダイヤの枚数が等しい場合にお いて、枚数が変化したならばその確率が変わ る点です。 この問題におけるポイント 条件付き確率の問題である事に注意: 平素の開発でもこの様な経験はないか? 図解等でまとておく事で実は更に考慮すべき ポイントに気が付ける場合もありそうです。
  6. まとめ 執筆をした経験が業務・個人問わず活きる瞬間は数多くあった様に思います。 1. 小さなインプットが積み重ねがアウトプットに繋がってくる: 最初からいきなり大きなアウトプットを試みようとすると敷居が高く感じてしまう事も多いと思います。 記事という単位で最初はなくとも、少しずつで構わないので自分の言葉で細かくまとめる所から始めると良さそうです。 2. 情報を「見える化・整理」をする習慣をつけると嬉しい事がたくさんある: 業務で取り組んだ実装やコードレビューを実施した内容で興味・関心を持った部分をもう一度復習する様なイメージで図解やド キュメントでまとめる作業に慣れると、執筆をする場合においてもこのスキルを十分に活用できると思います。

    小さなインプットを大切にした先に執筆や寄稿等の大きなアウトプットに繋がっていくと思います。 3. コミュニティへの参加やアウトプットを応援する場へのコミットも貴重な機会: 1人では筆が重かったり作業が捗らない事は僕自身も良くありましたが、コミュニティの皆様にモチベーションを頂く事も多々あ りました。コミュニティへの協力や同人誌作家へ寄稿といった形でのコミットも有意義な機会だと考えています。