新たに加わるエンジニアをもてなすための施策 - オンボーディング - Qiita
この記事はGoodpatch Advent Calendar 2017の19日目の記事です。 私の開発チームでは現在、数十人規模で開発を進めているのですが、エンジニアが増員される中でどのようなインプットがあると、スムーズにプロジェクトに入ってもらえるかを色々と考えてました。今回は新たにエンジニアが加わる際に考慮しておくと良さそうな事を書きたいと思います。 ちなみに私はフロントエンドエンジニアなので、フロントエンド＆Webアプリケーション開発に多少寄った内容になってしまう事をご了承ください。 サービス理解 まずは何と言ってもサービス・プロダクトの説明が必要です。 例えば、以下のような情報をもとに、対話形式で説明していくと理解してもらいやすいかと思います。 サービスのコンセプト、提供価値 サービスの歴史 ターゲットユーザー KGI・KPI 競合他社、競合サービス 開発ロードマップ 開発体制、組
開発チームでドキュメントを継続的に保守していくシンプルな方法
はじめに ドキュメントの管理方法はプロジェクトを進めるうえで頭を悩ませる話題のひとつであり、プロジェクトの本筋ではないこともあってなあなあで運用して後悔しやすい部分になります。ドキュメントを探しづらくなったり、ドキュメントが全然更新されずに使えるドキュメントがほとんどない状況になったり、ドキュメントの存在自体が暗黙知になったり、とにかく諸々の問題がよく起きます。こうしたことからプロジェクトに与える影響は存外に大きく、きちんと運用を考える必要性は高いと言えます。しかしながら、大袈裟な運用体制を敷いたり複雑なルールを作ったりすると、今度はコストが掛かり過ぎたりドキュメントを書くこと自体が難しくなったりもするので、費用対効果を考えると匙加減が難しい話でもあります。 そこで、本記事では比較的導入しやすく機能もしやすいシンプルな管理方法を提案します。なお、シンプルさを優先した方法なので要点を理解した
プロダクト開発を成功に導くドキュメントって何だ？iwashiさんに学ぶ“神ドキュメント”の作り方 - エンジニアtype | 転職type
2023.03.28 スキル プロダクト 誰にでも分かりやすく、信頼できるドキュメントの存在は、プロダクト開発を円滑に進める上で不可欠だ。 2023年3月11日に発売された書籍『エンジニアのためのドキュメントライティング』（日本能率協会マネジメントセンター）を翻訳し、自身もエンジニアとしてさまざまな開発ドキュメントに触れてきた岩瀬義昌さんは、「プロダクトが育つ開発組織には、優れたドキュメントとドキュメントを尊重する文化がある」と話す。 では、プロダクト開発を成功に導く「優れたドキュメント」とはどのようなものなのか。また、そんなドキュメントが存在する組織は、そうでない組織とどんな差が生まれるのか。岩瀬さんに話を聞いた。 書籍『エンジニアのためのドキュメントライティング』翻訳者 人気ポッドキャスト『#fukabori.fm』運営者 岩瀬義昌さん（@iwashi86） 東京大学大学院修士課程修了
エンジニアが開発しやすい環境作りをする
はじめに 自分は渋谷のWeb系開発会社にて執行役員兼エンジニアをやっています。(新卒入社3年目) 直近では6~8名程のエンジニアがいるプロジェクトで、ディレクトリ設計やissue作成、コードレビュー、スケジュール管理、PMへのUI/UX及び機能提案などを行なっています。 その中で自分が「エンジニアチームにとって開発しやすい環境整備」を色々試し、実践してきたので整理していきます。 この記事の主な対象者 エンジニアチームの開発モチベーションを上げたい人 エンジニアにとって開発しやすい環境の作り方 おことわり 今回紹介するのは自分が実践してきた一例であり、必ずしも正解というわけではありません 「こうしなさい」ではなく「こうするとより良くなるかも」といったモチベで書いています 具体的な開発の設計を紹介するものではありません エンジニアが開発しやすい環境作り 5つのセクションに分けて紹介していきます
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
