NTT Com オンボーディングハンドブック
オンボーディング ハンドブック #このサイトについて #NTTコミュニケーションズ(以降、NTT Com)社内で製作したオンボーディングハンドブックの内容を、より一般化して広く公開するものです。 ソースコード #本書のソースコードは https://github.com/nttcom/onboarding-handbook で公開しています。 ライセンス #NTT Communications Corporation 作『オンボーディング ハンドブック』は クリエイティブ・コモンズ 表示 - 非営利 - 継承 4.0 国際 ライセンス で提供されています。 関連ハンドブック #リモートワークの働き方に特化したリモートワークハンドブックや、チームビルディングのプラクティスをまとめたチームビルディングハンドブックも参照ください。 読み始める #こちらから本編に進めます。 はじめに
【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 - BppLOG
Googleでの「Design Docs」とは 2007年の Google Developer Day Tokyo での鵜飼氏のプレゼンによると「Google で必ず書くことになっているドキュメント」であり、「プロジェクト立ち上げ時の 1～2週間をかけて書く」ものです。 今回は Google のソフトウェアエンジニアである @cramforce 氏が自身のブログで「Googleでの Design Docs」について解説している記事を公開されていたため、氏の許可を得て翻訳しています。 原文： www.industrialempathy.com 関連書籍： Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス オライリージャパンAmazon 読了目安：11分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ
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
みなさん、コードを書く前に設計書を書きますか？ 書くか書かないかは人それぞれだと思いますが、「設計」というプロセス自体は意識的であれ無意識的であれエンジニアであれば全員やっていることだと思います。 今回は設計プロセスの改善という文脈で私たちがDesign Docという仕組みを導入したことについて共有しようと思います。もし同じような状況を経験している人がいたら参考になれば幸いです。 導入の背景まずは導入するに至った状況からお話します。 私たちのサービスは、利用していただくユーザーの数が増加しています。それに伴って品質のハードルも上がってきました。サービスに障害が発生するとユーザーさんに大きな損害を出してしまうことになるからです。そこで今まで以上に安全にサービスを開発できる仕組みづくりが必要になりました。ですが、実現のためには大きく2つの課題がありました。 課題1. 開発スピードが徐々に鈍化し
自分が良い 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の
バウンスしすぎて Amazon SES から追放された俺たちは Mailgun と SendGrid に国を作ることにした - ANDPAD Tech Blog
これは何 どのように技術選定してますか。よく聞かれます。SREチーム 鈴木心之介 です。しかし説明が難しい。難しいですが説明の助けになってほしく思い、技術選定を文書化した DesignDoc から1枚を公開してみました。 DesignDoc とは、ある程度の大きさや複雑さがあり一言で説明の難しい技術選定について、文書化したものです。これを通じて、技術選定をどのように行うか組織内に広めようとする試みです。2021年1月頃から始めています。 題材は、メール配信の冗長化をRailsで実現した tech.andpad.co.jp を、インフラ視点から技術選定した DesignDoc です。このメール配信SaaSの選定は2019年末頃に実施したもので、DesignDoc の取り組みを始めていなかった頃でした。時が経ち、ソースコードやSaaSの構成からは意図を読むことが難しく「なんじゃこれ」って質問を
2021/10から株式会社アンドパッドで働いているid:shiba_yu36です。現在はセキュリティチームで認証基盤に関するエンジニアリングをしています。 アンドパッドは2021/10/01時点で従業員数が539名となっています。入社する以前は「この人数になってくると自分が何か提案したとしても中々意思決定が進まずヤキモキするのではないだろうか」と不安に思っていました。 しかし入社してから自分が開発プロセスや人員配置に関して提案してみたところ、この心配は杞憂だったどころか、逆に思った以上の意思決定のスピードに驚いてしまいました。そこで今回は自分が入社してから1ヶ月ほどの間に実際に提案・採用した内容を書きながら、どの程度意思決定がスピーディだったか伝えられればと思います。 ミーティングではesaで同時編集しながら議事録をみんなで作るスタイルへ -> その日から開始 フルリモートでの円滑なコミュ
1200人以上の全社員がリモートワーク。GitLabが公開する「リモートワークマニフェスト」は何を教えているか？ スケールする組織を支えるドキュメンテーションの技術を”GitLab Handbook”から学ぶ その コメント GitLab Handbookで面白かったもの@コミュニケーション編 GitLabのリモート統括責任者が語る 日本企業が「まずやるべきこと」 を読んだ。主題はGitLab社の https://about.gitlab.com/handbook/ である。 2022.02追記 GitLabで学んだ最高の働き方 Developers Summit 2022-02-18 2022.01追記 リモートワークのいま学びたい、GitLab Handbook非同期コミュニケーションのススメ - Qiita Handbook要点 「GitLab社ではリモートワークの中でも生産性高く働
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 Design Documentと聞くと何を想像しますか？ 一般的にDesign Documentが指すのは設計書であることが多いのではないでしょうか。 設計書、簡単に説明するのであればソフトウェアを「どうやって作るの？」を説明したドキュメントです。 Googleではソフトウェアエンジニアリング文化における重要な要素として、今回お話ししていくDesign Docsと呼ばれるものがあります。 Design Docsとは？ Design Docsとは、開発者がコーディングに着手する前にソフトウェアシステムまたはアプリケーションの開発する
Design Doc の書き方 / How to Write a Design Doc (Ja ver.)
「Design doc とは何か」・「何を書けばよいのか」を説明するスライドです。 関連するプレゼンテーション「読みやすいコードの書き方」: https://gist.github.com/munetoshi/65a1b563fb2c271f328c121a4ac63571 © 2023 M…
スタートアップにクリーンアーキテクチャを適用したが、技術的負債が塵積った件 〜開発合宿で技術的負債を粉砕します〜 - ANDPAD Tech Blog
こんにちは。こんばんは。おはようございます。 アンドパッドで現在はバックエンドの方のエンジニアをやっている原田です。 アンドパッドには2021年6月にJOINしまして、現在までANDPADボードの開発に携わっています。 ANDPAD施工管理が比較的長期間の工事をターゲットにしているのに対して ANDPADボードは1日〜数日の間に短期間の工事や施工を行う際のスケジュール管理を行えるサービスです。 andpad.jp 今回は入社3ヶ月目というきりの良いタイミングで今まで行ってきたことを振り返りつつ、直近行った技術的負債を軽減するための「開発合宿」について書いていきます。 一応最初に書いておきますが、リファクタリングに関するチートスキルはないのでバーンとやってドーンと解決みたいなド派手な解決ではなく地道な改修作業をちまちま行いましたという内容です。 入社してからやってきたこと ANDPADボード
こんにちは。バクラク申請・経費精算 ネイティブアプリエンジニアのchocoyamaです。 最近妻が身近な金継ぎ師を探しているので、もし身近な金継ぎ師がいらっしゃる方はご紹介いただけると嬉しいです。 この記事はLayerXテックアドカレ2024の23日目の記事です。 今回の記事では私たちモバイルアプリチームが実装アーキテクチャをどのように決定・運用しているのかをご紹介したいと思います。 前提情報 現在バクラクのモバイルアプリチームは、社員3名 + インターン生1名といったエンジニア構成でFlutter製のネイティブアプリ開発を行っています。 このアプリはフォームを中心としたプロダクトで、今年9月にストアリリースを行いました。 bakuraku.jp アプリの規模感としては、実装ボリュームがとても大きく、クライアント側でカバーすべき機能の膨大さから、私個人の経験としても過去最大レベルに複雑度の
あなたの window.open はなぜ開かないのか，Chrome で - マンガ〜ノ伊藤ノ〜ト
先日 window.open をしようとしたらポップアップブロッカーに阻まれて open することができなかった． Blocked まあ，これならよくあることなのだが，いかんせん自分の記憶では onClick のようなユーザーのアクション内で開かれた window.open は阻まれないことになってると思っていた．だからそのときも onClick のイベントハンドラ内で window.open したから大丈夫だろう，と思っていたら，見事にブロックされてしまったのでなぜだろう，となっていた． 検証 なので，検証するために 3 つのケースを用意してみた: 検証ページを用意したのであなたの環境でも試してみてね♥ 今回試すブラウザは Google Chrome を前提にしてます ケース1 const immediate = () => { window.open('https://www.goog
先日 Wantedly さんのエンジニアリングマネージャー座談会に出演させていただいた。 wantedly.connpass.com テーマは、「エンジニアリングマネージャーの課題を相談したい人が多い」「その相談パブリックにしよう」なので、自分が最近課題に思っている「変化の速度感」についてざっくばらんに会話できたらなーというのが期待だった。 イベント中には、大きく 4 つの話をしたのかな。それぞれ会話の中では話しきれなかったことも補足しつつ書いていく。 技術スタックが違うチーム プロダクトと専門組織のバランス 専門組織を立ち上げるポイント 採用と oss-guild 技術スタックが違うチーム リンク先を見て貰うと顕著に分かると思うけど、はてなでは、そこそこバラバラな技術スタックを使っている。 hatenacorp.jp インフラは AWS、Google Cloud (オンプレはやっと撲滅し
私 (@kossmori) が働くアメリカのスタートアップでは、どんな会話においても ”Is there a design doc?” (デザインドックはないの?) という質問が連発します。 会話のコンテクストを合わせるため、取り組みの背景を理解するための必須資料として位置づけられています。 デザインドックは技術詳細を書いた仕様書ではありません。 取組みに関わる Why, What, How と、ハイレベルな実装戦略、主要な設計上の決定、決定の際に考慮されたトレードオフに重点を置いて文書化したもので、それをもとにエンジニアは必要に応じてTech docを書き、デザイナーはデザインを始めます。 追記: その2も書きました。最後の方に記事へのリンクを貼っています。 追追記: 思った以上に反響あり、この記事のおかげでこれまで非常に多くの スタートアップの方々とお話しさせていただく機会をいただき
これは何? React(Next.js)アプリケーションのテンプレートのための Design Doc React(Next.js)アプリケーションのテンプレートとして実装したリポジトリ shimpeiws/react-boilerplate-2022 の設計についてのDesign Docです SSR/ISRはせずnext exportしてStatic Fileを出力する構成です API Routesを使っていますが、API接続コードをローカルで動作させるためのもので本番動作させるためのものではありません Design Doc 本ドキュメントは実装したリポジトリの構成、ライブラリの選定理由など設計についての背景を示すためのドキュメントという位置づけです 「デザインドックで学ぶデザインドック」(https://www.flywheel.jp/topics/design-doc-of-desig
Developer Enablement Monthと、そこから生まれたコードレビュー手法｜Knowledge Work Developers Blog
こんにちは、よしこです。 みなさんコードレビューしてますか？ 今日の記事では、最近おこなわれた社内でのイネーブルメントを推進する取り組みと、そこから生まれた新たなコードレビューのやり方についてご紹介しようと思います。 コードレビューにおけるトレードオフ取り組みやレビュー手法の話をする前に、前提としてコードレビューの際に以前から私が持っていた悩みをお話しします。 （以降レビューする人をレビュアー、される人をレビュイーと記載します） ナレッジワークのフロントエンドチームでは私が主なレビュアーとしてコードレビューをしているのですが、その際に1つ悩ましいトレードオフがありました。 これはレビュアーにもよるかもしれないのですが、私の場合は「全体像を見てレビューしたい」という方針があります。 「ある振る舞いを実現するコードのうち一部だけのコード」よりも「ある振る舞いを実現するコード」をまとめてレビュー
これは何？ 私が現在活用しているAIエージェント設定、運用のTIPSをアウトプットします。 目的 AIエージェントを活用した開発の今の姿を整理する 開発に適したツールと設定の一例を共有する エディタ以外の開発フローの工夫を共有する AIエージェントについて 現時点ではRooCodeを軸に開発環境を構築しています。 RooCodeはClineを拡張したものでありより高度なAIアシストを提供するツールです。 Clineと比べてUIはやや複雑だが`機能は豊富 チームで設定をシェアしたり知見を溜めるため利用者の母数が多いRooCode、Clineを選択 CursorはDevContainerがうまく動作せず、他にも一部の拡張機能が使えない事例を見たため、互換性に課題が残ると判断しています。その他のAIエディタは十分に利用、検証できていません。 RooCodeが使いにくいと感じた場合はClineでも
リモートチームとして成長し、生産性を上げるための挑戦の軌跡 - LegalOn Technologies Engineering Blog
こんにちは、LegalOn Technologies 検索・推薦チームの志水と勝田です。 我々のチームではこの1年をかけてチームビルディングやアジャイル開発に繋がる様々な手法や施策を試し、その成果が徐々に出てきました。今日はその過程を紹介いたします。時間がかかっても必ず成果は出ると思うので、似た取り組みをしようとされている方はぜひ参考にしてみてください！ はじめに 2024年春、「LegalOn Cloud」がリリースされました。これまでの開発では、各機能に専任メンバーを割り当て、定期的な情報共有や技術的な相談を行う方式を採用していました。この開発スタイルは、開発内容が明確な状況下で高いパフォーマンスを発揮していました。しかし、属人性の解消や、不確実な状況への柔軟な対応のため、より効率的でスケーラブルな開発スタイルを追求する必要性が生じました。 検索・推薦チームは全員がフルリモートで働いて
10X ソフトウェアエンジニアの @metalunk です。ネットスーパー、ネットドラッグストアのプラットフォームである Stailer 事業で、機械学習（ML）と検索を専門として働いています。 2024年4月からいま（2024年8月）までの5ヶ月間で6つの推薦機能をリリースできました。この成果を支えたのはチームと ML platform（機械学習の基盤システム）です。このブログではチームの取り組み、ML platform の機能、および具体的な成果についてご紹介します。 このブログは技術ブログの体ではありますが、さまざまな業界、職種の方に読んでいただくことを目指して執筆しました。 (3) 章, (5) 章だけは機械学習に取り組んでいる人向けの内容を含みますので興味のない方は読み飛ばしてもらって結構です（機械学習に取り組んでいなくても興味のある方はぜひ読んでください）が、それ以外は IT
Design Doc でチームを跨いだ開発を円滑に行う - 一休.com Developers Blog
この記事は 一休.com Advent Calendar 2024 7 日目の記事です。 宿泊事業本部 ユーザー向け開発チームの原です。 一休.com と Yahoo!トラベルの主にフロントエンドの開発を担当しています。 今回は、普段の開発でコードを書き始める前段階で Design Doc を作ることで、円滑な開発を進められるようになったというお話をします。 チーム構成について まず、前提を共有するために私達が普段どのような体制で開発しているかを説明します。 私が所属している宿泊事業本部 ユーザー向け開発チームは、一休.com と Yahoo!トラベルの主に toC のユーザー向けの機能開発をしています。ユーザー向け開発チームのメインのミッションはユーザー体験を向上させることであり、そういった施策の機能開発を素早くリリースできることを大事にしています。 一方、プロダクト開発においては機能開
Message Passing is licensed under CC-NC-SA. It has a feed and is hosted by a GitHub organization. Uses this for the OG image.
仕様検討段階でのQAの関わり方やチームでの品質保証について - freee Developers Hub
こんにちは。freeeでQAエンジニアをしているkenseiです。 freee QA Advent Calendar2024の4日目です。 QAとしてある程度経験を積むと「もっと上流から関わっていきたい」という意識が出てくるという話をよく聞きます。 そこで今回は「QAが上流から関わる」というのは具体的に何をしているのか、どういったメリットがあるのかについてや、チームでやっている取り組みについて書こうと思います。 はじめに まずはfreeeでは実装に入る前にどういった工程があるのか、私が所属している開発チームを例に見てみましょう。 成果物 詳細 オーナー Brief開発のきっかけとなる課題や背景、想定ターゲットやインパクトについて記載する。 後述のPRDと合わせて作成されることが多い。PdM PRD課題解決にあたり何をするのか、しないのかをざっくり記載。スケジュールについてもここで考慮する。
こんにちは! ソウゾウのSoftware Engineerの@ogataka50です。連載：メルカリShops 開発の裏側 Vol.2の9日目を担当させていただきます。 9日目はメルカリShopsを開発する中でのDesign Docsの運用について紹介させて頂きます。 Design Docsとは Design DocsとはGoogleなどで取り入れられているシステム設計ドキュメント手法です。開発をする前にプロジェクトの背景や目的、設計、検討した代案などをdocument化します。そしてそれを持って関係者との共有、議論を行うことによって事前に全体を考察し、精度を高め開発後の手戻りを減らすなどが主な目的になります。 例として、GoogleでのDesign Docsについては下記にまとめられています。 Design Docs at Google メルカリShopsでのDesign Docsのte
ドキュメント指向の開発プロセス｜平野智也（トム）
ぼくが勤めるナレッジワークでは、創業時からリモートからの働き方に対応してきた。今では週一の出社日が設けられているが、現在でもリモートワークは継続しており、メンバー同士が異なる場所から働きやすい環境を実践できている。 コミュニケーション設計については前記事で触れたので、今回は、プロダクト開発チームが、どのようなコミュニケーションを取りながら業務を進めているのかについて紹介したい。 そこで着目するのが、ドキュメントだ。ナレッジワークでは、過去から現在に至る意思決定のプロセスや結論がドキュメントとして残されていて、もちろん開発プロセスにおいても例外ではない。社内において、情報のアクセスのしやすさ、つまりオープンであることが徹底されていて、自社の組織やプロダクトについてのドメイン知識については、ほとんどすべてアクセス可能になっている。 この情報の透明性を支えているのが、あらゆる意思決定の場において
プロダクトのBackendをServerless化した話｜Knowledge Work Developers blog
ナレッジワークでソフトウェアエンジニアをしている @yudoufu です。 先日、ナレッジワークのプロダクトBackendはGKEからCloud Runへの移行を終え、サブシステムを含むプロダクト全体がServerless化されました。 今回は、ナレッジワークのプロダクト本体のAPI BackendをGKEからCloud Runに移植した話を紹介します。 初期のナレッジワークのシステム構成ナレッジワークでは立ち上げ当初より、サービス本体とも言えるAPIバックエンドをGKE(Standard)環境で構築・運用されていました。 開発最初期には当然、PMFを目指すためにプロダクトには様々な試行錯誤的な機能追加が行われることになり、またシステムのワークロードなども含めて今後の運用形態に不透明な部分が多くあります。 そのため、システムの機能面・性能面の両面で拡張に対する柔軟性が高く、かつIaC運用と
支払依頼のUI刷新でエンジニアがどういう開発を行なったかを紹介します - freee Developers Hub
こんにちは、freee 会計のワークフロー（会社内の申請・承認の流れ）機能を開発しているエンジニアのミツバ (@mitubaEX) です。 先日ワークフローの機能の一つである支払依頼を刷新しました。この記事では刷新した手順とこだわりポイントについて紹介したいと思います。 以前の支払依頼について 支払依頼は主に請求書を元に申請を出し、稟議を回すものになっています。 刷新以前の UI は以下のようなものでした。 以前の支払依頼の UI 左側に取引先の情報、右上に請求書の明細の情報が表示されており、右下に請求書の画像が添付されています。この UI は明細が増えていくと請求書が画面下部に表示されてしまいます。これによって申請後に承認をする人が請求書を確認して入力された明細のデータを確認するための視線の移動が多くなってしまうという問題が生じます。 加えて昔から利用されている UI component
Companies Using RFCs or Design Docs and Examples of These
RFCs - requests for comment - or Design Docs are a common tool that engineering teams use to build software faster, by clarifying assumptions and circulating plans earlier. There are some similarities between writing automated tests for your code, and writing RFCs before you start working on a non-trivial project: Software engineers who write tests for their code - and ask for code reviews on it -
ノバセルにおいて意思決定ドキュメントの運用を3ヶ月してみて分かったこと - RAKSUL TechBlog
こんにちは。ノバセルのデータプロダクトチームにて開発エンジニアをやっている山中（yamnaku_）です。 現在は、ノバセルの各種分析システムのバックエンド開発を行なっています。 特に、データウェアハウス製品Snowflakeを利用したデータ基盤の開発・運用に取り組んでいます。 私の所属するチームでは、意思決定を記録するドキュメントとして、Architectural Decision Record（ADR）の運用を始めて3ヶ月ほどが経ちました。 今回は、感じることが出来た効果についてご紹介したいと思います。 背景と課題 採用したフォーマット ドキュメントオーナーと変更履歴 ドキュメントの目的 背景 概要 詳細 3ヶ月の運用の結果 呼び方の問題 より良い目的設定や、多くの選択肢が出てくるようになった 意思決定に関する自信の醸成と型化 ビジュアルの活用 まとめ 背景と課題 ひとつ目のプロダクトで
この記事はfreee 基盤チーム Advent Calendar 2023 の24日目の記事です。 はじめに はじめまして！ kanno と申します。freee SREで、freeeサインのプロダクトSREを担当しておりAWSインフラの改善や運用を主に行っています。初回の投稿で拙い文章になりますが、直近で実施したfreeeサインのAWSリージョンを移行した話を書こうと思います。 背景 元々、freeeサイン(旧ninja-sign)はHeroku上にアプリケーションをデプロイしていましたが、2022年の年末頃にAWSに移行しています。その際、元々のHerokuがus上で稼働していたことが影響して、AWSのバージニアリージョンに移行された状態でした。私がfreeeのサインチームにjoinしたのがこの時で、AWSリージョン移行を担当することになりました。 AWSリージョン移行のモチベーション
つながりをデータから解き明かしたい ~ 複雑ネットワークの世界とそれを活用した不正検知システム，さらに向こうへ | メルカリエンジニアリング
つながりをデータから解き明かしたい ~ 複雑ネットワークの世界とそれを活用した不正検知システム，さらに向こうへ この記事は Merpay Tech Openness Month 2021 の14日目の記事です．こんにちは，メルペイのMachine Learningチームのhmjです． 今回は昨年に引き続き「集団的な不正の検知」をテーマに，ここ一年間で少しづつ進めてきた集団的な不正の傾向分析や，検知のための機械学習パイプラインの構築・運用として Vertex Pipelinesの使用を検討しているので，それらの分かったことなどを紹介します． 昨年の記事はこちらとなります． Overview 「集団的な不正の検知」といっても，実際に定義は自明ではありません．その言葉を聞いた人によって，想像する集団の大きさや形，特徴などは様々です． 今回は，カード決済を利用した取引での集団的な怪しい取引のケース
はじめに こんにちは！お会計チームの yamakazu (@yamarkz) です。 10Xでは4月から新しい期が始まるため、最近はバタバタしています。新しい組織や取り組みが始まってきていて、今年度はこれまでとはまた違った大きな変化が生まれそうで楽しみです。 さてそんな今回は期の変わり目ということもあり、 節目として「Stailerの開発を支える取り組み」を紹介します。 取り組みはプロダクトの規模や性質、組織構造、願望によって変わる唯一無二の存在で、各社様々な工夫を凝らして、より良い開発体験を追求していると思います。 自分たちもその時々の状況に合わせて、最適なやり方に変えて開発してきました。 今後も取り組み自体は変わっていくと思いますが、2023春時点での取り組み状況 (仕組み / ルール / 文化 / ツール) をスナップショットとして取り上げみようと思います。 はじめに 前提 取り組み
はじめに こんにちは！yamakazu (@yamarkz) です。 10月から下期も始まり、10X社内は色々と変化が生まれ始めました。大きくは組織のアーキテクチャが刷新され、実務検証(ここから半年がProof of Concepts期間)が始まったところが大きいです。 yamotty.tokyo アーキテクティングの重要性を所属組織の構造変化という観点から経験知として学ぶ機会に遭遇できているのは貴重で、新たに加わる変化 (評価制度や目標設定など) でどのように組織が変化するのかは個人的にも関心があり、良い/悪い含めて前向きに学んでいきたいです。 さて今回はそんなアーキテクティング方面の話として、ソフトウェアアーキテクチャ分野で提唱されている アーキテクチャ特性 と呼ばれる概念と、それに対する10Xでの取り組みを紹介します。 ソフトウェアアーキテクチャに関心のある方は既に知っている概念かも
この記事は SMat Advent Calendar 2024 の12月10日分の記事です。 こんにちは、株式会社エスマットでエンジニアリングマネージャーを担当している仙葉です 前回の記事から期間が空いてしまいましたが、今回も開発生産性を向上させるための取り組み状況をご紹介していきます！ 昨年からの変化 とりあえずFindyTeam+から直近半年の数字持ってきました 全体的に向上していてとてもいい感じ。。。！ 弊社では昨年の段階でレビューやデプロイに関しての課題感はほぼ無くなっており、これ以上無理に数値にこだわっても仕方ないよねという共通認識ができていたので、今年は数値を安定させつつ新しい取り組みを模索する1年だったと思います FindyTeam+さんには引き続きお世話になっており、毎週エンジニア全体で行なっている定例に直近の数値を確認するアジェンダを追加し、そこでアラート検知的な役割で活
freeeの2024年新卒研修の事例 - 社内むけショート動画プラットフォームの開発 - freee Developers Hub
こんにちは！24新卒でfreeeに入社したkochanです！この記事では、実際に私が経験した2024年度のエンジニア新卒研修について紹介します。これから研修を控える方や、就職先を検討中の学生の皆さんに、freeeでどのような成長機会が得られるのかをお伝えします。 私たちはまず、営業メンバーも含めた新卒全体で会計などに関する業務知識についての講義を受け、演習を行いました。 その後、エンジニア新卒研修が2.5ヶ月間あります。内容としては前半・後半の2段階構成で、実践的なスキルと即戦力になるための経験を身につけることができます。 前半研修ではWebフレームワークを自作するといった本格的な技術トレーニングや、社内サービスやインフラに関する講義を受講しました。これによって、実務で必要となる基礎技術力を習得できました。 後半研修ではさらに踏み込んでエンジニアとデザイナーが混合チームを組み、実際の社内課
【Chrome】クリックしたらカーソルが表示される・キーボードを使ったページスクロール（PageUp/PageDown/Home/End）がうまく動かない、挙動がおかしい等が発生した場合に確認したい設定（カーソルブラウジング機能）
「ChromeやMicrosoft Edgeをアップデートして以降、カーソルキーやPageUp/Down、Home/Endキーなどを使ったページスクロールがうまく動作しない、反応しない」というユーザーが発生しています。 また、サイトの入力欄ではない部分をクリックしても、入力するときと同じようなカーソル（I字カーソル）が点滅表示されてしまい、普段と違うページの挙動になってしまう場合があります。 その他にも、これと関連してマウスジェスチャーツールがうまく動作しないなどの問題が発生する場合があります。 今回は、これらの問題に共通して原因となり得るChromeのとある「設定」および、その設定を「オフ」に切り替える方法を紹介します。 目次 1. 問題１：クリックするとカーソルが表示される2. 問題２：PageUp/Down、Home/Endなどの動きがおかしい3. 原因：「カーソルブラウジング」機能
ナレッジワーク CTO の mayah です。 前回、CEO の麻野より、ナレッジワークが作ろうとしているプロダクトについてお話ししました。今回は、ナレッジワークの開発組織において大切にしている考え方と、開発プロセスについてお話しします。 ナレッジワークでは「正しいものを正しく作る」という思想のもと、 正しいものを定義するための、情報流通の仕組み 正しく作るための、アジャイル開発をうまく回す仕組み に開発体制の特色があります。 話したいことはたくさんあるのですが、本日はこの２点に絞ってお伝えします。 プロダクト開発は総合力勝負ナレッジワークでは、プロダクト開発は総合力の勝負であると位置付けています。 プロダクトを開発する側をプロダクトサイド、販売する側をセールスサイドと分けたとします。プロダクトサイドはプロダクトマネージャー (PdM)、デザイナー (Des)、ソフトウェアエンジニア (S
元Google Japanエンジニア、株式会社ナレッジワークCTOを務める川中真耶氏 川中真耶氏（以下、川中）：「規模が拡大しても耐えられる創業期のシステム・組織設計」というタイトルで発表させていただく（川中）真耶です。よろしくお願いします。 まず自己紹介なのですが、僕はずっと技術で飯を食ってきた人間です。大学で情報科学を学んで、IBMでリサーチャーをして、Google（Google Japan）でソフトウェアエンジニアをして、という経歴です。 2020年に、CEOの麻野（麻野耕司氏）とナレッジワークという会社を創業しました。そこからCTOをやっています。 ナレッジワークは、セールスイネーブルメントクラウド「ナレッジワーク」というものを作っています。こちらのプロダクトは、営業力の強化・営業生産性の向上を1つのツールで実現するようなものになっています。 スタートアップが持つ、ビジネスとプロダ
Developer eXperience Day 2024【参加無料・アーカイブ配信あり】｜EventRegist（イベントレジスト）
2024年7月16日（月）と17日（火）の2日間にわたり「Developer eXperience Day 2024」（一般社団法人 日本CTO協会主催）を、オフライン・オンラインのハイブリッド形式で開催いたします。 【参加無料・アーカイブ配信あり】です。ぜひご参加ください！ 開催概要 名称：Developer eXperience Day 2024 開催日：2024年7月16日(火)・17日(水) 開催形式：オフライン（現地参加）・オンライン配信 会場：浅草橋ヒューリックホール＆カンファレンス アクセス：https://hulic-hall.com/access/ JR総武線「浅草橋駅（西口）」より徒歩1分 参加方法：事前申込制（参加費：無料） 申込サイト：本イベントサイトよりお申込みください 参加対象： ソフトウェア開発の第一線で挑戦するエンジニアをはじめ、テックリード、エンジニアリン
TestDesignDoc：テスト分析・テスト設計に関する新たな試み｜Knowledge Work Developers Blog
ナレッジワーク QAエンジニアの綿貫(@gun_chari)です。 以前「ナレッジワークQAのテスト設計プロセス」という記事でナレッジワークQAグループにおけるマインドマップを活用したテスト設計プロセスを紹介しました。 それから今まで、以前紹介したテスト分析・テスト設計のやり方をベースに試行錯誤を繰り返しながら、改善を進めてきました。本ブログでは、その試行錯誤の結果見えてきた課題を概観し、その課題解決の取り組みとして、TestDesignDocというテスト分析・テスト設計の成果物について紹介したいと思います。 1. 改善前のテストプロセスまず、テストプロセスの前提となるナレッジワークの開発プロセスを概説し、その後に改善前のテストプロセスを紹介します。 1.1 スプリントサイクルとその中でのテスト活動スプリントサイクルとその中におけるテストプロセスを以下に図示します。 ナレッジワークの開発で
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Design Docs at Google
安全安心にソフトウェア開発を行うためのDesign Doc導入ガイド｜面川泰明
【メモ】良いDesign Docs(Software Design Document)を書くためのリソース集
入社して1ヶ月で意思決定の速さに驚いた話 - ANDPAD Tech Blog
リモートワークのいま学びたい、GitLab Handbookと徹底した文書化への狂気 - Qiita
GoogleのDesign Docsから学ぶソフトウェア設計 - Qiita
CursorとDesign Docで実現する漸進的なアーキテクチャ改善 - LayerX エンジニアブログ
フルタイムでやる仕事を作る #wantedlydev - id:onk のはてなブログ
プロダクトマネージャーの必須スキル: デザインドックの書き方 - Design Doc｜kosuke mori
Design Doc for react-boilerplate-2022
現時点のAIエージェントを活用した開発方法と考え方とTIPS
10X の推薦を作るチームと ML platform - 10X Product Blog
Design Docs の逡巡- Message Passing
メルカリShopsでのDesign Docs運用について | メルカリエンジニアリング
freeeサインのAWSリージョンを移行した話 - freee Developers Hub
Stailerの開発を支える取り組み 2023春 - 10X Product Blog
アーキテクチャ特性の導入と手応え - 10X Product Blog
チームサーベイ活用で更なる開発生産性向上へ
ナレッジワークの開発体制｜Knowledge Work Developers Blog
テクノロジースタートアップの“ジレンマ”を解消するには？ 「技術負債を作らずに爆速設計」を可能にした“エキスパートによる完全分業体制”