【汎用ソフトスキル】ドキュメンテーションの続け方
この記事の目的 最近「良いドキュメントが作れているな」と思う機会が増えてきたので、その知見をアウトプットしたくなった。 想定読者 今所属してる組織(会社/プロジェクトなど)のドキュメントがイマイチで悩んでいる人 そもそもドキュメントが無い組織に所属していてつらい思いをしている人 「ドキュメントを作れ」という漠然としたタスクを振られて困っている人 想定読者ではない人 メンテなブルなドキュメンテーションのエコシステムが完成している組織で更によいやり方を模索している人 私もまだ模索中なので、いいやり方があれば教えてほしいです👀 顧客提出などの「納品が必要」なドキュメントの管理方法を模索している人 この記事では「社内の情報共有」にスコープを切って話をしています 書いている人のスペック(参考) 歴５年くらいのなんちゃってフルスタックエンジニア 普段は Node.js / React.js or R
わかりやすくて役に立つリリースノートを書くための10のポイント
リリースノートとは、ソフトウェアのリリース時に機能や目的などを知らせるための資料であり、ソフトウェアがアップデートされる場合も機能強化や不具合修正に関する情報をリリースノートとして公開します。リリースノートの中には優れたものもあれば悪いものもあるとのことで、「よいリリースノートを書くための10のポイント」について、ソフトウェア開発者のサイモン・ウィルソン氏がまとめています。 Writing better release notes https://simonwillison.net/2022/Jan/31/release-notes/ ウィルソン氏は、「リリースノートはオープンソースプロセスの重要な部分です」と述べ、GitHubなどでオープンソースのプロジェクトをリリースする場合、リリースノートを適切に書くことが大切だと主張しています。最近、「よいリリースノートの書き方」について考えていた
MVP（Minimum Viable Product）の意味を理解する。そして、なぜ私はEarliest Testable / Usable / Lovableを好むのか。 | ANKR DESIGN | デザインリサーチ・プロトタイピング・サービスデザイン
数年前、私はこんな絵を書いて、アジャイル開発やリーン開発のついての様々なプレゼンで用いた。 そこから、この絵は急速に広まっていった！記事、プレゼン、さらには本（Jeff Pattonの”User Story Mapping”という素晴らしい読み物なのだが）にまで至る所で姿を見せた。多くの人がこの絵は反復型開発、リーンスタートアップ、MVP(minimum viable product)の本質をよく捉えていると伝えてくれた。しかし、元の文脈から切り離して物事を捉える際にはごく自然なことであるのだが、この絵を誤解している人がいる。簡素化しすぎだと非難する人もいる。（正しい指摘である） この絵はあくまで比喩である。実際の車の開発の話ではなく、車を比喩とした一般的なプロダクトの開発の話なのである。 とにかく、これらのバズからこの考えの背景を話す時だと判断したのだ。 １つ目の例：not like
市場は「なんかいい感じにしてくれる」エンジニアを求めているのではないか - 毎日がもふもふ
エンジニア不足、エンジニア不足と言われて久しいですが、日本でのプログラミングスクールの先駆けとも言えるTECH::CAMPさんのサービス開始が2014年なので、今や8年が過ぎようとしているわけです。 ともすると、市場に既にベテラン級のエンジニアがわんさかいてもおかしくないんですが、今でも「エンジニア採用できない」という声が絶えることないように見えます。はて？どうしたことだろうか、と思ったので今市場でどんなエンジニアが求められているのかを考えてみました。 高い技術力よりも「いい感じ」力を求めている エンジニアというと、技術を駆使して問題解決をするスペシャリストというイメージがあり、技術力が高い=優秀という認識を持つのが自然です。実際、技術力が低くてまともにプロダクト開発出来ないようでは論外だし、技術的な難問の攻略が命運を分けるケースはあるにはあります。 しかし、実際には開発プロジェクトの失敗
8年運用したJavaScriptでの開発を段階的にTypeScript移行していくためにやっていること | CyberAgent Developers Blog
CyberAgent Developers Advent Calendar 2021 – Adventar 16日目の記事です。 マッチングアプリ「タップル」のバックエンド開発を担当している上村です。 タップルで現在進行中のTypeScript移行について、取り組む事を決めたモチベーション、移行の進め方について紹介します。 目次 TypeScriptとは 開発現場の背景 なぜ今までTypeScript移行が進められなかったのか？ なぜTypeScriptへの移行を決断したか？ TypeScript移行を進めるにあたっての課題 TypeScript移行の方針 タップルでのTypeScript移行の実際の勧め方 実際にTypeScript移行を進めてみた結果 TypeScriptとは 公式サイトに「TypeScript is JavaScript with syntax for types.」
「オープンソース」は壊れていない
Kailash Nadhのブログより。 不幸なlog4j2騒動の余波で書かれたこの記事(「オープンソース」はXeによって壊れている)を読みました。著者は、大規模な営利企業がFOSSを広く利用するようになってから、FOSS(フリーおよびオープンソース)の世界を悩ませてきた関連する問題について論じています。無数の「ユニコーン」がFOSSにほぼ完全に依存した評価額で無限の資金を調達し、FOSSが企業化と資本化に組み込まれてから、この問題はずっと続いています。それなのに、重要で広く利用されているFOSSの数え切れないほどのメンテナが、生計を立てるのに苦労しています。 これは誰のせいでしょうか? 私は、これが概念的なフレームワークやシステムとしてのFOSSのせいだとは思いません。もし、FOSSが壊れていたら、今日私たちが知っているようなインターネットは存在しなかったでしょうし、私たちが当たり前のよう
OSSが持続可能であるために――疲弊する「ボランティアエンジニア」を支援する新たな仕組みとは？
――皆さんはそれぞれ長らくOSSに関わられて来られたわけですが、その中でOSSを取り巻く環境の変化についてどのように感じていらっしゃいますか。 黒坂：OSSは、目的や意義が3世代にわたって大きく変わってきたように感じています。Linuxなど中心となるプロジェクトがあり、その開発に貢献したいという開発者が大勢を占めていたのが第1世代。その後の2004〜5年くらいから、そうした文化を引き継ぎながらも、「コスト削減」を目的に企業が使うようになり、オープンな環境での開発による進化速度や品質向上に価値を見出した開発者が増加しました。「OSSに貢献したい」というより、「新しい何かを生み出すためにOSSやOSSという開発手法を利用する」という価値観の変化が見られたのが第2世代です。 そして第3世代においてはAIやIoTなどイノベーションを起こすハイエンドな技術として認識されるようになり、OSSを使うこと
textlintプロジェクトの現在地 - SmartHR Tech Blog
こんにちは、今年1年でキーボードを3回買い替えたUXライターのkunyです。今は、NiZのATOM 66を使っています。 SmartHRでは、textlintに独自のルールプリセットを追加して利用しています。textlintは4人で運用していますが、自分もメンバーの1人です。この記事では、textlintの便利さを世の中に伝えたく、textlintの利用シーンや利用者の生の声をご紹介します。 ※この記事は、2021年SmartHRアドベントカレンダーの13日目の記事です。 textlintの利用シーン 開発現場において、各自のローカル環境・GitHubと連携したCircleCIで文言の正誤を判定しています。 ローカル環境では、エディター上でコマンドを実行すると、「エラー内容」と「正しい表現」がわかります。コマンドで「正しい表現」に置き換えることもできますが、前後の文脈を確認しながら文言を修
リモートでむしろ生産性が上がったエンジニア組織の作り方を一休 CTOの伊藤さんに聞いてみた
宿泊予約事業やレストラン予約事業などを手掛ける、株式会社一休。エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Teams」を活用いただいています。 今回は、執行役員CTOを務める伊藤直也さんにインタビュー。実際に「Findy Teams」上のデータを参照しながら、エンジニア組織における生産性についての考え方などを伺っていきます。 ■プロフィール 伊藤 直也 株式会社 一休 執行役員 CTO コロナ禍における開発を、Findy Teamsで振り返る ──こちらが御社の2020年1月から直近までのデータになります。プルリク作成数はだいたい平均値を超えていて、件数としては2020年7月と2020年10月に大きな山があります。今年は5月頃から全体的に伸びている傾向にありますが、これらの要因として考えられる部分はありますか？ Findy Teamsのチ
モグラたたき開発になる理由 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? モグラたたき開発になる理由 モグラたたき開発を卒業しようの一部として書いていましたが、項目が増えてきたので 別記事に独立させました。 これらは、ほとんどが推測です。 某銀行の次期システムとか、受注したが開発できすに中断した官公庁の案件とか、携帯電話開発の事例 その他もろもろの不幸な事例を元に推測で書いています。まるで自分のプロジェクトとのようだと思われる方がいらしても、他人の空似です。 チームとしての共通の目標を成し遂げようという意識が低下している。 ユーザー視点の欠落 セクショナリズムの蔓延、「それは自分の知ったことじゃない」 「今ま
2kgから800gに激減、教科書「PMBOK」新版に何が起こったのか
「プロジェクトマネジャーの教科書」とも呼ばれる「PMBOKガイド」第7版の日本語版書籍が2021年11月1日に発売される。第6版は重量が2kgあったが、新版は800gと一気に軽くなった。プロジェクトの流れをまとめたプロセスの記載が姿を消し、プロジェクト運営を成功させる「原理・原則」が前面に出るなど構成が大きく変わったことが影響した。変化が激しい時代に対応するため、開発プロセスにかかわらず活用できるように転換した。 米PMI（Project Management Institute）が発行したPMBOKガイド第7版は、従来版とは全く異なる構成になった。翻訳作業に中心的に携わったPMI日本支部の庄司敏浩標準推進委員会委員は「プロセス中心の構成をやめた」と説明する。 第6版までのPMBOKガイドは、QCD（品質・コスト・納期）をはじめとする要求事項を満たして円滑に成果物を作り上げることを重視して
アジャイル生誕20年──平鍋氏と及部氏が、エンジニアとアジャイル開発の関係を考えてみた【デブサミ夏2021】
日本におけるアジャイル開発の第一人者であり、ソフトウェア開発手法の必読書『アジャイル開発とスクラム』の共著者である平鍋健児氏と及部敬雄氏。2001年の「アジャイルソフトウェア開発宣言から20年を迎える2021年は、アジャイル開発歴10年の及部氏とアジャイル開発歴20年の平鍋氏にとっても、節目の年である。そこで、今回のセッションはアジャイル開発生誕20周年を記念し、両者のこれまでの軌跡とともに、なぜ自分がアジャイル開発と関わっているのか、その熱い想いが語られた。 株式会社永和システムマネジメント 代表取締役社長 平鍋健児氏（左上）、株式会社デンソー デジタルイノベーション室 及部敬雄氏（右下） アジャイル開発に「もっとよい世界があるかもしれない」と気づかされた 及部氏が楽天に新卒で入社したのは、2009年。エンジニアとして初めて書いたコードや最初のプロジェクト、初リリースで感動し、やりがいを
スケジュールにバッファを設けるのは悪か？ - ユニファ開発者ブログ
こんにちは、プロダクトマネージャーの田嶋です。 はじめにお断りしておきますが、本記事は、2021年7月にリリースした開発プロジェクト（以降「Rプロジェクト」）において、遅延なく開発を進められたことのプチ自慢です🎉 笑 週次で滞りなくバーンダウンが落ちていく様子を、チームで安心して見ることができました。スケジュールのストレスなく開発を進めることができたのは、チームの頑張りのほか、見積もりとスケジュール管理が良かったからだとも思っています！ 開発プロジェクトにスケジュールが求められる理由は様々ですが、キャンペーン施策や営業資料の準備計画を立てるため、あるいは利用顧客へも告知責任があるから、などです。そのいずれの場合も、計画やそのための作業見積もりは欠かせません。 しかし多くの開発プロジェクトにおいて、実績は見積もりよりも上振れし、遅延してしまうことが多いのではないでしょうか。 本記事では、R
Mock Service Worker で開発用のモックAPIを作る
フロントエンドの開発時に仮の API を使いたいってシチュエーションはわりとあると思います。 そんな時に、Mock Service Worker を使うと便利だったのでまとめます。 Mock Service Worker とは？ Mock Service Worker は、ネットワークレベルで API リクエストをインターセプトして mock のデータを返すためのライブラリです。API リクエストを含む処理のテストや、開発時の mock サーバーの代替として利用出来ます。 テストでの利用については以前こちらの記事でまとめました。 今回は開発時のモック API としての利用について書きます。 開発用の API というと、JSON Serverが有名ですが、Mock Service Worker では Service Worker を使ってリクエストを返すため、別プロセスでローカルサーバーを立
なぜスクラムチームの開発者が複数チームを兼任しないほうがよいのか
みなさんこんにちは。@ryuzeeです。 よく受ける相談の1つに、「スクラムチームの開発者は複数のチームやプロダクト、プロジェクトを兼任してもよいのか」というのがあります。コーチ業をしている人ならみんな受けたことがあるものだと思いますが、詳しく見ていきます。 まず最初に結論ですが、タイトルにもあるとおり、「スクラムチームの開発者は複数チームを兼任しないほうがよい」です（スクラムガイドには書いていないですが、スクラムガイドは全てを詳細に記したハウツーではありません。あくまでゲームのルールです）。 理由を順番に見ていきましょう。 1. 開発に使える時間がかなり少ないスクラムチームの開発者はスプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブといったイベントと、プロダクトバックログリファインメントのような活動に一定の時間を使います。 チームによって時間は変わ
アプリリニューアルを楽しくやりきる話 - クックパッド開発者ブログ
こんにちは。レシピ事業開発部 クロスファンクショナルグループの @kaa です。 クックパッドAndroidアプリは昨年秋にフルリニューアルを実施しました。 リニューアル内容としては半年ほど先にiosでリニューアルを実施したものを導入になります。 弊社はこのリニューアルプロジェクト開始の2ヶ月ほど前からリモート主体の勤務体制になっており、期間中は週1で出社という状況でした。まだリモート勤務にもみんなが慣れているとは言えないタイミングでの実施となりました。 このプロジェクトのため3ヶ月程度の期間、部署横断でメンバーを集め進めました。 体制は以下の通り。 アプリエンジニア6名(1名はAPI兼任)＋決済・基盤・テストのサポートに2名 デザイナー2名(デザインディレクション＋1名) ディレクター3名(PdM,PjM,開発ディレクション) このプロジェクトについて、開発ディレクションの立場から楽しく
プロダクトマネジメント私記
2 年前にソフトウェアエンジニアからプロダクトマネージャーにロールチェンジした。ソフトウェアエンジニア時代は割と頑張れてたし成果を出せてた気がするのだけど、プロダクトマネージャーになってからは正直かなり苦戦した。プロダクトマネージャー 3 年目を迎えてようやく仕事に自信が持てるようになってきた気がするので、振り返りを兼ねて、これから同じようにプロダクトマネージャーにコンバートしたいと思っている人の役に立てばと思って書きます。 Table of Contents プロダクトマネージャーになった理由 プロダクトマネージャーの役割 1. 何がユーザーの問題かを特定する 2. その問題を解決する製品を定義する 3. 製品がリリースされるまで開発チームに帯同し、リリースを成し遂げる 4. 製品が「正解」であったかの評価を行う 実際になってみてのギャップ プロダクトマネジメントの認知度が原因？ 一体型
.NET Framework 3.0 で作られたアプリケーションを .NET 5 に最新化して GitHub で公開するまでに行ったこと - しばやん雑記
CodePlex に置いてあった .NET Framework 3.0 時代に書かれたアプリケーションを、GitHub に移行しつつ .NET 5 で動くように 2 週間ぐらい頑張った話を書きます。正直なところ 12 年前に書かれたコードを何とかするのはめっちゃ大変でした。 今回コードの改善を頑張ったので色々な実験場としても使えるようにしています。特に GitHub 周りは新しい機能を使ってみるようにしています。 .NET Framework 3.0 時代に書かれたコードを何とかするのが本当に大変だった（まだ何とか出来てない https://t.co/u5SrISQRCL— Tatsuro Shibamura (@shibayan) 2021年5月9日 実際には .NET 5 で動くようにはなっていますが、中身は古臭い実装がたくさん残っているので、ツイートの通り全然何とかなっていない状況で
JavaScriptツールチェインの統一を目指す「Rome」開発チームが起業、「Rome Tools, Inc.」を立ち上げ
JavaScriptツールチェインの統一を目指す「Rome」開発チームが起業、「Rome Tools, Inc.」を立ち上げ 現在、モダンなJavaScript開発環境としては、ESLintに代表される構文チェッカーや、Babelに代表されるJavaScript変換ツール、モジュールを組み合わせるなどのバンドル操作を行うWebpackなど、さまざまなツールを組み合わせる、いわゆるツールチェインを用いるのが一般的となっています。 こうしたなかで、このツールチェインの機能をすべて備えた1つのツールでJavaScriptの開発環境を統一してしまおうというオープンソースのプロジェクト「Rome」が、昨年発表されました。 Romeでは、JavaScriptやTypeScript、JSXなどでの開発において、現時点で以下の領域をカバーする予定です。HTML、CSS、Markdown、JSONなどにも対
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソフトウェア開発の見積もりにおける問題点は何ですか？
