PyCon JP 2022 での発表スライドです。 GitHub: https://github.com/taishi-i/awesome-japanese-nlp-resources

2021/04/20 東京大学 講義 「ICTと産業」

Open8 勉強会で発表したレビューの仕方と心理的安全性の話しです。

※このスライドはPHPカンファレンス香川2024で登壇したトークのものになります。 未経験からエンジニアとして入社し、初めてのチーム開発を経験しました。 1年間の学びで重要だと感じたのはプルリクエスト（PR）の作成方法です。 PRはマージされて終わりのものではなく、後続のメンバーや開発段階のメンバーが参照することへの考慮が必要です。 PRはプロジェクトの重要な履歴であり、その質はチームの健全性に影響します。 美しく、有用で分かりやすいPRを作成することで、 ・コミュニケーションエラー減少 ・誤った仕様理解に基づく実装ミス削減 ・レビュワーのレビュー効率向上が期待でき、チームメンバーの幸福に繋がる といった効果が期待できます。 このトークでは、経験をもとに学んだ良いPRの具体的な要素やTipsに焦点を当て、良いPRがチームの生産性や雰囲気に与える良い影響についてもお話できればと思っています。

2019/06/11追記: これは2012年の投稿です。なぜかはてなブックマークで拡散されていますが、内容は時代にそぐわなくなったものもあるのでご注意ください。 これ知らないプログラマって損してんなって思う汎用的なツールのコメントに寄せられたツールを分類分けしてみました。 解説は、ほぼコメントに寄せられた内容のコピペです。 URLのみの記述は公式サイト(か、ほぼ公式サイトと化しているサイト) 公式サイトとは別に、ページタイトルだけでツールを説明しきっているページへのリンクも付けておきました。類似ページが複数ある場合は、はてブのブックマーク数が多いものを選びました。 知らないツールもあるので、分類がいいかげんなところもあると思います。何か気づいたらコメントください。 解説が不十分なツールについても、補足（コピペで本文に取り込める体裁だとありがたい）を頂けると助かります！ 元ネタの投稿は現在進

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