この記事は株式会社エス・エム・エス Advent Calendar 2023の13日目の記事です。 qiita.com はじめに 介護事業者向け経営支援サービス「カイポケ」のQAを担当している中村です。2021年10月に入社して早2年、現在ではQA組織の運営や横断的に複数QAチームに関わりつつ、チームのサポートや改善活動の推進など様々なことを担当させてもらっています。 今回の記事では改善活動で実施した施策の一つである、『E2Eテスト自動化の導入』をテーマにどんなテストを自動化しているか？どんな運用をしているか？など、現状を整理する形でお話ししていきたいと思います。ここでお話しするのはあくまでQAエンジニアの取り組みの事例で、開発エンジニアが実施しているUT（ユニットテスト）などの自動テストは触れませんのでご了承ください。 テスト自動化のお話し 1. どんなツールを使っているのか？ 弊社では MagicPod というノーコードのテスト自動化ツールを使用しています。ツール選定の主な理由は以下の通りで、約2年ほど使い続けています。 プログラミングスキルが不要で開発未経験でも導入が容易 テストの実行回数に制限が無く費用を気にせず繰り返しのテストが可能 ローカルPC上でテスト実行が出来るのでプロキシサーバーを介してWEBアクセスが可能 SaaSサービスなので環境構築、保守の手間が不要 2. どんなテストを自動化しているのか？ 担当している「カイポケ」では、主にWEBとネイティブアプリ(iPadOS)にサービスを展開しています。現状はWEBを対象にE2Eテストの自動化を進めていて、メンテナンスコストが掛からないように機能や画面に変更が入りにくい部分のリグレッションテスト（機能の追加や改修が入った際、既存機能に問題が起きていないかを確認するテスト）を対象としています。全機能を網羅するとテストケースが膨大になるのでハッピーパスなどの基本機能のテストに絞っていて、バグを見つけると言うよりはシステムが問題なく動作することの確認を目的としています。 3. どんな工夫をしたのか？ 過去の経験から実装/メンテナンスコストの増加、属人化、テストの安定性といったところの課題を感じていたので、以下の取り組みをすることでよりスムーズに導入出来るように進めていきました。 テスト実装/メンテナンスコストの削減 MagicPodが提供している以下の機能を活用して実現しています。 共有ステップ（共通化） 複数のテストで使う処理は基本的に共通化 参考： 共有ステップの活用 変数 テストケースやテスト環境によって値が変わるデータやロケーターは変数を使用 参考： 変数の活用 データ駆動テスト 計算結果を確認するようなテストでは、同じテストケースでデータパターン（入力値や期待値）を変えて繰り返し実行をしている 参考： データパターン(データ駆動テスト)の活用 属人化対策 実装者によってテストの書き方が大きく変わらないことや導入がスムーズに行えることを目的とした、実装方針や最低限のルールを記載した手順書を用意しました。以下は手順書の記載例となります。 共通化、変数の使いどころ テストの組み込み方法 コメントの使い方 命名規則（テストケース、共有ステップ、ロケーター） ロケーターの指定方法 テスト実行の安定化 テストの独立性 基本的に他のテストの影響を受けてテストが失敗することを防止するために、テストケース同士の依存関係は無くして、各テストケースが独立して動くように作成しています。また、テストを再実行した際にクリーンな状態でテストが行えるように後処理（テスト中に登録したデータの削除など）を実施しています。 リトライ 不具合ではなくタイミングや不確定要素によるテストの失敗は自動テストのあるあるなのですが、都度テストを再実行するのではなくMagicPodが提供しているリトライ機能を使って自動で再実行する仕組みを取り入れています。途中でテストが失敗した場合に元の状態からテストが出来るように初期化（テスト中に登録したデータの削除など）も実施しています。 実行環境を仮想環境に移行 主にローカルPC上でテスト実行をしているのですが、ブラウザの操作をツールに奪われてしまうので作業が中断してしまう、リモートワーク主体の中でも安定したネットワーク接続が必要（瞬断でもテストが止まってしまう恐れあり）といった課題があり、それに対応するためにテスト実行環境を仮想環境に移行し安定して動作するようにしました。 4. どんな運用をしているのか？ 現状はシステムに改修が入った場合やミドルウェアのバージョンアップが入った場合などに自動テストを実行するようになってきて、活用する機会がかなり増えています。簡易的な動作確認であっても、今までは時間をかけて手動で実施していた or 時間の都合により割愛せざるを得なかったのですが、素早く人の手を介さずに毎回テスト出来るようになったことで、より品質に自信を持って高速リリースが出来る状態となったのは大きな利点だと考えています。 5. 現状の課題は？ 上述したとおり導入は進められているのですが、課題もまだ残っていて現在進行形で進めている点や今後実施予定としている点をいくつか紹介していきます。 他チームへの拡張 現状は特定のチームでのみ導入が進んでいる状況です。人的リソースやスキル的な課題もあって十分に導入が進められていないのですが、リグレッションテストの使用頻度はどのチームでも高いので少しずつ範囲を広げていきたいという思いがあります。 定期実行の導入 定期実行自体はMagicPodの機能として提供されているのですが、「クラウド」実行のみ使用が可能となっています。前述した通り、弊社は「ローカルPC」での実行をメインとしているので、定期実行を実現するには自前で仕組みを作る必要があるのですが、まだ手を掛けられていないという状況です。 テストの高速化 テストケースが増えたり長くなると、相対的にテストの実行時間が増えてくるといった課題が出てきています。テストケースの見直しや並列実行の仕組み化などやれることがありそうなのですが、こちらもまだ手を掛けられていません。 さいごに 前述の課題対策に加え、開発チームとの協業/分担なども考慮したテスト自動化の最適化も必要になりますし、並行して始まっているリニューアルプロジェクトへの本格導入とまだまだ先は長いです。テスト自動化に関わる人手も今以上に必要になってくることを想定していますので、一緒に働く仲間は絶賛募集中となっています！ 最近QA組織の行動指針なるものを構築したのですが、テスト自動化もその中の取り組みの一つとなっています。そちらのブログも合わせて確認していただけると、QA組織の目指しているものがより見えてくるのではないかと思います。 tech.bm-sms.co.jp 少しでも興味を持たれた方がいたらカジュアル面談や選考へのご応募をよろしくお願いいたします。 エス・エム・エス-エンジニア採用情報 ソフトウェアエンジニア カジュアル面談(PM/EM/SRE/QAも歓迎)

この記事は 「株式会社エス・エム・エス Advent Calendar 2023」 の12日目の記事です。 こんにちは、Analytics&Innovation推進部（以下、A&I推進部）の小貝（ @oddgai ）です。 M-1グランプリの決勝が近づいてきて、今年ももう終わりか〜としみじみしています。 今年は夫婦で真空ジェシカ、令和ロマン、ヤーレンズ、敗者復活でななまがりを応援しています。がんばれ！ さて、社内のデータ活用チームであるA&I推進部にデータサイエンティストとして新卒入社して4年目になるのですが、今年の4月から 「カイポケ」のフルリニューアルプロジェクト のエンジニアチームに社内留学してアプリケーション開発も行っています。12月時点だとデータサイエンティスト1割、エンジニア9割くらいの割合で働いています。 この記事では、今年を振り返って なんで/どうやって社内留学したの？ 開始から今までにやってきたこと やってみてどう？ あたりをまとめようと思います。 なんで/どうやって社内留学したの？ 社内留学した理由を一言でまとめると、 今後のキャリアや社内での役割を見据えて、ソフトウェア開発の基礎的な経験を積んでおきたかったから です。これだけ書くと立派に見えますが、もう少し心の内をさらけ出して書くと下のようになります。 研修などでソフトウェア開発の体系的な知識を付けないまま新卒4年目まで来てしまい、 「同世代のデータサイエンティストが当たり前に知っているであろうことを知らない気がする」という焦り があった データサイエンティストとしてエンジニアとやり取りすることも多いが、あまり勝手がわかっていなかった 数理最適化や機械学習などのモデルは最終的に何らかのシステムに組み込まれることも多いので、ソフトウェア開発の知識や経験があったほうがいい 大きな環境の変化がないまま4年目になり若干だれてきた感があったので、何かしらの外的変化がほしかった このようなもやもやがあったので、3年目の終わりの考課面談で上長に相談してみました。周りに社内留学をした人がいなかったのもあり、このときは留学という発想はなく「何かしらの研修を受けさせてもらえたらいいな」くらいの気持ちでした。 そこからあれよあれよという間に話が進み、気づいたらエンジニアチームにいました。裏ではいろんな人が動いてくれていたのだと思いますが、私目線だと下のようなスケジュールになっていて、このときは正直このスピード感に心が追いついていませんでした。 2023/3/8: 考課面談で「開発経験が積みたい」と相談する 2023/3/24: 技術責任者の田辺さん（ @sunaot ）と面談して社内留学ができる説を知る このときは「やるにしても半年後くらいでしょ」と思っていた 2023/4/24: 受け入れ先チームの空中さん（ @soranakk ）達と面談する ここで「アッこれすぐの話なのか」と気づく 2023/4/28（その4日後！）: チームのモブプログラミングに参加して、以降ほぼフルコミット 開始から今までの振り返り こんな感じでいきなり始まった社内留学ですが、現時点で開始から7ヶ月くらいになるので、今までをざっくり振り返ってみます。 開始〜1ヶ月目：プロジェクトのことを知る期 最初にプロジェクトやチームに関わるいろんなドキュメントをもらったので、そのインプットから始めました。カイポケがリニューアルするのは知っていたのですが、その背景や具体的にやっていることまでは把握していなかったので、そこを埋めるようにドキュメントを消化していきました。 介護業界に関わるドメイン知識などはすでにあって、それに関するつらさがほぼ無かったのは社内留学のいいところだなと感じています。 ちなみに当時の私はこんな資料を残しています（A&I推進部内での報告資料です）。右下のE資格というのは日本ディープラーニング協会が実施している資格試験のことで「開発の勉強もしたいけど資格対策もしないと〜〜〜」と大変な状況でした。がんばれ！ 2〜3ヶ月目：バックエンドがんばる期 プロジェクトやチームの動きがある程度わかったところで、実際の開発タスクに手を付け始めます。 ちょうどその頃に着手予定になっていたバックエンドAPI実装をやったのですが、KotlinやSpring Bootを触ったことがなかったので、モブプログラミングで大いに助けてもらいながらなんとか実装しました。 モブプロはオンボーディング関係なくほぼ毎日やっているのですが、これが経験の浅い私にとっては本当にありがたくて、開発の勉強になるだけでなく「昨日〇〇がおいしかった」などの雑談も挟まるため チームの一員になっている感 があり、何もわからん状態だった私は精神的に救われました。やはり雑談は大事。 このAPI実装が終わった後に、チーム全体で別チームのバックエンド開発を手伝うことがあったのですが、そこまで難しくないタスクだったこともあり基本的には独力で進めることができて「なんかイケてるぞ」という自信に繋がりました。 また、この時期にはデータサイエンティストとして、求人のレコメンドAPI開発のプロジェクト管理もしていました。その際、エンジニアチームに依頼してAPIをサービスに組み込んでもらうタイミングがあったのですが、前よりもエンジニアの気持ちがわかるようになっていたからかスムーズに依頼ができて「 データサイエンティストとしてのスキルアップにも繋がってるぞ！ 」と嬉しくなりました。 ちなみに当時の気持ちはこんな感じだったようです。えらいぞ！がんばれ！ 4〜6ヶ月目：フロントエンドも触ってみよう期 バックエンドがチョットワカルようになってきたので、フロントエンドにも手を出し始めます。 最初は、当時タスクとして挙がっていた氏名入力フォームなどでの姓名分離（バックエンドは対応済みで、画面側の対応）をやりました。 ここでStorybookやChromaticに初めて触れたのですが、「画面がチェックできる！！すごい！！」と感動しました。成果物として実際に動く画面が見られるのは楽しいです。 次に手を出したタスクが当時の自分としてはやや難しく、というのも 最初の仕様ではそこまで難しいタスクではなかった 途中から仕様変更があり、チーム内で触ったことがないコンポーネントを扱うことになった 🤯🤯🤯 という変貌を遂げたもので、フロントエンドチームにも助けてもらいながらなんとか終えることができました。今振り返ると、デザイナーや別チームのエンジニアとやり取りしながら開発する経験ができたのでとても良かったです。 7ヶ月目〜現在：どんどんタスクを拾っていこう期 バックエンド、フロントエンドともに何となく進め方がわかってきたので、引き続き助けてもらいながらもどんどんタスクを拾っています。 積まれているタスクをやるだけでなく「ここの画面ちょっとおかしいですね→後で直しておきます」のような動きもできるようになり、「 俺は！！エンジニアとして働いているぞ！！ 」という実感があって楽しいです。 一方で、個々の開発タスクで得た知識や経験を有機的に結びつけられていない感覚もあるので、改めて体系的に基礎を学びたいです。 まとめると今の気持ちはこんな感じです。いいぞ！ やってみてどう？ 最初は「開発のことなんもわからん」「チームの雰囲気に慣れない」などで大変でしたが、振り返ると本当に良い経験をさせてもらっているなと思います。 具体的に良かったことは挙げるときりがないのですが、ぱっと思いつくだけでこのくらいあります。 経験が浅いところからのスタートというのもあって「先週できなかったことが今週はできるようになっている」が続いて楽しい データサイエンティストとしてのスキルアップにも繋がっている 社内でカジュアルにコミュニケーションできる人が増えて嬉しい モブプロ や 社内版potatotips などの文化がとてもよい エンジニアとの距離が縮まりテックブログへの投稿が増えた このアドベントカレンダーもそうだし、去年なら 「学会に出るから発表資料を公開しよう！」 という発想にはならなかった気がする 外からは見えにくいエンジニアの大変さがわかって、もっとリスペクトが湧いた いつまで社内留学を続けるのか具体的なスケジュールは未定ですが、もっとエンジニアとしてのスキルを伸ばしたいのと、このプロジェクトにもう少し関わっていたいので、もう少し続ける予定です。 おわりに 改めて振り返ると、慌ただしかったですがとても良い刺激を受けた1年でした。 最後になりますが、社内留学のために動いてくれた方々や、日々助けてもらっているチーム内外のメンバーには感謝してもしきれません。本当にありがとうございます！ 弊社では、データサイエンティストやエンジニアの採用を積極的に行っています。興味をもっていただけた方はぜひカジュアル面談にお越しください！ データサイエンティスト(AnalyticsTranslator) / 株式会社エス・エム・エス ソフトウェアエンジニア カジュアル面談(PM/EM/SRE/QAも歓迎) / 株式会社エス・エム・エス

