はじめに 時の経つのは早いもので、私がIT業界に身を置いて四半世紀になってしまいました。 その間、膨大な数の「設計書（仕様書）」を書いて来ましたが、未だに悩み・迷いは尽きません。 それでも、亀の甲より年の劫とも申しますので、私なりの経験則を「個人」と「チーム」の両観点でまとめてみました。 本稿のテーマは、「主に設計書を想定した、開発ドキュメントの書き方」です。 本稿で前提とする設計書は、ExcelやWordで書かれた、フォーマルな（≒納品物になりえる）設計文書、です。 したがって、自社サービス開発よりも受託開発、アジャイルよりもウォーターフォール、を前提として読んでいただいた方が、しっくりくると思われます。 ＜ご注意＞ 本稿の内容は執筆者独自の見解であり、所属企業における立場、戦略、意見を代表するものではありません。 個人的に心がけていること 当該文書の作成目的や位置付けを冒頭に記載する

TL;DR 自身の成果をアピールするために、1)Before/After、2)自分の寄与度、3)数字的インパクトを過不足なく伝えることが重要 説明の冒頭では、課題と解法の全体感と成果を述べ、詳細は後に肉付けすると伝わりやすい 課題を伝える際は"誰から見た課題か"を明確にする。課題は解法の前提であるためブレないように はじめに 技術広報のしゅーぞーです。この記事では、過去100人分程度の成果報告書を読み、気付いた "自分の成果をわかりやすく伝える書き方"をまとめています。 仕事をしていると自身の成果を的確に伝える機会は数多くありますよね。 評価期、転職面接、昇格面談など 評価者に自分の成果をどう分かりやすく伝えるか は自分のキャリアを伸ばす上でとても大事なスキルです。 しかし、自分の頑張りや成果を上手く言語化し、相手に正しく理解してもらうのは簡単ではありません。 特に、経験の浅い若手にとって

目次 はじめに 個人を特定する情報が個人情報じゃない デジタル署名は暗号化しない TLS(SSL) は共通鍵を公開鍵で暗号化しない TLS(SSL) が使われていれば安全じゃない 変数は箱じゃない Python 等は「ソースコードを 1 行ずつ実行するインタプリタ方式」じゃない 日本語 1 文字は 2 バイトじゃない 動画が動いて見えるのは残像によるものじゃない 標本化定理は「2 倍以上の周波数」じゃない その他いろいろ はじめに 2022 年から高等学校で、プログラミング等を学ぶ「情報Ⅰ」が 必修 必履修科目になりました。1 さらには 2025 年入試から大学入試共通テストでも出題されるようになり、教科「情報」の重要性が高まっています。 これで 2030年に79万人不足すると言われる IT 人材 の問題が解決！…と言いたいところですが、先日も『課題感ある教科1位「情報」』という調査結果が

突然ですが、質問です！ 以下の文章で、登場人物が実際に声に出して言っている部分と、心の中で思い浮かべている部分はどこでしょうか。 「みんなはね、ずいぶん走ったけれども遅れてしまったよ。ザネリもね、ずいぶん走ったけれども追いつかなかった」と言いました。 ジョバンニは、 （そうだ、ぼくたちはいま、いっしょにさそって出かけたのだ）とおもいながら、 「どこかで待っていようか」と言いました。 青空文庫　宮沢賢治『銀河鉄道の夜』 https://www.aozora.gr.jp/cards/000081/files/43737_19215.html 答えは簡単ですね。 「　」の中の言葉が声に出して言っている部分、（　）の中の言葉が心の中で思い浮かべている部分です。 前後の文章からも読み取れると思いますが、括弧の使い分けがされていることで、より分かりやすくなっています。 このように括弧類は主に文章内で会

技術文書の長音記号どうする？「コンピューター」と「コンピュータ」2022年現在と過去のルールについてのまとめ日本語Englishdocumentation外来語長音 長音記号付ける？付けない？問題とは "computer" を日本語のカタカナ表記で記載したい場合、歴史的経緯などから次の2通りの表記方法がありえます。 「コンピューター」 末尾に「長音記号」があるパターン 「コンピュータ」 末尾に「長音記号」を付けないパターン 2022年現在の結論 原則的に語尾の「ー」は付ける "computer" => 「コンピューター」 迷ったら？ 原語がUSA英語で単語としてのスペル的にあるいは一般的発音慣習で伸びる場合 => 付ける "computer" => [US] kəmpjútər => 「コンピューター」 "operator" => [US] ɑ́pərèitər => 「オペレーター」

「地の文の書き方」は、言語化が難しいと言われてきた――。 だが今は違う！十万字かければ語れる！教えられる！「地の文の書き方」、皆さんはどう習得しましたか？ 的確に「これを読めば書ける」という書物はありましたか？ 今回特に実感しているのですが、「プロット」や「文法」と違って、「小説っぽい文」「小説の描写」は！なかなか！論じるのが難しい！ わたくしもいくつか本を探して読んだことがあるのですが……「これさえ読めば」というものは見つかりませんでした。 言葉って正解がないし、芸術の分野だから「こう書こう」がまず定義・決定できないんですの！ケースバイケースの極み。 特に困るのが、国語やライティングの本を参考に「間違いのない文」は書けるけど「小説っぽい文ってなんだ!?」という中級者段階。 いやはやいやはや……マジで参考にできるやつが（見つけられ）ないんです。「とにかく書いてみよう」「好きな作家を模写しよ

「大江戸Ruby会議10」での発表資料です。 https://regional.rubykaigi.org/oedo10/

