【フォースタ テックブログ】技術書典への初めての出版物を書籍にしていただきました！

テックラボグループが有志を募り、2020年12月に技術書典に応募。その後2021年5月にインプレス社経由で出版を果たした。今回の記事では出版に至った経緯とその裏側に迫る。

▽▽▽今回出版に至ったVol.1▽▽▽

https://www.amazon.co.jp/dp/B097D6B8QY

－この度は初の技術書典での出展および本の出版、おめでとうございます！
　そもそも技術書典に応募しようと思ったきっかけや走り出しはどんなものだったのですか？

井原：
軽い気持ちで「技術書典に出してみたいね」と提案したところ話が盛り上がり、自然と集まったメンバーで書くことになりました。10月から執筆作業に取り掛かり約2ヶ月間で仕上げていったのですが、話し合いで決めたのは「10ページを目安に書き上げること」程度で、テーマに関しては特に戦略を立てて決めることなく各々の興味関心が高い分野で好きに書き始めました。

井原

－技術書典への応募・本の出版にあたり大変だった点や苦労した点を教えてください。

藤井：
内容の質の高さを出すのに初めはプレッシャーを感じました。執筆自体初めてのことですし、個人ブログではなく会社として発信するものだったため、読者に何かしらの発見を与え、読んで良かったと思ってもらうにどうするべきかと随分苦悩しました。後々自身で振り返って「このテーマは他の人に負けないくらい考えた」と思えるくらい考え抜こうと自問自答を繰り返しながら書きました。

藤井

村林：
通常業務に加え、テックブログの執筆や勉強会、ウェビナーの登壇も控えていた中、応募時と出版時で記事のフォーマットが異なっていたことが発覚しそのディレクションや編集作業に思いの外手間取りました。具体的にはRe:VIEW StarterからRe:VIEWに変える作業だったのですが、フォーマット変更に伴い表示にズレが生じてしまってないかを一つ一つ確認する必要があったのです。結果かなり出版ギリギリの提出にはなりましたが、なんとか間に合いホッとしたのを覚えています。

－今回記事を書いたことで良かった点や学んだことなど簡単な感想を教えてください。

村林：
自身のやっていることの言語化に繋がった気がします。全体像を気にせずバラバラ書いていったからか普段自分が感じている点や思っていること等が文章として顕著に落とし込まれていく感覚はありました。

村林

戸村：
フォースタでの自身の歴史を棚卸ししていくような内容だったので、これまでの振り返りができました。ヒューマンキャピタリストとして人材紹介事業に携わっていた頃から、エンジニアとしてテックラボに参画し現在のCTOを任されるまでの軌跡とともに「組織」について触れられたのは自身にとってもとてもいい経験だったと思います。

藤井：
メンバーの新たな“強み”を知れました。例えば村林さんは大学時代新聞部だったこともあり、キャッチーなタイトルをつけるのが上手でした。本文を書き出したはいいものの、読みたいと思わせられるタイトルをつけるのは文字数が少ない分想像以上に難しかったので、それをサラッと出していた村林さんはシンプルに凄いなと。

「何よりも実際に書籍として手元に届いた時は本当に嬉しかった」と話す皆さん

－技術書典に出した後の反響等はありましたか？

戸村：
知人からの買いました連絡を何件かいただきました。当時、Twitterで技術書典の購入ツイートを購買者がつぶやく度Slackに流れるよう連携しており、その通知が届く度に皆で盛り上がっていました。中にはその後に個人的に挙げた振り返り記事を見て購入したとツイートしてくれた人も。
執筆当初に想像していたよりも多くの方に閲覧いただけたようです。

－書籍の話が来てから本が出るまではどんな流れだったのですか？

戸村：
技術書典を出してからすぐにインプレス社からDMが届きました。あまりに掲載直後のDMだったので思わず一瞬半信半疑になってしまった程です（笑）

ですがせっかくいただいた話ですし、Amazonや書店で並んだ方がより成果を形に残せると思い、出版することにしました。契約締結後はSlackでのやりとりに移行し、村林さんに出版準備全般のディレクションをお任せしました。

村林：
インプレス社から出版話を持ちかけられた2020年12月がちょうどサービスのリリースのタイミングだったため、準備期間は多少長めにいただきました。フォーマットの修正やAmazonでの書籍紹介文の作成、表紙をご担当いただく絵師決め、ラフ画すり合わせ等で都度やりとりしながら、無事2021年5月25日に出版することができました。

