脱社内外注を進めています

デジタルイノベーションラボの齋藤です。

少し前から、社内で脱社内外注という話をしています。社内外注の状態でもうまく行っている組織もあると思いますが、クオカードの場合は色々と課題を感じた為、状況を変えようとしています。今回は社内外注にはどのような問題があると考えているか、またどのように脱却しようとしているかを説明します。

本記事内での社内外注、用語の定義は以下とします。

• ビジネス側が構築するシステムの要件定義を行い、リリース時期と合わせて開発側に依頼(発注)する
• 開発側は依頼された通りのシステムを構築し納品する
• 開発側：デジタルイノベーションラボ所属のエンジニア、デザイナー
• ビジネス側：エンジニア、デザイナー以外

内容的にビジネス側と開発側に対立があるように受け取られる部分があるかもしれませんが、クオカードはかなり協力的に進める事ができている組織だと思います。今回の件もビジネス側に相談したところ、ではどのように進めたら良いか教えて欲しいという申し出を頂きこの記事を書く事にしました。

社内外注の問題

正しいものを作るのが困難

DX 実践手引書　IT システム構築編　で、以下の外部委託の問題が挙げられていますが、この問題は外部委託が社内外注になった場合でもそのまま当てはまると考えています。

DX に取り組む上での課題を設定する際には、現場の人材の課題意識やニーズ、自社の強みを深堀することが重要であるが、それらの本質的な理解を外部の人材に求めることはそもそも難しい

ビジネス側が要件を作成する場合、作成したものを開発側に連携する形になりますが、必要なものを開発前の段階で漏れなく記載するのは不可能に近いと考えています。

要件だけが渡される場合、開発側がそれぞれの要件の背景や文脈を理解するのが難しいというものがあります。その為、要件に問題があったとしても開発中に気づくことができず、問題があったものがそのまま作られる事があります。

また要件だけが渡され、背景や文脈、現在の運用内容などの情報が連携されないと開発側に業務知識が蓄積されず、長期間開発を続けてもビジネス側に確認しないと何を作って良いかわからない状態が続いていきます。

エンジニア/デザイナーの専門知識が生かされにくい

通常システムを開発する際、機能要求に加え、性能やセキュリティなど、非機能要求も合わせて検討して行く事になります。

非機能要求の実現にかかる時間/コストは機能要求により変わる事がありますが、それらはシステム開発の専門家でないとわからず、社内外注の形だと非効率な設計になる事があります。

本来であれば要件の精査を行うところですが、社内外注の場合依頼を受けた時点でリリース時期が決まってしまっているなど、非効率なまま開発に着手せざるを得ない状況もあります。

また設計と実装は不可分なものと考えています。実装中に当初の設計に無理があることに気づいたり、より良い設計を思いつくことがあります。

またデザインもスキルが必要ですが、一方で専門職以外の人にそれが伝わりにくい領域だと感じます。こちらも言われたものをただ作っていくのではなく、必要に応じスキルを持っているメンバーがユーザーテスト等を実施し、正しいものを作るようにしていきたいと思います。

非効率

DX 実践手引書　IT システム構築編　で、以下の外部委託の問題が挙げられていますが、この問題も外部委託が社内外注になった場合でもそのまま当てはまると考えています。

外部委託開発はトライアルからのフィードバック、サービス実装者へのニーズの正確な伝達や設計実装などに時間的オーバーヘッドがかかりすぎることが問題となる。

目指す姿

エンジニアはシステムを作る存在ではなく、顧客(利用者)の課題を解決する存在

こういったものを作ってほしいという依頼が来た場合でも、それをそのまま構築するのではなく、依頼者の抱えている問題を把握し、場合によっては違うソリューションを提案した方が良いケースがあると思います。

例えば運用を変更する事で問題が解決するなら開発期間ゼロで問題が解決するため、ROIは高くなります。また時間をかけずに問題が解決するので顧客の満足度も高くなります。