はじめに こんにちは。エス・エム・エスのプロダクトデザイングループ マネージャーの酒井 ( @_atsushisakai ) です。 エス・エム・エスは、9月30日〜10月1日 に行われた Designship 2023 にゴールドスポンサーとして協賛をさせていただきました。この記事では、 Designship 2023 におけるエス・エム・エスとしての活動の振り返りと、メンバーによる参加レポートとなっております。 はじめてのデザインカンファレンス協賛 エス・エム・エスのデザイン組織としてはこのような大型カンファレンスへの協賛を行うのは初めてでした。今回は協賛にあたって、会場で流してもらえるCM動画やブースデザイン・配布するチラシデザインなど数々の制作も行いました。また、スポンサーセッションへの登壇なども行いましたので、それらを一挙にご紹介いたします。 CM動画「デザインの力で社会課題に挑む」 今回は会場内で流してもらえる15秒という短い時間の枠の中でしたが、多くのメンバーに参加してもらいながら、たくさんの想いを詰め込み、CM動画を完成させました。組織の中にいるメンバーとして見た時にも、ストレートでメッセージ性のある動画に仕上がっていると思います。会場内で流してもらうだけではもったいないので今後色々なところで利用していくことも想定しつつ、エンジニアやPOにも協力を依頼しながら制作しました。ぜひ、色々な方に見ていただきたいです。 スポンサーセッション、パネルディスカッション登壇 会期中には弊社デザイナーの登壇もありました。 Day 1 にはプロダクトデザイナーの戒能孝祐さんがスポンサーセッションへ、 Day 2 にはは同じくプロダクトデザイナーの蔡長宏さんがパネルディスカッションへの登壇を行いました。 戒能孝祐「介護事業にデザインでどう向き合うか」 戒能孝祐さんは2023年4月にエス・エム・エスに入社しました。エス・エム・エスのプロダクトデザイナーとしてのキャリアを選んだ背景や、入社後にどのような難題と向き合っているのか、また、現時点でプロダクトデザイナーである自分自身が組織の中でどのような役割認識を持っているかといったストーリーが語られており、今後のデザイナーとしてのキャリア作りのひとつのロールモデルとして興味を持っていただけたのではと思います。資料を見ていただくだけでも参考になる部分は多いと思いますので、ぜひご一読ください。 蔡長宏「デザインリサーチの重要性」 パネルディスカッションには、蔡長宏さんが参加し、エス・エム・エスにおけるデザインリサーチの重要性や知見を共有しながら、他社のデザイナーの皆さんとディスカッションをしました。リサーチの現場でどのような観点でユーザーを観察するか、観察して得られたインサイトをどのような形でプロダクトチームに持ち帰るかなど、各社のリアルな声を聞くことができ、とても興味深い内容でした。今回、長宏さんは、日本語での登壇が初めて(！)ということで大変緊張していたと言っていましたが、落ち着いてわかりやすく、丁寧に、参加者に向けて誠実に知見を共有してくれました。 ブースでのサービス紹介とアンケート企画 エス・エム・エスという会社のこと、デザイナーが扱っている介護事業者向け経営支援サービスの「カイポケ」のことについて、来場した皆様により深く知っていただくために、今回はブース出展も行いました。ブースでは社会問題に向き合うきっかけとして、簡単なアンケート企画も実施しました。 アンケート企画の集計結果 「 どんな未来を過ごしたい？ 」という問いに対して、以下のような4種類のカードを用意して、ブースに来ていただいた皆様に選んでもらい、パネルに貼り付けてもらう形で回答していただきました。このアンケートは、高齢社会で暮らす自分自身が将来どのような事を大切に感じながら暮らしたいか、ということを想像してもらいながら「介護」という世界にほんの少しだけでも触れていただくためのきっかけづくりとして実施しました。じっくり考えて回答してもらう方も多かったり、この「問い」と「カード形式での回答」を社内でも参考にしたいということで、パネルの写真を撮って帰ってくださる方もいたりなどしてとても嬉しかったです。 最終的にはこのような結果となり、パネルからはみ出してしまうぐらいの想像以上に多くの回答をいただくことができました。 集計結果としては、以下のようになりました。 合計回答数: 191件 「健康でさいごまで自立して」74件 「人との繋がりを大切に」70件 「大切な家族とさいごまで一緒に」40件 「慣れ親しんだ街で安心して」 7件 どの回答が正解というわけではないですし、豊かな暮らしを続けるためには全てが必要な要素かもしれません。とはいえ、特に「健康と自立した暮らし」「人との繋がり」を大事にしたいと感じる方が多かったようです。これを実現できる社会を作っていくために我々は様々な問題を解決し、乗り越えていかなければなりません。その課題解決のプロセスにおいて、「デザイン」はとても重要な役割・技術であると我々は考えています。 アンケートに回答いただいたみなさまには、今回のために特別に製作したノベルティ「カイポチくん おくすりケース」をお渡しさせていただきました。こちらも「かわいい！」とお渡しした方々に喜んでいただくことができて、デザイナーみんなで「作って良かった！」と盛り上がりました。 弊社デザイナーによるセッションの感想 さて、最後にカンファレンスに参加し、セッションを聴講したデザイナーの印象に残ったセッションとその感想をお届けします。 大坪 旅人 (クリエイティブデザイン) の感想 印象に残ったセッション: 望月 美憂さん「デザインプログラムマネージャーになって気づいた「これもデザイン」」 セッションの感想 デザインプログラムマネージャーという職種は自社にはないものの、現職でも役立つ考え方が多いセッションでした。 特に、 Design People という、デザインをデザイナーだけに留めず Notion や Figma を通して組織全体で普及させていく考え方が印象的です。 自分はマネージャーではなく、制作業務がメインのデザイナーですが、デザイナーと各部署でのコミュニケーションやドキュメント整備など、日々の取り組みから取り入れられる実践的な話しが聞けました。 組織全体で Design People としてふるまうために、まずはデザイナーがデザイナーという職種に固執しすぎることなく、組織間のコミュニケーションなどからデザインの考え方を取り入れていきたいと思います。 重留奈津美 (プロダクトデザイン) の感想 印象に残ったセッション: 舘山佳奈さん「存在しないものをデザインする・AIをデザインするという事」 ※引用元： https://design-ship.jp/2023/contents/session セッション終盤で語られていた未知のものに挑戦するマインドセットについて、「挑戦する」「前例はつくればいい」「プロセスを楽しむ」の三つを挙げられていましたが、どれも共感するものがありました。AI開発とは一見まったく違うように見えますが、カイポケリニューアルプロジェクトも不確実性の高さと合わせて非常に長期的なプロジェクトであることからくる、不安になるタイミングが多い点・不確かだからこそデザイナーが力を発揮すべきという点など、共通点は多く感じました。"挑戦"と最後に舘山さんが贈ってくれた"楽しむ"という言葉を忘れずに進みたいと思います。 戒能孝祐 (プロダクトデザイン) 印象に残ったセッション: 株式会社ビットキー デザイナー 中沢 大さん「PKのようなレビューをやめた」 レビューをしてくれるメンバーは本来仲間なはずなのに、自分のデザイン(ゴール)を突破しようとする敵のように扱ってしまっていませんか？という問いかけ。PKでなく、パスを繋いで一緒にゴールを狙いにいくようなレビューが理想。聞いたタイミングで、ちょうどそんなレビューをしちゃったかも、、と思って今回いちばん刺さる内容でした。インハウスのデザイナーだからこそ、チームの仲間を信頼していくことは大切にしたいと思えるスピーカーセッションでした。 さいごに 今回、協賛という形で Designship 2023 に関わることができて、デザイナーコミュニティの熱量の高さ、デザイナーが抱えている解決すべき課題の深さと幅広さを改めて実感することができました。また、エス・エム・エスのデザイナー目線では、部署の垣根を越えてたくさんの制作物を共同で作り上げたことで、チームとしての帰属意識・目的意識を統一することができたりなど社内向けの観点としても、とても良い経験となりました。 今後も、エス・エム・エスのデザイン組織として、もっともっとコミュニティに知見を還元したり、他社のデザイナーの皆さんとも繋がりを積極的に作っていきたいと考えています。 さいごに、ぜひ、エス・エム・エスのデザイン組織にご興味を持っていただけたのであれば、ぜひ採用情報もご覧いただけると嬉しいです。 r-kaipoke.bm-sms.co.jp

この記事は 株式会社エス・エム・エス Advent Calendar 2023 の11日目の記事です。 無いに越した事はありませんが、サービスを長い間運用しているとどうしてもシステム障害対応をやらなければいけないタイミングがあります。この記事では、小規模なアラート対応から数日間に渡るチーム横断での大規模障害までいくつのシステム障害対応に関わる中で実際に私が行ってきた事を 11 個紹介してみようと思います。 前置きとして、現在私が所属するチームはほぼ100%フルリモートで開発を行っており、それを前提とした内容になっています。 1. 専用のコミュニケーションスペースを作る 2. 役割分担をする 3. 積極的に音声通話でやりとりする 4. 情報整理用のダッシュボードを作る 5. 専用のカンバンを作る 6. 情報同期のための定時ミーティングを設ける 7. 通常業務を進めるメンバーを残す 8. メトリクスのスナップショットを残しておく 9. 異なるメトリクスを同じ時系列で並べる 10. 他のチームにも相談してみる 11. 意識して休憩を取る 最後に 関連資料 1. 専用のコミュニケーションスペースを作る まず、障害対応モードに入ったほうが良いと判断したタイミングで誰でも良いので専用の Slack チャンネルを作ります。これにより障害対応の情報を一つのチャンネルに集約して、普段チームが利用しているチャンネル上で障害対応の情報がノイズとならない様にします。関連する情報へのリンクは slack チャンネルの関連ページや canvas に記載しておきチャンネルから辿れる様にしておくと便利です。 その後、チャンネルを作ったらすぐにチャンネル上で huddle を立ち上げて関係者を呼び寄せ、障害対応の情報収集や役割分担を行います。 2. 役割分担をする 意思決定を迅速に行うために、インシデントコマンダーを頂上とした階層構造の組織体制を作ります。 指揮官(インシデントコマンダー) -- 全体の指揮を取り、他の役割を動かすための意思決定を行う 外部連絡役 -- カスタマーサポートやリスクマネジメントの部署とやりとりをし、チーム外とのコミュニケーション窓口となってもらう。普段からそういった部署とやりとりをしてもらっているメンバーに担当してもらう場合が多い。 観測・記録役 -- 原因調査・復旧担当や外部連絡役から入ってくる情報をまとめて、皆に伝えやすい形にする。インシデントコマンダーである自身が兼任する場合も多い。 原因調査・復旧担当 -- サーバーのログやメトリクスの調査を行い原因調査を行う。ほとんどの場合技術者が担当する。 場合によってはこれら以外にも現象の再現を試してもらう役割を作るなど臨機応変に対応します。いずれの役割を決める際も、コミュニケーションが混線してしまわない様に役割に対してまとめ役を必ず1名任命して、基本的にインシデントコマンダーはそのまとめ役とコミュニケーションを行う様にします。 なお、私の所属するチームはスクラムチームとして活動しているため通常時はトップダウンで意思決定を行う事はほぼありませんが、障害対応の際は例外的にこの様な体制に切り替えています。 3. 積極的に音声通話でやりとりする 障害対応では不確定な判断材料でリリース内容のロールバック、サービス停止、サーバースペック増強等の難しい判断を迅速に行う必要があります。このためコミュニケーション速度が速く、微妙なニュアンスを把握しやすい音声通話でのやりとりを積極的に使って作業を行います。特に対応初期はメンバーが揃わず情報収集もしづらいため、しばらく huddle を立ち上げっぱなしにしておいて状況の変化があった際にすぐに報告したり、何かを確認する際に声をかけやすい状況を作ります。 注意点としては、あまり多くの参加者が障害対応の本部機能を持った音声通話に入ってしまうと本部機能のノイズとなってしまう事があるため、役割分担が済み原因調査が動き始めたタイミングでそれぞれの役割ごとに音声通話を分けてもらう様気をつけています。 4. 情報整理用のダッシュボードを作る 障害対応時の情報整理は Notion 等のドキュメント管理ツールより miro の様なオンラインホワイトボードをダッシュボードとして使う様にしています。 ドキュメント管理ツールはシーケンシャルに構造化された情報を扱うのには向いていますが、複雑な関連性を表す表現力はありません。 オンラインホワイトボードツールであれば位置関係が離れている情報もドラッグアンドドロップですぐに移動できますし、何より縦横の二次元で情報を表現できます。更に位置関係を変えずに線を引いたり要素を囲ったりしてあげることで柔軟に情報の関連性や構造を表す事も可能です。複雑な判断要素が絡む障害対応ではこういった点が情報整理にとても役に立ちます。 5. 専用のカンバンを作る 状況が混乱していると記憶や認識のずれが発生しやすくタスク状態があやふやになる場合が多いです。これを避けるために障害対応専用のカンバンを作ります。私は miro の カンバン 機能を使い、標準のカラムに Backlog というカラムを追加して Backlog (検討中のもの) To do (実施が決ったもの) In Progress (対応中) Done (完了) というカラムがある状態にしています。今後進めるタスクの提案はいったん Backlog に入れて、対応する事が決まったものは To do へ、実際に実施中のものは In Progress へ移動して、状況が変わったら Done へ移動したり Backlog に戻したりといった運用です。 miro のカンバンは担当者を設定したり期日を決めたりすることも可能ですし、ホワイトボード上の他の情報から矢印を引っ張って関連付けを行う事ができるため GitHub Projects や Jira 等のカンバン専用のツールよりも柔軟な使い方ができます。障害対応では、この様にラフに使えるタスク管理方法のほうが情報を整理しやすいです。 6. 情報同期のための定時ミーティングを設ける 状況に応じてだいたい１〜２時間ごとに情報同期のための定時ミーティングを設けます。このミーティングでは 現在の状況に合わせてカンバンのアップデート 新たに発見した情報の共有 次に実施・中止するタスクの選定と担当決め を行っています。このミーティングは不確定要素の多い状況への適応とその対応を行うためのリズムを作ることを目的として、スクラムのデイリースクラムとプランニングをとても短い間隔で行うイメージでやっています。 7. 通常業務を進めるメンバーを残す 障害が発生すると不安から「全員で障害対応を行おう！」という気持ちになってしまう事があります。しかし、障害の内容によってはその原因調査を行えるメンバーが限られていたり、障害対応以上に重要な通常業務が存在する場合もあります。必要以上に障害対応への人員投下をするのでは無く、障害対応に入ってもらう必要があるメンバーを明確にしたうえで「〇〇さんは通常業務をお願いします」と、障害対応に入らなくて良いメンバーが明確になる様にしています。 8. メトリクスのスナップショットを残しておく メトリクスも種類によって保存期間や時間経過で情報の粒度が粗くなってしまい、障害発生当時のメトリクスが後から再現できなくなってしまう事があります。これを避けるために、気がついたタイミングで必ずメトリクスのスナップショットをスクリーンショットで残し miro に貼り付けておく様にしています。この際グラフがなるべく細かい単位で描画される様にしておくのもポイントです。 9. 異なるメトリクスを同じ時系列で並べる 障害発生時の状況把握を行う際はサーバー負荷やエラーレート、お問い合わせ発生日時等といった様々な情報の関係性を把握する必要があります。これを行うには同一時系列上に並列で異なるプラットフォームで取得したメトリクスを並べるのが効果的です。 ここで活用できるのが 8 で残しておいたスクリーンショットです。miro 上でx軸の時間を他のスクリーンショットのx軸の位置と合わせることで AWS 上のメトリクスや Datadog , Google Analytics といったプラットフォームの垣根を超えて同じタイミングで同時に変化が起こっているという状況が把握しやすくなります。miro であればグラフ上の気になる部分に注釈を付けたりする事も簡単にできますし、複数のスクリーンショットを繋げる事でブラウザ上では描画が難しい、長時間に渡るグラフを表現する事も可能です。 10. 他のチームにも相談してみる 障害対応にあたっているチームで原因や対策方法が見つからず解決が難しいと感じた場合、他のチームにも何か気がついた点が無いか相談してみます。複数のサブシステムが一つの共有リソースを使っている様なサービスの場合、特定のサブシステムでのみ発生していると考えられていた問題が実は別のサブシステムの影響によって発生していたり、共有リソースの問題がたまたまそのサブシステムに影響を与えていたという事もあり得ますし、他のチームメンバーが持っている専門知識によって意外な解決策が見つかる可能性もあります。 緊急事態なので、頼れる物は貪欲に頼るのが吉です。 11. 意識して休憩を取る 障害対応は場合によっては深夜作業や休日作業が発生してしまい体力的にハードなものです。この状態が続いてしまうと判断力が低下し、通常業務では行わない作業をやっている事も相まって不適切な情報を共有してしまったり、オペレーションミスでデータを削除してしまったりといった二次災害 1 を招いてしまう事があります。これを避けるために、意識して休憩を入れる様にします。 打ち合わせや議論が長くなる様であれば1時間ごとに小休憩を挟み、できるだけ昼休憩は通常と同じ様に設け、日が変わる前に一旦その日の対応を終え翌日再開できる様な動きができると理想です。当然それが難しい状況もあるのですが、その場合はシフトを組むなどして負荷が集中してしまわない様に配慮します。 最後に この記事を書くために当時の slack チャンネルを見ていると大変だった記憶が蘇ってきました。システム開発に関わる皆さんが、年末年始は何も起きず無事な年越しができる事を祈っています。 最後に、私が障害対応をするにあたって参考にしている資料を記載しておきます。 (筆者: プロダクト開発部桐生) 関連資料 今日からできる。初めての障害対応ガイド | DevelopersIO (dev.classmethod.jp) インシデント指揮官トレーニングの手引き | Yakst (yakst.com) Google - Site Reliability Engineering (sre.google) 重大事故の時にどうするか？｜miyasaka (note.com) -- ヤフー株式会社(現LINEヤフー株式会社)の元社長宮坂さんによる記事。 (PDF) National Incident Management System - Incident Command System (ICS) | FEMA.gov (www.fema.gov) -- アメリカ合衆国連邦緊急事態管理庁の資料。 Google SRE の資料中でもこのシステムが参照されており、インシデントコマンダーという役割を理解する際に Incident Command System (ICS) の章を翻訳しながら読みました。 疲労が原因によるものでは無いですが、ちょうど最近クラスメソッドさんでもクライアントのインシデント対応にあたって実施した作業でオペレーションミスによる障害が発生していました。 2023年12月5日に発生した複数AWSアカウントが操作不能となった障害について | クラスメソッド株式会社 (classmethod.jp) ↩