また、2021年7月に今回新たなメンバーで書き上げたVol.2を技術書典11に出しました。Vol.1とはまた違ったテーマを取り上げた渾身の一冊となっております！（急な宣伝）

techbookfest.org

－最後に、今回の総括をお願いします。

戸村：
フォースタートアップスのバリューの一つである “Be a Talent”は、「自らの生き様を社会に発信せよ」というメッセージが込められており、なかなかエンジニアとして体現が難しい中、テックブログや勉強会等で積み重ねてきたものを公に出せたのは良かったです。引き続き、技術書典も含め、よりいろんな挑戦を発信していけるチームにしていきたいと思っております。

CTO 戸村

Slackを最高に使いこなすためにフォースタがやっていること

どうも、フォースタートアップスでエンジニアをやっています村林です。

皆さん「Slack」使っていますか？Slack最高ですよね。
弊社もSlackバリバリ使っていて、Slack無いと仕事できないくらいには依存しているのですが、組織が拡大する中で様々な問題が出てきました。

チャンネルが多すぎてよくわからない

弊社は誰でもチャンネルを作成できます。そのためどんどんチャンネルが作成されていき、その結果大量のチャンネルが存在しています。それだけなら良いのですが「チャンネル名のルールがない」「チャンネルの説明がない」などの理由から目的のチャンネルが探しづらい状況になってしまっていました。

これはいかんということでSlackの活用ガイドラインを一部の有志で考えました。

Slack活用ガイドライン、チャンネル命名のルール

原則: 部署名_チーム名_目的で作る
特に接頭句に関しては以下のものから使ってもらっています。

• 部署内に閉じる場合

ac_ ：アクセラレーション本部
cp_ ：コーポレート本部
hr_ ：人事
oi_ ：オープンイノベーション
ta_ ：タレントエージェンシー本部
tl_ ：テックラボ

• 部署をまたがる場合

all_ ：全員いるチャンネル
pjt_ ：部署がまたがる(2ヶ月以上）
tmp_ ：一時的な集団（２ヶ月未満)

• その他の用途

guest_ ：他社の方との連携チャンネル
info_ ：情報共有系
notify_ ：システムからの通知
club_ ：趣味系

以上がチャンネル名のルールです。

具体的な例としては

pjt_startupbdb
弊社が展開しているSTARTUP DBに関して話し合うチャンネル

all_branding_pr
社外向けの情報周知がされるチャンネル

club_ラーメン
ラーメンの画像を貼るチャンネル。「今日のラーメン」と書けばラーメンじゃない画像を載せても許される風潮がある。

そこまで堅苦しいものにすると、実運用されないなと考えたことから接頭句のみ縛りを加え、それ以外は比較的に自由に設定できるようになっています。このルールが作られてから半年くらいですが、最初は守られていないケースも多々ありましたが、最近は殆どこのルールに従って作成されています。

ちょっとした命名規則ですが、あるとないとでは検索性、視認性が段違いなのでSlackのチャンネル多すぎてお困りでしたら皆さんもぜひやってみてはいかがでしょうか。

DMが多い

これもあるあるですよね。
「みんなの注意を向けられるほどの内容でもない」「変なことを聞いて恥をかきたくない（恥をかく対象範囲を最小限にしたい）」などの色んな理由から人はpublicなチャンネルではなく、DMを使います。
気持ちはわかりますが、DMは完全に秘匿された状態なので、そこで交わされた内容は誰の目にも触れることがありません。知識が社員の間で偏在し、横展開されることもなくなります。

Slackの素晴らしいところのひとつに検索性の高さがあると思っています。
Slackは検索能力が素晴らしいので「なんでこうなってるんだろ？」「これ今どうなってるのだろう」ってなったときに検索すれば大体経緯が出てきます。これは対面、電話、Zoomのいずれのコミュニケーション手段も達成していない価値なので是非活用しましょう。

でもたまにDMで感謝を伝えたり、伝えられたりは好きだったりします。なんかいいですよね（個人の見解）

ということで、この状況を打破するために以下の指針を出しました。

DMはやめて個人チャンネルでやり取りする