現在までの取り組み

アナウンス&説明

まずはビジネス側、開発側両方に現在どのような問題があるか、どう改善していきたいかのアナウンスや説明を行いました。

一度伝えたら理解してもらえるというものでもないので、何度か同様の説明を行なっています。

具体的にはビジネス側には要件ではなく背景・課題を共有するようにして欲しい、開発側にはもし要件を受け取ってもそれをそのまま実装するのではなく、背景・課題を確認し、運用フローを作成した上で開発に着手して欲しいと伝えています。

フィードバック

目指したい方向とずれた進め方になっていることに気づいた場合は、できるだけ早めにその旨フィードバックするようにしています。

開発側が運用フローを作成してから開発に着手

課題を明らかにするため、また焦点がずれた機能を開発するのを避ける為、開発側が運用フローを作成してから開発に着手するようにしています。この取り組みにより、開発側もビジネス面の理解が進みました。

上記の取り組みはまだ道半ばですが、できるだけエンジニアがその専門性を生かし、ビジネスに貢献できる組織としたいと考えています。逆に技術だけに興味があるもしくは顧客の問題を解決することに興味が無い、または機能要求、非機能要求などを全て決めて欲しいという人にはマッチしない会社になっていると思います。

クオカードでは、顧客の問題を解決したい、もしくはビジネス側と一緒に要件を考えるなど裁量を持って働きたいエンジニアを募集しています。

採用サイト quo-digital.jp

出典

DX 実践手引書　IT システム構築編

AndroidアプリのDIライブラリを KoinからHiltに移行しました

デジタルイノベーションラボPayチームのゴルゴです。 先日Androidアプリで利用するDIライブラリをKoinからDagger-Hilt（移行Hilt）へ移行したので、今回はその件について書こうと思います。

背景

Androidアプリの初期実装は主に2名のエンジニアで行ったのですが、2018年の当時はまだどちらもDaggerの利用経験がなくDaggerの学習コストが高いことがネックとなり、導入が容易なKoinを採用しました。 Koinを採用してから最近まで特に大きな問題はなかったものの、

• 近年Hiltがリリースされたことで導入コストが下がった
• Koinのバージョン変更に伴いコード改修を必要とした
• Koinが実行時に依存性解決するのに対し、Hiltはビルド時に解決するため問題の検出が早く安全に使える

などを考慮してHiltに移行することにしました。

進め方

準備

移行にあたってはまずはスクラムのスパイクタスクとして試験的に1画面の移行を試し、その中で課題の洗い出しと調査を実施することにしました。 Developersガイドに従って作業すると共に、Hiltのコンポーネントの分け方やライフサイクル、Koinで特殊な使い方をしていた箇所の移行方法についてまとめを行いチーム内で共有しました。 途中で躓いた点もあったのですがそれは後述しています。

本対応

2週間の１スプリントで気合を入れて一気に移行作業を実施しました。 Hiltのコンポーネントファイルは、アプリがMVVM+UseCase/Repository/DataStoreという構成なので、UseCase/Repository/DataStoreの各レイヤ毎に作成し、移行作業を進めました。 ただFirebaseAnalyticsのLoggerのような特定レイヤに属さず全般で使うようなオブジェクトもあるので、そういったものはApplicationModulesを作成してそこに属させることにしました。

また作業中に特に気をつけた点として、途中でリファクタリングやDeprecatedの対応をしたくなったのですが、これをしてしまうと万一問題があった際に原因切り分けに時間を要してしまうので、やむを得ない箇所を除きぐっとこらえて進めました。

躓いた点

途中躓いて調査を要したポイントです

ContextからEntryPoint取得

ActivityやFragment等のHilt既定のAndroidEntryPointと、依存オブジェクトを使いたい箇所が離れていてオブジェクトを引き回すのが難しいケースというのがどうしても出てきました。そのようなケースのためにContextさえあれば独自に定義したEntryPointを取得し、依存オブジェクトを取得する方法が用意されています。

