一定の規模の開発であればドキュメントは必須です。ドキュメントを使わない開発が存在するならば、すべての情報を口頭やチャットを使い、ソースコードレベルで記述する必要があります。一方で、効果的に記述されて運用されているドキュメントには、開発組織・チームをスケールさせる力があります。ドキュメントは互いの時間を拘束せずに非同期で書いたり、読んだりできるからです。したがって、ドキュメントを効果的に使えるならば、開発組織・チームの生産性を向上できます。しかし、ドキュメントの書き方をしっかり学んでいる人は多くないです。もしドキュメントライティングの基礎技術を事前に身につけられるならば、今後の開発者人生において非常にレバレッジの効くスキルとなります。本記事では、ドキュメントライティング術を学んだことがない人向けに、「ここまでは最低限知っておくと良い」という知識をお伝えします。 対象読者 対象読者は、以下を想
はじめに 会社員として働く上で評価は最も大きな関心事の1つでしょう。評価によって自身の職位や給料が決まるのでそれも当然です。 しかしながら、「納得感のある評価を受けられていますか？」と問うと明確にYesと答えられる人は稀でしょう。「成果を出したのに正しく評価されていない」と不満を持っていたり「評価は偉い人が勝手に決めるものだから…」と諦めている人もいるのではないでしょうか。少なくとも過去の私はそうでした。 そもそも、評価をどのように受けるべきか指導や研修を受けたことはありますか？私にはその記憶はなく、自身が評価者の立場になって初めて評価というシステムに真剣に向き合うことになりました。 評価の際に被評価者としてできることは、評価者に自分の成果や成長を適切にアピールすることです。そして、アピールの方法として最も確実かつ重要なのは伝わる自己評価を書くことです このエントリは、被評価者が評価者に正
以前博士論文執筆の際にお願いしたいことを書きましたが、 今回は論文の体裁に関するもっと細かいことを書き留めておきたいと思いました。 色んな学生さんの論文を審査したり添削したりすることがありますが、同じことに何度も巡り合いますので。 以下は主に弦理論、素粒子論業界の人のためのものですが、英文、数式に関しては適用範囲は広いかと思います。 また、以下書くことはどうでもいい慣習に関することも多いです。 しかし、業界の慣習を破る場合は、自分がそれが正しいと思って、意図的にやってくれたほうが良いと思います。 構成について 修士論文で新規の結果があるばあい、博士論文のばあいは、論文中のどこが先行研究のレビューでどこが新規なのかが明確にわかるようにしてください。 イントロダクションに明記した上で、該当節においても強調してください。 書いている本人は当然わかることですが、読んでいるほうにはわかりません。 S
hep-th 系の学生さんと話をしていると、勉強の仕方はわかっているのだけれど、 そこから論文を書くことになかなか移行できないケースが散見されます。 ではどうやったらいいのか、という話を何度かすることがあり、毎度同じような助言をしているので、 この際まとめておこうかと思った次第です。 理論物理で且つ hep-th にしか適用できない話も多いかと思いますので、悪しからず。 また、最近子供と話すことが多いので、口調が幼い子供相手のものに引きずられている気がしますが、すいません。 (初稿:2024/9/20) なぜ論文を書かないといけないの? 勉強しているだけではダメなの? 他のところでも書きましたが、教科書や、著名な大論文の勉強をやっていると素晴らしいことを学んで、理解が深まって、とても楽しいです。 一方で、論文を書くためにがんばって新しいことがすこしわかったとしても、自分でなしとげた、という
＜この記事の著者＞ ばんか（bamka） - Tech Team Journal Web制作会社の会社員（Webディレクター）として働きつつ、個人でブログ／メディアライターとしても活動するパラレルワーカー。 ChatGPT等AIを公私で駆使し、ITツール・ガジェットを用いて人々の生活をより豊かにするための活用術を提供するブログも運営。 QiitaやZennなど、ITエンジニアさん同士での情報共有を目的としたメディア。正直、Webディレクターの私が見ていてもチンプンカンプンな内容が多いのですが、それでも読み物として勉強になるので、よく拝見しています。 読む専門のITエンジニアさんも多いかもしれませんが、個人的には、自身のノウハウは積極的にアウトプットしていくのをオススメします。 「人の役に立つから」「自分の認知を広げられるから」など理由はさまざまですが、一番はシンプルに「自分のスキルとして定
「伝わる文章」とはどのようなものか 私はWEB媒体の編集者／ライターをかれこれ17年ほどやっている。日本語で情報を伝えるのが仕事だ。 ジャンルとしては長文の体験レポートを中心に扱ってきた。ライトな読み物で、書くのも簡単そうだと思われるかもしれない。いやいや、そうでもないのだ。それぞれのバックグラウンドを持ち観察力に優れた書き手が、五感をフルに使い数時間かけて体験取材をすると、情報量がとんでもないことになる。それを限られた字数で読者にわかりやすく伝えるのは、実は技術のいる作業なのだ。 また、私は特に編集部の中でも新人ライターを多く担当しており、書き慣れない人が書いた文章を一緒に直し、読み手に伝わる書き方をアドバイスする経験をずっと積んできた。 そんな私が、小学生の子供の中学受験によってあらためて「伝わる文章の書き方」を見つめ直すことになった。本稿ではその経験について少し語らせてほしい。
技術ブログの続け方ガイド こんにちは！ITベンチャー企業で半年間働いている駆け出しエンジニアです👨💻 今回はエンジニアで働く上でテックブログを続けるためのモチベーションの保ち方を記事にしてみました。 テックブログって敷居高いしめんどいよなぁ！？ 技術記事を発信する人材は重宝されるらしい。 ただ、僕は現段階で技術記事って面倒くさいし敷居が高いな〜書くネタもないな〜🐹 と思ってしまうのが事実としてあります。 僕だけなのかな？と思って調べてみたら… みんなめんどくさがってるやんけ！！！！！ そこで、めんどくさがりな僕たち向けにテックブログの続け方をノウハウとしてまとめてみました。 みなさんのモチベーション維持に貢献できれば嬉しいです👍 1. 初学的なところも書いてみる こんなの書いても誰のためにもならないんじゃないの…？😭 ということでも書いてみるのは大事である。 自身が悩んだり共感
この前職務経歴書を書いたので、そのとき色々考えたり調べたりしたことを書きます。 一般的な転職活動の職務経歴書は微妙だった 僕の転職は二回目です。 一回目の転職のときは、リクルートエージェントのサービスを使って転職しました。 リクルートが公開している、一般的な職務経歴書のサンプルは↓こんな感じです。 Wordで表をつくって、編年体に、何をやってきたかを書くことで、自分の職務経歴を書きます。 ただ詳細はちょっと長くなるので、職務経歴書の冒頭に数行でサマリーが書いてあって、親切ですね。 一般的な日本の職務経歴書というのは、このフォーマットで問題ありません。 実際一回目の転職のときは僕もこのフォーマットで転職しています。 二回目の転職活動も、この職務経歴書に二社目の経験を追記すればいいか、と思っていましたが、 見れば見るほどこのフォーマットで書いた自分の職務経歴書が微妙に感じてきました。 何が微妙
『日本語の研究』に出した書評が公刊されました。 オンラインに出るのは刊行の1年後なのでしばらくは紙媒体のみになります。 学術書の書評を書いたのは2度目になります。慣れたわけではありませんが，どうやって書評を書く仕事をしたのか少し記録を取っておきます。 依頼を頂いてから締切までは6か月でした。当たり前ですが、本を入手して通読します。読むときのスタイルは色々でしょうが、書評を書くことが決まっていたので、適宜付箋を貼り付け、鉛筆でメモを書き込みました。 今回の本は直接メモを書き込んでいましたが，前の書評では付箋を貼り付けて、notionに書き込んでいました。基本的に気になったら躊躇なく付箋を貼っていったのでそこそこの量になります。 ひと通り読み終わった後，notionでメモを作りました。アウトラインとも言えるもので，基本的にこれを書こう，これは伝えたい！というものを盛り込んでいます。ちなみにno
めもりーさんと語るFindy Engineer Lab オフ会＠東京 LT https://findy.connpass.com/event/294069/
現在こちらの記事は筆者視点で、推奨されていない可能性があります。最新の見解としては下記記事を参考にしてください。 知的・技術的進歩のスピードを限界まで加速するノートアプリ『Heptabase』 #新人プログラマ応援 - Qiita はじめに Obsidianという素晴らしいプロダクトが登場してから、デジタルノート術は活発化したと思います。私もその１人で、今日も楽しくObsidianを使っています。 しかし、その一方であまりノート術にこだわりが強くない方や深く理解するほど価値を感じていない人の中ではまだまだ単なるメモ帳として使われている現状があります。 そこで、今回は「がんばらない」Obsidianノート術として、「こだわりすぎない」「多様な原理原則がない」形で『書く』習慣を付けるためのノート術を書きました。 そんなノート術であったとしても、今後ノートを分解していけるような構造にしておくこと
気がつけばめっちゃ久しぶりどころか2023年初のnoteとなります。 色々書くので一旦前置きしておきます。 なお、これは個人の見解・意見であり所属組織及び業務とは何の関係もありません。 【前説】このエントリーは技術ブログや外部登壇、はたまた就職・転職活動において、 私（shinyorke）がどうやってアウトプット（スライド・ブログ・ドキュメント）を魅力付けしているか？その考えと少しだけテクニックを紹介 することを目的としたエントリーです。 ウケる・読まれる技術アウトプットを出したい 会社の技術ブログやイベントの資料をいい感じにしたい 魅力的なドキュメント（CVなど）を作って就職・転職に活かしたい 方に刺さるような話になっている可能性がありますが、基本的に私のポエムとして読んでいただけると幸いです。 あらすじ&今年の前半戦本題に入る前にちょいとした近況報告を。 気がつけば今年も半分が終わった
技術記事を書くまでのステップについて順にコツを解説していきます。 特に、技術記事を書きたくてもテーマ選定が難しい、文章が苦手だ、なぜか筆が進まない、うまくまとめられないといった方に読んで欲しい記事です。 一応、エンジニア歴としては数年以内のジュニアレベルの方を想定しています。 以下のように技術記事を企画して、書いて、公開するためのプロセスごとにちょっとしたコツをまとめています。気になるセクションだけでも読んでいただければ幸いです。 テーマを決めよう 対象読者を決めよう 章立てを決めよう 書こう タイトルを決めよう 【余談】技術記事を書く理由とは 筆者について QiitaとZennにて6年以上の記事発信経験があり、 Qiitaでは5,942Contributionsを記録、 Zennでは3,253Likesをいただいています。 テーマを決めよう コツ：テーマのカテゴリによって執筆のポイントや
米OpneAIは現地時間4月24日、ChatGPTなどOpenAIブランドを利用する際のガイドラインを公開した。ロゴマークやその利用方法、また「ChatGPT」などの文言を利用する際の注意点が記されている。 例えば、OpenAIのAPIを利用した製品について「◯◯GPT」「GPT-4搭載の◯◯」「ChatGPT搭載の◯◯」といった表現は使わず、「Powered by GPT-4」や「Built with GPT-4」などの表現を使うよう求めている。また、OpenAIのモデルを指すときはGPT-3、GPT-4、ChatGPT、DALL・Eを使い、Ada、Babbage、Curie、Davinci、GPT-3.5-turboなどのエンジン名を避けるようにとしている。
文章上達法について、「大量に書け」派と「大量に読め」派の人がいます。 「ひたすら大量に文章を書け。文章上達にはそれしかない」というのは書け派の典型。 「まずはラノベを千冊読め。話はそれからだ」というのは読め派の典型。 しかし、大量に文章を書いているのに文章の下手な人はたくさんいますし、 ラノベをたくさん読んだけど面白いラノベの書けない人もたくさんいます。 これはスキル全般に言えることで、 たとえば、アメリカに二十年住んでいるのに英語がいまいちな人なんて、いくらでもいます。 「量をこなせば自ずと質に転換する」のは、もともと才能のある人間だけです。 私のような凡才は、量をこなすだけでは効率よく上達しません。 質の高い修練を大量にやってはじめて、効率よく上達するのです。 では、質の高い修練とはどういうものでしょうか？ それは、次の２つです。 (1)優れた文章のどこがどう優れているかを、文章を書く
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