個人チャンネルは「分報」「times」などとも呼ばれていますが、特定個人のためのチャンネルです。個人チャンネルはpublicで作られているため、誰がどこのチャンネルに入ろうが勝手ですし、検索にも出てきます。また個人チャンネルという特性上、その人に関する話題なら何を振っても良い（良さそう）なため、publicなチャンネルでありつつも投稿をする心理的ハードルを下げるという効果を狙っています。

ということで、slackの困りごととそれに対応した話でした。
Slackのガイドライン策定などは色んな人の思いを汲んでやらなければいけないため、正直とても面倒くさいし、別に誰からも喜ばれない行為ではあります。
ただ、ちょっとした指針があるだけでみんなハッピーになりますし、Slackをみんなが使いこなす様を見ていると嬉しいので引き続き改善していければ良いですね。

We are hiring !

フォースタートアップスはエンジニア・デザイナーを積極採用中です😃

もしこの記事を読んでフォースタートアップスに少しでもご興味をお持ち頂けましたら、下記の「話を聞きに行きたい」ボタンより気軽にエントリーしてください。

事業やチームについての説明から技術スタックの解説まで、CTOやチームメンバーからさせていただきます。

【フォースタ テックブログ】RepositoryFactoryパターンをVueのAPIリクエストに導入する

こんにちは。エンジニアの藤井（@yutafujii）です。
社内向けのプロダクト「タレントエージェンシー支援システム（SFA/CRM）」のエンジニアをしています。

プロダクトはフロントエンドをNuxt/TypeScript・サーバーサイドをRailsで実装しているのですが、今回はフロントエンドのAPIリクエスト処理にRepositoryFactoryパターンを導入した話をさせていただきます。

RepositoryFactoryパターンとは

RepositoryFactoryとはAPIを呼び出す設計のデザインパターンとして、JorgeというVueエヴァンジェリストによって2018年に紹介されました。

（原文）Vue API calls in a smart way
https://medium.com/canariasjs/vue-api-calls-in-a-smart-way-8d521812c322

（日本語訳）【Vue.js】Web API通信のデザインパターン (個人的ベストプラクティス)
https://qiita.com/07JP27/items/0923cbe3b6435c19d761

Jorge氏のブログでは以下のような問いかけがされます。

How many times have you seen examples with an instance of axios in each component?
（各コンポーネントにaxiosインスタンスが書かれてるような実装をどれくらい見たことがありますか？）

そしてそのように実装されているコードに対してJorge氏は問題提起しています。

What happens if the endpoint changes?
（エンドポイント変更したらどうする？）
How I can handle mocks or different endpoints to test it?
（動作確認のためにエンドポイントをモックしたくなったらどうする？）
What happens if you need to reuse a call?
（再利用したくなったらどうする？）
What happens if you need to refactor some call or move it to a Vuex actions?
（Vuexに処理を移植するとかリファクタするとなったら？）

後述しますが、最後の”リファクタリングしたくなった”のがまさに私たちの陥った状況でした。
この問題に対処するために考えられたのがRepositoryFactoryパターンのようです。

これは名前の通りRepositoryパターンとFactoryパターンを組み合わせた設計ということになります。Repositoryパターンはドメイン駆動設計（Domain-Driven Design, DDD）で提唱された考え方、Factoryパターンはオブジェクト指向言語のCreational Design Patternsの一つです。

Repositoryパターンは、ドメインモデルのまとまり（Aggregateと呼ばれます）ごとにデータアクセスを1箇所に集約するRepositoryを作成し、データレイヤのロジックとドメインを疎結合にするというもの、Factoryパターンとはインスタンスの生成ロジックを一元管理するFactoryを作成し、インスタンスを必要とするクライアントから生成ロジックを分離するものです。

雑な言い方をすれば、両者を組み合わせることで以下のようなメリットを享受できるということになります。

• コードのメンテナンス性が向上（DRYに記述できる）
• 拡張性が向上（横展開するときに短時間で実装ができる）

導入背景

さて、弊社では2019年ころからモノリシックなRailsアプリケーションをフロントエンドとバックエンドに分離してきています。フロントエンドはVue/Nuxt/TypeScriptを採用していますが、詳細は下記ブログに記載しています。

tech.forstartups.com

ゼロから作ってきたばかりということもあり、APIへのリクエストは各コンポーネント中からaxiosを利用していました。