https://dagger.dev/hilt/entry-points

例えば任意の場所でFooBarを欲しい場合は

@EntryPoint
@InstallIn(SingletonComponent::class)
interface FooBarEntryPoint {
    fun get(): FooBar
}

という定義をしておけば、

val fooBar = EntryPointAccessors.fromApplication<FooBarEntryPoint>(application).get()

でオブジェクトを取得することができます。

ActivityとFragmentでViewModelを共有

Activityとその内部に配置しているFragmentで同じViewModelを参照し、Activityからの操作をFragmentの画面に反映したい場面がありました。 このケースではActivity/Fragmentそれぞれで通常通りby viewModels()でオブジェクトを取得すると、別インスタンスになってしまいActivityからの操作が画面に反映されない事態が発生してしまいます。

こういった場合、Fragmentからは

// Fragment内
private val viewModel: FooBarViewModel by activityViewModels()

で取得することで、Activity側と同じインスタンスを共有することができます。

https://developer.android.com/kotlin/ktx?hl=ja#fragment

ViewModelのコンストラクタで動的なパラメータを引き渡し

例えば、一覧から詳細画面に遷移する際に、詳細画面のViewModeにIDを渡すようなケースがあると思います。ViewModelにミュータブルなプロパティやセッターメソッドを用意し、Activity/Fragmentからセットしてもいいのですが、次のようにSavedStateHandleを使うことでイミュータブルにすることができます。

@HiltViewModel
class DetailViewModel @Inject constructor(
    savedStateHandle: SavedStateHandle
) : ViewModel() {
    val id = requireNotNull(savedStateHandle.get<ItemId>("id"))
   …
}

なお、savedStateHandle にはHiltによって activity.getIntent().getExtras()あるいはfragment.getArguments()が渡されますが、任意の値を設定したい場合にはAbstractSavedStateViewModelFactoryを継承したFactoryクラスをつくり、このクラスを使ってViewModelを生成することで実現できました。

fun provideFactory(
    owner: SavedStateRegistryOwner,
    defaultArgs: Bundle? = null,
    foo: Foo
): AbstractSavedStateViewModelFactory = object : AbstractSavedStateViewModelFactory(owner, defaultArgs) {

    @Suppress("UNCHECKED_CAST")
    override fun <T : ViewModel> create(key: String, modelClass: Class<T>, handle: SavedStateHandle): T {
        handle.set("key_foo", foo)
        return TopicViewModel(handle) as T
    }
}

やってみてどうだったか

移行作業の中で単純な記述ミスも時折あったのですが、コード内にEntryPointを定義した時点で依存解決できずにビルドエラーとなる、つまりHiltのメリットとして期待していたとおり、コード実行せずとも設定ミスがわかるので効率的にすすめることが出来ました。 動かしてから初めてエラーになるようなミスはなかったと記憶しています。 実はHiltに移行したアプリをリリースしてから既に数ヶ月経過しているのですが、今のところ移行に起因した問題は出ていません。広範囲の修正をおこなったのでリリース時は不安はありましたが、無事に移行できてよかったです。

この記事がどなたかの助けになれば幸いです。

クオカードを退職します

こんにちは、デジタルイノベーションラボの飯島です。

この度、2022/9/30 にクオカードを退職することにしました。 理由は転職です。 7 月末に実施された月 1 回のエンジニア全体振り返りでこの話をし、「退職エントリを書いてどこかに投稿しときます」といったところ、ノリと流れと目に見えない力で会社のブログに退職エントリを書くことになりました。

クオカードの良い点も悪い点も書いて欲しいとのことでしたので、それを踏まえて立つ鳥跡を濁さないような内容にしようと思います。

転職の理由

ベンチャー企業で働いてみたかったからです。

