Java もなかなか良い言語だと思いますが、 Android だとやはり Kotlin のほうが優勢な気がしている AIR Design for Apps 事業部 Android エンジニアの松下です。
最近 Kotlin でのエラーハンドリングについて色々考えているので、それについてつらつらと書いてみようと思います。
続きを読む情シスへの問い合わせ窓口をシステム化した時の話
こんにちは。株式会社ガラパゴスで情シス・コーポレートITを担当している赤松です。
前回に続き今回も情シス活動を一つ紹介したいと思います。
今回は、従業員からのお問い合わせのフローをシステムを使って仕組み化した時のお話になります。
なぜやるか
これまで従業員から情シスに対する問い合わせはSlackの何となく関連しそうなチャンネルで行われていました。
従業員数も少なく、対応する人も決まっている場合はそれでも問題はありません。
しかし、従業員数が200人300人となるとどうでしょうか。
問い合わせする人は「誰に聞けばいいんだっけ？」「ここのチャンネルで合ってる？」「前どこかで誰かが同じ質問してたような」
のように、問い合わせる前に色々と「？？」が生まれます。従業員のリテラシーも様々。社歴が浅い人なら尚更です。
会社として何より一番良くないのは、課題や不明点がそのまま放置されることです。
こういった課題は会社規模が大きくなるにつれて無視できないレベルになってきます。
また、対応する情シスのメンバーが増えた場合は、抜け漏れの防止やナレッジの共有などチーム内での横連携が更に重要になってきます。
お問い合わせの仕組み化は従業員体験の向上が大きな目的ですが、チーム内でのナレッジの蓄積・共有もスムーズにできなければいけません。 今回はそのフェーズ1（立ち上げ）という位置付けになります。
システムのスコープ・要件
大まかな要件は次の通りです。
- 従業員からの問い合わせのインターフェースはSlackに統一する
- 問い合わせた内容はSlack外部のシステムへ保存しナレッジとして蓄積する
- 問い合わせ受付時は一次受付のメッセージとともにその内容をSlackチャンネルに投稿する
システム構成
インフラ：AWS Lambda APIGateWay
言語：Node.js
FW：SlackBolt
使い方
Slackでショートカットを実行するとこのようなウィンドウが表示され、該当するカテゴリを選択します。
カテゴリを選択するとそのカテゴリに応じたフォームが表示されます。
※機器の問い合わせ
※その他の問い合わせ
フォームに入力し、送信するとその内容がNotionへ保存され、Slackのチャンネルに一次受付の回答が投稿されます。
まとめ
Slackのワークフロービルダーでもある程度フォームの作成は出来ますが、フォームの形式をインタラクティブに変更したいというのと、 問い合わせの内容を外部のシステムに蓄積するという要件を実現するためシステム構築することにしました。 （開発するの楽しいし）
また、ナレッジの蓄積についてはBackLogやFreshServiceなども検討しましたが、コストや社内認知度の観点から既に社内で浸透しているNotionを採用しました。
この辺りはある程度柔軟に対応できるので今後状況の変化に応じて適したものを選択していければと思っています。
まずは社内で使ってみて改善点があればどんどん変えていきたいと思います！
TCA使ってみます
こんにちは、
AIR Design for Apps事業部iOSチームのコードヒーヨアンです
久しぶりにブログを書きます。
今回のブログは次のアプリの新規作成について、The Composable Architectureを採用したことについて簡単に紹介させていただきたいと思います。
経緯
スルーテストとリリース頻度
弊社ではアプリの新しいバージョンをリリースする前に、検証チームにスルーテストを実施していただいてますが、リリース頻度を上げるには一つのネックになっています。
本来は機能を分けて小さいリリースを繰り返したいが、スルーテストは実装の規模に関係なく、
リリース内容を少なくしても、スルーテストにかかる工数があまり変化しません。小さいリリースと大きいリリースでスルーテストのコストが変わらないのであれば、リリースを大きくした方が時間的とコスト的に有利になります。
Snapshotテスト
この問題を解決するために、スルーテストの一部を自動化して必要な工数を減らせないか調べてみましたが、見つけたのが、アプリの前のバージョンと新バージョンのスクリンショットを自動的に比較して変わったところを教えてくれるSnapshotテストです。スルーテストと同じく、不本意な変化の発見ができますので、スルーテストの一部がSnapshotテストで自動化できると思われます。
Snapshotテストを調べた時にiOSでは主に二つのライブラリーがあります
- iOSSnapshotTestCase：歴史的につわれたライブラリー。フェイスブック製ですが、今はウーバーがメンテしています。
- Point Free **SnapshotTesting：**比較的に新しい。Swiftで書かれていて、近年こちらの方がはやってる感がありました。Point Freeという会社が提供しています。
SnapshotTestingを調べていたとき、同じくPoint Freeが提供しているThe Composable Architecture（以降TCA）というアーキテクチャーライブラリーに出会って、気になって調べてみました。
TCAとは
The Composable Architecture on Github
基本的にはそれぞれの画面の状態を表すStateとそのステートの更新を担当Reducerがあり、画面が直接Stateを変更するなく、ReducerにActionを送信して、更新させる。Stateに変更があれば、あわせて画面が更新されるようになります。
外（API、データベーズなどの非同期処理）とのやりとりはEnvironment経由になっていて、Dependence Injectionがかなりやりやすい形になっています。
EnvironmentにAPIのstubとかを作ることで、簡単に画面を単独で実装可能になります。特にSwiftUIの場合はpreviewを使って独立した状態で楽に画面を実装することができます。
Composable Architectureのcomposableは何かというと、複数の画面を繋いでいくときに、それぞれの画面のSateとReducerをcomposeして繋いでいきます。
遷移もとの画面に遷移先のSateを追加し、遷移元の画面のReducerを遷移先のReducerと合わせて両方の画面を含んだユニットのReducerを作ります。こういうふうにComposeして最終的にアプリ全体のStateとReducerが出来上がります。
詳細についてはまた実装経験を積めた後にさせていただこうと思います。
なぜこのプロジェクトでTCAを使おうと思ったのか
Swift UIとUIKit
このプロジェクトは来年秋にリリースを目指す大型案件ですが、それによりOSサポート範囲がiOS 14からになり、SwiftUIなどがやっと使えるようになりました。
ただ問題点としては、現時点でSwiftUIオンリーでアプリを作るのが厳しくて（Deep Linkなどちゃんとできるのか、pull to refreshはiOS 15でSwiftUIに追加されたので、対象範囲のiOS 14でまだ使えないなど・・）、UIKitベーズで、適切なところにSwiftUIを使うことにしようとしています。
そこで、TCAはSwiftUIを考えて作られたので、SwiftUIでかなり使いやすいですが、UIKitでも問題なく使えますので、同じアーキテクチャーで両方使えるところが強いと思います。サンプルコードもSwiftUIでもUIKitでも充実していて、実装時に参考になります。
わかりやすさ
画面単体で作ることができ、画面のReducerだけ見れば画面の状態はどのように更新されるかわかります。Actionを見れば、この画面でどんな操作ができるかわかります。
画面単独で作れるので、アプリ開発初期に、まだAPI機構などが完成していない時期でも画面のレイアウトと動作が単独で作れます。
単体テスト・Snapshotテスト
TCAのライブラリーに単体テストをしやすくするための機能が揃っていて、簡単にReducerなどのテストが書けます。
EnvironmentもDIしやすいので、APIに依存しないテストがかけて、画面での操作も、Actionという形でreducerに送られますので、storeにActionを送信して、更新後のstateの期待値とテスト後のstateを簡単にテストできます。
Snapshotも、ユーザーが画面で操作した時のテストを書きたいので、
画面のコントロールを触らずに、その操作に相当するActionをstoreに送信し、更新された画面のsnapshotを撮れば、操作後のsnapshotが簡単に撮れます。
気になる点
気になる点としては、いろんな画面を繋ぎ込んだ時の、わかりにくくならないかという点と、
Stateの更新のパフォーマンスが低くならない点が一番問題視しているところです。
両方も対策できると思いますので、実装進みながら適切に対応していきたいと思います。