はじめに この記事は 株式会社エス・エム・エス Advent Calendar 2023 の 10 日目の記事です。 カイポケリニューアルプロジェクトでエンジニアリングマネージャーをしている @hotpepsi です。 フロントエンドのチームが本格的に立ち上がってから一年ほど経過しました。現在では二つのフロントエンドチームが日々活発に開発しており、多くの時間は、アプリケーションコードを書いたり、より良い仕様を議論したりすることに費やしています。並行して、コンポーネント共通で発生する問題を解消したり、開発者体験や生産性を向上させる取り組みも数多く行ってきました。 今回は一年分のまとめとして、アプリケーション固有でない様々な取り組みについて紹介したいと思います。 こんな感じのスクリプト で一年分のフロントエンド共通の pull request の title と description を markdown で取得して、その中から 100 個をピックアップしました。カテゴリごとにおおよそ時系列に並んでいます。両方のカテゴリにまたがるものは関連性の高そうな方に分類しました。 利用しているフレームワークやコンポーネント 前提として、カイポケリニューアルプロジェクトのフロントエンドチームでは、以下のフレームワークやコンポーネントを利用しています。この構成になった経緯は「 大規模 SaaS 「カイポケ」の未来を支えるフロントエンドの技術選定 」にありますので、ぜひご一読ください。 言語: TypeScript UI framework: Next.js , Chakra UI linting: ESlint GraphQL client: Apollo Client state management: Recoil form: React Hook Form schema validator: Zod component catalog: Storybook testing framework: Jest testing library: Testing Library visual regression testing: Chromatic やったこと 共通ガイドラインやファイル構成 コードレビューガイドラインを追加 はじめに、pull request のテンプレートや、大まかなレビュー方針を作成。 コーディングガイドラインを esa から移設 開発者のドキュメントは esa に書いているが、コーディングガイドラインは GitHub にあるほうがレビューや議論がしやすいので移設した。 テスト実装に関するガイドラインを追加 なぜテストを書くのかや、Storybook の活用方針などを記述。 モノレポに移行 プロジェクトチーム全体で議論した結果、モノレポに移行した。サービス毎の GitHub Actions の調整などは必要だったが、GraphQL のスキーマ管理などがしやすくなった。 Props に type を使うことにした Props に interface と type が混在していた。たいていは type で十分であり、意図しない拡張も防げるので、 type を使うことにした。そのあと、Props 以外でもなるべく type を使っていくことにした。 Node.js のバージョンを固定する CI や開発者の Node.js のバージョンを揃えることにした。 package.json での記述など、複数の手段を検討したが、ツールの選択肢などを考慮して .node-version で固定することにした。 ファイルコロケーション テストを tests/ 、ストーリーを stories/ に置いたりしていたが、関連するファイルが同じディレクトリにあるほうが見通しがよくなるので、コロケーションを採用した。 named export への移行 default export を行っているコードが少し存在したが、 なぜ default export を使うべきではないのか？ を参考にして、named export を利用することにした。既存のコードを修正して ESLint の import/no-default-export も追加した。 コードレビューガイドラインにコメント prefix を追記 question: や suggestion: や nits: など、コードレビューのコメント時に prefix をつけて意図を明確にすることを推奨することにした。 ポータルドキュメントを GitHub に設置 様々な場所にストック情報が増えてきたので、フロントエンドチームのミッション・ビジョン・チーム構成などへのリンクをポータルドキュメントとして一箇所にまとめた。 テストガイドラインに、推奨するテストの書き方を追加 Common mistakes with React Testing Library で紹介されているようなベストプラクティスを導入していて、ガイドラインにも反映した。 zod の import 方法の統一 import * as z from 'zod'; と import { z } from 'zod'; が混在していて、 公式ドキュメント などを参考に、後者に揃えた。 ファイル名の規則の lint ルール化 コンポーネントの名前やファイル名は PascalCase、ディレクトリ名を lowerCamelCase にしており、それを lint ルール化した。 eslint-config-airbnb-base を参考に lint 設定を見直し ソースコードの src ディレクトリへの移動 ソースコードが src/ 以下にあるほうが grep や lint に便利なので、移動した。 PropsWithChildren 利用の lint 化 子要素を受け取るコンポーネントは PropsWithChildren の利用を推奨している。 no-restricted-syntax の selector を使ったカスタムルールにより、 ReactNode の children を検出してエラーにするようにした。 Design System Chakra UIでDesign Systemを構築 アプリケーションコードからChakra UIのimportを禁止する 基本的な部品を全てデザインシステム上に構築できたので、アプリケーションから直接importしないようにした。 import/no-restricted-paths により検出。 Design SystemのStorybookの分離 Design SystemのStorybookをアプリケーションから分離した。 Storybook と Chromatic StorybookでHMRを有効化 GitHub Actions で Chromatic を実行する Chromaticによりvisual regression testを行うようにした。 Fakerの結果を固定する モックデータをFakerで生成しており、毎回異なるとChromaticの差分として検出されてしまうので、seed値を与えてデータを固定するようにした。(なおその後Fakerを利用するテストを削除したため使わなくなった) Chromatic導入に伴うレビューガイドラインの更新 pull requestレビュー時に、見た目の差分がある場合には確認して承認する必要があるので、ガイドラインを整備した。 mainブランチマージ後にStorybook をビルドする featureブランチだけでなく、 main ブランチにマージされたときにもChromaticでビルドするようにした。 main ブランチのStorybookはURLが固定されているので、他のチームに共有するときに使用している。 Chromaticで意図しない差分が出るStoryをUI Testの対象から除外する ポップアップなどのアニメーションを使用しているStoryで、変更がなくても差分として検出されてしまうケースがあり、 delay オプションでも解決できなかったので、 disableSnapshot オプションで除外した。 除外対象の一部修正 レンダリング終了より早くクリックしてしまっていたケースがあったのを修正。 Chromaticの TurboSnap を有効化し、スナップショットの数を減らした Chromaticの差分が生じたときにコメントする Chromaticで差分が検出されたとき、見逃してマージしてしまうことがあるので、差分が発生したというコメントをpull requestに追加するようにした。 create-or-update-comment を使用した。 フォントのプリロードについて調査 Chromaticの結果が不安定なコンポーネントがあり、 公式ドキュメント に従ってフォントのプリロードを試したが、改善しなかったため導入しなかった。 Storybook 7 へのアップデートとマイグレーション Chakra UIが対応したため、Storybook 7にアップデートした。これだけで1記事にできるくらいの更新があった。 CSF もバージョン3にした。 日付に依存したStoryの現在時刻を固定する 現在月を表示する画面で、月が変わるごとに差分が発生していたので、 mockdate により日付を固定した。 ChromaticでModalやPopoverのスナップショットを修正する play関数やアニメーションにより描画領域が変化する要素のスナップショットを安定して取得するために、画面サイズを指定した。 pull requestのマージにChromaticの結果の承認を必須にする Chromaticの差分があるとき、承認せずにマージしてしまうと、baselineが更新されないため他のpull requestでも差分として表示してしまう。そのため、差分があったらpull requestの必須のアクションの状態をpendingにして、承認するまでマージできないようにした。 Chromaticの結果のリンク先をChromaticの対象ビルドにする Chromaticの結果(UI Tests)がアプリのトップページにリンクしていて不便だった。pull requestのイベントの github.event.target_url にビルド毎のURLが入っているので、それに書き換えた。 main ブランチでの実行では autoAcceptChanges を有効にする Chromaticの結果の承認を必須にできたので、 autoAcceptChanges を設定して、baselineを更新するようにした。 PR時の reactDocgen の無効化 Chromaticを高速化するため、pull request作成時にStorybookの reactDocgen を無効化した。 各ページにStoryを書くことにした コンポーネントだけでなく、ページのStoryも書くことにした。Storyやテストも同じ場所におけるように、ビルド対象であるページのファイル名のsuffixを .page.tsx とした。 テスト JestやStorybookでGraphQLのクエリをテストするためMSWを導入 MSWのレスポンスに型制約を与える @graphql-codegen/typescript-msw を導入した。 mockの姓名を 名姓 から 姓名 にする fakerが生成する fullName が 名 姓 の順だが、逆にした。 Jestのタイムゾーンを東京に固定 console.error が出ているテストがあれば CI を失敗させる CI でtestとbuildを並列で実行する テスト実行時間の可視化 10秒以上かかっているテストを洗い出し、分割するかどうか検討した。 CIのJestのテストを高速化する --shard と --maxWorkers を与えて並列実行するようにした。 CI にキャッシュを設定して実行時間を速くする main ブランチにpushしてビルドするとき、キャッシュを保存するようにした。 Jestでwrapperを書かなくて済むようにする custom renderを定義し、 ApolloProvider や RecoilRoot など、共通で必要なwrapperをいちいち書かなくて済むようにした。 Jestを3回リトライするようにした テスト実行時間のばらつきがあり、タイムアウトして落ちるテストがあるので、リトライするようにした。 ローカル開発ではJestをリトライしないようにした fireEvent よりも userEvent の利用を優先する userEvent のほうが実際のユーザーの操作に近いため、推奨することにした。lintルールも追加した。 テストの実行時間が長くなる場合は fireEvent の利用を許可する旨をドキュメントに追加 テストのshardingの改善 テストの実行時間のばらつきがあるため、前回の実行時間を考慮するTestSequencerを実装し、shardingを改善した。 testing library v14対応 jest.useFakeTimersを使うと userEvent が終わらない問題の対処などを行った。 Larger Runnersの導入 テストの高速化のためLarger Runnersを導入した。Jestの maxWorkers は CPUコア数 - 1 にした。 mainブランチではテストを1shardで実行する CIのキャッシュの効率化のため、 main ブランチではテストを1shardで実行するようにした。 JestのエラーをSentryに送る Jestで失敗したテストを、テスト用のSentryプロジェクトに報告するようにした。 テストの日付を固定する 現在時刻から年齢を計算して表示する画面があり、 useFakeTimers により日付を固定した。 main ブランチのCIが失敗したらSlackに通知する 大量の文字入力のテストをclick/pasteに変更した 大量の文字入力をチェックする際に、 user.type ではテストに時間がかかるため、大量の文字を扱う場合は user.paste を利用するようにした。 lintとデプロイ失敗時にもSlackに通知する 共通コンポーネント 編集中にブラウザの戻るボタンをクリックした確認ダイアログを表示する ブラウザバックを監視するカスタムフックを実装した。 カレンダー編集UIのパフォーマンスチューニング データ量が多い複雑な編集画面のパフォーマンスを改善するため、オリジナルの仮想スクロールを実装した。 Kaipochiコンポーネントを追加 カイポケのマスコットキャラクターであるカイポチくんを追加した。なおカイポチくんの身長は133.4cm、体重はイチゴ3個分である。 ゼロ埋めの内部処理を標準組み込みメソッドに置換 標準メソッドに String.prototype.padStart があったのでゼロ埋めのメソッドを置き換えた。 電話番号の表示にハイフンを付ける libphonenumber-js を導入して、電話番号の表示にハイフンを付けた。バンドルサイズを軽くするため、 Customizing metadata の方法で日本のmetadataだけ使うようにした。 Feature Flagの導入 開発中の機能を限定された範囲で有効にするため、Feature Flagを導入した。 デバッグ用に日付を固定する 日付や時刻によって挙動が異なるページがあるため、デバッグ用のデータをlocalStorageに保存して、特定日時にできる機能を実装した。 Storybook用のFeature Flag判定を追加 Storybookのみで有効になるコンポーネントが実装できるようになった。 Next.js Dynamic Routing で 403 になった際のフォールバックを追加 SPAかつCloudFrontの環境で、Dynamic Routingを使ったページでリロードすると、プレースホルダ置換後のURLをアクセスしようとして403となっていた。CloudFront内で403を404にリダイレクトし、アプリケーションの404のハンドラ内で、routerで元のページに戻すようにした。 Dynamic Routingで存在しないページをリロードしたときに404にする 存在するページのみでリダイレクトしたいので、ビルド時にページの一覧を生成して、マッチしたページがあるときだけ遷移するようにした。 アプリヘッダの再レンダリングを抑える アプリのレイアウトをページコンポーネントの .getLayout に移し、再レンダリングを抑えるようにした。 フォーム 全角の英数字入力を許容する フォームのバリデーションのタイミング変更 onChangeでバリデーションを行うと、入力してすぐにエラーとなり体験が悪かったので、バリデーションのタイミングをonTouchedに変更した。 入力した文字の前後の空白・タブをtrimする GraphQL Apollo Server でモック用の GraphQL サーバーを起動 refetchQueriesに関するガイドラインを追記 リスト系のデータの再描画では refetchQueries を発行する必要があり、いくつかの注意点をガイドラインに追記した。 特定コンポーネントのGraphQLのqueryにprefixをつける GraphQLのクエリ名が衝突しないよう、prefixをつけることにした。 @graphql-eslint/naming-convention により判定。 near-operation-file-preset 設定 .graphql ファイルをコンポーネントと同じディレクトリに生成するために @graphql-codegen/near-operation-file-preset を導入した。 フロントエンドでのsupergraph生成をやめ、バックエンドのファイルを参照するように修正 GraphQLのsupergraphの生成方法を試行錯誤した結果、最終的にバックエンドで合成するようにした。フロントエンド側ではCIのタスクでコピーして、変更点を確認したり壊れていないかどうかを検証するようにした。 複数のmutationを呼んだ時も確実にrefetchするようにする @deprecated の扱いを warn にする APIに @deprecated をつけるタイミングをフロントエンド側で決められず、 error だとCIが失敗するので、 @graphql-eslint/no-deprecated のルールを warn に変更した。 GraphQL 利用側の推奨ルールを導入 @graphql-eslint/operations-recommended を導入した。 Renovate Renovateの導入 パッケージのアップデートのため Renovate をGitHubに導入した。 Next.js を Renovate から除外する Next.jsのバージョンアップは慎重に行いたいので、Renovateからは除外した。 Renovateが作成したpull requestではChromaticを実行しないようにする ライブラリのアップデートでは見た目が変わらなかったり、頻繁にrebaseされたりするため、botが作成したpull requestでは自動実行しないようにした。 ChromaticのCIを手動で回せるようにした 見た目を確認したいこともあるので、手動でも起動できるようにした。 特定のライブラリのアップデートでChromaticを実行する Renovateが作ったpull requestはChromaticを実行しないようにしたが、Storybookなど見た目に関わるライブラリのアップデートではChromaticを実行するようにした。 手作業で閉じたRenovateのpull requestが再度作られないようにする Renovateが chore(deps): をつけたりつけなかったりして閉じたものを再度作るケースがあったので、 semanticCommits を enabled にして常に付与されるようにした。 GitHub actions デプロイ通知を良い感じにする デプロイ成功時のアイコンを機嫌の良いカイポチくんに、失敗時にはしょんぼりしたカイポチくんにした。 pull requestを作るbotは自前のトークンを使う GITHUB_TOKEN でpull requestを作成するとCIなどのワークフローが起動しないため、自前のトークンに置き換えた。 ドキュメントだけ更新したときにコード系のactionsを起動しないようにする dev環境へのデプロイを直列にする main ブランチにマージするとdev環境にデプロイするようになっていて、近いタイミングでマージするとリソースが壊れることがあったため、直列にした。 その他 pre-commit フックに時間がかかるので pre-push でチェックする Huskyのpre-commitを導入していたが、小さい単位でコミットしようとすると地味にlint待ちが発生していた。基本的にVSCodeで整形＆lintされているので、pre-pushに変更した。 git pull時に package-lock.json に差分があれば npm install する Huskyのpost-mergeで実装。 フロントエンドのhooksを希望者のみで発動するようにする モノレポで開発しており、必要な開発者だけhuskyのhooksを動作させたかったが、 npm install を実行したバックエンドの開発者でも発動してしまっていた。 .env.local ファイルに特別な記述をしたときだけ発動するようにして解決した。 Hygen 導入 循環参照の調査と修正 eslint-plugin-import の no-cycle で検出した。ルールを追加するとlintの時間が大幅に増加し開発効率が著しく下がるため、発見のみに使用した。 pre-push の処理を並列化 https://github.com/open-cli-tools/concurrently を導入してpre-push の処理を並列化した。 バージョン番号の生成スクリプトを作成 commit hashなどをJSONファイルとして公開し、どのバージョンがデプロイされているのか取得できるようにした。 ローカルデータ追加用のE2Eテストの設定追加 Playwrightを導入して、ローカル開発環境でユーザー登録から初期データ投入までできるようにした。 おわりに フロントエンドの技術は年々進化して複雑化しており、モダンな開発を普通に実践しようとすると、多岐にわたる取り組みが必要になることが確認できました。今後も、中長期のプロダクトを想像しつつ、より良い技術や手法をバランス良く取り込んでいきたいと思っています。 なおエス・エム・エスでは、フロントエンドだけでなく、様々なポジションで開発メンバーを募集しています。興味を持った方は、ぜひお気軽にお声がけください。

この記事は株式会社エス・エム・エス Advent Calendar 2023の9日目の記事です。 qiita.com はじめに 株式会社エス・エム・エスでエンジニアリングマネージャーをしている @emfurupon777 です。今回は両利きの経営という考え方をエンジニア組織に適用していくにはー？を考えてみる。ということで、概要の紹介と弊社の今年の取り組みをあてはめてみようと思います。 ※記載内容に誤りなどがある場合は筆者のX(旧Twitter)宛に連絡をいただけると幸いです。 参照書籍 エンジニアにとっては馴染みが薄い書籍かもしれないのですが、こちらです。 str.toyokeizai.net 原文は "Lead and Disrupt: How to Solve the Innovator's Dilemma" で受ける印象が学術っぽいですが、日本語では表紙に『「二兎を追う」戦略が未来を切り拓く』と書いてある本です。どうでもいいことですが、一石二鳥が座右の銘の私にとっては、日本語のほうがちょっとテンションが上がる好きな表現です。 両利きの経営 企業が両利きであるということはどういうことなのでしょうか。 企業活動における両利きは、主に「探索(exploration)」と「深化(exploitation)」という活動が、バランスよく高い次元で取れていることを指す。 ざっとまとめてしまうと、探索とは既存の枠を超えて破壊的イノベーションを生む活動で、リーダーシップ課題ととらえることができる。一方で、深化とは主に既存事業において品質や性能、効率性などを向上させることによる漸進的イノベーションを生む活動で、マネージメント課題としてとらえることができる・・・のような定義と理解しました。 両者では行動原理やKPIが異なるということですね。確かにこれを一人、一組織が同時に実行に移すことは難しそうです。みなさんの所属している組織では、今両利きの経営が意識的に行われている状態でしょうか？ そもそも変化が速いなかで、両利きの経営が求められている企業は多い気がしますし、エンジニアとしてはキャリアの中で、0->1, 1->10, 10->100といったフェーズの違いを意識していることも多く、探索と深化の両方を経験してきた/経験しようとしていることが多いのではないでしょうか？(採用活動の中でも、最近は「今回はこの経験が得られる環境を探してます」と明言される方が多い印象です) また、本書のなかでリーダーも失敗を認めるといったことも挙げられているのですが、アジャイルを志向しているプロダクト開発のコンテキストでは当然だと思うので親和性も高そうです。 なんだかエンジニアにとっても、組織のあり方を定義していくのに良さそうな考え方ですね。スゴイ、やろう、すぐやろう、今やろう。・・・では実践していくのに何が重要なのでしょうか？ 浸透させるのは価値観ではなく行動 両利きの経営をしていくためには探索と深化をつなぐカルチャーが大事だと説かれています。そして、組織が価値観(VALUES)を持つことは良いが、コントロールしていくためにはその価値観に基づいて期待される行動(NORMS)を明確にせよと言います。 例えば、様々な国がカルチャーを持っていることは誰もが認めているが、国の文化は価値観ではなく、予想される行動でしょ？組織として浸透させられるのは行動だよね、ということのようです。 具体例として挙げられていたマイクロソフトの変革では10のこと全てを行う必要があった、とまとめられています。これは非常に参考になる事例だなと思います。 news.microsoft.com しかし、マイクロソフトのサイズでこれら全てを実行するというのは、かなり難易度が高そうですね・・・ エス・エム・エスでの取り組み さて、弊社の取り組みについてです。 弊社では今年、まずテックブログにおいてカルチャーを言語化してみました。 tech.bm-sms.co.jp とはいえこれだけでは浸透は期待できません。様々なところでMVV(Mission Vision Value)は言語化する取り組みをしているものの、その浸透に四苦八苦・・・というのを多く目にし、私自身も経験してきました。 そこで、価値観を体現する行動をとっている社員をピックアップして紹介し、さらに最近技術責任者の田辺からは学習することへの投資の観点で推奨する行動の一部について発信してもらいました。 tech.bm-sms.co.jp これらはもちろん社内の取り組みとして実践していくことも可能ではあったのですが、両利きの経営において例示されたマイクロソフトにおいて、参考になるコンテンツがオープンでリーチしやすい状況にあったことがやはり良い体験でした。そのため、弊社も外部にもオープンなテックブログという場での発信によって、弊社について知っていただくとともに、あわせて社内への浸透もはかっている面があります。 今後について 弊社は創業から新規事業の開発とその継続的成長が重なって発展してきている会社です。そのため、我々エンジニアリング組織がマーケットに向けて働くにあたって、常に変化をしながら両利きの経営を実践していくケイパビリティが必要だと私は考えています。そのために我々のカルチャーをより強くしていきたいです。 先日、『両利きの経営』著者オライリー教授の講演(JBPress社 第19回 DXフォーラム)をきいていたところ、強いカルチャーを持つ企業がとっている手段として下記のような5つが挙げられていました。 5 Levers for Managing Culture (the LEASH Model) Leader Actions Employee Involvement Aligned Rewards Stories, Symbols and Signals HR Alignment どれも掘り下げていくと取り組みがいのあるテーマですが、私も(失敗しながらも)継続的に挑み続けたいと思います。そして、これらについて社内の取り組みだけでは視野が狭くなりそうなので、同じようなことを考えているエンジニアリング組織の方はぜひ情報交換してみたいです。 おまけ 知っていることと行うことは同義ではないとして、F・スコット・フィッツジェラルド氏の言葉として下記の紹介されていました。 「頭の中で相反する二つの考えを同時に持ち、なおかつ、その機能を維持することができるかどうかが、第一級の知性を占う試金石となる」 第一級の知性であるかどうかは別にして、これを行っていますよ、と自信をもって言える組織でいられるといいなーと素朴に思いました。 そして、弊社に興味を持っていただけた方は、ぜひこちらのページものぞいてみてください！