クオカードは設立から 30 年以上経っており、会社の制度もしっかり整っていて、もうずっと長く働いている人たちもいます。（かと言って悪しき文化に囚われ続けている訳ではなく、全社で Slack の導入が済んでいたり、コミュニケーションや文書のオープン化などの社内改革も実施されています）

転職先は設立から 2 年ほどしか経過していないので、会社の文化や雰囲気が全く違うんじゃないかな、と思っています。 そういった、今とは全く違う環境で働いてみたい、というのが大きな理由です。

また、バックエンドの開発言語も Kotlin から TypeScript になるので、自分が慣れ親しんだ Kotlin + SpringBoot ではない環境ではコードがどう変わってくるんだろう、という興味もありました。

転職の方針

以下のような方針で探していました。

ベンチャー（曖昧）
フルリモート
残業が無い、もしくは少ない
通話などの同期的な MTG が少ない
静的型付言語を主に使っている
提供しているサービスが面白そう

ちなみに働き方の面に関してクオカードはほぼ満たしています。 通話はもうちょっと少なくなれば良いなあと思っていますが、スクラムを導入しているのでイベントの為に割く時間は必要とも思っています。 参考までに、自分の 1 週間の通話時間はこれくらいです。

月 : 朝会 15 分
火 : 朝会 15 分 / スクラムイベント 約 2 時間 （2週間スプリントなので週ごとに変わる）
水 : 朝会 15 分 + 月末に一回 MTG 1 時間
木 : 朝会 15 分 + リファインメント 1 時間 + アーキテクチャ相談会 1 時間
金 : 朝会 15 分 + 月末に一回 MTG 1 時間

平均すると 1日 40 分ほどでした。

多分ですが、これってかなり短い方だと思うので、もっと短くしたいと言う自分の意見は結構わがままな気もしています。 また、毎週木曜日には外部から講師の方を招いたアーキテクチャ相談会が開催されています。サーバーサイドのアーキテクチャや DB 設計の相談をしてアドバイスをいただいたり、最近のエンジニア界の話題などを解説していただいており、とても参考になっています。 転職することでこの相談会に参加できなくなるのが残念です。

静的型付言語も結構重要なポイントとして見ていました。

あくまで自分の感覚ですが、動的に型付けされる言語だとテストが大変だったりエディタの補完がいまいちなイメージがあります。 そういった言語を触っていると頭がこんがらがってきてしまうので、コンパイラがある言語は必須条件でした。（Rust や Scala で求人を出している会社もあり、すごく魅力的で面談もしていただいたのですが、働き方の面でマッチせず何社か辞退しました。） クオカードはバックエンドに Kotlin、フロントエンドに TypeScript を使っているので、これも良いところだと思っています。

提供しているサービスに関しては、自分が今まで携わったことがないような分野や製品に関わりたいと思っていました。

転職活動

5 ヶ月くらいかけて、いろいろな会社の人に面談や面接をしていただきました。

全部で 10 社くらいだったと思います。

面談前に企業とチャットで会話できるサービスもあり、その段階でマッチするかどうか判断して面談に進まない選択もできたので、最近の転職サービスは凄いな、と思いました。

ここに書いて良いのか分かりませんが、クオカードは割と柔軟に1日の勤怠開始終了時刻を決められるので、8:00 - 16:30 に勤務し、30 分息をついて、17:00 - 18:00 で面談する、といった形で進められました。

転職活動後

ありがたいことに、帰ってきたくなったらいつでも帰ってきて良いよ、と言ってもらえました。

ただ自分は 35 歳までに飯島珈琲店を開くという昔からの夢があるので、もしそうなっていた場合はQUOカードPay 加盟店候補として営業にいくかもしれません。

よろしくお願いします。

あと事務手続き等でお世話になっていた S さんに転職の報告をしたところ、とても暖かい言葉をいただきました。

最後に

クオカードで働いた 3 年間で、エンジニアとして何段階も成長できました。 社内テトリス大会がコロナで開催中止になってしまったこと以外心残りはありません。 ありがとうございました。

