営業資料、マーケティング資料など、社会人によって資料作成の能力は必須スキルといっても過言ではありません。 はたして、みなさんの資料作りは“科学的に正しい”方法で制作されているでしょうか？ 株式会社クロスリバー社長・株式会社キャスター事業責任者で、これまで1万人以上に資料作成術をレクチャーしてきた越川慎司先生は、ヒアリング調査やAIによる分析を用いて伝わる資料の作り方を分析し、『科学的に正しいずるい資料作成術』を著しました。米マイクロソフト本社でパワポなどの責任者としても活躍していた越川先生の知見は、あなたの資料の作り方をがらりと変えてくれるはずです。 授業の前半である今回は、「わかりやすいスライド」とは何かのレクチャーや伝わる資料と伝わらない資料の比較など基礎的な内容となっています。
2018年6月1日に株式会社メルペイに入社して、4年が過ぎました。入社当時は、定年が60歳と聞いていたので、1年半の勤務だと思っていましたが、実際の定年は65歳であり定年まであと2年半です。 ソフトウェアエンジニアにとって重要な能力と（私は考えるが）、身に付けるのが難しいのが現実だと、この4年間で再認識したのは次の三つです。 開発の最初にAPI仕様をきちんと書けるソフトウェアエンジニアは少ない テストファースト開発を行っているソフトウェアエンジニアは少ないか、いない Tech Blogなどの執筆で、読み手を意識して、分かりやすい文章を書く、ソフトウェアエンジニアは少ない API仕様については、このブログでも何度か書いています（「API仕様を書く」）。テストファースト開発についても、「テストファースト開発」を書いています。分かりやすい文章については何も書いていないですが、「伝わる技術文書の書
朝日新聞社は4月2日、指定した字数や割合に長文を要約する「長文要約生成API」を開発したと発表した。評価用途に限り、無償で利用できる。会議の議事録や、採用活動で受け付けるエントリーシートの速読などに役立てられるという。
営業資料、マーケティング資料など、社会人によって資料作成の能力は必須スキルといっても過言ではありません。 はたして、みなさんの資料作りは“科学的に正しい”方法で制作されているでしょうか？ 株式会社クロスリバー社長・株式会社キャスター事業責任者で、これまで1万人以上に資料作成術をレクチャーしてきた越川慎司先生は、ヒアリング調査やAIによる分析を用いて伝わる資料の作り方を分析し、『科学的に正しいずるい資料作成術』を著しました。米マイクロソフト本社でパワポなどの責任者としても活躍していた越川先生の知見は、あなたの資料の作り方をがらりと変えてくれるはずです。 授業の前半である今回は、「わかりやすいスライド」とは何かのレクチャーや伝わる資料と伝わらない資料の比較など基礎的な内容となっています。
エンジニアはもっと図を書こう - 生涯未熟
たまには軽い話題をば。 自分の中で信頼できるエンジニアかどうか？を見極めるひとつの指標で「込み入った議論の時に図を書くかどうか」というのがあります。 今までの経験上、図を書く派のエンジニアは割と良い感じの人が多かったので採用している指標なのですが、何故これが機能しているかというのを改めて考えてみた。 他者の認知負荷を理解している コンテクストを合わせることにコストをかけられる意識がある 自分の思考の整理するツールとして図を扱えている ザッと挙げましたが、この３つが機能している要因なのかなという気がしています. 他者の認知負荷を理解している あれやこれやエンジニア間で技術議論している中で、「Aさんはこの領域に詳しいけどBさんはこの領域にはほどほど詳しいくらいだな」という個々のレベル差に応じて認知の負荷がかかります。ただでさえ議論していると結構なスピードで話が展開されていくので、認知負荷が更に
スケールする組織を支えるドキュメンテーションの技術を”GitLab Handbook”から学ぶ｜Anno Takahiro
ドキュメント文化は健全な組織のスケールのために必要 組織の中でドキュメント/文章を残し活用していくことはとても重要だ。クオリティの高いドキュメントがあることで、組織に情報が流通し、透明性を確保できるようになる。情報を流通させるためにいちいち口頭の説明がいらないから、メンバーの数が増えた時でもスケールしやすくなる。過去の結論にアクセス可能になるので、議論を積み上げていき、意思決定のクオリティを高めることにもつながる。そもそも何かを読むということは何かを聞いて教わるよりも時間あたりの処理量が多いし、非同期に実施できる。良いドキュメントをアセットとして社内に蓄積していくことはスタートアップのみならず、ありとあらゆる組織が成長していく上でとても重要であると言える。 しかしその一方で、良質なドキュメント文化を徹底できている会社は多くないように見える。例えば、社内のドキュメントを蓄積させていく場所とし
はじめに議事録、取ってるぅ？ そろそろ新人は現場に配属され始めた頃だろうか。 「議事録取っといてよ」とか軽く言われて頑張って作ったら、赤字まみれに添削されるのが通過儀礼。 だいたい新人が最初に任される仕事だと思う。 ところが、議事録を真っ当に取ろうとすると日本語能力、プロジェクトへの理解、構造化力とかが試されるので、割と高度なスキルの複合が求められるのである。 というわけで、議事録を簡単に作るコツを１つ伝授したい。もちろん、習得のためには訓練が必要なので、この記事ではTips程度の話だけど、結構便利だと思う。 実用系スキルなので最後に課金枠を作っておくが、課金枠に中身はない。 君はおひねりを落としてもいいし、落とさなくてもいい。 そもそも議事録とは議事録とは、議事を記録したものである。 一般に会議を行った際の議論の展開と結果を示すもので、発言を一字一句名前付きで記録するものは特に逐語録なん
はじめまして。Kyashでデータエンジニアリングを担当しているKyashデータマンです。この記事では、Kyash社内のデータ分析の基礎に関するドキュメントを紹介します。 Kyashでは、データエンジニアリング・ガバナンス・セキュリティなど様々な角度から、公正なデータの取扱いと活用を推進しています。従来は、一部の訓練された技術者がデータ分析を一手に担っていましたが、社内でもデータ活用のニーズも多く、その担当者に分析や集計の業務が集中するという課題がありました。 この課題に対して、データへの適切なアクセス管理を行い、そして適切なBIツールを導入することで、データを取り扱う人が自分でデータ分析・そして活用できるようになることを目指しています。アクセス管理には、個人情報やそれに準ずる機密データに対して、ポリシータグによるアクセス権のコントロール、そしてアクセス権のリネージなどのソリューションの導入
プレーンテキスト Markdown 時代の終焉
なぜ Day One は Markdown を捨てたのか Day One が Markdown をやめて WYSIWYG に移行した話は前書いた。 Day One がクソになった Day One 、このブログでも度々言及していて、 Markdown で日記が書けて便利だったんだけど、最近のバージョンアップ（ Mac は 2.8 以降 、 iOS は 3.0 以降）でプレー... portalshit.net 自分が知っている範囲でアンチ Markdown 勢は Scrapbox くらいしか思い浮かばず、 GitHub や Trello などのグローバル勢に加え、 Qiita やはてなブログなど日本国内向けのサービスでも当然のように Markdown が共通言語として使われているのに、その Markdown を捨てて WYSIWYG 化する1という戦略は疑問だった。 ひとむかし前の WYSI
伝えたいことは全てタイトルに書いた。 動機 https://github.com/topics/awesome を眺めていて本当にawesomeなものばかりだった (割にあまりどこにもそのawesomeさが書かれていないように見えた) ので書く。 awesomeリストとは GitHub で使われる慣習的なリポジトリについてまとめてみた#awesome より: 「特定テーマに関するキュレーションを行うリポジトリ。Markdown のリスト表記で一覧化するのが一般的。また、Contribution も受け付けている（人気のあるリポジトリはガイドラインも厳しめ）。」 Where? ここのことです: https://awesome.re/ 画像はリポジトリから引用。 What? What is an awesome list? よりDeepL翻訳 awesome マニフェスト もしあなたのリストを
利用が広がり人気が高まっている新しいプログラミング言語の習得に関心がありますか? ここから始めましょう。 Rust で高速で効果的なプログラムを構築するために必要な知識の基盤を築きましょう。 このラーニング パスの内容は次のとおりです。 Rust コードの最初の行を記述するために必要なツールをインストールする。 Rust の基本的な概念を学ぶ。 エラーを処理する方法を学ぶ。 Rust でメモリを管理する。 ジェネリック型と特性を使用する。 パッケージとクレート用のモジュールを設定する。 自動テストを記述して実行する。 コマンドライン プログラムを作成する。
こんにちは。壮（@sew_sou19）と申します。 メガベンチャー企業でエンジニアとして働いています。 エンジニアにジョブチェンジした当初は、ドキュメントの書き方なんてこれっぽっちも分かりませんでした。読みやすいドキュメントを書くことが本当に苦痛だったのですが、考えて、試行錯誤し続けた結果、以下のような評価を得るに至りました。 リーダーから「君は情報の整理が上手でドキュメントが本当に読みやすい。チーム全体の能力向上に繋げたいからドキュメント書く際のポイント共有してほしい」と言われたので、意識していることを言語化しつつテクニカルライティングの本でインプットしてるけど、学びが多い。ついでにnoteにもまとめてる — 壮 (@sew_sou19) November 28, 2022 そこでこのnoteでは、僕がドキュメントを作成するときに、特に意識して実践している7つのことを書きます。（本当は2
システム構成図をテキストで
Gigazineさんでdrawthe.netを取り上げていたので紹介です。使い方はGigazineさんのほうが丁寧なので、気になる方はチェックしてみてください。（2020年12月1日、追記） drawthe.netとは cidrblock/drawthe.netは複雑なネットワーク図も「テキストで書いてブラウザ上でSVGレンダリングできるようにしよう」というコンセプトのもと開発されたツールです。下図のように複雑な構成図も精度高く描くことができます。 拡大してみると情報量が多いこと、またいかに整っているかがわかると思います。 デモサイトも用意されているので、サクッと試したい場合はコチラが便利です。コードはGitHubで公開されています。更新が2017年末で止まってしまっているのが玉に瑕ですが、十分な性能を発揮してくれます。 drawthe.netを使いたい理由 美しい構成図といえばInter
短いメッセージを書くことはできても、まとまった文章を書くのに苦労している人は多いのではないでしょうか。 この記事では、まとまった文章を作るときの技術を学ぶことができる記事や学習コンテンツを紹介します。新人エンジニア向けです。 文章の「型」を学ぶ まとまった文章を書くには、「型」が必要です。頻繁に使うものは、「型」を覚えてしまいしましょう。 バグレポートの書き方を学ぶ エンジニアとして書く文章の代表例が、バグレポートです。 バグレポートでありがちな失敗として「何が問題だと思っているのか」が伝わらないというものがあります。 これを防ぐために、「期待する結果」「実際の結果」「再現手順」の3つを必ず書くようにしましょう。 質問の書き方を学ぶ エンジニアが扱う技術は、最初はわからないことだらけです。 それを解決するために、質問の文章を作成する技術が必要となります。 概ね下記の4つの情報があれば、良い
手順書フォーマットは千差万別 みなさんは自己流または、組織やプロジェクトで定められた手順書のフォーマットはありますか? 私は自己流の手順書フォーマットがあります。 自己流の手順書フォーマットがあるといっても、かなり扱いがふわふわしているので、備忘やメモの意味合い強めでまとめていきます。 「もっとこうした方がいいよ!!」などフィードバックがあれば、ぜひお願いします! いきなりまとめ 手順書はExcelやスプレッドシートではなく、Markdownで書く 手順書はgitで管理する 5W1Hを意識して手順書を書く 基本的にはCLIを使った手順書にする 手順書はExcelやスプレッドシートではなく、Markdownで書く 手順書をExcelやスプレッドシートで書くメリット・デメリット 手順書をExcelやスプレッドシートで書いている方も多いと思いますが、私はMarkdownで書いています。 Exce
本当に使ってよかったOpenAPI (Swagger) ツール | フューチャー技術ブログ
サードパーティ製のツール本家からは上述のツールが提供されていますが、サードバーティ製の様々なツールが世の中には存在します。 エコシステムが成熟しているのもSwaggerを利用するメリットの一つですね。 https://openapi.tools/ 冒頭のとおり、このサードパーティ製のツールの中で実際に利用して良かったツールを3つご紹介したいと思います。 Stoplight Studiohttps://stoplight.io/studio/ 1つ目のツールは「Stoplight Studio」というAPI仕様を記載するためのGUIエディタとなります。 今までSwagger Editorを利用してYAMLを書いていたそこのみなさん、YAML筋力はもう必要ありません。 Design APIs 10x faster の謳い文句どおり、Stoplight Studioを使えばGUIで直感的に、高速
メモアプリの知見のお返しにきた
去年の大晦日に「メモアプリの知見を貸してほしい」という増田を書いた者です。750超のブックマークと注目をいただきまして大変感謝しています。 https://anond.hatelabo.jp/20221230142549 あれから半年経過してみて自分の使うメモアプリが定まってきただけでなく、メモの意識およびスタイルに変革が生じました。これを、皆さんからお借りできた知見の「お返し」としてご報告したいと思います。 「中身に興味無いけどブコメしたいからブクマした」という人は、簡単に作れそうな激辛料理を教えてください。最近自炊が楽しいもので…中華ばっかりですが。 コメントが「メモの意識変革」をくれましたブコメは270件、増田のトラバは50件と膨大なアドバイスや激辛スナック情報を頂いて、まずは発見がありました。 ある人が「タラタラしてんじゃね〜よ は激辛？」と聞いてきた折に「自分は激辛とは思ってない
こんにちは丸山@h13i32maruです。つい先日、devchat.fmというポッドキャストに出演して、「ドキュメント」というお題について話しました。なぜこんなニッチなお題について話したかというと、Ubie Discoveryに入社して5ヶ月の間にいくつか*1まとまったソフトウェアドキュメントを書いたので、自分の中でホットな話題だったからです。 #devchatfm 33回目は、Ubie DiscoveryのSWE @h13i32maru にドキュメントを書くことで得られるメリットや、ポイント・工夫などを聞きました！ #33 チームの生産性を上げるドキュメントのすすめ with@h13i32maruhttps://t.co/TrmZd13D91— 久保 恒太 / Ubie CEO (@quvo_ubie) 2021年8月12日 これらのドキュメントは個人的にわりと良く書けたと思ってますし、
と注記しています。 すっきり分けにくい場合も 動詞の下に付けて補助的に使えば漢字の意味が意識されないと考えられるわけですが、形だけでわかるとは限りません。 動詞の下に付いていても 「傘を学校に置いて来てしまった」「子供を家に置いて行く」 などは、「来る」「行く」にも意味があって漢字で書いてもよさそうです。 同じ「しれない」でも 「彼ならあんなことも言うかもしれない」 「あんなことを言う彼の気が知れない」 ――と、後者は漢字で書いてもよさそうです。 「意味が薄れた」かどうかは微妙で難しいものがあります。毎日新聞用語集は「言う」「いう」の書き分けをこのように例示しています。 「大家といえば親も同然」という例が挙がっていますが、「といえば」でも 「気にならないと言えばうそになるが……」 のように使う慣用句では、実際には言わないけれど「口に出して言ってしまうと」という感じなので「言」を使ってよさそ
システム開発にドキュメントは欠かせません。ドキュメントが得意になれば活躍の幅が大いに広がりますよね。 この記事では、まず冒頭でドキュメントの作成に求められると思うことを整理した上で、そのスキル獲得に役立つと思われる記事や書籍を集めてみました。もちろん他にもあると思うので、もしお薦めのものがあれば是非コメントで教えて下さい 更新履歴 ・2021/04/16：文章術系にリンクを追加しました。 ・2020/11/28：文章術系にリンクを追加しました。 ・2020/07/24：文章術系にリンクを追加しました。 ・2020/05/24：文章術系にリンクを追加しました。 ・2020/05/14：スライドデザイン系にリンクを追加しました。 ・2020/04/29：スライドデザイン系にリンクを追加しました。 ・2020/04/17：文章術系にリンクを追加しました。 ・2020/04/12：関連するTwit
プログラマーがドキュメントを書かない理由
この記事は、著者の許可を得て配信しています。 Why programmers don’t write documentation 最近ではずっとコードのドキュメンテーションに関連した記事を書いていたので、当然、私のMediumのおすすめ記事には「開発者がドキュメントを書かない本当の理由」という記事が表示されるようになりました。この記事では、ドキュメントを書くための優れたツールがないことが、ソフトウェアエンジニアが自分の作業や判断をドキュメンテーションする意欲を失わせる最大の原因について書いています。 私は普段、特定の記事を批判したりはしませんが、この記事には怒りを覚えました。このライターは図解ツールについていくつかメリットに関して述べてはいますが、全体的に誤解を招くような内容になっており、この重要な問題をより分かりにくくさせています。2つの図解ツールを比較して、どちらも不十分なツールである
プロジェクトに浅瀬を作る
はじめに プロジェクトに参加しているメンバーがうまく環境に適用できずに離脱することがあり、ともすれば、身体を壊してしまうケースもあります。これは新規メンバーに限定されず、既存のメンバーでも、プロジェクトや本人の状況、その役割が変われば発生し得ると思っています。 そういったことを回避できた状態を想像した時にプロジェクトに浅瀬があったら良いのではというイメージからこの言葉が浮かんだのだと思います。2年ほど前のメモ書きにこのタイトルが残されていて、今見直した時にすごくしっくり来ました。 メモ書きを発見したツイート この「プロジェクトに浅瀬を作る」とは、どういうことなのか、改めて深堀したいと思います。 どういうこと？ 溺れないようにするのが目的 監視員が必要のない状態が理想 溺れないようにするのが目的 溺れるというのは、闇雲に時間がかかってしまい心身ともに疲弊してしまうイメージです。不慣れなため必
コーディングのようにノートを取る技術 - Qiita
はじめに 何かを学習するとき、ノートを取っているでしょうか？ 小学生の頃や中学生・高校生の時の「ノート」は紙に手書きだったかと思います。 しかし、最近になってからはパソコンを使ってノートを取る、という選択肢が増えました。 その変遷の中で生まれたパーソナル・ナレッジ・マネジメント(Personal Knowledge Management) という考え方があります。 その考え方を共有できたらと思います。 直感的なデジタルノート術の原罪 ケース1: ひたすらに手を動かす 学生の頃、黒板に書かれた内容をそのまま必死にノートに写している人がいたのを覚えていますか？ また、その人は成績が高かったでしょうか？ たいていの場合、成績は乏しい人が多かったと思います。自分もそのタイプでした。 手を動かすだけのノート術の不幸な点は、「考える」というアクティビティが行われないため、本当の意味で筋肉を動かすだけと
Amazonのミーティングはとても奇妙な形で行われることが多い - ミーティングの最初にドキュメントを参加者が黙読するのだ。議論は全員が読み終わったことを確認してからスタートする。基本的に文章を読まずにいきなり発言し出したりということは許されない。大人数が一つの部屋に集まり、一つの文章を黙って読む姿は結構シュールである。 私はこの奇妙なミーティングをする会社に7年ほど勤めていた。こういった環境で生き残るには人に読ませる、よいドキュメントを書かねばならない。しかもアメリカで働いているのだから当然英語で書く必要がある。しかしながら私は帰国子女でもなく、特段英語が得意というわけでもない。最初の頃に書いたドキュメントは複数人にレビューされていつも真っ赤っかになっていて、そのマークアップの量を見ては鬱々としたものである。が、小さな子供とVisa問題を抱えて異国の地でクビになるわけにもいかない。英語弱
「リーダブルなテストコードについて考えよう ～VeriServe Test Automation Talk No.3～」で使用したスライドです。 https://veriserve-event.connpass.com/event/243280/ 登壇動画はこちらで公開されています。 https://vimeo.com/742517199/e001ac43ac ＜参考リンク＞ Twitter https://twitter.com/jnchito Blog https://blog.jnito.com/ Qiita https://qiita.com/jnchito プロを目指す人のためのRuby入門［改訂2版］ https://gihyo.jp/book/2021/978-4-297-12437-3 Everyday Rails - RSpecによるRailsテスト入門 https://
「うまい文章を書ける人」は “この5つ” を自然とできている - STUDY HACKER（スタディーハッカー）｜社会人の勉強法＆英語学習
「文章力」は、社会生活を送るうえで基本的かつ重要なスキルです。きれいで伝わる文章を書ける人はやはり信頼したくなりますし、逆に文章がめちゃくちゃだと「この人は大丈夫かな……？」と敬遠したくなるもの。メールやチャットがコミュニケーションの主流となった現代では、文章力がその人の印象を左右すると言っても過言ではないでしょう。 そこで今回は、「文章を書くのが苦手……」「文章だとなぜか理解してもらえない……」と悩んでいる人のために、文章力向上のコツを5つご紹介します。 【1】ゴールから逆算して必要なことを書く かつて進研ゼミ小論文編集長を務めた文章表現インストラクターの山田ズーニー氏は、「文章の良し悪しは目指すゴールによって違う」と述べます。たとえば、依頼メールであれば「人を動かすこと」、履歴書やエントリーシートであれば「内定」、小説であれば「感動」がゴールになるでしょう。このゴールがあやふやだと、た
One of the key elements of Google's software engineering culture is the use of design docs for defining software designs. These are relatively informal documents that the primary author or authors of a software system or application create before they embark on the coding project. The design doc documents the high level implementation strategy and key design decisions with emphasis on the trade-of
大事だけど AWS 構成図では省略してしまうことが多いサービスについて - サーバーワークスエンジニアブログ
コーヒーが好きな木谷映見です。 今回は小ネタです。AWS 構成図を書く際、省略してしまうことが多いサービスについて思いを馳せました。 よくある？構成図 リージョン アベイラビリティゾーン ルートテーブル AWS IAM インスタンスプロファイル Amazon EBS Elastic IP Elastic network interface（ENI） セキュリティグループ セッションマネージャーする時のエンドポイント 最終構成図 終わりに よくある？構成図 よくあると思われる構成図を描いてみました。 AWS になじみがある方から見ると、 「ふむ、パブリックサブネットとプライベートサブネットに 1 台ずつ EC2 インスタンスがあって、プライベートサブネットのインスタンスにはセッションマネージャーでログインするのかな？S3 バケットもあるな」 くらいの想像ができるかもしれません。 リージョン
こんにちは。「リーダブルコード」を先月読破して、感銘を受けた弁護士の人です。 なにに感銘を受けたかというと、「エンジニアが高級言語を効率的にコーディングするための工夫」は、契約という言語をコーディングするために援用できることがとても多いということです。 例えば、リーダブルコードは「関数には空虚な名前（tmpとかretvalとか）でなく、エンティティの実体に即した名前をつけよう！」と提案しています。 これめっちゃわかります！！！なぜなら、契約言語では当事者というクラスの表現のために「甲」「乙」という定義を未だに使います。そして、甲と乙を逆に書いてしまったままReviewを通過することが実際によくあります。オライリーさんには激怒されるでしょう。 しかし、よく考えると高級言語と契約言語が似ているのは当然だと思うようになりました。それは、どちらも「一定のインプットを入れると、必ず一定のアウトプット
みなさん、コードを書く前に設計書を書きますか？ 書くか書かないかは人それぞれだと思いますが、「設計」というプロセス自体は意識的であれ無意識的であれエンジニアであれば全員やっていることだと思います。 今回は設計プロセスの改善という文脈で私たちがDesign Docという仕組みを導入したことについて共有しようと思います。もし同じような状況を経験している人がいたら参考になれば幸いです。 導入の背景まずは導入するに至った状況からお話します。 私たちのサービスは、利用していただくユーザーの数が増加しています。それに伴って品質のハードルも上がってきました。サービスに障害が発生するとユーザーさんに大きな損害を出してしまうことになるからです。そこで今まで以上に安全にサービスを開発できる仕組みづくりが必要になりました。ですが、実現のためには大きく2つの課題がありました。 課題1. 開発スピードが徐々に鈍化し
＜書くことが苦手な人でも「オレオ公式」を知ることで、誰でも論理的な文章がすぐに書けるようになる＞ ハーバード大学で受け継がれているライティングメソッドから生まれた「オレオ公式」。 書くことが苦手な人でも「オレオ公式」を知れば、論理的かつ説得力のある「伝わる文章」の達人になれる。 『作文宿題が30分で書ける! 秘密のハーバード作文』（CCCメディアハウス）の「第1章 ハーバード大生みたいに考える」より一部抜粋。 作文上手になるためのセンターピンをねらえ！ 以前『ニューヨーク・タイムズ』の記者が書いた『習慣の力』（チャールズ・デュヒッグ著、講談社）という本が、世界中で話題になりました。人間の習慣の秘密について著者の考えをまとめた本です。 この本の中で著者は、「ボウリングのセンターピンを1本倒すだけでほかのピンも次々と倒れていくように、まず、その人が変えたいと思うもっとも大きな習慣をひとつ変える
新しいプロジェクトに参加してローカル環境を作り始めると、何かとエラーに遭遇します。 また、設計や実装について開発者に相談したり、コードレビューを依頼することもありますね。 開発者が近くにいれば、（それなりに、程よいタイミングを見計らって）話しかけて、エラーの原因を調べてもらったり、設計方法をホワイトボードにスケッチしながら相談できますが、リモート開発ではそうはいきません。 リモート開発で成果を上げるためには、このブログのように何の装飾もインタラクティブ性もない文章で、自分の状況や相談したい事柄を正確に伝える必要があります。 とはいえ私は昔、「文章がわかりにくい」と毎日、毎日上司にフィードバックをもらうくらいには文章を書くのが下手くそでした。今もわかりやすい文章が書けている自信はありません。 それでも、これまでに何度か、議論が好転したり、プロジェクトが前に進むきっかけとなる文章を書けたことが
パワポのスライドと箇条書きが人間を駄目にする 今から20年前の2003年、データの可視化やインフォメーションデザインの先駆者として有名なイエール大学の教授エドワード・タフティが「パワーポイントの認知スタイル」というエッセイを発表しました。 彼はこのエッセイの中で、パワーポイントのようなスライド形式はプレゼンテーション自体の質を低下させ、余計な誤解や混乱を招き、さらに言葉の使い方、論理的な説明、そして統計的な分析といったものが犠牲になるため、スライドをつくる人の思考回路にダメージを与えると主張します。 こうした主張に賛同する人は現在でも多くいて、その典型的な例がアマゾンです。アマゾンではミーティングの前に文章形式の資料が配られ、ミーティングの最初の5分はそれぞれがこの配られたレポートを黙って読むことから始まるという話は多くの方も聞いたことがあるのではないでしょうか。（リンク） 実は、アマゾン
自分が良い Design Docs(Software Design Document)を書くために、読んだ/参考になったリソース集 一覧 Design Docs とは Design Docs at Google デザインドック(Design Doc)について デザインドックで学ぶデザインドック 残業も減らせる!? 上級エンジニアになるための Design Doc 超入門 「Design Doc」って何なのか？ What Is A Design Doc In Software Engineering? (full example) What is a Design Doc: Software Engineering Best Practice #1 https://github.com/kaiinui/note/blob/master/Design--Designdoc.md Googleの
はじめにTIG真野です。 秋のブログ週間2023 の3本目は、設計ドキュメントをGit管理して腐らせないようにがんばってみた話をします。 前段として6年前、「我々はいかにシステム開発におけるドキュメント腐る問題と戦えば良いのか」という記事を書いたのですが、その後の試行錯誤はどこにも残していないことに気づきました。普段のフューチャー技術ブログですとちょっと引け目を感じるテーマですが、秋の夜長を楽しむため読み物成分を多めに書くというテーマのこのブログリレーにピッタリな気がするため、この機会をお借りします。 ドキュメントも色々な種別があるかと思いますが、この記事では設計ドキュメントを指すことにします。設計ドキュメントは開発メンバーが参照するもので、ステークホルダーへの説明資料に引用して使うことはあれど、主目的は異なるという前提です。Design Docの場合もありますし、システム構成図、ERD、
Obsidian がすごくいい
Obsidian（オブシディアン） と出会ってまだ3日目ではありますが、ここ最近で一番興味をそそられるアプリだったので紹介します。 A second brain, for you, forever. https://obsidian.md/ 出会いの経緯 を眺めていたときに一つの記事が目に付きました。 私がソフトウェア開発者として Notion から Obsidian に移った理由トップ3 何やら少し挑戦的なタイトルです。私も情報を整理するときに Notion はよく使用しています。不満がないとは言わないものの、Notion の機能を超える情報整理ツールは中々ないことくらいはわかります。 気になった記事は、まず読んでみることです。 読みながらの感想 "Obsidian" ……なんて読むの？ｶﾀｶﾀ……オブシディアン。いやー、スペルも読み方も覚えられないなぁ……。どんな意味なの？ｶﾀｶﾀ……
クラウドサービスでは大量の機能が多種多様に提供されており、簡単なアプリでも複数のサービスを組み合わせて利用することも珍しくありません。そうしたバックグラウンドのサービスを設計する際に役立つのがサービス間の構造を図に落とし込んだ「アーキテクチャ図」です。これまでもサードパーティーからさまざまなアーキテクチャ図作成ツールが提供されてきましたが、2022年2月17日にGoogleが自社クラウド向けの公式アーキテクチャ図作成ツールをリリースしたので、早速使い勝手を試してみました。 Google Cloud Developer Cheat Sheet https://googlecloudcheatsheet.withgoogle.com/architecture Introducing a Google Cloud architecture diagramming tool | Google Cl
こんにちは。電通デジタルでEMをしている河内です。エンジニアにおける採用・評価、スクラムマスターなどを担当しています。今回はすこし実装プラクティスから離れた話題になりますがお付き合いくださいませ。 弊社もご多分に漏れず完全テレワークを実施しており、かれこれ4か月が経ちます。その中で見えてきた課題とエンジニアチームとしてどう対峙したか、そしてそこで得た気づきを綴っていきたいと思います。この内容は、過去に開催したオンラインイベントでお話した内容になります。 テレワーク環境で私たちのエンジニア部門で急務と感じた課題テレワークが開始された2月後半、プログラミングやシステム開発プロジェクトを生業とする私たちの部では「リモート？全然OK。支障無いっす。」とタカを括っておりました。しかし開始されて間もなく、やっぱり慣れていない事が判明・・・。テレワークを経験されている読者の多くの方が感じていることと同様
文化審議会の国語課題小委員会は30日、半世紀以上前の通知に従い、公文書では読点に「，」（コンマ）を使うとのルールを見直し、一般に広く使われている「、」（テン）を用いるよう求める中間報告案をまとめた。年度内に正式な報告をまとめ、文化庁がその後に内閣官房と通知見直しに向けて協議する。 公文書は、1952年に当時の官房長官が各省庁の事務次官に通知した「公用文作成の要領」で、「なるべく広い範囲」で左横書きとし、横書きでは句読点には「。」（マル）とコンマを使うと定められた。ただ、現在は多くの省庁がテンを使っており、文化庁は要領改定を検討してきた。
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
元米マイクロソフト本社パワポ責任者が教える「科学的に正しい資料の作り方」- Schoo PENCIL
伸ばすのが難しい能力: 柴田 芳樹 (Yoshiki Shibata)
朝日新聞社、長文を要約するAPIを無償公開 500字→200字に圧縮、重要事項の自動抽出も
小説の推敲補助ソフト「Novel Supporter」に隠れた文章癖をあぶり出す分析機能／文字種・文章長・段落長などの推移をグラフ化
元米マイクロソフト本社パワポ責任者が教える「科学的に正しい資料の作り方」- Schoo PENCIL
議事録を簡単に構造化(っぽく)する方法｜とあるコンサルタント
ゼロから始める、データ分析と可視化 - Kyash Product Blog
GitHubのawesomeリストが本当にawesomeなものばかりだから一度見てほしい - Qiita
Rust の最初のステップ - Training
読みやすいドキュメントを書くために今日からできる7つのこと｜壮｜Masato Tanaka
伝わる文章作成の基本を学ぶための記事・学習コンテンツのまとめ - Qiita
自己流の手順書フォーマットを公開してみた | DevelopersIO
ソフトウェアドキュメント作法 - maru source
「してほしい」だけじゃない 漢字で書けるのに仮名にする言葉
ドキュメント作成スキル向上を目指す人向けおすすめ記事まとめ - Qiita
英語が苦手な人が英文Writingを学ぶにあたっておすすめの本五選｜Yuki Nakazato
リーダブルテストコード / #vstat
Design Docs at Google
もし「リーダブルコード」を弁護士が読んだら？ - MNTSQ Techブログ
安全安心にソフトウェア開発を行うためのDesign Doc導入ガイド｜面川泰明
ハーバード大学で150年以上教えられる作文術「オレオ公式」とは？...順番に当てはめるだけで論理的な文章に
リモート開発を助ける「思いやりのある文章」の書き方 - ROUTE06 Tech Blog
パワポのスライドと箇条書きが人間を駄目にする - Qiita
【メモ】良いDesign Docs(Software Design Document)を書くためのリソース集
設計ドキュメント腐る問題、Git管理で運用してみた結果 | フューチャー技術ブログ
Google純正の構成図作成ツールが登場したので早速使ってみた
テレワークで始めたドキュメント駆動業務｜Dentsu Digital Tech Blog
公文書の読点「，」から「、」に 半世紀以上前の通知変更へ ｜ 共同通信