この記事は、「株式会社エス・エム・エス Advent Calendar 2023」7日目の記事です。 qiita.com Webサービスが長期間運営されると、成長に伴い複雑なプロダクトコードが蓄積されます。このような長寿サービスは多くの人が関わってきたということでもあり、様々な思いや依頼のもとにプロダクトコードが少しずつ変わってきています。そんな長いサービスに対して手を加えるとき、関わってきたすべての人たちがコミュニケーションできる範囲内にいるとは限りません。そのため、いまあるプロダクトコードから当時の意図を汲み取り、手を加えるという場面は多く存在すると思います。 これらの場面に直面する話は多くあれど、実際にどのように読み進めていくかというのはあまり多くは語られていないと思っています。そこで今回は「過去携わった人が近くにおらず、GitHub上でバージョン管理されたコードを読み解きながら改修をする」というようなシチュエーションを想定して探り方と直し方のアプローチ例をご紹介できればと思います。 どのようにアプローチするか 今回は、以下のような改修の依頼を題材に、大きく3つのステップに分けて取り組み方の例をご紹介していきます。 『TOPページのリストアイテムの並べ順を更新日時が「更新日：2022-11-20」の形式になっているので、その値をもとに日付の降順に並べ替えてほしい』 1.変更箇所にあたりをつける まずは改修する機能とソースコードの位置に関してあたりをつけます。これは改修依頼の内容によってアプローチは変わりますが、一番直感的な追い方は「改修箇所のユニークな部分から特定する」というやり方がよいと思います。 たとえば今回ののような改修の話であれば、"更新日："という文字列を手がかりに探すということができます。もちろん扱っているフレームワークの構造などから「TOPページ」というところを手がかりに探すこともできるので、自身の持ち合わせている知識や利用しているフレームワークの特性を活かしてで特定していくのがよいと思います。 変更する場所がわかったら次は歴史を追っていく作業です。 2.GitHubのblameとhistoryの機能を利用して「何故行われたのか」を追う ソースコードを改修するときに「なぜ今の形になっているのか」というのを確認する作業が必要な場合が多いです。その時に役に立つのがblameです。blameは直訳すると「非難」という意味なので物騒な言葉ではあるのですが、GitHubでソースコードを探すときには大変有効に利用できます。 GitHubのblameの機能を利用すると、行単位に「いつ」「誰が」「どのコミットで」変更してくれたのかを可視化してくれます。 この機能を使うことにより、目星をつけた改修箇所のコミットを確認できるので差分を確認することができます。また、コミットがわかるので、コミットに紐づくPullRequestも確認することができます。PullRequestを見ることができればdescriptionを読むことができるので、そこから新しい情報を入手することができます。文章そのものも有益な情報ですが、JIRAやbacklogなどの別サイトで管理されている依頼情報を追うこともできたりするので、当時の背景理解を助けてくれます。 またhistoryの機能を使うとそのファイルが過去に行われてきた変更を確認することができます。commitによってはrevertしているなどで直前のコミットだけでは変更の真意まで読み解けないときがあるので、そのようなときにhistoryを使って過去のコミットを順を追っていくことで得られる知見もあります。 この過去の内容を追うときに念頭においたほうがいいのは「該当箇所にどんな変更があり、何故その変更が行われたか」です。例えば最初に挙げたリストアイテムの表示順を並べ替えたいという話であれば、何故最初に昇順で実装されていたのか、その後変更がされた形跡があるかというのは一度調べておくといいかと思います。これを調べることにより現在の担当者が知らなかった背景が見つかったりする場合もありますし、逆に当時何も考えて作られていないことがわかれば修正してしまってもなんの問題もないという裏付け材料になるので、調べておくことのメリットは大きいです。 3.前後比較ができる状態で改修をかける 変更箇所がわかり、修正する内容に関しても憂いがないことがわかったらあとは直すだけです。ただ直す際に気をつけなければいけないのは「関係ないところを変更してしまわない」ということです。 例えば今回の改修依頼の例でいくと、並び順は降順になったが、リスト表示するアイテムがおかしくなってしまう、などの事象が起きてはいけないので、その点に関して修正前後で問題がないかというところを確認する作業が必要です。 修正する箇所にテストコードがあり、修正した箇所以外に変更が加わっていないかということが検証できるのが一番良いのですが、歴史の長いコードベースの場合はちゃんとテストコードが用意されていないこともあります。そのため、予め「修正前後を確認できる方法」を用意しておいたほうがいいと思います。 修正前後を確認できる方法というのは、テストコードを書き足すということでも実現できます。もともの改修前の箇所に関してテストコードを書き足し、その後改修とワンセットでテストコードも書き換えるというやりかたです。こうすることにより元の仕様の理解も深まり、また未来コミットログを見た人がどういう振る舞い変化を期待して直したかというのもわかりやすくなります。 ただ、テストコードが継ぎ足すのが構造上難しい箇所もあると思います。その場合は一般的にマニュアルテストと呼ばれているようなテストケースを文章で書き起こし、それを実施するというのも方法の一つだと思います。その場合はPullRequestのdescriptionに行ったテストケースに関する情報があれば、未来の人に何をしたかを残すこともできます。 ここで大事なのは「修正したい場所と修正する場所に近いところがちゃんと壊れていないかを確認する工程を踏む」ということを意識づけてやるところなので、テストコードでもマニュアルテストでも確認作業を踏む、踏んだ足跡を残せるとよいかと思います。 過去を探ることで、足場を固めて改修する 歴史のあるプロダクトコードはビジネスの成長に合わせて無理をしていることもあります。そのようなプロダクトコードに手を入れるときに当時の背景を理解するということは改修の手助けになることがあります。過去を知るチームメンバーに色々と話を聞けるとよいのですが、もしそのようなメンバーがいない場合、GitHubでソースコードを使うことで断片的にでも情報を探ることができます。 また断片的に得られた情報から改修を行う際は、テストコードなどで足場を固めて改修をしていくとバグを生み出す確率を減らすことができます。下記のPullRequestでは今回のアプローチで紹介していたような探りを入れ、そこに対し既存実装にあわせたテストコード（RSpec）を追加、そのRSpecを元に既存実装から改修実装に切り替え、最終的に影響が他に伝搬してないかを確かめつつ改修しています。かなり複雑な箇所の改修でしたが、大きな不具合を出すことなく改修ができました。 これらのアプローチを無意識にやっている方が多い部分もあるとは思いますが、もしこの記事で少しでも学びや再発見があれば幸いです。 こちらの文章は直近 入社エントリ を書いた高田の提供でお送りしました、明日のアドベントカレンダーもお楽しみに！

この記事は 株式会社エス・エム・エス Advent Calendar 2023 の6日目の記事です。 エス・エム・エス BPR推進部 カスタマーデータチームの橘と申します。 私は「ナース人材バンク」等のキャリア事業を中心に、社内のデータ活用の推進、データ基盤の開発運用を担当する、データエンジニアの役割を担っています。 今回は私の組織におけるデータエンジニアの役割を簡単にご紹介し、データ活用の推進のために進めている活動の1例として、データカタログの整備についてご紹介します！ データエンジニアとは そもそもデータエンジニアとはどういう役割でしょうか？ 一言でいうと、社内のデータ活用に携わるITエンジニアです。ビジネスの意思決定を決めるデータ活用の基盤として、データ分析基盤があります。そのデータ分析基盤はデータの収集、蓄積、加工、可視化、出力などの機能を持っています。また、データ分析基盤を活用するためのデータの整理、カタログ化、セキュリティの担保等も必要になってきます。これらの開発・運用に携わるのが私たちのチームにおけるデータエンジニアとなります。 私たちキャリア横断開発グループではGoogle Cloud を中心にデータ分析基盤を構築しております。以下の記事でもご紹介しておりますので、合わせてご覧ください。 キャリア事業におけるデータ活用 エス・エム・エスのキャリア事業のみに限定しても、「ナース人材バンク」や「カイゴジョブ」等の複数サービスを展開しており、非常にたくさんの種類のデータが、あちこちに存在します。 これらのデータを1つのデータストレージ、具体的にはGoogle Cloud のBigQuery に連携して、データを活用できるようにしています。 私たちは貯めたデータをもとに、マーケターからヒアリングした課題の解決に向けて、データの出力や可視化、分析を進めています。 とはいえ、単に条件を指定したデータの出力や単純な可視化等は、データエンジニアチームを介すことで実装完了までのリードタイムが生じたり、依頼内容と開発者の認識の祖語が発生したりする問題もあります。そのため、マーケター自らが収集したデータを探して、活用していくという、“データの民主化”に課題がありました。 キャリア事業というドメインのデータ分析基盤は、データメッシュという考え方における、“セルフサービス型データプラットフォーム”を目指してます。データエンジニアに依存せず、マーケター達が自律的にデータを取り扱えるようなデータ基盤を構築し、データカタログ、データマート、BIツール等の各ツールを活用して、データの分析を行う世界を目指しています。 今回はそのうちのデータカタログというプロダクトに焦点を当ててご紹介します。 データカタログの整備 前置きが長くなりましたが、データカタログについての話に入ります。 そもそもデータカタログとは何でしょうか？その名の通り、“データのカタログ”になります。データのメタデータ、ビジネス要件などをドキュメント化して、検索ができるカタログのことを指します。 私たちのデータ分析基盤では、目的に応じた大量のテーブルが存在し、各テーブルには大量の項目が存在しています。 セルフサービス型データプラットフォームは、こういった大量のデータを分析するにあたって、データを発見しやすく、アクセスしやすい環境でなくてはなりません。そのため、データ分析基盤の各データのメタデータをもとに、データカタログを作成する必要があります。 私達のデータ分析基盤(今回はGoogle Cloud のデータウェアハウス、BigQuery 内のデータに限定しています)におけるデータカタログの要件は以下としています。 分析を始めたい人がデータカタログにすぐにアクセスできる 各データセット、テーブル、項目の定義やビジネス要件が整理されている データカタログを検索できる メタデータの収集は自動化できる ビジネス要件を継続してメンテナンスできる これらの仕組みが一か所に集約され、データカタログを起点にデータへのアクセスが容易となっている 単純にメタデータの収集であれば、Google Cloud にも、 Data Catalog という製品があります。 しかし私たちは上記の要件を満たすために、Googleスプレッドシートで簡易的なものを作成して運用しています。 今回はそのGoogleスプレッドシートで作成したデータカタログついてご紹介します。 実際のデータカタログ こちらが実際のGoogleスプレッドシート上のデータカタログになります。 実際にデータ一覧をお見せすることはできないので、Cloud Loggingからエクスポートしている、App Engineのnginxのリクエストをテストデータとして表示しています。（テストデータのため、論理名や説明は省略してます） シートの構造は以下の通りです。 README データカタログの使い方を記載したシートです。 データセット一覧 分析用プロジェクト内の、BigQuery データセットの一覧や説明を記載したシートです。 テーブル一覧 分析用プロジェクト内の、BigQuery テーブル（Viewやテーブル関数なども含む）の一覧や説明を記載したシートです。 利用者は主にこのシートを参照します。テーブル一覧のみでは分析用途として事足りないので、Google Apps Scriptを用いて、上記キャプチャのように、選択中のセルのテーブルで、項目一覧シートの情報を検索し、結果をモーダルで表示する機能を用意しています。テーブルの情報、各項目の情報を一覧で見れたり、SQLやテーブルスキーマファイルの自動生成などといった機能も用意しています。 項目一覧 分析用プロジェクト内の、BigQuery テーブル全ての項目の一覧や説明を記載したシートです。 データカタログの更新方法 データカタログの更新方法は、 BigQuery のメタデータ取得による自動更新 データエンジニアによるビジネス要件の手動入力 の2パターンがあります。 これらのアーキテクチャを簡単にまとめますと以下のようになります。 BigQuery のメタデータ取得による自動更新 項目名、型、更新日時や件数などの情報はBigQuery のメタデータにあるため、SQLで取得することができます。 以下のようなSQLを実行し、自分たちのデータカタログの各シートに出力できる形に整形して、日次のバッチ処理でスプレッドシートに自動出力される仕組みです。 1.BigQuery データセット一覧を取得 SELECT * FROM INFORMATION_SCHEMA.SCHEMATA 2.取得したデータセット毎に、BigQuery テーブル一覧とメタデータを取得(それぞれのクエリで取得できる情報は異なります) SELECT * FROM [データセットID].INFORMATION_SCHEMA.TABLES SELECT * FROM [データセットID].__TABLES__ 3.取得したデータセット毎に、BigQuery の全テーブルの項目一覧と、メタデータを取得(それぞれのクエリで取得できる情報は異なります) SELECT * FROM [データセットID].INFORMATION_SCHEMA.COLUMNS SELECT * FROM [データセットID].INFORMATION_SCHEMA.COLUMN_FIELD_PATHS データエンジニアによるビジネス要件の手動入力 テーブルや各項目の説明（集計項目であれば集計ロジックなど）、更新頻度など、メタデータで取得できない情報については、テーブルを実装したデータエンジニアが手動で入力する必要があります。また、不足している情報があればスプレッドシートの編集権限を持つメンバーが更新できるので、入力インターフェースとして準備が簡単だったGoogleスプレッドシートを採用しています。 とはいえ、メタデータ取得は自動的にされているものの、ビジネス要件が入力されておらず、カタログとして情報が不足してしまうことも多々あります。そのため、定期的にデータカタログ上で情報が不足している箇所を検知して、Slackに通知し、データエンジニアに入力を促すなどしています。データを収集してテーブルとして公開するまでが仕事ではなく、実際に分析するユーザーがデータにアクセスしやすい環境づくりを心掛けています。 まとめ 以上、私たちのチームにおけるデータカタログについてご紹介しました。 実際に分析をするマーケターや、開発担当のメンバーからも、 「BigQueryのデータを見るときはまずこのデータカタログから見てます！」 「テーブルをリリースすると項目定義が自動で連携されるから便利！」 といった声が上がっています。 一方で、利用範囲が広がるにつれ、データのオーナー情報、集計ロジックを直接見れるGitHubのURLも載せてほしいなど、データカタログとして管理していきたいビジネス要件が増えてきて対応しきれない部分もあるのが課題としてあります。 社内のデータの活用を推進する立場として、こういったドキュメントの整備も怠ることなく進めて行きたいと考えております。 エス・エム・エスは新しいメンバーを募集しています。 特に私たちのチームでは、データ分析・データ活用の推進に関わるデータエンジニアを募集しています。 今回紹介したデータカタログは、データエンジニアの仕事のほんの一例のご紹介にすぎません。 弊社の事業に携わってみたい方、興味のある方は、ぜひこちらのページものぞいてみてください。 エス・エム・エス - エンジニア採用情報 データエンジニア（キャリア事業） / 株式会社エス・エム・エス