AWS WAFをv2へ移行しました

デジタルイノベーションラボのIです。 今回はクオカードペイシステムのAWS WAFをClassicからv2へ移行した件について書こうと思います。

背景

クオカードペイではインフラにAWSを使用しており、外部に公開しているALBにはWAF Classicを適用していました。その名の通りこのWAFは旧世代扱いで、現在ではWAF(v2)の使用が推奨されています。

※ 正確には旧世代のWAFは「AWS WAF Classic」、現世代のWAFは「AWS WAF」という名称なのですが、わかりやすく区別するためにこのエントリでは現世代のWAFをAWSのAPIのように「v2」と呼ぶことにします。

botからのアクセスを弾くために、WAF bot controlを使いたいというのが移行を考え始めた直接のきっかけでしたが、更にカスタムレスポンス機能だったり、Log4jの脆弱性に対応したマネージドルールだったり、v2にしかない機能を使いたいというケースが増えてきました。

また今後もWAFの新機能はv2でしか実装されないと思われるため、このままClassicを使用していてはその恩恵も受けられません。

このような経緯でv2への移行を決めました。

移行方法

Classicからv2への移行にはAWS公式の手段が存在します。

—------------------------------------------------------------------------------------------------------------------------

1.自動移行では、既存のウェブ ACL に関連するすべての内容が読み込まれます。AWS WAF Classic で変更または削除される内容はありません。ウェブ ACL とその関連リソースの表現を作成します。この表現は、AWS WAF と互換性があります。新しいウェブ ACL の AWS CloudFormation テンプレートを生成し、Amazon S3 バケットに保存します。

2.AWS WAF でウェブ ACL および関連リソースを再作成するために、テンプレートを AWS CloudFormation にデプロイします。

3.ウェブ ACL を確認して手動で移行を完了し、新しいウェブ ACL が最新の AWS WAF の機能を最大限に活用するようにします

4.保護されたリソースを新しいウェブ ACL に手動で切り替えます。

—------------------------------------------------------------------------------------------------------------------------

上記引用の通り、既存のClassic ACLの各種設定をもとに、新規でv2 ACLを作成するCloudFormation stackがデプロイされます。

検証環境で一度実際に試してみた結果、主に以下の理由からこの方法は採用しないことにしました。

• 結局手動での追加作業が必要な部分が多い
• 新しく作成されるv2 ACLの名前を指定できない(どうやら、「<移行元Classic ACL名>+<自動で付与されるuuid>」となる様子)
• そもそもクオカードペイのAWS環境は基本的にTerraformで管理しているため、できるだけCloudFormationでのリソース管理は避けたい

よって、完全に一からv2関連リソースを新規作成することにしました。

ルール設定

移行前のClassicではAWS Marketplaceの「Fortinet Managed Rules for AWS WAF Classic - Complete OWASP Top 10」を利用していました。

v2ではそれに代えて、AWS標準のマネージドルールグループを使うことにしました。WCUを1500以内に収める必要があるため、以下のマネージドルールをACLに追加しました。

—--------------------------------------------------------------------

AWSManagedRulesCommonRuleSet
AWSManagedRulesKnownBadInputsRuleSet
AWSManagedRulesSQLiRuleSet
AWS-AWSManagedRulesLinuxRuleSet
AWS-AWSManagedRulesUnixRuleSet
AWS-AWSManagedRulesAmazonIpReputationList
AWSManagedRulesBotControlRuleSet

計1475WCU

—--------------------------------------------------------------------

また、IPセットも使用してIPアドレスでの制御も実施しました。これはClassicと大差ありません。

チューニング

AWS標準のマネージドルールは特にブラックボックス的なので、実際の動作をみながらのルールのチューニングが必須です。