しかし、実装量が増大するにつれてAPIへのリクエストで共通の修正を行う場合に該当箇所や対象ファイルも増大し、メンテナンスが難しくなりました。そして、あるタイミングで実際にaxiosの処理をrescueしたいという話になりました。

「axiosを書いた各コンポーネント全部の箇所に修正を入れていく方法は避けた方がよいので別の方法を考えましょう」と一緒に働くメンバーの方が色々調査してくれて、RepositoryFactoryパターンを採用することにしました。

実装する

まずRepositoryパターンを導入していきます。

ドメインごとにデータへアクセスする処理をそれぞれ1枚のRepositoryに集約し、axiosによるAPIリクエストはこのファイルから（このRepositoryを通して）のみ行われるようにします。

次にFactoryパターンを導入します。

今回のFactoryパターンにおける具体的な生成物はRepositoryです。
Factoryを記述するファイルを作成し、どのRepositoryを生成するかを（呼び出し元のクライアントではなく）Factoryが決定できるようにします。

最後にaxiosを直利用していたコンポーネントを修正します。

データに対するCRUDアクションを行うときは必ずRepositoryを通すのがRepositoryパターンです。従ってaxiosを直で利用せずにRepositoryを指定するということになりますが、直接Repositoryインスタンスを生成せずにFactoryに”生成依頼”するのがFactoryパターンなので、最終的にはコンポーネントはFactoryに対してRepositoryインスタンス生成の依頼を行うよう修正します。これが下の図の .$repository(‘user’) です。

これによって得られたRepositoryは共通のInterfaceが備わっているので、あとは取得したRepositoryへのメソッド呼び出しを行うよう書き換えます。

なお、実際にはFactoryを呼び出すにあたって事前にpluginでFactoryをNuxtAppにインジェクトしておきます（repositoryという名称をつけました）。こうすることで context.root.$repository でFactoryを呼ぶことができます。

import { Inject, NuxtApp } from '@nuxt/types/app'
import {
 ApiRepositoryFactory,
 RepositoriesType,
} from '@/factories/api-repository-factory'
 
export default ({ app }: { app: NuxtApp }, inject: Inject) => {
 const repositories = (name: string) => {
   return ApiRepositoryFactory.get(name)(app.$axios)
 }
 inject('repositories', repositories)
}
 
declare module 'vue/types/vue' {
 interface Vue {
   $repositories: RepositoriesType
 }
}

また、コンポーネントにおけるRepositoryを通したCRUDアクションはcomposition APIを利用してcompositionとして切り出し、コンポーネントでは当該compositionをimportして使っています。

pages/index.vue

import useUsers from '~/composables/useUsers'
 