こんにちは。介護事業者向け経営支援サービス「カイポケ」でエンジニアリングマネージャーを担当している橋口( @gusagi )です。 今回は、少し前にカイポケの訪問看護チームで行った「システム障害対応訓練」について紹介します。 なお、システム障害対応訓練に関しては、今回の記事だけでなく裏側を中心に紹介する記事を掲載予定です。 今回の記事ではやったことを中心に紹介させてもらい、別の記事では準備期間・当日・ふりかえりの裏側でどんな動き・工夫があったのかを紹介する予定です。そちらもなるべく早く公開するつもりですので、ご期待いただけますと幸いです。 きっかけ 訪問看護チームでは、テックリードを中心とした体制で開発・運用を行っています。 この体制は現時点で機能していますが、ある時のふりかえりで「テックリードが不在の時に何らかの問題が起こったとしてもうまく連携して対応することができるか？」という指摘が上がりました。 テックリードが不在となった場合に心配なことは何かを具体的に挙げていったところ、票が一番多く集まったのがシステム障害が発生して対応を行う時でした。訪問看護チームではシステム障害対応のガイドラインも策定していたのですが、その中で対応時の指揮官（インシデントコマンダー *1 ）を毎回担っているのがテックリードであったため、不在の時にチームが同じように動けるのかが不安要素として挙がったのです。 特に、以下の課題に関しては早い段階で手を打つ必要がありそうでした。 テックリード以外にインシデントコマンダーを担える人がいるかが分からない チームで行う対応がインシデントコマンダーの判断・指示に依存している QAチームとの連携がスムーズにできていない そこで「テックリードが不在の時のシステム障害対応」という課題に対する対応案として、表題にもあるシステム障害対応訓練を実施するという取り組みがスタートすることとなりました。 このシステム障害対応訓練において期待する効果は以下です。 短期・直接的な成果: 障害対応の解像度を上げる インシデントコマンダーを担える人間を増やす 中長期的な期待: 各人がシステム障害対応に主体的に関われるようなチームへの成長 やることが決まるまで システム障害対応訓練を行うということを決めて、そこからどんな内容にするかをチーム内で考えていく流れとなりました。 企画に名乗りを上げてくれた若手エンジニア２名を含めて打ち合わせをして、大枠として以下のことが決まりました。 お客さまからのお問い合わせをトリガーとして、問題の調査や解決を進める流れとする 実際にシステム障害を起こしたりはせず、チーム内でシミュレーションを行う形とする ただし、ログや各種メトリクスの調査は、ある程度まで実際にやってみる そのシーンで実行できるアクションは選択肢を提示しつつも、それ以外にも参加者が考えて何をするか決めて良い インシデント時のガイドラインに則って専用のSlackチャンネル作成なども行う チーム外に不要な混乱が起きないよう、事前の周知を徹底する他、当日のSlackチャンネル名などにもシステム障害対応訓練であることを明記する 上記を満たす方法を検討した結果、テーブルトークRPG（TRPG） *2 の形式を取るのが良さそうだという話になりました。 TRPGとは、ゲームマスター（GM）と呼ばれる進行役と、プレイヤー（PL）と呼ばれる参加者で協力して会話をベースとして物語を進行させていく遊びです。 実際には起きていないシステム障害に対するシミュレーションで、選択肢にない参加者の行動も柔軟に拾っていくことを考えた結果として、TRPGが良さそうだとなりました。 TRPGの形式が良いと判断した主な理由は以下です。 リモートワーク中心の状況で実際にシステム障害に対応する場合でも、複数人で会話をしながら対応を進めることが予想されるため、近しい状態で訓練することができる シミュレーションによる訓練となるため、進行役としてGMが存在する方が柔軟に対応できる 訓練だからこそ、少しは遊び心を入れて楽しみながら取り組めるようにしたい また、企画に名乗りを上げてくれたエンジニアがどちらもTRPGを知っていたこともスムーズに方針が決まった一因になったと思います。 当日までの準備について まずは発生したとするシステム障害の内容と大枠のシナリオを決めることとしました。 訪問看護チームは、介護事業者向け経営支援プラットフォーム「 カイポケ 」のうち訪問看護の領域を開発・運用しています。従って、カイポケのサービスにおいて特にお客さまへの影響が大きく緊急性の高いシステム障害が発生したと想定する方が望ましいと考えました。 そこで、発生したシステム障害の内容を決めた上で「一部のお客さまから『診療報酬明細書（レセプト）が出力できない』というお問い合わせが来た」という状況からシナリオが始まるようにしました。 なお、シナリオにはフラグによってエンディングが分岐する仕掛けを入れておき、GoodエンドからBadエンドまで何種類かのエンディングを用意しました。 また、TRPGを知らない・詳しくない参加者がいることが予想されたため、企画に参加しているエンジニアのうち片方の人にGM役を、もう片方の人には参加者として他の人のフォローに入ってもらうことをお願いすると共に、参加者の人にはシナリオを伏せた状態で準備を進めるようにしました。 合わせて「ハンドアウト」と呼ぶ事前資料を用意して、目的を意識して訓練に臨んでもらえるようにしました。 ハンドアウトではシステム障害対応訓練の目的や進め方の説明と合わせて、TRPGに不慣れな人向けのロールプレイの説明や会話をしながら進めることの必要性なども記載しました。また、トレーラーと呼ぶようなシナリオの予告ストーリーも載せておき、訓練ではあるもののゲームとして楽しめるような遊び心も盛り込ませてもらいました。 当日の実施レポート 当日は、まずは訓練会場として用意したZoomに集合してGMから改めて当日の流れを説明しました。 その後、実際のお問い合わせを模した形で内容をJIRAのチケットとして起票し、Slackで運用担当者への確認依頼をGMから伝えて、訓練開始となりました。 初めてのシステム障害対応訓練、かつTRPG風というアレンジが入っていたことで、訓練の途中にルールへの質問が入ったり、対応に関する相談が想定以上に盛り上がり時間が押してしまうというハプニングもありましたが、PdM・エンジニア・運用・QAといった日頃の役割を超えて意見の交換が行われており、概ね成功したと言えるのではないかと思います。 なお、最後は駆け足気味になっていましたが押さえるべき観点をしっかり押さえた対応を行えており、シナリオの結果として一番良いエンディングに到達することができていました。 訓練の最中にも「このペースで問い合わせが来ているの、相当ヤバい状況だね」「どう動いたら早く・確実にこの事象を解消できそう？」という会話が出ており、訓練を通して参加者がしっかりとシステム障害対応に取り組むことが出来ていたのではないかと思います。 振り返りについて 訓練結果を有効に活用するため、訓練直後に簡単なアンケートに協力してもらい、その内容を事前に共有した上でYWT形式でふりかえりを行いました。 アンケートの回答では、訓練を実施したことそのものに対する好意的な意見、訓練を通して得た気付き、訓練の進め方に関する改善の提案、今後の希望など多くの回答がありました。 また、アンケート結果を踏まえてのふりかえりでも、書き出しの時間をそこまで取ることが出来なかったにも関わらず、想像を大きく超える数の付箋が書き出されました。内容も、やったこと(Y)よりも、そこからわかったこと(W)や次に行うこと(T)の数が圧倒的に多く、この点からも、参加者にも楽しんでもらうと共に、システム障害対応訓練で気付きを得てもらうことが出来たのではないかと思います。 公開できない情報もあるためお見せすることができないのが残念なくらいでした。 あとがき ここまでで、訪問看護チームで行ったシステム障害対応訓練でやったことの紹介は終わりとなります。 ですが、冒頭にも書いたように、準備期間・当日・ふりかえりの裏側でどんな動き・工夫があったのかを紹介する別の記事も準備していますので、そちらもなるべく早く公開するつもりですので、ご期待いただけますと幸いです。 *1 : インシデントコマンダーについては Asanaの記事 や Atlassianの記事 が参考になります *2 : TRPGに興味のある人は 富士見書房さまによる紹介ページ や Wikipediaの記事 もご覧ください

この記事は、「株式会社エス・エム・エス Advent Calendar 2023」3日目の記事です。 qiita.com 介護事業者向け経営支援サービス「カイポケ」の開発をしている @koma_koma_d です。 私が所属しているチームは、介護事業所の業務のなかの一部の領域を扱う箇所の開発を担当しています。最近、このチームの置かれている状況に変化があり、それに伴って（他にも様々な変化が必要になっているのですが）ドキュメンテーションについての方針転換がありました。この方針転換は、私個人にとってもこれまでの働き方を一部改めるきっかけになるものでしたので、今回の記事では、その方針転換について紹介したいと思います。 これまでのチームの状況 私たちのチームが担当している領域のシステムは、大雑把にいうと、ユーザーが触るアプリケーション（サーバーサイドレンダリングをベースとする典型的なWebアプリケーション）と、その更に裏側で動作するバックエンドのアプリケーション（WEB API+非同期処理を担うワーカー）の2つの部分に分かれています *1 。 私たちのチームが担当する業務は、カイポケの他のコンポーネントで作られたデータを入力とするのですが、基本的にはこれらの2つのコンポーネントで完結します。したがって、カイポケの他のチームのメンバーは私たちのチームの担当する業務ドメインについての知識をほとんど持つ必要がなく、ユーザーから見える仕様もこれら2つのコンポーネント間のAPIの仕様もほぼ自由に変更することができました（もちろん仕様を変える際は対ユーザーのコミュニケーションは不可欠ですが）。この自由度を活かして、新しい機能を追加したり、そのために内部API仕様を変更したりを活発に行なってきました。 カイポケリニューアルプロジェクトの進行に伴う状況の変化 しかし、ここ数ヶ月の間で、状況が変わってきました（予定通りではあるのですが）。それは以前から動いているカイポケのリニューアルプロジェクトの進行に伴うものです。 careers.bm-sms.co.jp このリニューアルプロジェクトでは、既存システムとは別の新システムを開発しており、私たちのチームが担当する業務ドメインについても、別のチームが開発をしています。しかし、先述の2つのコンポーネントのうち、 後者のバックエンドのアプリケーションについては、既存システムと新システムとが共用します 。リニューアルプロジェクト側では、ユーザーが触るWebアプリケーション *2 だけを新規開発し、そのアプリケーションから私たちのチームのシステムのWeb APIを利用するわけです。 この状況の変化により、 これまで私たちのチームだけが知っていれば良かった知識の一部を、他チーム（リニューアル側の開発チーム）にも知ってもらう必要が出てきました。その中には、業務ドメインに関する知識と、内部APIの仕様の知識の両方が含まれます 。このことが、ドキュメンテーションの方針に変化を強いることになります。 これまでのドキュメンテーションの考え方 基本はチーム内向けのドキュメント 私のチームでは、ドキュメンテーションツールとして esa を主に利用しています。esaはMarkdownで書くことのできるツールで、個々の記事がバージョン管理されるほか、 フロー情報とストック情報を分ける機能 などがあります。esa以外には、ソースコードに近い情報はGitHubリポジトリ上のコメントやREADMEなどで記述しているほか、内部APIの仕様についてはOpenAPI Specification（コードから自動生成しています）から作成したドキュメント *3 があります。 このうち、内部APIの仕様についてはチーム外の人が見ることを意識していましたが、esaに書かれるドキュメントについては基本的にチーム内の人（未来の自分たちを含む）が読むことを想定して書いてきました。もちろん仕事をしている中で別のチーム（開発チーム以外を含む）に向けて情報共有をすることはありましたが、そのときに適切な情報が伝わればよいケースがほとんどで、メンテナンスされるようなドキュメントとして書いていなかったり、必要が生じたタイミングで書くという形で書いていたため網羅性の乏しいものになっていました。 読み手としてチーム内の人を想定する場合の考え方 読み手としてチーム内の人を想定する場合、ドキュメントを書く際に意識することは少なくて済みます。まず、チーム内の人であれば、コードを読むことで得られる情報など、既に関連する部分の知識を持っていることを前提としてドキュメントを書くことができます。コードを読んだ方が正確に・詳細に把握できる事項についてはドキュメントを書かないでおく選択を取ることもできます。 また、（新規参画したメンバーは別ですが）過去の経緯がある程度頭に入っていることも期待できるので、ある時点で書かれたフロー情報的なドキュメントを見たときにそれが書かれた文脈を想像してもらいやすいですし、必要に応じてgitの履歴やGitHubのPull Requestの履歴とも紐付けて読んでもらいやすくもあります。 このような背景から、ドキュメンテーションに対する考え方は、（チームとして明確に意識していたわけではありませんが） 「多少読みづらくてもよいので、とにかくたくさん情報を残しておく」 という方に寄っていたように思います。また、私個人の経験としても、チーム開発におけるドキュメンテーションの最初の壁は「共有されてもいい情報がドキュメンテーションツール上に書かれない」ことだと感じていたので、「書くハードルを下げる」「些細なことでもとにかく書いておく」ということを重んじてきました。個人で何か作業をしたときや調査をしたときも気軽にドキュメンテーションツールに書いておくことで、他のメンバーや将来の自分の参考になる情報をなるべく増やすという考え方ですね。現在のチームの前に所属していたチームでは、この考え方に基づいたプラクティスが上手くワークしていたこともありました。以下の記事で紹介している「転ばぬ先の杖」がそれです。 tech.bm-sms.co.jp 「書き手の書きやすさ重視」のアプローチ このアプローチは、「書き手の書きやすさ重視」のアプローチということもできます。もちろんドキュメンテーションはそもそも読み手のためのものなので、書き手の書きやすさを重視することも究極的には読み手のためではあるのですが、読み手にとっての利便性のうち、情報量を増やすことにフォーカスしており、「簡単に情報にアクセスできる」「わかりやすく情報がまとまっている」という部分は犠牲にしている側面があります。読み手は検索やリンク（esaにはバックリンクを表示する機能もあります）の機能を駆使してドキュメントを「漁る」ことで、必要な情報を得ることになります。 生じてきた課題 しかし、先述の状況の変化により、課題が出てきました。 チーム外向けのドキュメントだけでは足りない まず第一に、従来からチーム外向けを意図して書いていたドキュメントでは、全く情報が足りないということを本格的にリニューアル側の開発が始まってから痛感しました。これは見立てが甘かったと言ってしまえばそれに尽きるのですが、どう想定と違ったかを少し紹介したいと思います。事前のイメージは「Web APIのクライアントとなるリニューアル側の開発チームは、OpenAPI Specificationベースのドキュメントと、それを補足するようなドキュメントがあれば開発できるだろう」というものでした。しかし実際に開発が始まってみると、私が想定した以上に細かく、実装に近い仕様や業務ドメインに関する知識を質問されることが多かったのです。 内部APIのモジュールとしての性格 こうなってしまった理由を考えてみますと、私たちの開発している内部APIのモジュールとしての性質に思い至ります。私たちのチームで開発していた内部Web APIは、情報の隠蔽を志向しているというよりは、クライアントであるユーザー向けのWebアプリケーションで求められるユースケースを最大限実現できるようにすることの方を優先して作られていました。 もちろん、内部APIとして切り出す意味がある程度の複雑な機能をAPIの裏側に持っている（データベースやオブジェクトストレージ、KVS、非同期処理を実現するためのメッセージキューなども独自で持っています）のですが、非同期処理の過程のステータスの遷移などの情報はあまり隠蔽せず、APIで露出させることでクライアント側で画面に表示したり制御に利用したりできるようにしています。 『A Philosophy of Software Design』 における表現を使えば、「機能は多いが、インタフェースも多い（複雑な）」、DeepともShallowともいえないモジュールだということです。『A Philosophy of Software Design』については、以前個人ブログの方に書いた記事や、NTTコミュニケーションズ社のブログ記事も参考にしてください。 ky-yk-d.hatenablog.com engineers.ntt.com チーム外の人も、API仕様以上の知識に関心がある このようなモジュールとしての性質から、クライアントの開発者はこの内部APIを使って開発をする際に、かなり多くの知識にそもそもOpenAPI Specificationベースでドキュメント化されているAPI仕様の段階で触れることになります。その上で、そこに露出している知識を最大限に理解した上で実装をしようとすると、OpenAPI Specificationでは書ききれていない情報、ほぼ実装の詳細に関わるような内容や、背後にある詳細な業務知識までも知りたくなってしまうようでした（そもそも私たちのチームではそこも把握した上でユーザーの触るWebアプリケーションを実装しているわけです）。 チーム内向けとして書かれていたドキュメントをチーム外の人が読む チーム外に向けて書いていたドキュメントだけでは足りないとなると、他チームのメンバーとしては個別に私たちに質問するか、私たちがチーム内向けに書いたドキュメントを読むかして情報を得ようとします。私たちのチームとしてもリニューアルプロジェクト側の開発が滞りなく進むように支援することの優先順位は高く設定しているので、もちろん質問してもらっても大いに構わないのですが、すぐに応答できないこともありますし、双方にとって効率的でないこともしばしばです。したがって、やはりドキュメントで完結する部分を増やすことは重要になります。 チーム外の人にはチーム内向けのドキュメントは理解しづらい それでは、チーム内向けとして書かれていたドキュメントをチーム外の人が読もうとすると、どんな困りごとが出てくるのでしょうか。第一に、 ドキュメントを読むだけでは理解できない ということがあります。これは先述したような、チーム内であれば期待できる前提知識や、コードを読むことによって得ることのできる情報を、チーム外の人は持っていないからです。もちろん他チームであっても開発者ではあるので「コードを読んでください」と言えば読んでもらうことは可能なのですが、私たちのチームとリニューアルプロジェクト側のチームとでは技術スタックがやや異なっていることもあり、あまりここに頼りたくはありません。 チーム外の人にはドキュメントに書かれている情報の鮮度を判断しづらい また、チーム内向けのドキュメントではフロー情報としてある時点での情報を書いたものをそのまま残してあるものも多いのですが、チーム外の人は私たちのチームやそのシステムの過去の経緯までは知らないことが多いので、あるドキュメントを見たときにそれがup-to-dateなものかの判断が付きづらく、誤った（out-of-dateな）認識を持たせてしまう危険性があります。 チーム外の人は必要なドキュメントに辿り着きづらい 更に、そもそも 必要なドキュメントに辿り着けない という問題もあります。先述の通り、「書き手の書きやすさ重視」のアプローチでは、読み手の利便性のうち、「欲しい情報への辿り着きやすさ」は犠牲になっており、検索やリンクを駆使してもらう必要があります。 チーム内であれば自分たちがどういう言葉を使っているかが分かりますし、何かを調べようと思ったときにどのようなキーワードで検索したら見つかりそうかの候補もすぐに思いつきます。「あの記事からリンクされていた気がする」というのも覚えているかもしれません。しかし、これはチーム外の人には期待すべくもないことです。もちろん最小限の語彙はOpenAPI SpecificationベースのAPi仕様という形で見えるようになっており、そこで接した用語について関心を持って調べ始めるわけなので、全く白地からというわけではありませんが、やはり「欲しい情報へ辿り着く能力」には差が出てしまいます。 ※ちなみに、将来的には現状の全文検索やリンクに加えてAIによる要約やチャット形式での検索が発展して、現在よりは必要な情報に辿り着きやすくなるのではないかと妄想しますが、その場合でもデータソースを書き捨ての文章のみで構成するのはなかなか厳しい気がします。 これからのドキュメンテーションの考え方 以上のような課題から、私たちのチームではドキュメンテーションの考え方を改めることにしました。具体的には以下のような方針を定めました。 チーム内向けとチーム外向けを分けない これまで、ドキュメントはデフォルトがチーム内向けで、例外的にチーム外向けを書くという形になっていましたが、この分け方自体をやめることにしました。チーム外の人でも読めるものに最初からしましょう、ということです。実際には、チーム内のメンバーしか読まないドキュメント（たとえば、運用上の手順書など）も出てくると思いますが、その場合でも暗黙の前提知識を要求するような形では書かないということを原則としようとしています。 ドキュメントを小分けにせず、なるべく大きなまとまりにする これまでは「場所に悩んだりして書かないよりは、とにかく書いておくことを優先する」という方針で、仕事をしている過程で小さなドキュメントをたくさん書いてきました。しかし、このアプローチでは、一度書かれたあとに更新されないドキュメントが増えがちです。更新されないドキュメントが存在することは、読み手、特に過去の経緯まで把握していないチーム外の読み手にとっては大きなノイズとなります。 新しい方針では、なるべく大きなまとまりの文書をメンテナンス対象とし、加筆・修正していくことにしています。あるテーマについてはこの文書だけが信頼できる唯一の情報源（Single Source of Truth）であるという状態を作ることです。 こうしておくことで、まず第一に、欲しい情報に辿り着きやすくなります。また、これはチーム内で話をしている中でメンバーから言われて「なるほど！」となった点なのですが、 読まれる頻度の高いドキュメントは更新されるチャンスも多くなる ということもあります。ドキュメントが更新されるタイミングとしては、何か変更が入った際に「あのドキュメントも更新しなきゃなー」と更新されるのがベストですが、更新を忘れてしまうことは実際には多いです。しかし、日頃から繰り返し開くことの多いドキュメントであれば、「あ、ここ情報が古いじゃん」と気づく機会が増えます。もちろん、ドキュメントが大きくなればその中の一部の記述だけを目当てにしてそれを開くことも増えると思いますが、それでもその部分以外の記述も併せて目に触れることはある程度あり、更新のきっかけになると思います。 フロー情報を書いたものはドキュメントとして扱わない 上の内容とも関連しますが、フロー情報として書いたものをドキュメントとして扱わないようにしようと考えています。 これまではフロー情報を書いたものもドキュメントの一部として扱い、「読まれる」ことを期待していました。しかし、この考え方はともすると「本来ストック情報として書かれるべきものがフロー情報として書かれっぱなしになってしまう」という事態を招きやすいと感じます。「フロー情報を残しただけでドキュメントを書いたつもりになる」のをやめなければなりません。そのためには 「フロー情報を書いたものはドキュメントではない」 というくらいの意識が必要だと思います。有益な情報として残すべきだと考えたなら、その情報が書かれるべきドキュメントを探して、メンテナンスするものとして記述します（もちろん、もはや必要でないと判断した場合には「メンテナンス」の一部として削除することもあるでしょう）。 インデックスとなる記事からリンクだけで必要な情報に辿り着けるようにする。 これはドキュメントへの辿り着きやすさの改善のための方針です。これまではドキュメントを新しく作成するとき、「どのようなタイトルにするか・どのような文言を入れておくか」という検索でのアクセスのしやすさの観点と、「どのディレクトリ *4 に入れておこうか」という階層構造を使ったアクセスのしやすさの観点を意識することはありましたが、他の記事との関係でいうと、関連する記事同士をリンクで結びつけることによるネットワーク構造の作成くらいまでしか意識してきませんでした。 今回、新しく各グループ（ex. 仕様に関するドキュメント群）ごとにインデックス（ルート）となる記事を設定し、そこから明示的なリンクを辿ることで必要な情報を見つけられるようにしようということになりました。先述の通り、検索頼みにするのはチーム外の人にとっては利便性が特に低いですし、「検索や階層構造で見つけてくれる」というのに甘えると自分たちがその文書に辿り着くのも意識的にアクセスしたときに限られやすくなるため、書きっぱなしで更新されないドキュメントになりがちです。特定の記事からリンクだけで辿り着けるようにしておくことで、チーム外の人からアクセスしやすくなると同時に、更新されやすいようになることを狙っています。 終わりに 以上、私たちのチームにおけるドキュメンテーションの方針の転換について、その背景と併せてご紹介してきました。この方針で動き始めたのは最近なので、実際にどうなったか（うまくいっているのか・いないのか）はまだご紹介できる段階にありません。ドキュメントをメンテナンスしていくのはそもそも簡単ではなく、だからこそ従来の方針のような「書き手の書きやすさ」を重視するという方針にも意味がある（最初から読み手の利便性を100%満たすドキュメントを書けるのであれば苦労はしない）わけですから、今回立てた方針を適切に実行できるかどうかも不透明です。 しかし、社内向けとはいえチーム外にAPIを提供するチームとしては、ドキュメントをプロダクトの一部として捉え、コードと同じくらい大切にする必要があります。ソフトウェア自体に不具合がなくても、ドキュメントが不足していたり誤解を招くものであったりした場合、使い方を間違えることでシステム全体としては正しく動作しなくなってしまうこともあるわけです。「ドキュメントをプロダクトとして扱う」という考え方は 『エンジニアのためのドキュメントライティング』 でも語られています。 pub.jmam.co.jp また、私個人としては、これまで他の開発者にクライアントとして使ってもらうソフトウェアをメンテナンスする経験がほとんどなかったので、これまでに形成してきた自分自身のドキュメンテーションに対する考え方をアンラーンする必要を感じています。今回のチームとしての方針の転換をいいきっかけとして、プロダクトの一部としてのドキュメントに真剣に向き合っていきたいと考えています。 「株式会社エス・エム・エス Advent Calendar 2023」 、明日4日目は、 @soranakk の記事を予定しています！ *1 : なぜこのような構成になっているかは割愛します。 *2 : 厳密には、リニューアルプロジェクトではフロントエンドとバックエンドがGraphQLのAPIで通信するアーキテクチャとなっているため「ユーザーが触るWebアプリケーション」はフロントエンドだけなのですが、ここでは簡略化のためバックエンドの部分も含めて「ユーザーが触るWebアプリケーション」と記載しています。 *3 : 当初は Swagger UI 、現在は Redoc を利用しています。 *4 : esaでは、ディレクトリ構造を作って記事を整理することができます。個々のディレクトリに相当する部分のことを「カテゴリ」と呼びます。

