はじめに 対象読者 主なキーワード 共通ID基盤プロジェクトについて なぜプロジェクトを開始したのか？ 共通ID基盤構築の要件 共通ID基盤の技術選定 認証基盤に関連する技術群 どの技術を使うべきか？ アーキテクチャの検討 隠れたサービス要件の発覚 サービスに求められる要件について OIDCで必須のOPへのリダイレクト OIDCとサービス要件の不一致 別の方法を探る 1. 主力プロダクトをOPとする案 2. サービスのドメインを統合する 3. サービスをコードレベルで統合する 終わりに はじめに スマートキャンプ株式会社京都開発拠点では、自社開発プロダクトであるSaaSマッチングプラットフォーム「 BOXIL SaaS 」とオンラインイベントサービス「 BOXIL EVENT CLOUD 」の間でアカウントを共有する共通ID基盤の開発を進めています。 この記事では、その開発過程でOpenID Connect（OIDC）の採用を検討した結果と得られた知見について解説します。 具体的には、共通ID基盤の開発過程を時系列で紹介し、OIDC採用の検討過程、ビジネス要件との折り合いをつけることが難しかったこと、およびOIDCを使わないケースも含めたシングルサインオンの代替案についても触れます。 対象読者 ID基盤を作る際に、OIDCを導入しようか迷っている人 かつOIDCの基本的なことは理解している人 主なキーワード BOXIL SaaS : SaaSマッチングサービス。主力プロダクト。 BOXIL EVENT CLOUD : ビジネスのための情報共有の場としてのオンラインイベントプラットフォーム。 OpenID Connect（OIDC） : 認証基盤としての最有力候補技術。 シングルサインオン（SSO）: 一つのID（アカウント情報）を入力するだけで、連携する他のサービスにもログインできる仕組み。 OpenID Provider（OP）：OIDCにおけるユーザー認証のサービスを提供するサーバーまたはプラットフォーム Relying Party（RP）：OIDCにおけるユーザーの認証情報を利用するサービスやアプリケーション 共通ID基盤プロジェクトについて なぜプロジェクトを開始したのか？ プロジェクトの対象サービスがBOXIL SaaSというサービスと、BOXIL EVENT CLOUDというサービスであることは冒頭にお伝えしました。 BOXIL SaaSとBOXIL EVENT CLOUDとは、別々のサービスではありますが、片方はSaaSを導入したい／提供したい企業向けのマッチング、もう片方はイベント開催を通してビジネス上の知見・つながりを提供しています。 ですのでターゲットとする顧客としてはある程度重なる部分もあります。 現状ではそれぞれ独自の認証システムを持っているので、ユーザーは各サービスで別々に登録する必要があり、サービス間のデータ連携もありません。一方のサービスに登録しているユーザーに対して、そのデータを活用したもう一方のサービスで便利な機能を提供するなどの施策を簡単に提案できない状況でした。 このような課題を解消するため、共通ID基盤の導入により、一度登録すれば複数のサービスでアカウントを共有できるようにするプロジェクトがスタートしました。 ここで現状におけるサービスの簡単な構成図をお見せしておきます。 それぞれのサービスがユーザー情報を独立して持ち、認証も別々に行なっていることがわかります。 認証の仕組み(Before) では現状を踏まえたうえで、要件をまとめていく次のステップに移ります。 共通ID基盤構築の要件 チームでは、ビジネスサイドのメンバーとも話を進め、共通基盤に求められる具体的な要件をまとめていきました。 要件をかいつまんで説明すると下記のような内容になります。 ドメインの異なる2サービス（BOXIL SaaS、BOXIL EVENT CLOUD）でIDを統合して利用できるようにする もともとユーザー属性の近いサービスであるため、IDの一元化によりサービス間での相互送客を狙いたい 会員情報の二重入力や更新の手間を省き、サービスのUXを向上したい 各サービスのデータを紐づけたうえで、データ分析やマーケティング活動に活用したい 属性の近い別のサービスを将来的に連携する際のID連携の基盤を作る 新規サービスにおいても、既存サービスのユーザーを低コストで連携できるようにしたい 本プロジェクトでは上記の要件を満たすべく、まずは関連する技術選定から始めていきました。 共通ID基盤の技術選定 認証基盤に関連する技術群 今回のように異なるドメインのサービス間でのSSOを実現する際に、関連技術をいくつかピックアップし検討していきました。 以下に主要な検討技術をピックアップして簡単に特徴を説明します。 OIDC OAuth2.0を拡張し、認証にも利用できるようにしたプロトコル IDトークンを用いて認証をして、UserInfoエンドポイントからユーザーのプロフィール情報を取得する 異なるドメインのサービス間でのSSOが実現できる データのやり取りはJSON形式で行なう OAuth2.0 認可のためのプロトコル（認証ではない） この仕様で認証を賄うには独自に拡張を行なう必要があるが、リソースサーバーから提供されるプロフィールAPIを用いての認証の方法には脆弱性があり、拡張の際にはセキュリティなどのリスクに特に気をつける必要がある データのやり取りはJSON形式で行なう SAML 異なるドメインのサービス間でSSOを実現できるプロトコル SAMLは独自に定義された認証規格であり、OIDCがOAuth 2.0に基づいているのとは対照的 SAMLはXML形式でデータをやり取りする 独自構築 規格には属さないものの、完全に独自で認証システムを設計する選択肢も存在します。この方法は、特定の要件に対してもっとも柔軟に対応できる点が強みです。しかし、OIDCなどセキュリティも考慮された規格とは異なり、セキュリティリスクも自分たちで考慮の上仕様を決める必要があるため、その点で難易度が高いと言えます。 さらに、この手法は既存のライブラリや参考資料が少ないため、構築と運用のコストが他の方法よりも高くなる可能性があります。 どの技術を使うべきか？ チームでは、先にまとめた既存規格の技術、独自認証などの特徴と、求められる要件を考慮したうえで検討した結果、今回の共通ID基盤プロジェクトにおいては第一候補としてOIDCを採用することになりました。 選定の際に考慮した点については下記の通りです。 社内のスキルセットとのマッチング OIDCはOAuth2.0の拡張であり、基本的なフローはOAuth2.0とほぼ同じであること 既存プロダクトではOAuth2.0の導入実績があり、社内で知見がある程度蓄積されていること 低い複雑性 SAMLよりもプロトコルがシンプルで、仕様自体の見通しが良いこと 走り出しから継続して検討をしながら進めていくような今回のプロジェクトには、シンプルであることがプラスで働くこと 将来的に新しいサービス連携することを考慮したときに、スピーディに連携できそうなこと セキュリティの考慮 IDトークンの署名・暗号化や、 PKCE （Proof Key for Code Exchange）など、多くのセキュリティ機能とベストプラクティスが組み込まれており、必要十分であること ライブラリの充実 標準化され多く利用されている規格であるため、既存のライブラリやツールのサポートが豊富で、設定例やドキュメントも充実していること 基盤のベースの技術としてOIDCを採用したので、それを前提としてシステム構成を考えていきます。 アーキテクチャの検討 次にOIDCを前提として、共通ID基盤を入れたときのサービス全体のアーキテクチャを検討しました。下記に簡略化した構成図を掲載します。 現状のシステム構成図は「 なぜプロジェクトを開始したのか？ 」の章を参照してください。大きく変わったところは下記です。 認証を担う機能を共通ID基盤として新たに構築する BOXIL SaaS、BOXIL EVENT CLOUDでそれぞれ持っていた認証の実装を、共通ID基盤のOIDC経由で行なう実装に置き換える。 各サービス上にあるユーザー情報のうち、認証に使う情報を中心に共通ID基盤に移す。（それ以外の多くのサービス固有のユーザー情報は据え置き） 認証の仕組み(After) OIDCの観点だと、BOXIL SaaS、BOXIL EVENT CLOUDの各サービスはそれぞれRPとなり、新しく作る共通ID基盤はOPとして振る舞う形になります。 隠れたサービス要件の発覚 チームでは、作ったアーキテクチャの想定を元に、実際にOIDCを使ったときに具体的にどのような画面遷移になるだろう？実際のUXはどうなるだろう？といったユーザー観点での調査を重ねて、ビジネスサイドとも話を進めていきました。 サービスに求められる要件について ところで、BOXIL SaaSでは、さまざまな施策を通じて会員の獲得効率（CVR）を最大限に高める戦略を採っています。たとえば、資料請求フォームの入力後に会員登録処理と並行してログインができるよう実装したり、EFO（Entry Form Optimization）によるUXの最適化に重点を置いています。 今回のプロジェクトでも、会員登録の手間を減らしてUXを向上したり、サービス間での相互送客を実現するなどの目的がありますが、実際問題としてはCVRを損なわないという前提条件下で考慮される必要があります。 ただ、この要件は事前に明文化できていたわけではなく、チーム間で明確に認識の形成ができずにプロジェクトが進行して、徐々に懸念が強く浮き彫りになってきたという感じでした。 OIDCで必須のOPへのリダイレクト OIDCの仕様の中にはいくつかの認証フローが定義されていますが、特に今回採用を予定していた認可コードフローにおいては、"OPへのリダイレクト"という仕様があります。 下記のシーケンス図をご覧ください。 シーケンス図 認証の開始時にRPであるBOXIL SaaSから、OPである共通ID基盤にリダイレクトされ、認証が完了した後にOPからRPに認可コード付きでリダイレクトされて戻ってくる流れがあることがわかります。 このリダイレクトはOIDCの仕様上重要で、RPとOP間の疎結合性を保つことで、安全に認可コードをRPに渡すことを実現しています。 OIDCとサービス要件の不一致 さて、前述したように、BOXIL SaaSとしては会員獲得におけるCVRに影響を与える変更は極力避けたい事情がありました。プロジェクトチームでは、OIDCのリダイレクト仕様がBOXIL SaaSのCVRにどのような影響を与えるかを慎重に考察しました。 結果、リダイレクトを入れることで会員登録やリード獲得のプロセスに影響が生じ、ユーザーが外部の認可エンドポイントへ移動することで、会員獲得の動線が分断されて、CVRやEFOによるユーザー動線の最適化にも悪影響を及ぼす懸念が出てきました。 それを避けるために、なんとかリダイレクトしつつも極力CVRに影響を与えない次善策を含め、調査と検討を重ねたのですが、決定的な策が提案できず、最終的には独立した共通ID基盤経由でOIDC認証をする構成を採用しない決断をしました。 高い自由度のUXを確保するために、OIDCのリダイレクト要件は今回のプロジェクトには合わないと判断したのです。 別の方法を探る では、前述した「リダイレクトしたくない」というビジネス要件と、「リダイレクトが必要」というOIDCの仕様を受けて、どういった意思決定をすべきでしょうか。 私たちが現状調査・検討してきた案をいくつかご紹介します。 BOXIL SaaSをOPとする案 サービスのドメインを統合する サービスをコードレベルで統合する なお、この記事を執筆時点では、目下、案の検討を進めている途中のため、どれを採用したのかは言及しません。どの案もUI/UXへの影響や、開発・保守運用工数への影響などなどトレードオフがあり影響度も大きいため、慎重に検討を進めていく必要があります。 また考えるうえでは、短期的なメリット、中長期的なメリットなど時系列も含めて議論が必要と考えています。 以下にそれぞれを簡単に紹介します。 1. 主力プロダクトをOPとする案 認証の仕組み(BOXIL SaaSをOPとする案) この案はOIDCの認証を管理するサーバー（マイクロサービス）を新規で開発・運用するのではなく、考慮すべきビジネス要件が多いBOXIL SaaSをOPとして振る舞わせ、BOXIL EVENT CLOUDはRPとしてそのエンドポイントを利用する形です。 そうすることでBOXIL SaaSでは従来の会員登録のフローを変更する必要がなくなるため、ネックだったリダイレクトの影響に対する懸念は考えなくて良くなります。 デメリットとしては、認証機能自体のBOXIL SaaSへの依存が強くなってしまうため、連携するサービスの負荷でBOXIL SaaSも影響を受けてしまったり、例えばBOXIL SaaSがクローズする際に連携サービスが影響を受ける可能性などがでてきてしまいます。 また、この案は一度しか使えず、今後連携するサービスでは通常のOIDCによるリダイレクトが強制される形になります。 以降の案はOIDCを使わない案です。 2. サービスのドメインを統合する 一方のサービスのコードベースを、もう片方のドメインに丸ごと移すやり方です。 認証の仕組み(サービスのドメインを統合する案) 例えば、BOXIL SaaSは現在 boxil.jp 、BOXIL EVENT CLOUDは boxil-event-cloud.jp でホスティングしていますが、これを boxil.jp 、 event.boxil.jp に変更すれば、サードパーティクッキーの制限がなくなります。 片方でログインして、もう片方のサービスとログインセッションを共有することも技術的に可能になります。 3. サービスをコードレベルで統合する これはできるケースが限られると思いますが、もし連携するサービスのビジネスドメインや会員属性が近く、数が多くない場合は、サービス自体を一つのコードベースに統合する案も考えられそうです。 認証の仕組み(アプリケーションをコードレベルで統合する) 当然ながら自由度は非常に高いですが、引越しする側のサービスについてゼロベースに近い開発が必要になるため、完了までにかかるコストや、統合にあたっての双方のデータスキーマの見直しなど、多岐にわたる検討が必要になります。 終わりに 本プロジェクトの開発過程では、技術選定だけでなく、ビジネス要件との整合性も重要であることが明らかになりました。OIDCは多くの場合に有効な技術ですが、それありきで進めるのではなくUXとビジネス要件をしっかりと両立させ、最適な技術選定と実装を広い視野で追求していく必要があることを今回学ぶことができました。 この記事が皆さまの参考になれば幸いです。

