はてなブックマーク

ナレッジワーク QAエンジニアの綿貫(@gun_chari)です。 以前「ナレッジワークQAのテスト設計プロセス」という記事でナレッジワークQAグループにおけるマインドマップを活用したテスト設計プロセスを紹介しました。 それから今まで、以前紹介したテスト分析・テスト設計のやり方をベースに試行錯誤を繰り返しながら、改善を進めてきました。本ブログでは、その試行錯誤の結果見えてきた課題を概観し、その課題解決の取り組みとして、TestDesignDocというテスト分析・テスト設計の成果物について紹介したいと思います。 1. 改善前のテストプロセスまず、テストプロセスの前提となるナレッジワークの開発プロセスを概説し、その後に改善前のテストプロセスを紹介します。 1.1 スプリントサイクルとその中でのテスト活動スプリントサイクルとその中におけるテストプロセスを以下に図示します。 ナレッジワークの開発で

ナレッジワークQAエンジニアの岡崎（@rabbit_tail14）です。 ナレッジワークでは、プロダクト開発における初期品質およびアジリティを高めるための取り組みとしてバグ分析を行っています。 この記事では、実際に計測しているメトリクスや、どのように運用しているのかなど、できるだけ具体的に記載していきますので、バグを資産として活用したいと思っている方や、既に活用しているが他社の事例も知りたいと考えている方などの参考になれば幸いです。 バグ分析を始めた背景と目的バグ分析に取り組む前の状況私は2022年3月にナレッジワークに入社したのですが、当時はまだバグ分析は実施されておらず、対応完了後にバグチケットを見返すことはほとんど行われていませんでした。 そのため、なぜバグが埋め込まれたのかは基本的に対応者しか把握しておらず、個人の知見にしかなっていない状況でした。 一方で、よく耳にするようなデグレ

はじめにナレッジワーク Enablement Groupの上田（＠tenntenn）です。 私が所属するEnablement Groupでは、「エンジニア職にできる喜びを届ける」というミッションを掲げて、エンジニアイネーブルメント事業を行っています。 具体的には、Goエンジニア向けの_YOUR WORK for Gophers(β)の開発、Enablement WorkshopやEnablement Internshipなどのイベントの企画・運営などを行っています。 本記事ではエンジニアイネーブルメント事業の1つとして行なう予定の「Enablement Bootcamp for Gopherizing 〜業務で使えるGoを学ぼう〜」について、開催に向けて思いを述べます。 なお、エンジニアと表記した場合、ソフトウェアエンジニアを表しています。 エンジニア採用におけるジレンマ企業の事業やミッシ

ナレッジワークで SWE をしている味野（@minodisk）です。 ナレッジワークは、ナレッジを蓄積し活用するためのプロダクトを提供しています。一口にナレッジと言っても、組織によってナレッジを作るソフトウェアは異なり、そのファイル形式はさまざまです。 ナレッジワークでは、さまざまなファイル形式をウェブブラウザ上で表示することをサポートするために、ファイルを前処理してプロダクトで取り扱える形式に変換する仕組みを作っています。 この一連の変換を、Content Processing System と呼んでいます。今回は、 Content Processing System のシステムデザインの概要を解説します。 システムデザインまず、Content Processing System は Initiator・Converter・Processor・Finalizer と大きく 4 つのステッ

はじめまして。2022年2月からナレッジワークでバックエンドエンジニアをしているhiroです。 この記事では、私がナレッジワークに入社する1番のきっかけになったコーディング面接について、主に受けた側目線で紹介します。 伝えたい内容は大きく以下の2つです。 コーディング面接をとても大切にしている 模擬面接があるので興味のある方は是非受けて欲しい まず前提として、ナレッジワークでは自分達の仲間は自分達で集めるをモットーに、エンジニアチームのシニアメンバーがエンジニアの採用に深く関わっています。 この採用プロセスの内のひとつがスキル面接で、コーディング面接の形式で行われています。質疑応答のみの技術面接とは異なり、お題に対して、その場で実際にコードを書いて解く形式の面接になります。 コーディング面接を大切にしているコーディング面接は、採用プロセスである以上、候補者様の技術を引き出し、正しく評価する

