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の
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社ではリモートワークの中でも生産性高く働
バウンスしすぎて Amazon SES から追放された俺たちは Mailgun と SendGrid に国を作ることにした - ANDPAD Tech Blog
これは何 どのように技術選定してますか。よく聞かれます。SREチーム 鈴木心之介 です。しかし説明が難しい。難しいですが説明の助けになってほしく思い、技術選定を文書化した DesignDoc から1枚を公開してみました。 DesignDoc とは、ある程度の大きさや複雑さがあり一言で説明の難しい技術選定について、文書化したものです。これを通じて、技術選定をどのように行うか組織内に広めようとする試みです。2021年1月頃から始めています。 題材は、メール配信の冗長化をRailsで実現した tech.andpad.co.jp を、インフラ視点から技術選定した DesignDoc です。このメール配信SaaSの選定は2019年末頃に実施したもので、DesignDoc の取り組みを始めていなかった頃でした。時が経ち、ソースコードやSaaSの構成からは意図を読むことが難しく「なんじゃこれ」って質問を
概要 Design Documentと聞くと何を想像しますか？ 一般的にDesign Documentが指すのは設計書であることが多いのではないでしょうか。 設計書、簡単に説明するのであればソフトウェアを「どうやって作るの？」を説明したドキュメントです。 Googleではソフトウェアエンジニアリング文化における重要な要素として、今回お話ししていくDesign Docsと呼ばれるものがあります。 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 Munetoshi Ishikawa, supported by LINE corporation
スタートアップにクリーンアーキテクチャを適用したが、技術的負債が塵積った件 〜開発合宿で技術的負債を粉砕します〜 - ANDPAD Tech Blog
こんにちは。こんばんは。おはようございます。 アンドパッドで現在はバックエンドの方のエンジニアをやっている原田です。 アンドパッドには2021年6月にJOINしまして、現在までANDPADボードの開発に携わっています。 ANDPAD施工管理が比較的長期間の工事をターゲットにしているのに対して ANDPADボードは1日〜数日の間に短期間の工事や施工を行う際のスケジュール管理を行えるサービスです。 andpad.jp 今回は入社3ヶ月目というきりの良いタイミングで今まで行ってきたことを振り返りつつ、直近行った技術的負債を軽減するための「開発合宿」について書いていきます。 一応最初に書いておきますが、リファクタリングに関するチートスキルはないのでバーンとやってドーンと解決みたいなド派手な解決ではなく地道な改修作業をちまちま行いましたという内容です。 入社してからやってきたこと ANDPADボード
あなたの 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つ悩ましいトレードオフがありました。 これはレビュアーにもよるかもしれないのですが、私の場合は「全体像を見てレビューしたい」という方針があります。 「ある振る舞いを実現するコードのうち一部だけのコード」よりも「ある振る舞いを実現するコード」をまとめてレビュー
デザインドックで学ぶデザインドック | フライウィール
エンジニアの太田です。 皆さん、デザインドックはご存知でしょうか？いわゆる設計書ですが、エンジニアによって書かれ、書いた本人またはチームによって実装される点と、技術的な詳細を明確にし技術的な議論をすることにフォーカスがある点が特徴です。他人に開発を依頼するための設計書や、既存のシステムを解説するための文章とは性質が異なります。 デザインドックを書くことの利点としては以下のような点があります。 開発を始める前に全体のシステムを考察する機会を得る文章化することで、曖昧な部分が明確になる早い段階でチームメイトや専門家、関係者からフィードバックを得る機会を得るシステムの設計について明確な承認を得られる新しいメンバーがシステムの概略を理解する手助けになる弊社でもすでに多くのデザインドックを利用しており、エンジニア間での議論の活発化を担っています。 具体的にどのような内容を書けばいいのでしょうか？今回
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.
こんにちは! ソウゾウの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での取り組みを紹介します。 ソフトウェアアーキテクチャに関心のある方は既に知っている概念かも
【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つのツールで実現するようなものになっています。 スタートアップが持つ、ビジネスとプロダ
「アーキテクチャ特性の導入と手応え - 10X Product Blog」の記事を補完する内容です。 10Xにおける「アーキテクチャ特性」という概念に対する解釈を定義しています。 これは元々社内向けに書かれたドキュメントでした。社内ドキュメントをそのまま転記する形で記載しています。 概念の出自は「ソフトウェアアーキテクチャの基礎」です。 ここでの内容が、アーキテクチャ特性への理解の足がかりになれれば幸いです。 アーキテクチャ特性とは なぜアーキテクチャ特性が必要なのか 備えるべきアーキテクチャ特性とは 1. 設計に対する考慮事項が要求仕様として明らかなもの (明示的) 2. 設計の構造的な側面に影響を与えるもの (暗黙的) 3. ソフトウェアの成功に不可欠 or 重要なもの アーキテクチャ特性の見極め ドメイン特性 (ドメイン由来) 明示特性 (要件由来) 暗黙特性 (システム由来) 見極
デザイナーやクリエイターの中には、自分たちが接することの少ない業界やユーザーに向けたサービス開発やデザインを行う人も多いかと思います。では特定の業界に特化したサービスのデザイン現場ではどのようにデザインを進めているのでしょうか？ 建設業界に特化したクラウド型の建設・建築現場プロジェクト管理サービス「&ANDPAD（アンドパッド）」を提供する株式会社オクトの建築業界に特化したサービスとデザインチームついてお話を伺いにいきました。 登場人物 株式会社オクト 開発部 リードデザイナー 後藤啓之氏 ７番目の従業員としてサービスのシード時期からジョイン。プロダクト全般のUI/UXデザイン、デザインチームの立ち上げとマネジメントを担当。現在はブランディングに従事。 課題解決のヒントは「現場」にある ── 今日はよろしくお願いします。まずは株式会社オクトについて教えてください。 後藤：株式会社オクトは「
この記事は ANDPAD Advent Calendar 2023 の 7日目の記事です。 1年ぶりの登場となります、後藤です。 全然こちらではネタを書かずに1年経ってしましました。おかげさまで毎日忙しく組織課題に立ち向かっています。 そんな中で今日は少し一般論的な話にもなりますが役割と責任みたいなネタを整理したものを書いてみようと思います。 ResponsibilityとAccountabilityで語られるような話です。 だいぶ前の話なんですが、社外のCTOの方とお話しをさせていただく機会があった時に似た話になったのと、EMFMというpodcastの話とつながって、そういうことかーとなった話なのでまとめて書いてみました。 この概念は元々存在していて、RACI図とかにおけるRとAに相当します。言葉尻だけでインターネットで調べてみると色々出てくると思いますが、今回ここで私が書こうと思ってい
どうも、iinoです。株式会社ナレッジワークでQAエンジニアをしています。 今回は社内のLT大会で発表した内容を記事にしてみました。 社内のLT大会については、同日の登壇仲間である torii さんが、彼の発表内容をまとめた記事内で紹介してくれているので、そちらをご参照ください！ 登壇資料（Googleスライド） 社内のLT大会ということで、登壇資料には「minispec」「DesignDoc」「TestDesignDoc」などの社内用語を使用しています。本記事内では一般的な用語に置き換えるようにしていますが、興味がある方は以下もご参照いただけると嬉しいです。 ナレッジワークの開発体制 TestDesignDoc：テスト分析・テスト設計に関する新たな試み はじめに 今回取り扱う内容は『分かりやすい、読みやすい文章の書き方』・・・ではありません！ 私が普段、設計ドキュメントのレビューやテスト
はじめに こんにちは。22卒アナリティクスエンジニアの井下田(@hiroki_igeta)です。 普段からデータ基盤の整備とDWH開発はもちろん、ダッシュボード作成、広告ロジック改善にも携わっています。 -- 本記事は、Rettyのデータ分析チームが約3ヶ月間取り組んできた「dbtの導入」を中心テーマとした連載 #dbtでデータの民主化 の3記事目です。 dbtの導入背景については連載記事の1つ目、dbt移行のプロジェクト進行については2つ目をそれぞれご参照いただけますと幸いです。 (Rettyではdbt導入のためにプロジェクトを立ち上げ、dbt移行を推進しました。) 連載記事1つ目：データアナリストがdbtを使って育てるデータマネジメント 連載記事2つ目：dbt移行プロジェクトを振り返ってみた 連載3記事目の本記事では、「DWHの管理を内製ツールからdbtへ移行する際に工夫した点・反省点
![DWHの管理を内製ツールからdbtに移行した話[連載3/3] - Retty Tech Blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/fffcfefbd2d67a5c1ebfbfb26969137ee9e9fc39/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fr%2Frettydev%2F20220927%2F20220927082220.png)
B2B SaaSエンジニアMeetupの忘年会やってきました - SMARTCAMP Engineer Blog
スマートキャンプのエンジニア井上です！ 本記事は「スマートキャンプ Advent Calendar 2019 - Qiita」の9日目の記事です。 先日、B2B SaaSエンジニアMeetup - Sharing Issues というイベントを弊社で開催させていただきました。 今回は今年1年でやりきったこと・反省点、来年こそは○○するぞ！というテーマで開催しました！ 忘年会ということもあり、ビールを片手に課題を語り・聞くという不思議で楽しい会でした 笑 参加者も前回に引き続き40名強もの方にお越しいただき、とても充実した会でした！ 私も主催者でありながら、ただの１参加者として発表に聞き入ってしまい、途中司会業を忘れかけるようなこともありましたが、無事イベントは盛況のうちに終わりました。 このSharing Issuesというイベントをどのよう意味で作ったかは下記で紹介しています。 tech
TestDesignDoc：テスト分析・テスト設計に関する新たな試み｜Knowledge Work Developers blog
ナレッジワーク QAエンジニアの綿貫(@gun_chari)です。 以前「ナレッジワークQAのテスト設計プロセス」という記事でナレッジワークQAグループにおけるマインドマップを活用したテスト設計プロセスを紹介しました。 それから今まで、以前紹介したテスト分析・テスト設計のやり方をベースに試行錯誤を繰り返しながら、改善を進めてきました。本ブログでは、その試行錯誤の結果見えてきた課題を概観し、その課題解決の取り組みとして、TestDesignDocというテスト分析・テスト設計の成果物について紹介したいと思います。 1. 改善前のテストプロセスまず、テストプロセスの前提となるナレッジワークの開発プロセスを概説し、その後に改善前のテストプロセスを紹介します。 1.1 スプリントサイクルとその中でのテスト活動スプリントサイクルとその中におけるテストプロセスを以下に図示します。 ナレッジワークの開発で
はじめに アンドパッドの土方です。 最近エンジニア採用に携わっております。 今回はアンドパッドの開発組織について紹介したいと思います。 はじめに 開発組織のミッション テクノロジーを武器に社会変革にチャレンジする 開発組織が取り組んでいること 開発の進め方、チーム 技術顧問の参画 継続的アウトプット 開発における様々な改善活動を行っています エンジニア組織 プロダクト開発部門 品質管理/保証部門 テクニカルサポート部門 アプリケーション基盤部門 SRE/データ基盤部門 技術スタック 終わりに 開発組織のミッション テクノロジーを武器に社会変革にチャレンジする 私たちの開発しているANDPADは、少しだけ便利に、というよりも革新的に仕事環境が変わったというインパクトを与える可能性を持っています。 プロダクトの開発を通して業界の働き方に変革を起こす、テクノロジーを武器にチャレンジすることが開発
本連載は『Webアプリケーションアクセシビリティ──今日から始める現場からの改善』を補うものです。紙幅の都合で同書に収められなかった原稿を再構成しました。 同書の第7章「アクセシビリティの組織導入」の続編にあたります。同書第7章は、会社内でたった一人でアクセシビリティの取り組みを始めてから、正式なチームを立ち上げるまでのノウハウを紹介しました。本連載はそこからさらに取り組みを広げていくためのノウハウをまとめます。 2024年4月22日追記：同書の第7章「アクセシビリティの組織導入」も「アクセシビリティを組織で向上させる ──たった一人から始めて、社内に認知されるまで」として公開しました。 Webアプリケーションでは機能改修や機能追加により、成長とともに新しい画面が出現します。時には新しいアプリケーションが作られる場合もあります。「新しく作る画面」がはじめからアクセシブルになるようにプ
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
フルタイムでやる仕事を作る #wantedlydev - id:onk のはてなブログ
プロダクトマネージャーの必須スキル: デザインドックの書き方 - Design Doc｜kosuke mori
Design Doc for react-boilerplate-2022
Design Docs の逡巡- Message Passing
メルカリShopsでのDesign Docs運用について | メルカリエンジニアリング
freeeサインのAWSリージョンを移行した話 - freee Developers Hub
Stailerの開発を支える取り組み 2023春 - 10X Product Blog
アーキテクチャ特性の導入と手応え - 10X Product Blog
ナレッジワークの開発体制｜Knowledge Work Developers blog
テクノロジースタートアップの“ジレンマ”を解消するには？ 「技術負債を作らずに爆速設計」を可能にした“エキスパートによる完全分業体制”
10Xにおけるアーキテクチャ特性の定義 - 10X Product Blog
建築現場の課題をどう解決するか？ 建築現場のSaaSとデザインチームの哲学
役割における仕事の性質の変化 - ANDPAD Tech Blog
とあるQAエンジニアによる日本語へのこだわりのススメ
DWHの管理を内製ツールからdbtに移行した話[連載3/3] - Retty Tech Blog
アンドパッドの開発組織を紹介します！ - ANDPAD Tech Blog
第3回 アクセシビリティを新規開発の「当たり前」に組み込む | gihyo.jp