株式会社エス・エム・エス Advent Calendar 2023 エス・エム・エスで開発者をしている @koma_koma_d です。 今年もアドベントカレンダーの季節ですね、ということで、今年はエス・エム・エスでもアドベントカレンダーをやります！ qiita.com 記事は、このブログ以外に、各メンバーの個人ブログ、Qiita、Zennなどの様々な媒体に投稿される予定です。公開された記事はXのアカウント @BM_SMS_tech で随時シェア予定ですので、ぜひアカウントをフォローしていただけると幸いです！ 誰が何を書くのか 参加するメンバーは、 開発者 SRE エンジニアリングマネージャー QAエンジニア プロダクトマネージャー など、プロダクト開発に関わる多様な職種が集まっています。 内容についても、業務に関わることに限定せず、各メンバーの好きなテーマで書いてもらいます。エス・エム・エスのメンバーがどういう技術に興味を持っているのか、日頃どのようなことを考えながら仕事をしているのか、などを知っていただける機会になると嬉しいです！ 初日である明日の執筆者は、フロントエンドエンジニアの setoh です！お楽しみに！ setoh が過去に執筆・登場した記事 tech.bm-sms.co.jp tech.bm-sms.co.jp

はじめに エス・エム・エスのヘルスケア事業部所属のエンジニアの今村と申します。この会社に転職してきて気がつけば10年以上となります。 その間に、新規登録の処理を何度も何度も設計してきました。設計とは言うものの、入力用の画面を用意しPOSTしたらその値をサーバーサイドで検証してDBに登録するという大枠の流れは同じです。しかし最近になって、それで本当に良いのか？ と再考する機会がありました。 今回は、その時に再考した内容を整理したいと思います。 再考することになった経緯 仕事では、webサービスの改善・運用の他、業務で使うkintoneのカスタマイズも担当しています。 ある日、kintoneアプリのカスタマイズ要望がありました。具体的には、画面内の項目Aに特定の値を入力して保存した場合、ダイアログを表示して「次に担当者がとるべきアクションを明示したい」というものです。 kintoneには固有のイベントハンドラがあり、データの保存が成功したことをトリガーにして処理を実行することができます。今回はこれを使えば簡単に実装できると思っていました。 前提として、今回の値は新規登録と更新のどちらのケースでも入力されうるものです。そして、kintoneの画面は、新規登録を行っても完了ページには遷移せず、その画面内の項目が全てdisabledになるのみです。もしそこで「編集ボタン」をクリックすると、disabledが解除され、各項目の値を変更したりできるのです。業務アプリケーションではkintoneに限らず、よくある仕様と言えるでしょう。 しかしこの仕様、合理的なように見えますが、ユースケース次第では厄介なことになります。 更新画面ではURLで対象レコードのIDを指し示している必要があるものの、新規登録画面入力時には、まだIDが払い出されていません。このためkintoneでは、登録完了のレスポンスをAPIから受け取ったあと、フロントエンド側でリダイレクトをかけて編集画面を表示していました。 その結果、新規登録時の送信成功イベントハンドラを使って表示したダイアログは、一瞬だけ表示されるのみで、すぐリダイレクトされることがわかりました。これではイチロー並みに動体視力が発達した人しかメッセージを読み取ることができません。 結局、新規登録時には処理成功のイベントハンドラでCookieを発行し、編集画面が表示されたタイミングでCookieの有無をチェックしてダイアログを表示し、その後にCookieを削除するという煩雑な処理が必要でした。 そこで、ふと思ったのです。「新規登録では、入力完了後にデータを保存し、IDを払い出すのが唯一の正解なのか？」と。 新規登録という名の更新 気になった私は、早速世の中のさまざまなwebサービスはどうなっているのか調査しました。結果、一部のサービスでは、新規登録を行うと入力開始前にIDが払い出されて、新規登録画面という名の更新画面を表示していることがわかりました。 メジャーなサービスでは、Google Workspace(Docs、Sheets)、note、Zenn.devがこのような設計になっています。これらのサービスでは、一度登録画面を表示した後に入力を行わず離脱すると、そのデータは一覧上には表示されません。しかしURLを直接入力すれば表示できます。数日経つと、URLを入力してもアクセスできなくなります。以降ではこの方式を便宜的に「登録編集共通方式」と呼ぶことにします。 登録編集共通方式のメリットとデメリット この処理方式、主にフロントエンド観点では、実装が楽になるというメリットばかりとなります。一方バックエンドは、フロントエンドの実装が楽になったしわ寄せとして、主にDB周りの設計に複雑さが生じます。以下詳しく整理してみます。 メリット フロントエンド側の考慮事項が減る 登録と編集を共通化してしまえば、新規登録を編集と同等の挙動に見せかけるための様々な工夫が不要になります。当然、実装もシンプルになると言えます。 多重POST問題から解放される IDが払い出されていない場合、同一の投稿がすでに送信されていないか判断する必要があります。フロント側でボタンをごく短時間不活性化すれば良いとの意見もありますが、ユーザーは数秒後に同じ内容を送信してくることもあり、バックエンド側での多重POST判定の処理が必要なケースもあります。 他方、IDを払い出す場合、内容如何によらず、POSTされたら素直に上書き保存すれば良いだけなので、先述のような考慮は不要になります。 デメリット テーブル設計が複雑になる この設計を実行に移すには、未入力の状態でも登録ができるように、多くのカラムでnullを許容する設計にするか、IDを払い出すための最小項目の親テーブルと実データを格納する子テーブルの関係で設計する必要があります。 チームの方針として、テーブルの項目に原則nullを使用しないことになっている場合は、自ずと後者の設計を選択することになるでしょう。 新規登録時点では親テーブルのレコードのみを登録してIDを払い出し、最初のデータ保存のタイミングで子テーブルのレコードを登録します。これはアプリケーションの都合にDB設計が従属する形となるため、受け入れられないこともあるでしょうし、受け入れられたとしても、テーブルの管理が従来より煩雑になるのは間違いありません。 ごみレコードが沢山できる/定期的に削除処理が必要になる 新規登録の画面を開く都度にレコードが作成されるため、結局その後保存されずに離脱されてしまうと、そのレコードは、ゴミとして蓄積していくことになります。 DBの性能とシステムの規模によっては、パフォーマンスの劣化を早めてしまうため、定期的な削除が必要で、その場合バッチ処理を別途作成することになるでしょう。 まとめ 以上の通り、 登録編集共通方式について、採用した場合の具体的なメリットとデメリットを整理しました。 繰り返しになりますが、登録編集共通方式ではフロントエンド周りの開発コストが削減できそうですが、バックエンド周りの開発コストは増える可能性がありそうです。 例えばフロントエンド周りの機能が今後複雑化していきそうな場合には、バックエンド側が開発コストを多く負い、フロントエンド側をシンプルに保てる登録編集共通方式のほうが長期的に優れた結果をもたらすでしょう。一方、従来の会員登録のような機能では登録編集共通方式の採用はデメリットが目立つ結果になりかねません。 このため、プロジェクト全体の方針やユースケースに応じて、既存の方式と登録編集共通方式を比較検討しながら、その時々でベターな選択をしていけると良いかなと思います。

技術責任者の @sunaot です。エス・エム・エスのプロダクト組織では、カンファレンス参加や専門書籍による学習などを強く推奨して、金銭的・時間的な支援も広く行なっています。 取組み自体はとくに最近の Web の会社では珍しいものではありません。ただ、位置付けや考え方を表明しているのはやや珍しいらしく、入社してきた人やカジュアル面談の場などで説明すると面白がってもらえることがあります。そこで、今回はその背景や考え方を説明してみます。便宜上ソフトウェアエンジニアを例に説明をしますが、基本的にはプロダクトマネージャーやデザイナーなど他の職種においても同じことが言えると考えています。 学習への投資は責任を果たしてもらうための必要経費 エス・エム・エスのプロダクト組織では、カンファレンス参加や書籍の購入といったものに会社のお金や業務時間が使えることを 福利厚生として位置付けていません 。では、報酬ではないのだとしたらどのような位置付けなのでしょう？ 実は、これは十分なクオリティの仕事をする上で当然必要なもの、 責任を果たすための過程で必要なものの一部 として提供をしています。 元々、エンジニアを始め、プロダクト開発の仕事というのはタスクを終えることが仕事ではなく、一定の品質水準を満たすものを届けることが仕事の完了条件に含まれています。そして、その自律の求められ度合が高いのが特徴です。ソフトウェアは目に見えないのでぱっと見で品質の判断ができず、自律しないと手抜きができてしまいます。さらに、目の前でやる仕事が全て自分の知識の範囲に収まることは非常に少ない仕事であることも特徴です。エンジニアであれば、大体知らない技術要素であったり製品だったりが関わってきます。 そのため、成果物に対してプロフェッショナルな水準の仕事をするとなったときに「調べる・学習する」ということが仕事の当たり前の一部になってきます。そして、仕事のたびに全部を新しく調べるわけにはいかないとなると、自分の道具を磨くための学習をし続ける必要があります。 必要な品質を満たすために十分な調査・学習をしてほしい こうした見方をしているので、今のエス・エム・エスのプロダクト組織では学習をするということに対して積極的に支援をしています。それは仕事に必要だと知っているし、明らかに投資に対してリターンが大きいからです (全部を学習し終えた人を転職市場から探して採用してくるのはとても難しくコストもかかります)。 "知らないことを調べることも仕事の内で、自身でクオリティの判断ができないうちに仕事を期限だけに対して終わらせないでほしい。必要な品質に対して調べることをしてほしい" ということもよくメンバーに対して伝えています。これも同じ理由で、それがまともな品質のエンジニアリングの仕事に必要だからそう求めています。仕事の時間を使って経験のない技術の調査をしてよいと聞くと、一見その人の時間への優しさのように聞こえますが、実はそうではなく仕事のクオリティへの厳しさゆえの方針だったりします。 直接は目の前の仕事に関係しない勉強会を仕事の時間にやっていたり、カンファレンスへの参加を業務時間に入れているのも同じ理由で、けっきょくいつ学ぶかだけの問題で、そうして積み重ねた学習がなければ必要になったときに一から全部学ぶことになってコストが高いから積極的に奨励している、という背景になります。そういう仕事だから、ですね。 もちろん、そうした学び合う環境があるほうが働いていて楽しいとか、優秀な人と学習すると刺激になって働きがいがあるとか、学習を支援している環境のほうがわいわいしていて周りの人も学ぶ気持ちになるとか、色々副次的なメリットもあるとは思っているのですが、一番の理由は「そういう仕事で、必要だから」という考え方をしています。 まとめ この記事のまとめです。 エス・エム・エスのプロダクト組織ではカンファレンス参加や専門書籍・コンテンツによる学習を推奨し、広くその支援をしています。 これは個人の学習支援のためという以上に、そのときにマーケットやプロダクトが必要とする水準のクオリティの仕事を求めるという姿勢から来ています。それまでの経験で得た知識・スキルでできる範囲のクオリティの仕事をしていくのでなく、必要であれば都度学習しながら未知の課題にも取り組める人とチームでいるための方針なのです。