大学や大学院で論文の書き方を鍛え上げた人たちには遠く遠く及ばないが、僕の様なはぐれもの1でも最近は Amazon 社内で文書の質が高いと評価してもらえるまでにはなった。Software Engineer として、コードでのアウトプットはもちろん大事だけど、文書のアウトプット(およびそれによって得られた実際のアウトプット)は同じだけ重要である2。今回は自分が最近どういうところに気をつけて技術文書を書いているのか、ということについて数年後の自分が忘れてないことを確かめられる様にまとめておく。 そもそも文書とは？ 英語だと document。ここで指す(技術)文書とは、人間が読む文体で書かれた技術に関連する情報、といったものだ。具体的に言うと以下の様なものを想定している: 新しいプロジェクトの骨子を説明する資料 会議の叩き台となる 1 枚ペラ 本番環境に変更を加えるにあたっての包括的な情報や具体

会食の本質は「店選び」ではない「２週間後に会食のセッティングをお願い！ ４人で、いい感じの店の予約と準備を任せた！ じゃ、あとはうまくやっといてね！　よろしく！」 上司からの依頼。何度聞いても心臓の奥で嫌な汗が出るような、この瞬間。そう、会食はビジネスパーソンにとってできる限り避けたい「雑務」である。 単に店を選べばいいだけかと思ったら、大間違いだ。少し考えるだけでも気が重くなる調整とビジネスパーソンとしての機微が求められる。 上司がクライアントと会食をセッティングする背景の理解 -相手の役職やビジネス背景、会食で達成したい目的を踏まえてどのような価格帯/立地の店にすべきか 上司やクライアントの食の好みの理解 -肉料理希望と言われたがステーキ/焼肉/肉割烹/メインが肉のフレンチやイタリアン、どれを選ぶべきか 個室が必要か不要か -オープン席の場合は席間隔はどのくらい空いた店にすべきか 二次

第0部　まずは「分かりづらい説明」を知ろう（p.14～） 第1部　口頭説明編（p.25～） 第2部　資料作成編（p.63～） 第3部　スライド作成編（p.81～） スライドのまとめ（p.115～）

大手ITスタイルガイドがベースGoogleやMicrosoftなど大手IT企業の英語スタイルガイドの基準がベース。一般的な英語表記から外れません。

先日投稿した以下のエントリで、「使い方がわからない」という意見を多く頂いた。 mugi1.hateblo.jp マルチカーソル自体の操作方法は調べれば出てくるし、事例だけ紹介しとけばええやろ、と思っていたのだが、いきなり応用のサンプルを貼りすぎてわけがわからなかったらしい。申し訳ない。 せっかくなので、基礎から含め、どういったキー入力で上記のような操作を実現しているのかを紹介したいと思う。 🔥実践！マルチカーソル / 入門編 なおmac環境です。Windowsやその他環境の方は気合で調べてください。 また、言い訳臭くて申し訳ないが、私は普段はSublime Text Keymap and Settings Importerを使っており、SublimeTextっぽいキーバインドに変えて編集している。 一旦無効にしたうえでVSCodeデフォルトの状態で一通り調べて書いたつもりだが、もし違って

GitHub上の実際のコミットメッセージやIssueのやりとりをみて、チートシート作りました。 共通的なこと コミットメッセージやIssueのタイトルは、主語省略し、1文で書き行末ピリオドは付けない 動詞は現在形・過去形のどちらも同じくらいの頻度で見られるが、どちらかに揃える。 コミットメッセージを書く Japanese English

ここは倉本圭造（経営コンサルタント・経済思想家）のブログです。詳細な自己紹介等はウェブサイトへどうぞ→コチラ https://www.youtube.com/watch?v=BmYv8XGl-YU （アイキャッチ画像はウィキペディアからお借りしました） 今朝ツイッターを眺めていたら、フェイスブック創業者マーク・ザッカーバーグが母校ハーバード大学の卒業式に呼ばれてスピーチしてる動画のリンクが流れてきて、軽い気持ちで再生しはじめたら凄い迫力で、３０分以上のスピーチ最後まで全部見てしまったってことがあった。 結構笑えるジョーク（窓ガラスに数式書いたりしないよ！・・・とかいう映画”ソーシャルネットワーク”を根に持ってるようなジョークとか）やハーバード内輪ネタ（と思われる・・・ちょっとググると出て来るのが今の時代の救いですが）も交えつつ、卒業生と１０歳も離れてない立場から”僕ら世代の責任”という切り

自分がプログラマから起業して沢山失敗したので、同じミスをプログラマ、エンジニアの方にして欲しくないという想いから、よくある失敗をまとめました。(常に追加中) プログラマでなくても、フリーランスや起業する方に役立つでしょう。 特に技術分野の経験だけしかない人は、気をつけましょう。 技術以外の大量の会社関連の知識、実行能力、実行する時間、経験が必要になります。 従業員との最も大きな違いはリスクかと思います。 従業員は金銭的なマイナスリスクは非常に少ないですが、フリーランスや取締役は数百万円以上のリスク負うことが非常に多いので、リスクヘッジをするための知識と経験が(嫌でも)多く必要になります。 技術も持っているのでプロダクトを作りたい方も多いと思いますが、会社の場合プロダクトを作るだけではなく、市場で勝てるプロダクトを作る会社組織も同時に作らなくてはなりません。どのような人材をどの順番でどのよう

なぜDMMがweb3に参入したのか。Seamoon Protocolが目指す新たなエンタメ体験の未来とは