まずは検証環境に適用し、また本番環境でもルールのアクションを最初はCount状態にして動作確認・ログ分析をしました。WAFのログ出力先はいくつか選択肢がありますが、今回は直接S3に出力してAthenaで分析することにしました。

確認の大きな観点は以下の2点です。

• 不正なリクエストをブロックできているか
• 正常なリクエストをブロックしてしまっていないか

WAFに期待しているのは当然前者の機能ですが、ある意味後者の確認のほうがより重要だと思います。正常なユーザアクセスに影響があっては本末転倒です。(実際、検証が不十分でトラブルを起こしてしまいました...)

ブロックの原因となっていたルールをログから特定し、ルールグループから除外しました。

まとめと今後の展望

以上、大まかではありますがWAFの移行に関して実施したことを記載しました。 そもそも移行元のWAF Classicのほうでも沢山のルール設定はしておらず、移行すべきものは少なかったため、実質一から構築したものの作業量はそれほど大きくはなりませんでした。もし複雑なルールを多数設定していたら移行ももっと大変だったと思います。

今後についてですが、現在は正常なリクエストが引っ掛かったルールはルールグループから単純に除外しているのみですが、特にWAF Bot Controlに関してはより細かい制御ができるので時機を見てチューニングをしていきたいです。

15分ルールを導入しました

デジタルイノベーションラボの齋藤です。

以下を参考に15分ルールを導入しました。

https://www.reddit.com/r/MachineLearning/comments/4w6tsv/comment/d6diast/?utm_source=share&utm_medium=web2x&context=3

内容は簡単にまとめると以下のようなものになります。

・何かわからない事があった時、最初の15分間自分で調べる ・もし15分間自分で調べて解決できなかったときは共有用のSlackチャンネルで状況を共有し、他のメンバーにヘルプを依頼する ・共有された問題に知見のあるメンバーがいたらヘルプする

導入の背景

チームで協力して仕事を進める形を目指していますが、他の人にヘルプを求めるのが苦手な人もおり、知見があるメンバーがいてもフォローすることが出来ない状況がありました。またそれによるスケジュール遅延も発生していました。

チームのルールとすることで、他の人にヘルプを求める敷居を下げ、チームで協力して仕事を進められるような形を目指しています。

現状はほぼフルリモートなので、申告が無いとそれぞれの状況が見えにくくなりがちな状況になっています。そのため、早めにアラートが上がる仕組みとしたいと思いました。

質問の仕方

以下のような情報を記載することでヘルプを受けやすくなると考えています。

・背景、文脈を記載する -> 何を実現したいのでその対応をしようとしているのかを記載する

・今までに何をしたか記載 ->どのような試行錯誤を行いどのような結果となったか、その際出力されたログがあればそれも共有する

デジタルイノベーションラボではチームで協力して開発を進めたいエンジニアを募集しています。

QUOカード Digital Innovation Lab.

リモートワークスタイルチェックをやってみました

デジタルイノベーションラボの齋藤です。

永和システムマネジメント アジャイル事業部さんがリモートワークスタイルチェックをやってみたという記事をアップされていました。ミスマッチを防ぐ為に良い取り組みだと思ったので、クオカード　デジタルイノベーションラボでもリモートワークスタイルチェックをやってみました。

永和システムマネジメント アジャイル事業部さんの記事

https://blog.agile.esm.co.jp/entry/remote-work-style-check-esm-2022

@mugi_uno さんのリモートワークスタイルチェック

https://gist.github.com/mugi-uno/a794bc199ce7d663f01a434a6e72504c

クオカードでは現在全社的にリモートワークを導入していますが、デジタルイノベーションラボとは少し状況が異なっている為、今回はデジタルイノベーションラボに限った形でチェックをしています。

リモートワーク比重度

リモートワークの導入期間

どの程度リモートワークを導入しているか (≒ 組織としてのリモートワークへの慣れ)

👉「4: 継続してリモートワークを3年以上導入している」