はじめまして。株式会社エス・エム・エスで介護事業者向け経営支援サービス「カイポケ」のQA組織の運営をしている星と申します。2020年1月に入社し、チーム活動やQA組織づくりを通じて体制強化を進めています。 本記事ではこれまで行ってきたQA組織強化に対しての状況アップデートと、それに付随して行動指針や大切にしていきたいものを言語化するまでの過程をまとめています。 他ロールのメンバーも弊社テックブログにチームとしての価値観を紹介する記事を投稿していますが、QA組織としてカイポケ含め、エス・エム・エスのサービスと開発組織をどう捉えているか、その中でどういった思いを大切にして品質に対して向き合っていこうと考えているのかを記事にしています。 QAエンジニアの方のみでなく、チームで品質を作り込んでいくことに興味がある方は是非ご一読頂けると嬉しいです。 QA組織のこれまでと現状 以前、弊社テックブログにQA組織として過去と未来についての話を投稿しましたが、私が入社した2020年も引き続き、記載されているようなQAプロセスの浸透、メンバーのアサインや検証に対する各施策の細かい実行、小さな改善を積み重ねていくことで体制強化を図っていました。 tech.bm-sms.co.jp 弊社は複数のチームに分かれて開発を進めておりますが、私もカイポケの1チームを主軸にjoinして、実作業に深く携わりながらプロセスを意識した日々の品質活動や実際の検証業務を行っておりました。 QA含む開発チームからの協力の中で、改善活動やコミュニケーションを積み重ねてきましたが、その活動を経てカイポケや弊社の事業を取り巻く環境や特性の解像度を上げていくことが出来たと実感しています。入社から3年が経ち、チーム横断の開発時の検証や介護報酬改定という大きなイベントも経験しました。 その中で、エス・エム・エスとして取り扱っているサービスがもっているミッションの解像度の高まりもあり、各チームで取り組む品質の担保・向上のためのテストプロセスに柔軟性を持たせて、進めていくことの重要性を感じ、改めてQA組織としての行動指針を言語化していきたいと考えるようになりました。 こういった考えにシフトしたのは、取り組んできた以下の課題について、一定先が見通せる状態になってきたという背景があります。 QAプロセスの安定化 各チームにて一連のテストプロセス浸透が進められている。 目的に即した形かつリスクを念頭に置いた状態で、対応内容ごとにプロセスの要不要判断をチームで議論する土壌も出来つつある。 QAチームの品質活動の定常化 リリースに向けた検証対応以外の品質活動を各チームで考え、進められる状態になった。 E2Eテストの自動化や属人化を防ぐ活動、QAメンバー以外との連携を各チームで検討しながら進められている状態。 このような各メンバーによる小さな課題解決の積み重ね、育成や採用での体制強化の結果があり、前述の思考へ舵が切れる状況になったということが大きいと感じています。 QA組織から見たカイポケや開発組織について 前提として、私含めたQA組織が弊社のサービスや開発組織をどういう視点で捉えているか触れておきます。 エス・エム・エスは医療・介護・ヘルスケア・シニアライフの4つの領域で高齢社会の情報インフラ構築をミッションとしている会社です。エス・エム・エスが行っている事業を取り巻く環境の変化は激しく、極めて不確実性や複雑性が高いものを取り扱っているという認識を持っています。介護業界も例に漏れず変化が激しい業界ですし、3年に1度の介護報酬改定という大きなイベントも定期的にあります。 tech.bm-sms.co.jp そのため、QA組織を含む開発組織としてのフェーズの変化に加えて、市場やニーズの変化に対応していくべく、QA組織としての考え方を継続的にアップデートしていく必要があると考えています。 その他の背景としてはカイポケリニューアルの始動と開発組織のバリュー言語化があります。 リニューアルプロジェクトは、従来のカイポケの追加開発・制度対応のプロジェクトとは性質が様々な点で異なるため、QAチームとしてもその性質に適応した活動をしていく必要性を感じています。 また、これまでQA組織の価値観の言語化は独立して行われてきましたが、今回開発組織全体のバリューの言語化が始まったことで、QA組織の価値観の言語化を開発組織全体の価値観と整合性の取れる形で行う良いタイミングだと考えました。 リニューアルプロジェクトについては、EMの酒井さんの記事を、 tech.bm-sms.co.jp 開発組織のバリューの言語化については、技術責任者の田辺さんの記事をそれぞれご覧ください。 tech.bm-sms.co.jp QA組織の行動指針検討の過程 始めに、行動指針の検討とQA組織が大切にしているものを言語化していくにあたり、大事にしたかったポイントを書きます。 エス・エム・エスのサービスの特性、組織として持っているミッションと開発スタイルを踏まえて言語化し、貢献に繋げたい。 あくまでも大切にしたい価値観、考え方の指標にする。これをベースに各チームでも落とし込みや最適化が出来るようにしたい。 QAエンジニアとして楽しみながらチャレンジができるものにしたい。 適宜見直すことを前提に、なるべくシンプルかつ目的にピンポイントな言語化をしたい。 行動指針を定義していくにあたり、次に挙げる3つの要素の読み解きと洗い出しから言語化を進め、それをベースとして検討をしていきました。 QA組織の行動指針検討に用いた要素 ☆エス・エム・エスの「サービスの特性や開発スタイル」の読み解き 前述の「カイポケの特性」や弊社の開発スタイル、開発組織全体のチームバリューを読み解いて可視化していきました。その中でQA組織がどう貢献していけるか、どう貢献していきたいかを議論していきました。 ☆「アジャイルテストの10の原則」の読み解き、活動とのリンクづけ 活動や日々の仕事において大事にしたい点として、『Agile Testing Condensed』にもある「アジャイルテストの10の原則」の考え方があり、上述のサービスや開発組織の特性、取り組んでいきたい活動をテストマニフェスト *1 と掛け合わせた形での可視化を進めようと考えました。 leanpub.com ☆QA組織として「取り組んできたこと、やっていきたい品質施策」の洗い出し 現状のQA組織と各開発チームの品質に関わる取り組み、継続してやっていきたい取り組みを洗い出しました。新規で取り組んでいきたいことだけでなく、「QA組織として過去と未来についての話」でも記載があったE2Eテストの自動化であったり、連続性がある検証といった要素も継続取り組みとしてピックアップしています。 QA組織の行動指針言語化 これらの要素を踏まえた検討を繰り返し、大きく3つの行動指針へ落とし込んでいきました。 行動指針と実際の動きのイメージを結び付けやすくするため、一例としてユーザーストーリーマッピングや探索的テストといった形で具体的な活動ともリンクさせて言語化しています。 ☆継続的テスト リリースを含めたプロセスの最適化(高速化や安定化含む)を目的とし、一連の開発プロセスを通じた改善に向けた前倒しテスト、フィードバックのサイクルをまわしていく活動が重要と捉えています。 これによって、不確実性が高い業界のサービスであるという特性に対し、品質のキープと向上を見据えつつも、状況に応じて最適なプロセスにチューニングするといったアプローチをとれるようにしていきたいという思いがあります。 ☆価値に対するテスト ユーザーの課題感や実際の業務プロセスを理解し、最優先に考え続け、それを品質活動にも適宜取り入れていくことを大切にしていきたいと考えています。 前述の通り、社会の変化に対して貢献していくことが大きな価値になるサービスであると捉えています。そこに向けて大切にしていきたい価値観となっています。 ☆チームで品質保証 各ロールの専門性を持ち、協働して開発を進めることで、難解な制度にも安定した品質で対応していけるように進めたいと考えています。 複雑性が高い業界のサービスであるという点を特に考慮し、PdMやエンジニア、ドメイン知識に秀でたメンバー含め、チーム全員で取り組んでいく意識を持つことを言語化しています。 行動指針のひとつとして「価値に対するテスト」を掲げていますが、前述の市場の変化や定期的な報酬改定を踏まえて、ユーザーが継続して当たり前の業務プロセスを通せるかということも大きな「価値」となると考えています。 そのため、新しく生み出していく価値の品質にフォーカスするだけでなく、E2Eリグレッションテストを駆使し、既存の価値も担保し続けるという意思は変わらず強くあります。 弊社のQA組織としては既に根付いている価値観ではあるため、行動指針としての定義や言語化、アクションとしてあえての記載はしていないですが、取り扱っているサービスの特性上、ここも非常に大事なポイントと捉えているということを補足しておきます。 完成したものについて社内公開や共有を進め、今後も引き続き活動への落とし込みとブラッシュアップをしていきたいと考えています。 行動指針をベースに取り組んでいる活動の一例 今回言語化した価値観をベースにして、既に各アプリチーム内でQAチームが関わっている活動、主導して進めている活動がいくつかあります。 ☆実例マッピング 早期の開発内容理解、テストスコープの共通認識化でテスト分析や設計のスピード向上、ふるまい上で気にしているポイントをフィードバックすることでの手戻りやリスク低減をメイン目的として取り組んでいます。進め方自体もチーム内で振り返りをおこない、随時精度を上げている現状です。 leanpub.com ☆業務フローの理解と顧客価値を踏まえたテスト戦略の定義 リリースや機能開発ごとの提供価値の読み解きから、テストレベルの最適化やテスト分析、テストカバレッジの共通認識化といったチーム内での価値共有をメイン目的としています。複数アプリチームで活動していることから、横断的な視点も必要になってくるため、引き続き精度を上げるように日々開発しているものの価値を考え続けています。 ☆開発者とのテスト最適化検討 複雑なシステムに対して、チームで品質担保をしていく足がかりとして取り組んでいる施策です。エンジニアとQAでお互いがやっているテストをより深く知っていくことで、チームで担当している機能に対しての共通認識化、該当箇所の開発対応の難易度すり合わせとしても活用していけると考えています。 ☆E2Eテスト自動化 引き続き、E2Eテスト自動化に対しての施策を重点的に進めています。以前はテスト戦略の策定や設計、実装面での課題も多くありましたが、今ではリグレッションテストとしての運用やプロセスへの組み込みも進められています。今後も活用シーンが更に増えてくることを見込んでおり、運用/保守の検討にも力を入れていっています。 取り組みの詳細や効果については改めてテックブログ内でも公開したいと考えていますが、まずは一例として紹介しました。 前述の通り、カイポケ開発は複数チームに分かれて運用しており、それぞれがもつ担当アプリの特性やチーム状況等も踏まえ、各チームで最適な施策を模索し、取り組み活動と改善のサイクルを回しています。 その中で、今回言語化に至った「大切にしていきたい価値観」をベースに品質への活動も考え、取り組みを続けてきている組織だということを、言語化を通して再認識することもできました。 これからのQA組織 エス・エム・エスの開発組織には、ユーザーに対しての価値を考え続け、作り込み、継続的に提供していく思いが強いメンバーが多く在籍しています。 開発組織のチームバリューにもある通り、変化し続ける課題に対しての動き含めて、柔軟性と目的をもった品質活動を定義してチャレンジしていける組織だと思っていますし、それに対して技術責任者、エンジニアリングマネージャー、他ロールの方々からの協力を沢山もらえる環境です。 もう1点、今回公開した行動指針やそれに伴う活動については、落とし込みも含め、見直せる点や精度を上げていける点が非常に多く、取り組みとしてもこれから積極的にチャレンジしていきたいものを含んでいます。 例えばユーザー理解から、それを検証や品質活動としてフィードバックしていくことに対しても、まだまだ沢山の取り組めることがあると思っています。 tech.bm-sms.co.jp QA組織としてもまだまだ多くのチャレンジやキャリアアップが出来る環境であると思っていますし、「過去と未来についての話」にも記載している通り、将来的には「サービスを運営する上で全ての品質に関わっていきたい」という思いは継続してあります。 そして、それを実現するための仲間もまだ足りない状況です。 今回ご紹介させていただいた、QA組織として大切にしていきたいと思っている価値観に興味を持ってもらえた方がいらっしゃれば、是非お気軽にご連絡ください！ *1 : 参考: 「【翻訳記事】テストに対する考え方「Testing Manifesto」 - ブロッコリーのブログ」 https://nihonbuson.hatenadiary.jp/entry/TestingManifesto 2023年10月12日閲覧

11月2日「Qiita Night～プロダクトマネジメント～ 」でLTを行いました 11月2日に開催された「Qiita Night～プロダクトマネジメント～ 」で、プロダクトマネージャーのキム ダソムが「BtoB の顧客理解が捗るミニリサーチ」のタイトルでLTを行いました！ increments.connpass.com 資料「BtoB の顧客理解が捗るミニリサーチ」 こちらが当日使用した資料です。 speakerdeck.com 当日に発表を聴いていただいたみなさま、イベント主催のQiita株式会社のみなさま、ありがとうございました！ 2024.2.21 追記 発表の内容をログミーTechさまで記事にしていただきました！ logmi.jp

こんにちは、WEBエンジニアとして2023年7月に入社した髙田です。この記事では入社エントリとして私が転職先としてなぜエス・エム・エスを選んだかというのを通して、少しでもエス・エム・エスの魅力を伝えることができればと思っています。 私のこれまで 前職ではベンチャー企業で開発組織がほぼない状態のところからある程度の形になるまでを体験し、Ruby on Railsを主体に開発業務やチームリーディングに従事してきました。その中で、転職する間近まで事業責任者に近いポジションの方と一緒に仕事をすることがあり、企業成長のための売上をつくるためにどのようにエンジニアリングリソースを使うべきかということを考えさせられる場面が多くありました。 買ってもらえるプロダクトを提供するために限られた人員でどう開発を進めるか、ただでさえ時間的制約が多い中で同時多発的に発生する課題へどう向き合うか、そしてその状況下で事業側の求める要求にどう沿わせていくべきか、そんなことを考えることが多かったように振り返ると思います。 成長に沿わせながら課題解決をさせる難しさはその時に身をもって痛感しました。そして同時に「会社の成長を考え、同時に難しい課題を解く」ということをやり続けることは、自分自身の糧になる部分が非常に多いということも感じていました。 そうしたことをやっていく中、転職を思い立つタイミングがやってきました。 入社を決めたきっかけ 転職を思い立った理由は様々な理由が折り重なった複合要因ではあったのですが、次の会社を探すにあたっては「事業や収益拡大に貢献できる」「健康的な生活サイクルで仕事をできるか」ということを軸にして色々な会社とカジュアル面談などをしました。 というのも事業の拡大を目指す過程では様々な課題が降り掛かってくるので、それをこなしていくと自然と自分自身の成長にも繋がり、ひいては会社も大きくなるので得るものが多いと思ったからです。ただこのように事業の拡大を目指す場合にベンチャーなどではハードワークとワンセットで語られることもあり、自分の中で「健康的な生活サイクル」という軸もワンセットで考えていました。 そんな軸を持ちながら色々な会社にお話を伺ったりしていたのですが、最終的に「エス・エム・エスに決めよう」と思ったのは選ぼうと思った軸に関して満たしている会社であり、「会社の成長を考え、同時に難しい課題を解く」ということをやっている会社だったからでした。 こちらに関しては 直近で公開された記事 を見ていただいたほうがわかりやすいのでそちらを見ていただければと思うのですが、面接を通しても部分的に記事内で紹介されていることの説明があり、非常に共感できる部分が多いので転職を決めたというところがあります。 自分自身がやれることを着実にやる そんなこんなで現在転職してからしばらく経つのですが、現在は看護学生向け就職活動情報「ナース専科 就職ナビ」のWebアプリケーション開発に携わっています。 サービスとしては歴史が長いため様々な機能が実装されており、それが故に仕様が複雑化しているものも数多くあります。例えば合同説明会の機能です。もともとはイベント会場などで行われる合同説明会のために作られていたものでした。しかしながら、コロナ禍でオフラインの開催ではなくなり、オンライン開催の形に添わせる必要が出てきたため、仕様として方向性の違う拡張をしなければならず、複雑な構造になってしまっていました。 そのような状況に対処すべく、直近で私を含めて新たにチームメンバーが増え、人数に沿った開発のやり方をシフトチェンジしている真っ最中です。私自身は過去にチームの拡大をいくつか経験してきたので、その経験をもとに現状のチームでは何がベストなのかを模索しながらチーム内で提案や議論をしながら進めています。また、元々のチームメンバーも私の提案に耳をしっかりと傾けてくれるので、新しい人の発言もしっかりと受け止めてもらえるのはもともとの会社の文化醸成のたまものなのかな、と思っています。 私個人としては自分の過去の経験を活かしつつ、自分自身がチームに貢献できることを探し、チームの一員として着実にできることを増やし、ひいてはチームのポテンシャルを上げていくということを直近では取り組んでいます。 サービス成長の結果生み出されてしまった複雑さと向き合いながら、もっと良くしていくためにどういうアクションを起こすべきか、という難しい課題に取り組むことは自分の成長にまた寄与してくれると信じて日々職務に取り組んでいます。 やれることがたくさんある 私が携わっているのはエス・エム・エスの開発におけるほんの一側面であり、様々なプロダクトや開発チームが存在している状況です。様々な選択肢があるのもこの会社の特徴だと思います。どの方も「誠実」であるなということは感じているので、非常に気持ちよく仕事ができるのではないかと思っています。もしエス・エム・エスにご興味を持たれたらぜひ採用サイトを覗いてみてください。

2023年春、エス・エム・エスのプロダクト開発部にデータプラットフォームチームが立ち上がりました。データプラットフォームの構想から経営層の意思決定、チームづくりまでがスムーズに進行し、現在は技術選定を終え、実証の段階にまで駒を進めています。 ここまでスピード感をもって進めることができているのは、プロダクト開発部のバリューである「マーケットへ向けて動く」という意識が、経営層からチームメンバーにまで浸透していることの現れであるともいえます。「組織や各メンバーの役割だから」ではなく、「マーケットへ価値を提供できているか」という視点でそれぞれが責任感を持ち、プロジェクトに取り組んでいます。 今回は、データプラットフォームチームをリードする三浦に、データプラットフォーム立ち上げの背景や展望、またマーケットに対し日々どのように向き合っているのかについて聞きました。 顧客に価値提供するプロダクトとしてのデータプラットフォーム ——三浦さんの経歴や普段の業務内容について教えてください。 ソフトウェアエンジニアとして約15年のキャリアがあり、ガラケーのサービス開発や社内向け分析基盤の整備、小売業の機械学習パイプライン整備などさまざまな案件に取り組んできました。エス・エム・エスには3年ほど前に入社し、介護事業者向け経営支援サービス「カイポケ」の技術的な課題解決のための取り組みを始めていきました。現在は、プロダクト開発部のカイポケ開発グループで、カイポケのリニューアルをリードしています。エンジニアリングだけ/プロダクトマネジメントだけではなく、リサーチから、プロダクト戦略立案、リソース調達などあらゆる領域をカバーしています。 ——現在カイポケでは、データプラットフォームの構築・整備を進められているそうですね。データプラットフォームの構想はどのような問題意識から生まれたものなのでしょうか。 介護サービス関連のデータが散在することで、利用者の全体像が見えづらくなっているという背景があります。詳細はこちらの記事（ 「なぜ介護事業者向け経営支援 SaaS「カイポケ」でデータプラットフォームをこれから作るのか」 ）にまとめています。 介護職員は、介護サービスを提供する事業所のほか、複数のサービス事業所や居宅介護支援事業所、医療機関などと日々連携していくことが必要となりますが、現状では、情報共有には電話とFAXが使われることがほとんどで、利用者のデータが分散してしまっています。 また、介護サービスは入退院の前後に提供されることが多いため医療との連携も不可欠ですが、医療ではバイタルデータなど定量的な情報を扱うのに対し、介護では普段の生活の様子など非構造化データの重要性が高まります。要配慮個人情報を扱うことから、高いセキュリティも求められます。 このため、利用者を軸にデータを集約・構造化し一元管理できるプラットフォームをつくり、介護サービス関連の事業所を横断してセキュアにデータ共有できる情報インフラの構築を目指すべきだと考えました。 ——プロダクトとしては具体的にどのようなものをイメージされていますか。 データプラットフォームや分析基盤というと社内向けのイメージがありますが、最終的には、カイポケのお客さまに対して価値提供できるプロダクトにしていきたいと考えています。現行のカイポケにおいても情報共有機能は一部ありますが、事業所と利用者の1対1で共有する形となっています。これを、1人1人の利用者データに対して、各サービス事業所、介護職員、医療などあらゆるステークホルダーが適切な状態でアクセスできるようにしていくイメージです。 出典: 厚生労働省 「地域包括ケアシステム」 顧客視点で課題感を解像度高く伝え、経営陣の理解を得る ——データプラットフォームに関するこれまでの取り組みについて伺えますか。 日常的にリサーチ活動をしているなかで、2022年秋ごろからデータプラットフォームの必要性を感じるようになり、大まかな構想を練り始めました。当時はカイポケの新アプリの方向性が固まり、スケジュールが見えはじめた時期だったので、データプラットフォームの取り組みに時間を掛けられるようになったという背景もあります。2022年末ごろまでに社内やアドバイザーへのヒアリングを重ね、2023年に入ってからカイポケの事業責任者の合意を得て具体的に動き始めました。2023年2月には、経営陣へプレゼンテーションを行いました。 ——経営陣の反応はいかがでしたか。 社内のデータ分析関連組織を再編成する話が動いていたので、そことのつながりをどうすべきかという議論はありましたが、データプラットフォームのコンセプト自体には賛同を得られました。エス・エム・エスのミッション *1 と密接に関わっているプロダクトであり、お客さまにとってどのような価値を持つものなのか理解してもらえたと感じています。 プレゼンでは、会社として長期的な視点で考えた際にどういう意味を持つプロダクトなのかを意識して話すよう心がけました。また、現行のカイポケの機能でのデータ連携による価値を評価していただいているお客さまの声や、エス・エム・エスのアドバイザーからいただいたデータ連携の要望などを紹介し、マーケットの現状についても整理しました。経営陣への提案がスムーズに通ったのは、お客さまやユーザーの観点から現在の課題感を解像度高く伝えられたことが大きかったと思っています。 実際にプレゼンに利用した資料の一例 あらゆるレイヤーのメンバーが「マーケットへ向けて動く」を意識 ——経営陣としても「マーケットへ向けて動く」という意識が高いということですよね。 エス・エム・エスの入社最終面接で、代表の後藤からは、戦略を立てる際には長期かつ業界全体の視点をもって見渡すことに加え、フワッとならないよう会社や顧客の成果を解像度高く設定し、その成果から逆算して主体的に動いていけなければ、エス・エム・エスにおいてはリードしていく人材にはなれないと伝えられました。 経営との進捗会議の中で後藤からカイポケと隣接するマーケットで過去の事例を紹介してもらい、そのファクトからマーケットの見立てを説明していた時の解像度の高さに驚いた場面が何度もありました。「マーケットへ向けて動く」はエス・エム・エスにおいては十分に文化になっていると感じています。 ——三浦さん個人としては、「マーケットに向けて動く」というバリューを普段の業務のなかでどのように意識されていますか。 最初に意識を持つようになったのは20代後半に転職したコンシューマ向けWeb サービス企業にエンジニアとして転職してからになります。その会社では常に自分の仕事を誰に評価されたいのか *2 というところを起点に仕事をしていく文化でした。 さらに大きな転換点となったのは前々職の国内EdTech企業で、幼稚園生向けのiPad用の教材を開発していたときのことです。児童向け遊戯施設を国内外に展開する企業とともに、タイ・バンコクの遊戯施設でその教材をトライアル導入することになったのですが、実際に設置してみたところ現地の方からまったく利用されていないとの指摘を受けました。ビデオ通話で現場の様子が中継され、自分たちの遊具の周りにだけ子どもたちが集まっていない光景を見たときはショックでしたね。急いで現地に向かい、まずは実際の子どもたちの動きをみて課題を整理してきました。さらにその後は、開発チームのメンバー全員で現地に行き、改善を繰り返していきました。最終的には大盛況で終えることができたのですが、この経験を経て、プロダクトは最終的にユーザーの行動を変えるものであり、その行動に至る背景や目的、その後のアクションなどを具体化しなければ、最終的なプロダクト像は見えてこないと思うようになったんです。 ——現在ではどのような形でマーケットを意識されていますか。 社内のドメインエキスパートやアドバイザーに日常的に話を聞いたり、リニューアルのコンセプトを検証するために現場へ同行して議論したりなど、基本的には現場に足を運ぶようにしています。また、厚生労働省が主催する介護分野における生産性向上推進フォーラム *3 や健康・医療・介護情報利活用検討会介護情報利活用ワーキンググループ *4 を視聴したり、財務省による予算執行調査 *5 の中から社会保障費に関わる分野の調査を調べて、介護の現場における情報の利活用の現状や今後についてリサーチを継続しています。 特に現状のカイポケでは、施設系の介護サービスに対応できないという課題があります。この課題に対応するために、事業責任者とともに現場へ向かい、実際の業務や利用者の様子、IT環境も含めた周囲の環境などを把握し、帰り道に業務の課題をディスカッションしたということもありました。 利用者にとってプロダクトは、画面の中だけで完結するものではありません。実際の環境があってはじめて利用者の行動につながるものとなるので、現場を理解していくことは非常に重要です。 マーケットに向き合っていれば、「未来にある普通」がつくれるはず ——データプラットフォームチームのメンバーの特徴について教えてください。 チームづくりは経営陣へのプレゼンテーション後に本格的に動き始めました。データエンジニアリングや分析の領域は採用市場が小さいうえに、経験値を積んでいる人材となるとかなり希少で、メンバー集めには苦戦すると思っていました。しかし、タイミングと運がよく3名の副業メンバーが集まりました。狙ってやったわけではありませんが、「人が人を呼ぶ」という状態ができていたのかもしれません。 メンバーは皆それぞれ、データプラットフォーム構築を複数回経験しており、視座を高く持って自走できるレベルの人たちです。抽象度や不確実性が高い状況でもデータの持つ力を理解できるメンバーであり、介護事業者の業務構造や情報分断という社会課題の重要性、データを通してお客さまに価値を提供することに対して皆強く共感しています。 ——ここまでかなりスピード感を持ってプロジェクトを進められてきたように思います。何かハードルになった点はありましたか。 開発環境の整備やメンバーのスケジュールの工面など、立ち上げ時には多少苦労しましたが、比較的スムーズに進んでいます。長期視点かつユーザー視点で物事を考え、データの重要性を理解している会社だからこそできているように思っています。 ——データプラットフォーム構築に向けた今後の展開や課題について伺えますか。 技術選定、アーキテクチャの設計はできているので、現在は実証フェーズに移っていく段階です。チームメンバーに加え、SREやアプリ開発、バックエンド、セキュリティを担当するチームなどとの連携が始まるため、ステークホルダーのコンセンサスを取ることが今後は重要な動きになっていくと考えています。 ——最後に、三浦さん個人としてデータプラットフォームに掛ける思いをお聞かせください。 私としては、ドラスティックに業務や生活を変えるようなプロダクトよりも、「現在にはないが、未来にある普通」をつくっていきたいと思っています。当たり前であればあるほど、マーケットのシェアも拡大していくはずです。現場に足を運ぶようにしているのも、こうした考えがもとになっています。介護関係者が日々のケアで当たり前に利用するプロダクトを目指していきたいですね。 *1 : https://www.bm-sms.co.jp/company/mission/ *2 : https://jkondo.hatenablog.com/entry/20060422/1145674096 *3 : https://www.mhlw.go.jp/stf/kaigo-seisansei_forum.html *4 : https://www.mhlw.go.jp/stf/shingi/other-rouken_485753_00001.html *5 : https://www.mof.go.jp/policy/budget/topics/budget_execution_audit/index.htm