UNIXという考え方 スマートキャンプでエンジニアマネージャーをしています林です。 私はエンジニアマネージャーをやっているのですが、エンジニアではありません。 マーケターとしてスマートキャンプに入社し、マーケティングの成果を最大化するためにディレクターの立場でプロダクト改善を行ううちに開発チームのマネージャーになったという経歴です。 tech.smartcamp.co.jp 非エンジニアがエンジニアのマネジメントをするにはエンジニアについて学ばなくてはいけないことが多々ありますが、私が色々と学んできた本の中で、 特に役に立った書籍 を紹介していこうと思います。 「UNIXという考え方」 この本をオススメする対象者と読むメリット この本を読んだ背景 本の内容・構成・読みやすさ 私視点で学びになったポイント3点 ①「スモール・イズ・ビューティフル」 ②大きな一まとまりをつくるよりも、分解した小さなシステムを連携させるほうが応用がきく ③できるだけ早く試作を作成する この本を読んで役立った事 まとめ 「UNIXという考え方」 この本をオススメする対象者と読むメリット 今回ご紹介する本は、私のようなマネージャーだけではなく、 エンジニアと一緒に仕事をする人 なら読んでみるととても参考になる本だと思います。 サブタイトルにある通り、UNIXの設計思想と哲学について解説した本なので特定のOSについて語ったものではあるのですが、そこには良いプログラムとはどういうものなのかという事など、プログラミングについての本質が書かれているように思います。 これらの内容はエンジニアの考え方を理解するのに一役買うと思いますし、想像力を膨らませて応用すれば、エンジニアでなくても自分自身の業務の改善に役に立つ要素が多く見つかると思います。 厚さは1cmないくらいで140ページ程の読みやすいボリュームの本なので、ぜひ読んでみてください。 この本を読んだ背景 この本は、弊社のエンジニアチームのメンバーに勧められて読みました。 私が大好きな経営者に、ミスミグループの社長をされていた三枝匡という方がいます。その方の書籍のなかで、事業組織はなるべく小さくあるべきという意味合いで「スモール・イズ・ビューティフル」という言葉が語られていますが、その話をしている時にこの本を紹介されました。 「エンジニアも同じ考えを重要視している」という文脈で、その詳細が書かれた本として教えてもらいました。 本の内容・構成・読みやすさ この本では、上で紹介した「スモール・イズ・ビューティフル」だけではなく、プログラミングの根幹になるような考え方が様々紹介されています。 本の構成は、まず冒頭で主要な項目の概要の説明があり、次の章から項目のそれぞれについて詳しく紹介していく形になっています。 内容としては、UNIXの考え方として「教義にも匹敵する」と表現される程重要視される9つの項目と、「UNIX文化の一翼を担っている」と表現され、人によっては重要度に差がでるものの重要と考えられている10項目があります。それらの項目１つ１つについて、章やセクションを分けながら詳細に説明がされていきます。 最後にはその他のOSの思想についての説明があります。 このセッションがあることによって、相対的にUNIXについて考える事ができる構成になっていて、非常にわかりやすいですし、興味深く感じました。 構成は非常にわかりやすいですし、文章も著者の経験に基づく事例を交えながらフランクに語られている印象で、肩肘張らず読む事ができると思います。 私視点で学びになったポイント3点 ①「スモール・イズ・ビューティフル」 冒頭で三枝さんが事業組織について同じことを言っているという話をしましたが、この本を読んで、「スモール・イズ・ビューティフル」は真理だなと再認識しました。 小さく分解して考え動かす事はマーケのタスクでも応用可能です。 例えばEFO(入力フォーム最適化)のためのABテストをするとき、フォームの配置の問題、フォームの入力補助の問題、誘導文言の問題、背景色の問題など切り分けてテストすると、どの項目がどれだけ影響を与えるかが明確にわかり改善PDCAを回しやすくなります。 何か施策を考える時に、最小単位に分解できているか？と考える事 は施策の精度をあげるのに貢献してくれます。 ②大きな一まとまりをつくるよりも、分解した小さなシステムを連携させるほうが応用がきく スモール・イズ・ビューティフルに関連する内容ではありますが、 小さな単位で作ると組み合わせでいろんな事ができる というのも真理だなと思います。この内容は、なんとなくそうだと思っていたものが言語化された感覚でした。 私でいうとこれはKPIをメンバー毎に振り分けていく時の考え方に近いと思います。大きくざっくり「みんなでこのKPIをおう」みたいな設定をしてしまうと、役割分担が不明確でメンバーが力をだしきれなかったり、終わった時に評価ができないという問題がおきます。 KPIも適切に分解し、そのKPIを追う人が結果をコントロールできる単位にすることが重要です。そのためKPI設計時に上記の考え方をもっていると、よりシャープに設計ができると思います。 ③できるだけ早く試作を作成する リーンスタートアップなどの書籍によって、今やアーリーリリースの重要性は多くの人が認識している状態だと思いますが、数十年前に既にそれが設計思想として定着していた事は驚くべき事だと感じました。 長く生き残っているものの根本思想はやはり優れている（先をいっている）と感じさせてくれ、そういうものから学ぶ事の重要性を再認識させてくれました。 できるだけ早く試作を作成する事自体は私は常に取り組んでいかないといけない事ですが、タイミングによっては徹底できてない事もあります。この件についてはしっかりと意識し、引き続きやっていきたいと思います。 この本を読んで役立った事 エンジニアを理解するという方向で役立った事としては、『 エンジニアの頭の中がどうなっているか 』を想像しやすくなった事があります。 日々の会話のなかで、「要素を小さく分解してるんだな」とか、「過去のプログラムを組み合わせて活用する事を考えているんだな」とかいう想像がついたり、よく言われる「闇」という状態が何となく想像できたりして、この本を読んだことでよりコミニュケーションがとりやすくなったと思います。 またリファクタリングの重要性や価値についてより理解できるようになるので、その工数を取りたいというエンジニアの要求についても合理的に理解できるなどしています。 根本思想を理解することができると、大枠何が正しくて何が間違っているかが判断できるようになり、そのレイヤーでは 共通認識を持つことができます 。それによるメリットはかなり大きいと感じています。 まとめ この本は、エンジニアの考え方について理解する上で非常に役に立つ本です。 また概念を応用することで、私でいえばマーケティングなど、エンジニアリング以外の業務に役立てる事もできると感じます。 エンジニアを理解する上でも、ご自身の仕事の上でも実用的な本だと思うので、ぜひ一読される事をおすすめします。