デジタルイノベーションができてからまだ5年経ってないので4になりました。ちなみに設立当初からリモートワークを導入しています。

リモートワークの導入ポリシー

👉「3: 恒久的な導入だが、根本的な制度変更が行われる可能性はある」

設立当初からリモートワーク前提の組織な為おそらく今後リモートワークができなくなる事は無いですが、変更が行われる可能性はゼロではない為3にしました。

リモートワークのマジョリティ度合い

👉「4: 全員が常にリモートワークの可能性がある（出社している可能性もある）」

全員が基本的にリモートワークですが、たまに会社で抽選で配るメロンやチケットなどが当選した場合など、稀に出社することがあります。

申請・許可の必要性

👉「5: 申請や許可は必要ない」

申請は不要です。

リモートワークの適用範囲

👉「5: 業務に関わる全メンバー（正社員以外も含む）がリモートワークを利用できる」

正社員以外も全メンバーリモートワーク利用可能です。

出社義務

👉「4: 年に数回の頻度で出社する必要がある」

入社日はPC等備品受け取りやセットアップの為に出社をお願いしています。

リモートワークで必要なサービス・アプリケーションの取り扱い

👉「4: 業務で利用するサービス・アプリケーションは主にリモートワークを前提としている。一部リモートワークでは利用できないものがあるが、リモートワーク前提のものに移行中・または移行予定がある、あるいは何らかの代替手段によってすべて解決できる。」

基本的にほぼリモートで対応可能ですが、バーコードの精度チェック機など、物理的なデバイスがオフィスにしか無いものも一部あります。

情報のアクセス範囲

👉「5: リモートワーク・非リモートワークでアクセスできる情報に差はない」

差はありません。

その他

✅社内において一定の権限を持つ人物（役員など）がリモートワークを実践している

❎5,000円/月以上のリモートワークに関する手当がある

❎オフィスが存在しない

❎対外的にリモートワークに関する発信・発表を積極的に行なっている

社長も実践しています。またリモートワーク手当は4,000円/月です。

リモートワークの文化

同期・非同期コミュニーションの割合

👉「B: 非同期コミュニケーションが中心だが、一部で同期的なコミュニケーションが必要」 👉「D: 同期的なコミュニケーションが主で、非同期コミュニケーションツールは補助的な利用のみである」 こちらはチームによって状況が違う為、BとDにしました。エンジニアはSlack中心ですが、込み入った話になった場合はMTGも行っています。

テキストコミュニケーションの割合

👉「B: テキストが主で、補助的にビデオ通話・音声通話を用いる」

一つ前の質問と同じですが、Slack中心ですが、込み入った話になった場合はMTGも行っています。

コミュニケーション頻度

👉「B: ミーティングに加え、それ以外でも日々活発にコミュニケーションを取る。雑談もそこそこ。」

毎日朝会を実施しており、それ以外でもSlackでコミュニケーションを取っています。雑談は多くは無いかもしれません。

働く時間

👉「B: 全員働く時間は定まっていないが、コアタイムなどで重なる時間が存在する」

コアタイムはありませんが、チームメンバーで朝会の時間を調整しており、その時間は重なっています。 現在は8:30から9:30の間に業務を開始する人が多いです。

最後に

結構積極的にリモートワークを実施しているのではないかと思います。リモートワークになってから他チームの人たちと雑談する機会がなくなったという声があり、課題になっています。

クオカード　デジタルイノベーションラボではソフトウェアエンジニアを募集しています。

OSSへの支援について

クオカードでは様々なOSSを利用していますが、現在は業務として技術的な貢献をする余裕が無い為、寄付という形で支援をすることにしました。

今回は社内の多くのプロジェクトで利用しているJUnit 5に寄付をしました。

https://junit.org/junit5/

今後もJUnit 5に限らず、できるだけ継続的に多くのOSSの支援をしていきたいと考えています。

クオカードではソフトウェアエンジニアを募集しています。

https://quo-digital.jp/