介護事業者向け経営支援サービス「カイポケ」のプロダクトマネージャーを担当している 田村 恵 です。 我々のようなBtoB SaaSでは、ユーザーや業務を深く理解することがサービスの価値を生み出す上で重要です。今回はどのようにユーザーからインプットを得ているのかを紹介します。 今回紹介する活動 私たちは、ユーザー業務に対する理解を深めるために、ユーザー事業所を月に1回ぐらいのペースで訪問しています。カイポケユーザーである介護事業所を訪問し、実際の業務や関連業務を見学することで、ユーザーの業務に対する理解を深める取り組みです。 業務を見学することの重要性 私たちのユーザー訪問では、単に訪れるだけではなく現場の活動を間近で見学し、ユーザーが日々どのような業務に取り組んでいるか、どういったところに課題があるのかを実際に目で見ることを重視しています。具体的な業務の実態を目にすることで、抽象的な概念から具体的な課題やニーズへとつなげることができます。 仮説を持たない姿勢で取り組むこと ユーザー訪問では、あらかじめ仮説を持つことなく、ユーザーの業務に没頭するよう心がけています。仮説を持つことは、既存の予断や偏見を持ち込む可能性があるため、ユーザーの実際のニーズや課題を見逃す可能性があります。そのため、素朴な疑問や興味を持ちながら、ユーザーの業務に没頭することで、真のニーズを探り出すことを意識しています。 デザイナーやエンジニアの参加 ユーザー訪問には、プロダクトマネージャーだけでなく、デザイナーやエンジニアも積極的に参加してくれています。デザイナーやエンジニアもユーザーの業務に対する理解が必要であり、プロダクト開発において重要な視点を提供してもらいたいからです。デザイナーやエンジニアの参加により、ユーザーの視点や現場の課題をより多角的に捉えることができます。 このことの重要性は、事業責任者の園田が書いた記事「 大規模SaaS「カイポケ」の意思決定を支える事業責任者の思考と技術 」でも触れていますが、自分たちのプロダクトを、ユーザーが現場でどのように使っているのかの肌感覚を得ることを大切にしています。 解像度を上げるための工夫 事前準備 ユーザー課題の解像度を上げるために、訪問前の準備として以下のようなことをしています。 ユーザー情報の確認 訪問させていただく事業所が法人設立からどれぐらい経っているのか、法人・事業所規模、カイポケをお使いいただいている期間、担当利用者数、毎月の請求実績などの情報を事前に確認しています。 訪問メンバーの現在地の確認 訪問するメンバーが入社後どれぐらい経っているのか、ユーザー訪問の回数、担当している領域などを確認し、状態にあった訪問先を選定したり、どのようなことをメインで確認するかを決めたりしています。 見学業務の事前レクチャー 訪問させていただく事業所で、訪問日にどのような業務を見学させていただく予定かを事前に訪問メンバーに伝え、必要に応じて実際の画面だとどのように操作をするのかをレクチャーします。 これによって、理想的な操作、遷移はこうだという情報を持っていくことができるので、ユーザーがどこで課題を感じているかの解像度が上がりやすくなります。 有識者の同行 ユーザー訪問には、社内のドメインエキスパート(介護業界経験者)やカスタマーサクセス担当者、セールスメンバーなどにも同行してもらっています。ドメインエキスパートやビジネス部門のメンバーは自身の専門知識や経験を通じて、より深い洞察を提供してくれます。彼らとの協力により、私たちはユーザーのニーズや要件をより高い解像度で把握することができます。その結果、開発チーム全体が的確な方向性を持ち、効果的なプロダクトを提供することができると感じています。 ユーザー訪問の効果と継続性 プロダクトへの直接的な効果 ユーザー訪問によるプロダクトへの直接的な効果として、やはりユーザーの課題にダイレクトに直面するので、生の声をプロダクトに反映させることができる点があります。 例えば、50〜60代の年齢層のユーザーであれば、「今の画面だと文字が小さいなぁ」という反応をいただくことができたり、「曜日の色が分かれていないと見えづらい」などといったフィードバックがあります。 副次的な効果 定期的なユーザー訪問を通じて、デザイナーやエンジニアが業務に対する高い解像度を持つことができるようになりました。彼らが実際の現場を見学し、ユーザーと直接対話することで、プロダクト開発における意思決定が迅速かつ的確に行われるようになりました。さらに、ユーザー訪問に参加したチームメンバーが「自分が訪れた事業所でも同様の課題がある」と気づくことがあります。これにより、私自身がプロダクトマネージャーとしても安心感を持つことができます。 また、ユーザー訪問時やユーザーインタビュー時に撮影した内容を、チームメンバーで見る上映会をすることがあるのですが、実際に訪問していないメンバーが参加してくれたり、「この人に喜んでもらえるプロダクトを作りたい！」というモチベーションにつながっていたりするので、とてもいい取り組みだと感じています。 さいごに ユーザーを深く知ることと解像度の維持は、私たちにとって非常に重要です。ユーザーのニーズや要件は絶えず変化しており、1回の訪問だけでは完全には把握できません。そのため、私たちはユーザー訪問を継続し、定期的に現場を訪れることで、ユーザーとの関係を深めています。今後も、私たちは常に最新の情報を得ながら、ユーザー中心のプロダクトを提供していきたいと考えています。

初めまして。 エス・エム・エスのBPR推進部EA推進グループの西田です。私の簡単な自己紹介からさせていただきます。大学卒業後、2017年4月に人材紹介会社に入社し、求職者集客のマーケティング業務を行いました。その後、2018年3月にエス・エム・エスにカイポケのインサイドセールスとしてジョインし、インサイドセールスの小チームリーダー、営業組織全体の営業企画、マーケティングと経験を積みました。2023年4月からBusinessArchitect（以降 BA）としてカイポケ全体の既存事業の高度化/社内業務の高度化・効率化を担当しています。 BAになったキッカケ カイポケでは、入社時点から業務基盤としてSalesforceをメインに利用していましたが、 日々の行動指標やKPI管理ではまだまだスプレッドシートが使われていました。 そんな時Salesforceのセミナーに参加し、システムとしてのパワーを体感した私はその後もインプットを深める中で、レポート/ダッシュボードだけではないSalesforceの機能を知り「うちでやっている〇〇は、Salesforceの△△を活用したら解消できるかもしれない」というアイディアが浮かぶようになり始めました。 その当時、部内のこういった課題を取りまとめて、エンジニア（当時は業務委託のみ）と会話をする、という役割を持った人がおらず、改善アイディアに対する合意形成も上手くできませんでした。 BA不在当時のやり取り 事業サイド：商談オブジェクトに〇〇という項目を追加してほしいです。項目を1つ追加するだけだから短納期でお願いしたいと考えています。 ↓ エンジニアサイド：その項目を追加するには△△について調査する必要があり時間がかかりそうです。また、既に似たような項目がありますがコチラを使って対応できたりしないのでしょうか？そもそもSalesforceの商談には～という機能があって、、、 ↓ 事業サイド：こちら側の意図した通りに実装してほしいので進めてもらえますか？ というような具合で、事業サイドとしてはSalesforceやシステムについて、エンジニアとしては事業サイドのビジネスニーズ/背景について、まだ理解を深める余地がある状態でした。 「自分がここの間のかけはしになったら良いのでは？」と思うようになりました。 Salesforceの入門資格であるアドミニストレーターを取得した上で、当時の上司に「ココの役割が足りず、必要な改修を進めることができていないので担当させてほしい」とお願いし、ココの役割を営業担当と兼務でやり始めました。これがBAとしての第一歩になって現在の役割を担当しています。 そもそもBAとは？ BAはBusinessArchitect（ビジネスアーキテクト）の略称です。一般的にはBusinessAnalyst（ビジネスアナリスト）と呼ばれたりしています。 iiBA という組織の定義によると「ビジネスアナリシスとは、ニーズを定義し、ステークホルダーに価値を提供するソリューションを推奨することにより、エンタープライズにチェンジを引き起こすことを可能にする専門活動」とされています。 プロダクト開発の文脈でもBusinessAnalystという役割の人がおります。当社の棲み分けとしては、顧客の業務改善⇒プロダクト開発部、社内の業務改善⇒BPR推進部、というような具合です。 最近では、DXの取り組みが注目されている背景からIPAがBusinessArchitectという役割について明文化してくれており「DXの取組み（新規事業開発/既存事業の高度化/社内業務の高度化・効率化）において、ビジネスや業務の変革を通じて実現したいこと（＝目的）を設定した上で、関係者をコーディネートし関係者間の協働関係の構築をリードしながら、目的実現に向けたプロセスの一貫した推進を通じて、目的を実現する人材」というようなまとめ方もされています。 引用元) 「DX推進スキル標準」人材類型の定義 エス・エム・エスでのBAの役割 私達の部署においては「戦略推進/支援の中で、価値提供先の要望の深堀りやソリューションの提案を行うことはもちろん、業務担当者や他部門の関係者など、多くのステークホルダーを巻き込みながらその中心となり、推進の主体となる役割を担う者」としております。 基本的には、社内業務の高度化・効率化についての課題に対応しておりますが、最近は既存事業の高度化にもチャレンジしております。 社内業務の効率化というとバックオフィス系の効率化というイメージを持たれる方もいらっしゃるかもしれませんが、私のところでは主にフロントオフィス（マーケティング/セールス/カスタマーサクセス/サポートetc）の課題について取り組んでおります。バックオフィス（契約管理、販売管理etc）の課題との比率的には６：４ぐらいになります。 事業の戦略や重点Issueを踏まえた上で自分のリソースをどのように配分するかを判断して動いているようなイメージです。 BAの2つの視点から思うエス・エム・エスで働く魅力と楽しさ 私自身、今の環境が非常に面白いなあと感じています。 「Salesforceの活用の仕方」と「価値提供先との距離」の2つの視点からお伝えしたいです。 Salesforceの活用の仕方について 製品としてはAccountEngagement（旧：Pardot）、SalesCloud、ServiceCloudを利用しており、一部Salesforce外で開発したシステムもありますが、マーケティング、セールス、カスタマーサクセス、サポート、契約管理、販売管理などの業務プロセスのほとんどをSalesforce上でカバーしています。 これは私のポリシーなのかもしれないですが、何かSalesforce改修を行う際は、できるだけ標準オブジェクトや標準項目、標準機能を使ってビジネスニーズを満たせないか？という観点でソリューションを検討するようにしています。私自身、Salesforce好き、ということもあるかもしれませんが、標準周りの機能を使っておけばメジャーリリース等で機能追加されるかもしれない、標準オブジェクト/標準機能に関連した強化が行われるかもしれない、と期待していますし、何より実装/保守/メンテコストが安くなります。 念を押してお伝えしたいのですが、ApexやVisualforce、LWC（LightningWebComponent）などのカスタム開発を全く行わないわけではありません。価値を実現し、ビジネスニーズを満たし続けるために最適なQCD（Quality/Cost/Delivery）を常に考慮に入れてどのように作るかを判断するようにしています。ビジネスの動きも常に変わっていくことも考慮し、作り込みすぎずに標準機能を踏まえながら小さく作って検証を回すような動きになることが多いです。 価値提供先と距離が近い 今の立場で非常にありがたいと感じていることは、「価値提供先と一緒に問題抽出や課題設定を行うことができる」ことです。 中長期でどのようなことを実現したいか？をきちんと理解し、あるべき姿と実現したい世界観を事業側とすり合わせるようにしています。 意識としては、事業側で時間/労力をかけて作った戦略を念頭に置き、その戦略を推進するための戦術実行を支える、という具合です。また、戦術を着実に実行するために、BAの立場からシステム外のオペレーションについても問題整理/課題設定、提案を行う場面もあります。 そのため、細かい保守/エンハンス案件、一定規模以上のプロジェクトなど規模の大小にかかわらず、事業としてどんな姿になっていきたいか？今注力すべきIssueは何か？を念頭に優先順位を決めるようにしています。 価値提供先との距離が近いので、取り組みによるアウトカムが見えやすく、フィードバックループを着実かつ素早く回すことができます。そのため、価値提供先への貢献実感を持って業務に取り組むことができていると感じています。 また、事業側とも距離が非常に近いので、問題抽出、課題設定段階では、なるべく一次情報に触れてインプットを行うようにしています。 業務を遂行するのはあくまで現場メンバーであることを意識し、実際にDoする人が納得感を持てるように設計や運用の落とし込みをする必要があるためです。 例としては「管理者やマネージャーから聞くのと合わせて、現場メンバーが業務しているところを見る」「実際のデータを見たり、分析する」ようなことをしており、時には事業側と一緒に「法令文書を調べる」などもしております。 実体を繋ぎ合わせる作業を事業担当者と一緒に行うことで現状認識が統一され、今まで顕在化してはいなかったけど実は原因ってココだよね、と言った整理もできるようになります。 ワークとしては、 EventStorming を行うことが多いです。 終わりに 私たちの部署ではBusinessArchitectやSalesforce エンジニアがとても不足しています。業務に近いところで戦略推進/戦術支援をしたい、Salesforceの機能をフル活用できるようにスキルアップしていきたいという方にはとてもおススメです。ご興味ありましたらお声掛けいただけますと嬉しいです。

こんにちは、Analytics&Innovation推進部の小貝（ @oddgai ）です。 先日 ブログでも告知していた ように、9月14日(木)～15日(金)に開催された 日本オペレーションズ・リサーチ学会 2023年秋季研究発表会 にて登壇予定だったのですが、体調不良により残念ながら参加できなかったため、発表に使う予定だったスライドを公開いたします。 弊社のOR分野における取り組みを知っていただきたいのはもちろん、個人的には今回の研究発表会をかなり楽しみにしていたので、その気持ちに区切りをつける意味でも公開いたします。興味のある方はぜひ読んでみてください。 なお、内容は過去に小貝が書いたブログ記事をまとめたものになります。 tech.bm-sms.co.jp 弊社では、データサイエンティストやエンジニアの採用を積極的に行っています。ORを研究している方、研究内容に興味をもっていただけた方はぜひカジュアル面談にお越しください！ open.talentio.com