本記事は、 一休.com Advent Calendar の23日目です。 宿泊事業本部フロントエンドエンジニアの宇都宮です。 先日(12/19)、一休の宿泊予約サービス（以下、一休.com）のスマホ版の予約入力画面リニューアルをリニューアルしました。本記事では、 どのような方針で どのような技術を使って どのような設計で どのように実装していったか を紹介します。 Before/After リニューアル前 ファーストビュー エラー通知 次の画面へ進む前に、alert() リニューアル後 ファーストビュー エラー通知 項目の上に表示&自動フォーカス 主な変更点 デザインの刷新 エラー通知の改善 クレジットカード入力画面、オプション注文画面の統合 実装面では、ASP.Net Web Formsのユーザーコントロールを大幅に削り、Vue.jsのコンポーネントに置き換えました。 以前の画面の課題 リニューアル前の予約入力画面には、いくつかの課題がありました。 UIが使いにくい　特にエラー通知が不親切 画面の表示が遅い（サーバサイドで大量のデータを読み込んでいるため） ユーザーコントロールの変更が難しく、生産性が低い エンジニアの観点からすると、特に生産性の低さが気になっていました。ユーザーコントロールとはASP.Net Web Formsフレームワークの機能で、再利用可能なコンポーネントを定義する機能です。 ユーザーコントロールは、上手に活用すれば生産性を向上させる機能だと思いますが、残念ながら一休の予約入力画面では、生産性を低下させる原因となっていました。というのも、数千行規模のユーザーコントロールが複数存在し、それぞれが密結合していたのです。 4月に、フォームの入力欄の順番を入れ替える作業を行いました。表面上は簡単な調整で、普通のHTMLなら30分でできそうな作業でしたが、実装1日+テスト0.5日という工数を費やす必要がありました。 あるユーザーコントロールから別のユーザーコントロールに入力欄を移動するには、その入力欄のために定義されているフィールド／プロパティやメソッドを、まるごと別のユーザーコントロールに移す必要があったためです。 ↓は当時のプルリクのスクリーンショットですが、3項目の移動で+3,571 −166という大きなdiffが生じています。 また、予約入力画面のaspxファイルは単体で5,000行（※）ほどあり、ファイル内で行きつ戻りつするのも非常に大変でした。 ※：JSが3,000行、残りはHTMLとASP.Netのコードナゲット このような理由から、予約入力画面のリニューアルを検討しました。 リニューアルの方針と実装 スコープ 予約の画面は膨大な業務ロジックに支えられているため、実装工数が膨らむことは避けられません。そこで、以下のようにスコープを限定して進めました。 対象はスマホ版の予約入力画面のみ PC版や、スマホ版でも予約確認画面や完了画面には手をつけない サーバサイドの業務ロジックにはできるだけ手をつけない。レスポンス速度の改善はスコープ外 技術選定 予約入力画面のリニューアルでは、EFO(Entry Form Optimization)の観点から、JavaScriptでリッチなエラー通知を行うことを目指しました。あわせて、開発者の生産性を向上させる必要性も感じていました。そこで、JavaScriptフレームワークのVue.jsを導入しました。 既存の画面で使用しているjQueryではなく、Vue.jsをメインに据えた理由は、生産性が大きな要因です。Vue.jsの 単一ファイルコンポーネント を使用すると、画面上の要素（コンポーネント）ごとに、関連するロジック(js)とスタイル(css)をひとまとめにすることができます。コンポーネントを小さく保ちながら実装を行えば、コードのメンテナンス性を大きく向上させることができると考えました。 実装 Vue.js + Vuex + VeeValidateというスタックで実装を行いました。 Vuex を導入するかは迷いましたが、予約入力画面で使用する膨大なデータを一元管理できるのは大きなメリットでした。 VeeValidate はpluggableな構成になっていて、独自のバリデーションを簡単に定義できるようになっているのが良かったです。 テストには vue-test-utils を使用しています。Vueコンポーネントのテストは一部のメソッドと算出プロパティだけで、レンダリングのテストは行っていません。 現在のところ、コンポーネントの構成は以下のようになっています。 大枠から作っていって、徐々にコンポーネントを分割していくという方針を採ったため、コンポーネントの粒度は大きめです。また、本来はコンポーネントにすべきなのに、コンポーネント化できていない部分もあったりします（たとえば、お知らせメール受信設定）。 目安として、.vueファイルが100行を超えたらコンポーネントを分割できないか検討するようにしていました。最も大きなコンポーネントで.vue 200行 + .js 300行ほど、平均的なコンポーネントのサイズは100行程度に抑えることができたため、コードの見通しはかなり良くなりました。 また、以前は5,000行ほどあった予約入力画面のaspxファイルは、リニューアルによって200行にまでスリム化しました。 残る課題 本ページのリニューアルに関しては一区切りというステータスですが、以下のような課題が残っていると認識しています。 一休.com全体でのデザイントーンがバラバラ 画面の表示は相変わらず遅い コンポーネントの粒度はもう少し細かい方がよさそう JavaScriptの単体テストが不足している CSS Modules がまだ使いこなせてない デザイン面の課題はデザイナーと協力して、プログラムの課題は他のエンジニアとも認識を合わせながら、引き続き改善していきたいと考えています。 明日はzimathonさんの「開発組織の目的型組織への移行」です。