Cybozu Frontend Monthly#27 (ゲスト：株式会社ナレッジワーク)参加メモ
概要
メモ
ナレッジワークの紹介
ミッション「できる喜びが巡る日々を届ける」働くことを変えたい
イネーブルメントをやっていく会社
イネーブルメントのためには
やるべきことの明確化、できることの最大化
Style：行動指針
Act For People
Be True
Craftsmanship
これが日々に浸透している
今は30人いかないくらいの人数
てぐりんさんは最近入社して、印象どうですか？
Style体現できているメンバーばかり
9月入社のメンバーも「Style体現できていてすごい」と話していた
採用でもみている？
明確に入っている。「Style面接」があるくらい重要視している。
転職のきっかけは？
前職まではフルスタックだった
どこか尖った技術が欲しくなった
最終的にナレッジワークを選んだ
プロダクトの紹介
営業に特化したイネーブルメントクラウド
なぜ営業なのか
営業という領域の伸びしろに注目した
イネーブルメントを達成するための4象限
ナレッジ、ワーク、ラーニング、ピープル
ナレッジ：格納
ワーク：資料使う
ラーニング：資料や動画を使ってテスト等作って学んだり
ピープル：開発中。自分の現在地や次のステップに進むための道がわかるようなものを作りたい。
創業何年目？
3年目
リリースしたのは？
今年の5月
ステルスで開発していたにも関わらず、お客さんがたくさんいてすごいと思いながら見ていた
プロダクトでの技術スタック
去年の9月に出した
こだわりポイント
フロントに関して
①State
②Suspense
③Recoil
たどり着くまでのつらみ
今まで使っていたReduxが、個人的に辛くなってきた
シングルステート与えれば返ってくる単純さのうまみを享受しにくかった
情報によってはマスクしなければいけなかったりするし
パーツが分かれている部分も、右から左に流しているだけになってしまっていたり
サーバーとのデータの二重管理
書いて1年経つが、変更あった？
大きく変わったところは基本ない
アプリケーションのアーキテクチャは一度変更した
コンポーネントのディレクトリ構成は今後変えるかも
当初は配下の階層はフラットに置いていたが、アプリケーションが大きくなってきてコンポーネントが肥大化してきた
局所的なものと再利用していくものとを整理していくといいかもと考えている
確かに、似たドメインが出てきた時にフラットに置いてあると迷いそう
（ここから数分離席した）
他のメンバーからしてどうだった？
あおしさん：React使ったことなかったが、とっかかりやすかった
てぐりんさん：事前に設計されており、秩序がある基盤になっている
最初はどこに何を置くべきか迷ったが、コードレビューを通して慣れていき、今は違和感なく開発できている
人が決めた構成と自分の思想が離れているときもあると思うが、迷いが少なく入りやすそうでいいですね
フロントエンドのアーキテクチャ説明のスライドがあり、それをオンボーディングで使っている
ルールは時間の経過によって増減があるかと思うが、どのように意思決定して全体周知しているか
リポジトリ増やす件の話とか
誰がどう舵を切っている？
リポジトリの時はよしこさんだけだったが、フロントエンドが今は3人になった
隔週でフロントエンド定例があり、そこに議題を持っていく
業務委託のかたなどに意見を聞いたりもしている
ディレクトリ構成の話なども、みなさんのところでは今までどうやってました？などを聞いて参考にしている
技術的な最終的な意思決定はよしこさんがするが、みんなの意見を聞いた上で最適な決定をしたい
議論の場があることで、そこがイネーブルメントの場にもなって良い
フロントエンドエキスパートチームはどう？
アーキテクチャ決めるのはプロダクトチーム
今だとkintoneの刷新などでフレキシブルに技術変えたりしている
機能切り出した範囲で技術選定したりしている
チームごとに裁量があり、選定する技術も違う
大企業ならではの面白みもあり、試行錯誤している
社内でのナレッジがあるからやりやすそうで良さそう
チーム間の共有、支援のし合いがある
チームが別の技術やっていることで得られることもある
チーム別にブログ書いたり
社内で共有会したり
やっていいこと、悪いことなどを共有できてよい
同じ目的で違う技術選定することってあんまりないから、面白いですね
チームごとにADRとってて、決断を記録し共有している
ナレッジワークさんどう？DesignDocの扱い
機能を開発するとき使うドキュメントは、minispecとDesignDoc
minispec：機能の仕様書
プロダクトデイリーというミーティングでデザインや機能を揉んで、PMが機能に落とし込んで記述している
解決すべき課題、ユーザーボイス、どう解決するかを書いている
DesignDoc：より詳細な設計文書
minispecもとに記述
システムの概要、APIの定義、DBのスキーマ、開発していく上で考慮すべきことなどを書いている
機能単位で必須で書くわけではなく、大規模なものなどを起こしてレビューして手戻りなく開発できることを目的にしている
DesignDocは誰が書いてる？
APIの設計、DBのスキーマなどならバックエンド
フロントエンドでも大きめの設計が必要になるときは書く
「全員でレビュー」
エンジニアユニット全員にメンション飛んでいる
時間と共にドキュメントが陳腐化していく件
その時の開発をするためのもの。当時の仕様、スナップショット的な扱い
デザインもデザインのスナップショットをFigmaに落とし込んでいく的な運用をしている
DesignDocを見直した時、「なぜこの増改築したんだっけ？」となったことない？
あまり開発終わってから見返すことは少ない
合意形成についてのドキュメントは残している？
DesignDocのコメントに残したり
「他に検討した設計」というセクションに残したり
今の課題
技術の課題
スタイルが共通化しきれておらず、コピペのCSSや微妙にデザインの違う似たパーツがある
資料やコメントの更新にすぐ気づくことができない
ネットワークが不安定な状態では資料を閲覧することができない
パフォーマンスの劣化に気づけない
現場どのようなパフォーマンスでプロダクトを提供できているか正確に把握できていない
デグレ検出がE2E頼りになっており、Componentレベルのバグを検出するコストが高い/検出できていない
今後は実行時間の課題も出てきそう
今は2週間1スプリントで開発している
チームの課題
ちょうど今日アップした記事！見てね！ここに書いてあることなどを今後やっていきたい
社内のイネーブルメント強化