ナレッジワーク CTO の mayah (@mayahjp) です。 去年（2022年）後半ごろから開発人数が増えても生産性をキープするための施策の１つとしてモジュラーモノリス化を少しずつ進めていました。一定のマイルストーンとして大きな枠組みの合意と整理に達したため成果を共有します。 チームにあったアーキテクチャを求めてモジュラーモノリスに至りましたナレッジワークは創業当初は数人のソフトウェアエンジニアで開発していました。初期 (2020年) はフロントエンドバックエンド含めても３人で、2022年頭でも正社員のソフトウェアエンジニアとしては６人でした。この頃はチーム分けも何もなく１チームで開発をしていました。 この頃は Go で書かれたサーバーサイドアプリケーションは単なるモノリシックなアーキテクチャでした。具体的には、ディレクトリ構造としては下の様にトップレベルで domainmodel

執筆趣旨：イネーブルメントのモデルケースを示すナレッジワーク HR Manager 徳田です。 今回のDevelopers Blogは、エキスパート人材の活動を支援する「ナレッジスポンサーシップ制度」を紹介します。 ナレッジワークは仕事のイネーブルメント(能力の向上や成果の創出)をコンセプトとした企業向けソフトウェアを開発・提供しています。 コーポレート部門は「イネーブルメントのモデルケースを示す」をミッションとして掲げ、ナレッジワークがイネーブルメントを体現するモデルとなれるように組織作りに取り組んでおり、2022年10月-12月の3ヶ月間でも計8つの制度を社内リリースしました。 そのうちの1つが「ナレッジスポンサーシップ制度」です。 制度内容はシンプルで「世の中へのナレッジシェアのための社外活動について、業務時間利用や会社費用負担等を認めることで支援する」というものです。 制度はシンプ

ナレッジワークでソフトウェアエンジニアをしている @yudoufu です。 先日、ナレッジワークのプロダクトBackendはGKEからCloud Runへの移行を終え、サブシステムを含むプロダクト全体がServerless化されました。 今回は、ナレッジワークのプロダクト本体のAPI BackendをGKEからCloud Runに移植した話を紹介します。 初期のナレッジワークのシステム構成ナレッジワークでは立ち上げ当初より、サービス本体とも言えるAPIバックエンドをGKE(Standard)環境で構築・運用されていました。 開発最初期には当然、PMFを目指すためにプロダクトには様々な試行錯誤的な機能追加が行われることになり、またシステムのワークロードなども含めて今後の運用形態に不透明な部分が多くあります。 そのため、システムの機能面・性能面の両面で拡張に対する柔軟性が高く、かつIaC運用と

こんにちは、よしこです。 みなさんコードレビューしてますか？ 今日の記事では、最近おこなわれた社内でのイネーブルメントを推進する取り組みと、そこから生まれた新たなコードレビューのやり方についてご紹介しようと思います。 コードレビューにおけるトレードオフ取り組みやレビュー手法の話をする前に、前提としてコードレビューの際に以前から私が持っていた悩みをお話しします。 （以降レビューする人をレビュアー、される人をレビュイーと記載します） ナレッジワークのフロントエンドチームでは私が主なレビュアーとしてコードレビューをしているのですが、その際に1つ悩ましいトレードオフがありました。 これはレビュアーにもよるかもしれないのですが、私の場合は「全体像を見てレビューしたい」という方針があります。 「ある振る舞いを実現するコードのうち一部だけのコード」よりも「ある振る舞いを実現するコード」をまとめてレビュー

ナレッジワーク CTO の mayah です。 前回、CEO の麻野より、ナレッジワークが作ろうとしているプロダクトについてお話ししました。今回は、ナレッジワークの開発組織において大切にしている考え方と、開発プロセスについてお話しします。 ナレッジワークでは「正しいものを正しく作る」という思想のもと、 正しいものを定義するための、情報流通の仕組み 正しく作るための、アジャイル開発をうまく回す仕組み に開発体制の特色があります。 話したいことはたくさんあるのですが、本日はこの２点に絞ってお伝えします。 プロダクト開発は総合力勝負ナレッジワークでは、プロダクト開発は総合力の勝負であると位置付けています。 プロダクトを開発する側をプロダクトサイド、販売する側をセールスサイドと分けたとします。プロダクトサイドはプロダクトマネージャー (PdM)、デザイナー (Des)、ソフトウェアエンジニア (S