export default defineComponent({
 components: { },
 setup(_, context: SetupContext) {
   const {
     get,
     post,
     // ...
   } = useUsers(context)

composables/useUsers.ts

import { computed, reactive, toRefs } from '@vue/composition-api'
 
export default (context: any) => {
 const state = reactive<{
   user: UserType
   loading: boolean
 }>({
   user: {},
   loading: true,
 })
 
 const get = async (userHash: string) => {
   const response = await context.root
     .$repositories('user')
     .get()
   // ...
 },
 
 return {
   ...toRefs(state),
   get,
   post,
   // ...
 }
}

実装の概要は以上ですが、RepositoryFactoryパターンをAPIリクエストに導入した全体像を記載しておきます。

実装してみて

実装を終えて数ヶ月が経ちますが、当初の目的であったAPIクライアントに関するエラーハンドリングを1箇所に集約して管理することができるようになり（そしてそれは再利用が可能）、設計を一度理解すればコード管理が行いやすくなりました。

フロントエンドにとってはBackend For Frontend（BFF）サーバー以降のAPIサーバー・各種データソースをデータレイヤと見做すことができますが、その意味でドメインモデルとデータレイヤの中間にドメインごとに（正確にはAggregateごとに）1種のRepositoryレイヤを設けたことのメンテナンス性の高さをチーム一同実感しています。

副次的な効果として、以前の実装では設計から落ちておりスクリプトエラーとして拾っていたAPIのエラーを全てリクエスト段階で捉えて監視ツールにロギングできたことで、バグ発見までの時間を短縮できたことがありました。

Factoryパターンに厳密に従っているわけではないものの、それでもDRYに書けた部分が多く、今後もこのパターンに沿ってAPIクライアント側の機能開発は拡張していきたいと思います。

参考文献

以下のブログは実装の際に参考にさせていただきました

• https://qiita.com/lucaspoppy/items/a081beb8fdd7746a8c05
• https://sagatto.com/20201229_nuxt_axios_ts_repository

Vue API calls in a smart way
https://medium.com/canariasjs/vue-api-calls-in-a-smart-way-8d521812c322

【Vue.js】Web API通信のデザインパターン (個人的ベストプラクティス)
https://qiita.com/07JP27/items/0923cbe3b6435c19d761

Repositoryパターン
https://medium.com/canariasjs/vue-api-calls-in-a-smart-way-8d521812c322

Factoryパターン
https://www.oodesign.com/factory-pattern.html

【フォースタ テックブログ】Tryを決めるだけでは意味がない。チームに成果を還元するための取り組み。

お疲れ様です。エンジニアのHur Junhaengです。
フォースタートアップス（以下、フォースタ）に今年の２月に入社しました。

今回は、スクラム開発を行っているチームが振り返りで決定するTryをどう管理するべきか個人的な見解を込めて、フォースタでどのように対応しているかについてご紹介していきたいと思います。

スクラムにおいての振り返り

そもそもの話になりますが、振り返りは何故必要なのでしょうか。

振り返りを行う目的は、組織ごと違いはあるものの「過去にあった出来事から学び、チームをよりよい方向に変化させる」という大枠は同じかと思います。なので、振り返りの結論としてはチームをよい方向に変化させるための次のアクションを決めることが必須不可欠になります。

スクラム開発を採用している組織において、振り返りそのものは珍しいことではありません。振り返りのフレームワークは数え切れないほど多く存在していますが、Keep・Problem・Try方式（以下、KPT方式）を使ったことがない組織は少ないでしょう。表現は少し変わってしまいますが、この方式の場合でも「続けるべきこと（Keep）」と「抱えている問題（Problem）」を洗い出して、最終的には「次のアクション（Try）」を決定するために振り返りをしていることが分かります。

どの方式が組織に適切なフレームワークかはさておき、他の振り返り方式を採用している組織においても、新しいTryを決定することは重要ではないでしょうか。ただ、Tryを決定するだけで終わってしまうと個人によって取り組みがズレてしまったり、継続的な管理ができないことが多いです。よって、一度決定されたTryはチームとして「Tryに対する評価」をすることで、その成果をチームに還元する必要があります。

チームが抱えている課題

私が働いているチームではKPT方式を含め、色んな振り返りフレームワークを実施しています。フレームワークごとに手法は異なりますが、最終的なアウトプットとしては複数のTryが決定されています。ただ、決定されたTryは体系的に管理されておらず、チームやメンバーの状況によって左右されるという問題が発生していました。

• Tryによっては共通認識にズレがあり、メンバーごとの解釈が異なる
• 目の前のタスクが優先され、新しい取り組みを忘れてしまう
• 効果があっても、チーム全体の行動改善に繋がりにくい

明確なTryの評価フローがなかったので、Working Agreement（以下、WA）は存在しているが、良いTryだと評価されていても適切なタイミングでWAに反映されておらず、そのままフェードアウトしていくようなケースもありました。

振り返りを通じて、チームで議論して決定された方針が、知らない内に忘れられてしまうことは望ましくありません。チームとして、もう少しTryの扱いを改善する必要があると認識しました。

Try一覧とステータスを可視化

チームの問題を解決するために最初に取り入れたのは、決定されたTryを別ドキュメントにまとめることでした。今までは振り返りの時に作成した議事録の中で各Tryを記載していたので、Tryを確認するたびに作成された日の議事録を閲覧していました。スプリントを跨いでも一目で状況が分かるような仕組みを作り、Tryを取り組む際のフットワークをなるべく軽くする必要がありました。

専用の一覧ページには振り返りで決定されたTryを記載し、それぞれの進捗状況をステータスとして表示させます。 そのステータスは毎スプリントごとに再評価を行い、最終的にはチーム全体の行動を変化させるためにWAやチームのCultureとして還元することを目的にします。

In progress
: 最初にtryが決定されている時の状態
Keep
: Tryを継続し、今後も効果を図りつつ継続したい
Done
: 実施済み、または意識しなくても既にに達成されている
Close
: 実施できない、または実施する必要がなくなっている
WA
: Tryの結果、チームとして守るべき行動規約として決定されたもの
Culture
: Tryの結果、特に意識しなくてもチームに浸透している状態

Try一覧を作成してステータスを管理することは、常に最新状態であり、信頼できる情報元を1画面で提供することに意味があります。例えばメトリックス監視など、情報の可視化のためにダッシュボードにリソースの情報を集約させることを考えてみましょう。情報を集約し、現在のステータスを可視化することは継続的な管理手法の第一歩と言っても良いでしょう。

Tryのライフサイクル

先ほどご説明しましたが、Tryを評価することはTryを決定することと同じくらい重要です。リスト化されたTry一覧を管理することができれば、次は定期的な評価を行う必要があります。現在のチームでは2週間を1スプリントとして進めているので、スプリントの振り返りを行う際にTryを再評価を実施しております。

振り返りの実施結果としてTryが作られたら`In progress`として設定させ、1スプリントの実施時間を経て評価を行います。実行すること自体が目的であるタスクレベルのTryはこの時点でDoneに移行するケースが多いが、その他の場合はチームでそのTryを継続して取り組むべきかを検討する必要があります。

• スプリントの中で、メンバーはそのTryを遵守して行動していたか。
• 実施してみて、本来想定していた効果は得られたのか。
• Tryの効果よりも、継続するためのコストが高くないか。

この中でTryをチームが継続して取り込む価値がないと判断されたらステータス`Close`に設定し、継続を中止します。また、1スプリントで評価できなかったTryに関しては次のスプントまで効果検証を継続します。数は多くないかもしれませんが、1スプリントで充分に効果検証を完了しており、チーム全体で今後も取り組みたいと判断する場合は`WA`や`Culture`に反映することもよいでしょう。

次のスプリントではこの`Keep`ステータスのTryを同じ方式で評価して行いますが、`Keep`状態として残り続けることは警戒する必要があります。評価のタイミングを先送りにし実施されないTryが残り続けることは、効果の判断ができないTryをチームとして意識し続けなければならいことを意味します。

私が働いているチーム場合、`Keep`ステータスから`Keep`ステータスに変化することは、最初Tryが決定から2スプリント（4週間）が経過していることを意味します。2スプリントが経過したにもかかわらずTryが残り続ける状況の場合、評価を阻害する要因が存在しているか確認する必要があります。その場合、阻害要因を無くすためにチームとして取り組むべきことを先に実施した方が良いでしょう。

最後にTryの結果をWAやCultureに反映することに決まった場合は、それぞれを専用のドキュメントとしてまとめ、常に最新の状態になるように管理しなければなりません。これはTry一覧を作成する際と同じく、継続的な管理を行うためです。チームが取り組んでいることを言語化することによって、メンバーの共通認識を促すことと同時に、新しいメンバーが参加する場合にもチームの働き方をスムーズに吸収することができます。

チームの今

全てのTryは一覧で管理されており、スプリントごとにその効果を検証しているので、どんなTryでもしっかり評価されるようになりました。また、Try一覧を作成してから3ヶ月間、22件のTryが作られましたが、`Keep`ステータスのTryは2件のみでその他は何からの形でチームに還元されています。

特にTryの結果、WAとCultureに4件の行動規約が追加されており、Tryのステータスが変更されたタイミングでWAとCultureを更新するので、常に最新の情報が反映されています。WAにはチームとして遵守すべき内容のみ記載することになってので、Tryの管理仕組みを取り入れる前と比べれば非常にコンパクトになっています。WAに収まらない項目はCultureに記載することによって、遵守すべきものとチームの文化を区別することができました。

WAの例 :
エラー対応を完了する際には、その根拠をコメントに記載する
Cultureの例 :
githubは1function - 1commitを原則とし、日本語でコミット内容の説明文を記載する

現在はTry一覧を朝会などでチームと確認する時間を作って、スクラムの一部として取り扱っています。今後チーム内で確認する時間を作らなくても、メンバーがTryを意識して働くような文化が染み付くようになったら、別途時間を作る事なくTryを継続していくことができるでしょう。