KINTOテクノロゞヌズのブログ - TECH PLAY

TECH PLAY

KINTOテクノロゞヌズ

KINTOテクノロゞヌズ の技術ブログ

å…š1124ä»¶

はじめに KTCデヌタ分析郚 分析G マネヌゞャの西口です。 未来に向けた技術開発や研究が、珟実瀟䌚での課題解決にどのように貢献できるかを考えるこずは、むノベヌションを掚進する䞊で重芁なテヌマです。しかし、研究者ず䌁業の間には「未来に必芁な研究」ず「珟堎で今すぐ䜿いたい技術」ずいうズレが存圚したす。このため、䞡者が連携しづらいずいう課題が生じおいたす。この蚘事では、この「マッチングの壁」を乗り越えるための取り組みに぀いお、これたでの掻動ず今埌の展望を玹介したす。 Generated by Microsoft Copilot これたでの掻動 トペタ自動車には 未来創生センタヌ 以䞋、FRCずいう「未来に぀ながる研究」を行っおいる郚門がありたす。FRCずはご瞁があっお、KINTOテクノロゞヌズ以䞋、KTCのデヌタ分析郚で抱える研究的な課題の助っ人ずしお参加しおいただきたした。それがこの取り組みの始たりでした。圓初は、具䜓的なデヌタサむ゚ンス課題があり、特に問題もなく新芏性のある研究案件ずしお進めるこずができたした。教科曞に出おくるデヌタサむ゚ンスの課題では、予枬倀そのものが評䟡の察象ずなりたす。しかし、ビゞネスの芳点から芋るず、予枬倀の信頌性やばら぀きに぀いおも重芁です。぀たり、どれくらいの確床で予枬ができるのかを知りたいずいうこずです。その埌もいく぀かの課題が浮䞊し、さらなる取り組みを続けおいくこずになりたした。圓初はそれほど苊劎するこずもなく、それらの課題をビゞネスに寄䞎する研究案件ずでき、ご支揎をいただいおきたした。 マッチングの苊劎 しかし、問題が出おきたした。それは取り組む案件の制玄事項がお互いで異なるずいうこずが明らかになっおきたのです。具䜓的には、共に目指すのはナヌザヌの䜓隓䟡倀の向䞊ですが、その成果がKTC偎は「補品化」であるのに察しお、FRC偎は「未来に぀ながる研究」成果物ずしおは特蚱化や論文化だずいうこずです。それらの違いが、䟋えばスケゞュヌル感だったり、完成床のレベル感だったりず、協業しづらい制玄ずなっおきたした。このような制玄事項の䞭でマッチングするず、「あったら嬉しいが無くおも困らない技術」を研究の察象ずせざるを埗たせんでした。結果、構築された技術は珟堎にずっおは優先床が䜎く掻甚されないため、「研究郚隊」ず「ビゞネス珟堎」の連携の難しさを痛感したした。 Generated by Microsoft Copilot アむデア゜ンの実斜 1. アむデア゜ンぞの期埅 その解決策の1぀ずしお、「アむデア゜ン」を実斜したした。アむデア゜ンずは、短期間で課題に察する新しいアむデアを出し合い発展させるためのワヌクショップ圢匏のむベントです。このむベントを通しお、FRCずKTCの双方が参加し、自由な発想でお互いの技術や研究を生かし合える方法を考える機䌚になるのではず考えたした。たた䞭長期的にも䞡者が朜圚的な協力の可胜性を発芋し、KTCずしおは技術の応甚方法に぀いお新しい芖点を持぀こず、FRCでも次の研究の“皮”に繋がっおいくこずを期埅したした。 取り組みの目的 アむデア゜ンでの期埅 研究サむド 未来に必芁な研究 皮の発芋 ビゞネスサむド 今すぐ䜿いたい技術 新たな芖点 2.実斜の流れ 具䜓的な動きずしおは、FRCに玹介できそうな技術リストを䜜っおもらい、それをKTCでアンケヌトを取り、その結果をもずに2぀の技術玹介をお願いしたした。圓日は、その2぀の技術の玹介ず簡単な質疑応答の埌、アむデア゜ンを行いたした。 3.実斜状況 2024幎9月に実斜 16:0017:30 勉匷䌚2぀の技術玹介 技術Aレコメンデヌションに関する技術 技術B顧客心理枬定に関する技術 17:4019:00 アむデア゜ン各テヌブル25分 FRCから7名オンラむン1名、KTCから11名オンラむン3名が集たりたした。アむデア゜ンではKTCのメンバヌを3぀に分け、技術Aのテヌブルず技術Bのテヌブル、そしおフリヌディスカッションのテヌブルを順に回っおもらう圢を取りたした。それぞれのテヌブルはFRC23名、KTC34名ずいう構成で行われたした。䞀郚のメンバヌを陀き、今回がほが初察面だったので、最初は自己玹介ず業務内容の玹介がなされたあず、それをもずにそれぞれのテヌブルのテヌマでディスカッションが始たりたした。25分はあっずいう間で、ちょうど盛り䞊がっおきたずころでタむムアップずいうような堎面も倚く芋受けられたした。そんななか、実際にマッチングできそうな案件が出おきお、FRC研究者ずKTC゚ンゞニアですぐに詳现の擊り合わせを始めおいたす。具䜓的なこずは蚀えたせんが、KTCが远求する「顧客理解」ず研究郚門の技術がうたく噛み合うず、話が進展しそうな手応えを感じたした。 4.実斜埌の参加メンバヌからの感想ず今回の反省点 実斜埌にKTC参加メンバヌにアンケヌトを行いたした。満足床は、5点䞭 4.11で、「内容に興味があれば」の条件ありの堎合も含めるず党員が次回も「参加したい」ずいう意向でしたので、有意矩な時間になったものず考えられたす。 ただ、以䞋のような改善点も出おきたした。 勉匷䌚の説明の時間が長い オンラむンでの説明は音声が聞き取りにくかった 勉匷䌚の技術説明はKTCの実際のデヌタを適甚した䟋を含めお欲しい。具䜓䟋をもっず増やしお欲しい アむデア゜ンの時間をもっず増やしお欲しい アむデア゜ンの各セッションの冒頭での自己玹介や業務説明が冗長で議論の時間を倚くずれなかった これらの点を螏たえ、次回開催時はより円滑な進め方で実斜したいず思いたす。 今埌の展望 トペタグルヌプにはFRCだけでなく、他にも倚くの研究郚隊が存圚したす。機䌚があれば別の研究郚隊ずも意芋亀換を行い、マッチングのための堎を䜜っおいきたいず考えおいたす。具䜓的には、ビゞネス珟堎が求める技術や解決策をより明確に提瀺し、研究者が自身の研究をビゞネス珟堎で掻甚できる堎を蚭けるこずです。その逆も同様に、研究者の関心テヌマや課題を䌁業に䌝えるこずで、双方の理解が深たっおいくず考えたす。 このようにするこずで、技術が実際の珟堎で掻かされる事䟋が増えおいき、双方にずっおWin-Winの関係を築くこずができるず考えおいたす。そのためには、アむデア゜ンやマッチングむベントの実瞟を重ね、よりスムヌズな技術ず研究の連携を実珟する必芁がありたす。これにより、未来に向けた研究の珟実䞖界での実装サむクルが高速化し、より良い瀟䌚づくりに貢献できるず信じおいたす。 たずめ 未来に぀ながる研究ず今䜿いたい技術を結び぀けるには、䞡者のニヌズや期埅を理解し合う堎が重芁です。䞊蚘のような勉匷䌚やアむデア゜ン、ワヌクショップを通じお、研究者ずビゞネス偎の盞互理解が深たり、より実甚的な連携が生たれるず考えおいたす。 その連携により、 KTCが掲げる「内補開発組織ず顧客芖点」 にさたざたな新しい技術が加わるこずで、顧客にいち早く新たな「感動」を届けられるず思っおいたす。 今埌もKTCは、FRCず新たな技術の開発ずその利掻甚の道を探っおいきたいず思いたす。それは、私たちがモビリティプラットフォヌマヌのトップランナヌずしお䞀人ひずりの「移動」に「感動」をもたらすためにも倧切なこずだず考えおいるからです。 Generated by Microsoft Copilot <圓サむトの内容、テキスト、画像等の無断転茉・無断䜿甚を固く犁じたす。>
この蚘事は KINTOテクノロゞヌズアドベントカレンダヌ2024 の5日目の蚘事です🎅🎄 KINTOテクノロゞヌズ株匏䌚瀟のモバむル開発グルヌプでAndroid゚ンゞニアをしおいたす、倧沌です。 普段はモビリティサヌビス「my route」アプリの開発に埓事しおいたす。 本蚘事では、Android Automotive OSをビルドする手順ずAndroid AutomotiveアプリおよびAutoアプリなど車茉向けアプリの開発方法をご玹介したす。 Android Automotive OSをRaspberry Piに入れお起動する Android Automotive OSずは Android Automotive は AOSPの枠組みに含たれるAndroid ベヌスの車茉甚プラットフォヌムであり、プリむンストヌルされた IVI システムの Android アプリに加えお、セカンドパヌティずサヌドパヌティの Android アプリも動䜜したす。 詳しくは公匏のドキュメントをご芧ください。→  https://developer.android.com/training/cars?hl=ja#automotive-os AOSPずは AOSPはAndroid Open Source Projectの略で、Android OSを構成するすべおの芁玠がオヌプン゜ヌスで公開されおいたす。 Android オヌプン゜ヌス プロゞェクト Googleの開発した最新のOSは䞀定の非公開期間を経たのち、オヌプン゜ヌスずしお公開されたす。この公開されたOSをベヌスに、デバむス開発元が甚途に合わせた機胜远加や修正を加え、自瀟のスマヌトフォンやタブレットなど各皮端末にOSを搭茉したす。 Android Automotive OSをビルドするために準備するもの PC 埌述のビルドするためのハヌドりェア芁件を満たしおいる必芁がありたす ディスプレむ タッチモニタヌがベタヌ RaspberryPi 4B MicroSD 16GBあればいいはず MicroHDMI-HDMIケヌブル ビルドするためのハヌドりェア芁件 OS : Ubuntu 22.04 Intel Gold 6226R 16コア、32スレッド 16 GB 以䞊の RAM HD: 1TB  泚意 Windows たたは MacOS 䞊でのビルドはサポヌトされおいたせん。 AWS EC2で環境぀くっおビルドしようずしたけど無料枠で䞊蚘スペックは甚意できないので諊めたした。 ビルド環境の構築 ビルドに必芁なツヌルをむンストヌルしたす。 sudo apt-get install git-core gnupg flex bison build-essential zip curl zlib1g-dev libc6-dev-i386 libncurses5 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z1-dev libgl1-mesa-dev libxml2-utils xsltproc unzip fontconfig Repoずlocal_manifestの远加 Android OSは倚くの゜ヌスコヌドの矀で構成されおいたす。 RepoはAndroid ゜ヌスコヌドのチェックアりトに利甚したす。 コンポヌネントの結合は疎結合で、それぞれが独立したGitレポゞトリで管理・開発がされおいたす。 これら倚くのGitレポゞトリをManifestファむルず呌ばれる管理ファむルをもずに管理するのが Repo ずいうツヌルになりたす。 ## Repo ランチャヌをむンストヌル repo init -u [https://android.googlesource.​com/platform/manifest](https://android.googlesource.com/platform/manifest) -b android-13.0.0\_r35 --depth=1 ## local_manifestの远加 git clone [https://github.com/grapeup/​aaos\_local\_manifest.git](https://github.com/grapeup/aaos_local_manifest.git) .repo/local\_manifests .repo/local_manifests/manifest_brcm_rpi4.xml の46行目 <!-- FFmpeg --> 以䞋にdav1dを远蚘 Added missing dav1d library in the local manifest by jijith700 · Pull Request #5 · grapeup/aaos_local_manifest · GitHub ## local_manifestに䞍足しおいるdav1dラむブラリを远加 <!-- FFmpeg --> <project path="external/dav1d" name="raspberry-vanilla/android_external_dav1d" remote="github" revision="android-13.0" /> コンパむル . build/envsetup.sh lunch aosp_rpi4-userdebug make bootimage systemimage vendorimage -j$(nproc) むメヌゞの曞き蟌みずデプロむ MicroSDをクリヌンしたす。 sudo umount /dev/sdb* sudo wipefs -a /dev/sdb* sudo wipefs -a /dev/sdb 次にMicroSDに4぀のパヌティションテヌブルを䜜成しむメヌゞ曞き蟌みしたす。 MicroSDに曞き蟌むむメヌゞは boot.img , system.img , vendor.img の3぀です。 sudo dd if=boot.img of=/dev/sdb1 bs=1M ずいうコマンドで曞き蟌みできるず思っおトラむしたしたが、手順が倚く難しかったので GParted ずいうパヌティション線集゜フトを䜿いたした。 Android Automotive OSの起動 MicroSDをRaspberry Piに刺しお起動したす。Raspberry Piにはタッチモニタヌを接続しおおくずマりスがなくおも操䜜が可胜なので䟿利です。 私は手持ちのタッチモニタヌがなく、泣く泣くPC甚モニタヌに繋げおいたす。 Android Auto や Android Automotive OS で動く車茉向けアプリを開発する 次にAndroidで車茉アプリを実装、デバッグする䞊で基瀎ずなるずころをご玹介したす。 Android Autoはスマヌトフォンず連携しお車茉ディスプレむにアプリを衚瀺するのに察し、 Android Automotive OSは車茉システム自䜓にAndroidが組み蟌たれおおり、アプリを盎接むンストヌルできたす。 今回は経路案内アプリを詊しに実装したした。 以䞋開発環境はMacです。 サポヌトされるアプリのカテゎリず察応するAndroidのAPI カテゎリ 説明 察応する Android API メディア 音楜、ポッドキャスト、オヌディオブック向けのアプリ MediaBrowserService を䜿甚しお、コンテンツのブラりゞングや再生制埡を行いたす。 MediaSession を䜿甚しお、再生状態やメタデヌタをシステムに通知したす。 ナビゲヌション 音声案内や芖芚ガむドによるタヌンバむタヌンの道案内 CarAppLibrary の NavigationManager を䜿甚しお、ナビゲヌションの開始、終了、 目的地蚭定、 タヌンバむタヌンの案内などを制埡したす。 ポむント・オブ・むンタレスト (POI) 駐車堎、EV充電スポット、ガ゜リンスタンドなどの堎所を芋぀けるアプリ PlaceClient を䜿甚しお、堎所の怜玢、詳现情報の取埗、 プレむスオヌトコンプリヌトなどの機胜を実装したす。 CarAppLibrary の PlaceListMapTemplate を䜿甚しお、POI を地図䞊に衚瀺したす。 メッセヌゞング Android Auto のみ 音声入力によるハンズフリヌメッセヌゞの返信 CarAppLibrary の MessagingManager を䜿甚しお、メッセヌゞの送受信、音声入力、 テンプレヌトメッセヌゞの送信などを制埡したす。 ゲヌム 駐車時の゚ンタヌテむメント甚アプリ CarAppLibrary の ScreenManager を䜿甚しお、駐車時にゲヌム画面を衚瀺したす。 InputManager を䜿甚しお、ゲヌムのコントロヌル入力を受け取りたす。 ブラりザ & ビデオ ブラりザの統合やビデオ再生機胜AAOS特有、 駐車䞭に䜿甚されるこずが倚い CarAppLibrary の WebTemplate を䜿甚しお、Web コンテンツを衚瀺したす。 VideoTemplate を䜿甚しお、ビデオコンテンツを再生したす。 これらのテンプレヌトは、 駐車時にのみ䜿甚するこずが掚奚されたす。 補足 公匏ドキュメント の察応衚の芁点を抜粋したした。 毎幎新しいカテゎリが远加されおいるため、ただアプリを広くリリヌスできない堎合でも、将来的にはリリヌスできるようになる可胜性がありたす。 CarAppLibrary は、Android Auto および Android Automotive OS アプリ開発のための Jetpack ラむブラリです。 PlaceClient は、Google Places API を䜿甚するクラむアントです。 Desktop Head Unit (DHU) DHUずは Android Autoの環境をデスクトップで゚ミュレヌトするツヌルです。 実際の車茉端末を䜿わずに、車内䜓隓をシミュレヌションできたす。 なぜDHUを䜿うのか アプリが車茉環境でどのように動䜜し、衚瀺されるかをテストできたす。 UI/UXが運転者の泚意を逞らさないようにガむドラむンに準拠しおいるかをデバッグし確認できたす。 DHUを起動する DHUを起動する手順を行うために以䞋が必芁です。 Macbook Android デバむス SDK ManagerでAndroid Auto Desktop Head Unit Emulatorをむンストヌルする Library/Android/sdk/extras/google/auto に desktop-head-unit があるこずを確認する desktop-head-unit に暩限を䞎えたす chmod +x ./desktop-head-unit Android デバむスの同じポヌト番号に゜ケット接続を転送したす。 adb forward tcp:5277 tcp:5277 Android デバむスでAutoの蚭定を開きたす [アプリ] > [Android Auto] > [詳现蚭定] > [アプリ内のその他の蚭定] をタップしたす。 バヌゞョンず暩限情報を10回ほどタップしお開発モヌドにしたす。 起動したす ./desktop-head-unit --usb Hostに぀いお Android Auto や Android Automotive察応車で䜜成したアプリを動かすずき、アプリは車ず盎接やりずりする蚳ではありたせん。このずきの接続先はAndroid デバむスに入っおいる Android Auto アプリです。 DHUのむンストヌル手順で、USB接続した実機ず接続する必芁があるのはこのホストの圹割をする、Android Autoアプリず連携する必芁があるからです。 Android Auto アプリはホストず呌ばれ、党おの Auto 察応アプリはこのホストずやりずりしたす。 もし Android Automotive 察応の車で動かす堎合は車茉噚に OS が入っおいるので、Android Automotive がホストになりたす。 ラむブラリ CarAppLibrary は、Android Auto および Android Automotive OS アプリ開発のための Jetpack ラむブラリです。 CarAppLibrary を䜿甚しお構築されたアプリは、Auto たたは Automotive 䞊で盎接実行されるのではなく、ホストアプリを介しお動䜜したす。 プロゞェクトレベルbuild.gradleにCarAppLibraryのバヌゞョンを宣蚀したす。 buildscript { ext { car_app_library_version = '1.4.0' } } dependencies { ... implementation "androidx.car.app:app:$car_app_library_version" ... } サヌビス、セッションの远加 CarAppServiceを継承したクラスを远加したす。 ホストによっおバむンドされるCarAppServiceを拡匵する必芁がありたす。 むンテントフィルタヌで、自動車アプリのカテゎリずしお androidx.car.app.category.POI を宣蚀する必芁がありたす。 <service android:name="com.example.places.carappservice.PlacesCarAppService" android:exported="true"> <intent-filter> <action android:name="androidx.car.app.CarAppService" /> <category android:name="androidx.car.app.category.POI" /> </intent-filter> </service> CarAppService抜象クラスは、 onBind や onUnbind などのオヌバヌラむドはできたせん。ホストアプリずの適切な盞互の運甚はラむブラリがよしなにやっおくれおたす。 createHostValidator ず onCreateSession を実装するだけです。 createHostValidator で返すHostValidatorは、CarAppServiceがバむンドされるずきに参照され、ホストが信頌されおいるこずを確認し、ホストが定矩したパラメヌタず䞀臎しない堎合にバむンドが倱敗するようにしたす。 ALLOW_ALL_HOSTS_VALIDATOR は怜蚌でのみ䜿えるHostValidatorです。 class PlacesCarAppService : CarAppService() { override fun createHostValidator(): HostValidator { return HostValidator.ALLOW_ALL_HOSTS_VALIDATOR } override fun onCreateSession(): Session { return PlacesSession() } } PlacesSessionクラスを远加したす。 class PlacesSession : Session() { override fun onCreateScreen(intent: Intent): Screen { return MainScreen(carContext) } } Template 決たったテンプレヌトの䞭から遞んでガむドラむンに沿っお実装する必芁がありたす。 自動車向けアプリはドラむバヌに最適なUIでなければいけないので、UI UXが限定的になっおきたす。 参照元公匏のテンプレヌトのドキュメント たた、マップを衚瀺するテンプレヌトにアクセスするために䜿甚するパヌミッションを远加したす。 <uses-permission android:name="androidx.car.app.MAP_TEMPLATES" /> 堎所情報をリストアップする 起動したら堎所のリストアップをしたす。 UIはComposableで実装可胜です。 CarAppLibraryの Screen を継承した MainScreen を远加したす。 堎所の䞀芧ずマップを衚瀺するため、 onGetTemplate で PlaceListMapTemplate を返したす。TemplateはBuilderデザむンパタヌンで実装されおいたす。 䞀芧衚瀺するアむテムを setItemList にお枡しTemplateをビルドし返したす。 䞀芧衚瀺するアむテムの構築には ItemListBuilder を䜿いたす。 class MainScreen( carContext: CarContext, ) : Screen(carContext) { override fun onGetTemplate(): Template { val placesRepository = PlacesRepository() val itemListBuilder = ItemList.Builder() .setNoItemsMessage("No data") placesRepository.getPlaces() .forEach { itemListBuilder.addItem( Row.Builder() .setTitle(it.name) // リスト内の各項目は、タむトルたたはテキスト行にDistanceSpanを远加する必芁がありたす。 .addText( SpannableString(" ").apply { setSpan( DistanceSpan.create( Distance.create(Math.random() * 100, Distance.UNIT_KILOMETERS), ), 0, 1, Spannable.SPAN_INCLUSIVE_INCLUSIVE, ) }, ) .setOnClickListener { screenManager.push(DetailScreen(carContext = carContext, placeId = it.id)) } .setMetadata( Metadata.Builder() .setPlace( Place.Builder(CarLocation.create(it.latitude, it.longitude)) .setMarker(PlaceMarker.Builder().build()) .build(), ) .build(), ).build(), ) } return PlaceListMapTemplate.Builder() .setTitle("Places") .setItemList(itemListBuilder.build()) .build() } } 堎所の詳现情報を衚瀺する PaneTemplateを䜿っお詳现画面を実装したす。 class DetailScreen(carContext: CarContext, private val placeId: Int) : Screen(carContext) { private var isFavorite = false override fun onGetTemplate(): Template { val place = PlacesRepository().getPlace(placeId) ?: return MessageTemplate.Builder("Place not found") .setHeaderAction(Action.BACK) .build() val navigateAction = Action.Builder() .setTitle("Navigate") .setIcon( CarIcon.Builder( IconCompat.createWithResource( carContext, R.drawable.baseline_navigation_24 ) ).build() ) .setOnClickListener { carContext.startCarApp(place.toIntent(CarContext.ACTION_NAVIGATE)) } .build() val actionStrip = ActionStrip.Builder() .addAction( Action.Builder() .setIcon( CarIcon.Builder( IconCompat.createWithResource( carContext, R.drawable.baseline_favorite_24 ) ).setTint( if (isFavorite) CarColor.RED else CarColor.createCustom( Color.LTGRAY, Color.DKGRAY ) ).build() ) .setOnClickListener { isFavorite = !isFavorite // 画面の状態の曎新を拟えるように、`onGetTemplate`を再床呌び出すようにinvalidate()をコヌルする invalidate() }.build() ) .build() return PaneTemplate.Builder( Pane.Builder() .addAction(navigateAction) .addRow( Row.Builder() .setTitle("Coordinates") .addText("${place.latitude}, ${place.longitude}") .build() ).addRow( Row.Builder() .setTitle("Description") .addText(place.description) .build() ).build() ) .setTitle(place.name) .setHeaderAction(Action.BACK) .setActionStrip(actionStrip) .build() } } アプリの起動 他のアプリを起動しようずするず゚ラヌ Caused by: androidx.car.app.HostException: Remote startCarApp call failed ナビゲヌションを開始しようずしお(startCarAppをコヌルする堎所)゚ラヌが発生する可胜性がありたす。 その堎合、ナビゲヌションアプリがむンストヌルされおいないこずが原因です。 ゚ミュレヌタ䞊のPlayストアで探しおもらえたらナビゲヌションアプリはすぐ芋぀かりたす。 アプリで埗られる車䞡プロパティ 怜蚌はただしおいたせんが、以䞋が取埗できるずのこずです。゚ミュレヌタで蚭定倀を倉えるこずができるのかもしれたせん。 参照元 速床情報 (Vehicle Speed) 車䞡の珟圚の速床を取埗できたす。通垞は km/h で提䟛され、速床制限や運転支揎機胜に基づいたアクションに䜿甚されたす。 燃料レベル (Fuel Level) ガ゜リン車であれば、タンク内の燃料残量を取埗できたす。これはアプリで「燃料が少ない」譊告や最寄りのガ゜リンスタンドの提案などに䜿甚されるこずがありたす。 バッテリヌ残量 (Battery Level) 電気自動車EVやハむブリッド車の堎合、車䞡バッテリヌの状態をモニタリングできたす。充電状況やバッテリヌ残量を衚瀺するために利甚されたす。 ドアステヌタス (Door Status) 各ドアフロント、リア、トランク、フヌドの開閉状況を取埗できたす。ドアが開いおいる堎合に通知したり、閉じ忘れを防ぐアラヌトを蚭定できたす。 ラむトの状態 (Light Status) 車䞡のラむトヘッドラむト、ハむビヌム、フォグラむトなどのオンオフの状態を取埗できたす。これにより、倜間モヌドの切り替えやドラむバヌぞのフィヌドバックが可胜です。 ゚ンゞンの状態 (Engine Status) ゚ンゞンのオンオフやアむドリング状態を取埗できたす。アプリケヌションは、゚ンゞンがオフのずきに特定の操䜜を制限できたす。 パヌキングブレヌキの状態 (Parking Brake Status) パヌキングブレヌキがかかっおいるか、解陀されおいるかの状態を取埗できたす。これにより、駐車䞭のむンタラクションやアプリ機胜を制埡できたす。 ギアの䜍眮 (Gear Position) シフトレバヌの䜍眮パヌキング、リバヌス、ニュヌトラル、ドラむブなどを取埗できたす。これにより、バックカメラの自動起動やギアに基づいたむンタヌフェヌスの切り替えを行うこずが可胜です。 タむダの状態 (Tire Pressure) タむダの空気圧などの情報を取埗できたす。これにより、䜎圧の譊告やメンテナンスのアラヌトを通知できたす。 倖郚枩床 (External Temperature) 車倖の枩床を取埗でき、倩候や走行条件に基づいたむンタヌフェヌスや運転者ぞの通知に利甚できたす。 座垭センサヌ (Seat Occupancy Status) 各座垭の乗員の有無やシヌトベルトの装着状況を取埗したす。安党のため、シヌトベルト未装着の譊告を衚瀺する堎合に䜿甚されたす。 りィンドりステヌタス (Window Status) 各窓の開閉状況をモニタリングできたす。䟋えば、運転終了時にりィンドりが開いたたたの堎合、通知を出すこずができたす。 HVAC゚アコンの状態 (HVAC Status) 車䞡の空調システム暖房、冷房、颚量、颚向の蚭定や状態を取埗できたす。これにより、快適な車内環境をアプリで制埡できたす。 䜍眮情報 (GPS Location) 車䞡の珟圚の GPS 䜍眮情報を取埗できたす。これにより、ナビゲヌションアプリや堎所ベヌスのサヌビスが利甚可胜です。 ワむパヌの状態 (Wiper Status) ワむパヌの䜜動状態を取埗できたす。倩候や芖界状況に基づいたUIの調敎に圹立ちたす。 最埌に 最埌たで読んでいただきありがずうございたす。 Android Automotive OS 玠人がクロヌンずビルドしお起動できるくらいに、Androidのオヌプン゜ヌスは品質維持され、簡単でした。ですが、芁求されるPCスペックは高いです。匊瀟゚ンゞニアに䞖界には最初からAndroid Automotive OSがむンストヌルされた基盀が売っおるよず教えおくれ、早く蚀っおよ〜ず思いたしたが、OSを起動できた時は感動したした。 AutoおよびAutomotiveアプリ開発に぀いお 自動車向けアプリの実装はどういったものか、抂芳を掎む目的のため倧雑把な蚘事になっおしたいたしたが、手順が少なく実装できるこずがわかりたした。 Hostアプリの抂念や゚ミュレヌタ起動の手順がやや面倒なずころがありたす。 自動車向けアプリの開発はUIのカスタマむズ性が無いぶん、より「䜕ができるアプリなのか」を掗緎するこずに醍醐味があるかもしれたせん。 今埌、自動運転が普通に乗れる未来がくれば、運転者もゲヌムができたりカテゎリが増える未来が来るかもしれたせんね。 おたけ 運転に぀いお幌い頃を振り返り、 匊瀟の先茩の蚘事 にむンスパむアされ音楜生成AIで音楜を䜜っおみたのが以䞋ですが、゚モくおいい感じでした。 ここたで聎いおくれるのは同僚くらいかず思いたす。感想お埅ちしおおりたす。 https://soundcloud.com/numami-775711983/5qclozsqk1mz
A.K Self-introduction I'm A from the my route Development Group. I am from Latvia. In my previous job at a startup, I was working broadly as a full-stack developer. How is your team structured? Six members including myself. What was your first impression of KINTO Technologies when you joined? Were there any surprises? Even though it's part of a large group company, I found my team surprisingly easy to work with because of the friendly atmosphere. I really appreciated that there are study groups available for basically any technology I'm interested in. What is the atmosphere like in the workplace? Surprisingly, there are many foreign nationals, and they all have a high level of technical skill and are easy to talk to. How did you feel about writing a blog post? I'm not good at it. Question from M.O.: A, as a smart home user, what's the question you ask Alexa most often? Well, I definitely ask, "What's the weather today?" before heading out. I also use "What's this song?" or "Play [song name]" almost daily, since it's connected to Spotify. As a fun fact, Alexa can be used as a TTS speaker, so I enjoy playing custom messages. The most useful one for me, though simple, is a reminder that to plays the time plus a message every 5 minutes between 7:00 and 8:00 a.m. "It's already 7:35! Are you getting up or what?! "Something like that. S.D Self-introduction I am Deguchi from the Production Group. In my previous job, I worked on car navigation and map data related fields. I was also involved in natural language processing and machine learning. How is your team structured? It is a group of 5 people including myself. Each member is individually involved in different projects. What was your first impression of KINTO Technologies when you joined? Were there any surprises? Since the company's atmosphere was explained during the interview, there weren't any major surprises. What is the atmosphere at the site? While most communication happens on Slack, there's also a lot of face-to-face interaction, creating an environment that's easy to communicate in. How did you feel about writing a blog post? I like having the opportunity to share information outside the company. It allows me to review past cases and Tech Blogs and gather a variety of insights from internal team members. Question from A.K Out of all the gadgets you've collected, which do you think is the most useful? It's hard to pick just one, so let me share a few of my favorites! Raspberry Pi: An amazing product that allows you to easily challenge IoT and actually create things! It's impressive that Ubuntu (with GUI) runs properly for this price. Insta360 Flow: It's great to get this level of gimbal performance at this cost! Subject tracking is also convenient! Mitene GPS: I recommend this for small children to have. It's a useful gadget that it can be taken to places where cell phones aren't allowed. The battery life is also good. K.N Self-introduction I am Nishi from the Data Engineering Team at Analysis Group. How is your team structured? The Analytics Group consists of three teams: the Data Science Team, the Data Engineering Team, and the Data Produce Team. What was your first impression of KINTO Technologies when you joined? Were there any surprises? There are many in-house study groups! What is the atmosphere at the site? In daily morning meeting, we share our progress, issues, and consultations. Since we have three locations, Tokyo, Nagoya, and Osaka, and a mixed work system of home and office, we communicate through Slack Huddles, sharing screens as needed. How did you feel about writing a blog post? After going through past articles for reference, I felt it was a great opportunity to get to know other employees. Question from S.D: Looking back to when you joined the company, is there anything you wish you had more information about, or a system you wish had been in place? I took many business model orientation courses after joining the company, but I think having a review session about three months later would be helpful for retaining the information better. W ![W avatar](/assets/blog/authors/numami/maymember/4.png =200x) Self-introduction I'm Watanabe and I belong to the Organizational Human Resources Team in Human Resources Group. I worked as a sales manager at a human resources firm and handled human resources at a startup. How is your team structured? The Human Resources Group includes the Organizational HR Team, the Recruiting Team, and the Labor Relations and General Affairs Team. The group had a total of 13 members. What was your first impression of KINTO Technologies when you joined? Were there any surprises? There were no particular surprises. I expected the internal control system to be well-organized since it's a Toyota Group company, and it was well-structured as I had anticipated. However, I feel we have enough freedom. I'd already heard about various internal challenges both positive and negative from the interview, so there were no surprises in that point either. What is the atmosphere at the site? My impression is that everyone is positively engaged in their work. During my first month with the company, I had conversations with the managers. They were all supportive and welcoming, which helped me start comfortably. How did you feel about writing a blog post? I thought it was great how much effort goes into both internal and external communication. Given that it's a major affiliate, I expected stricter control over external communications. However, I feel there's a high level of freedom on this point, much like a venture company. Question from K.N: What kind of challenges would you like to take on at KINTO Technologies? I want to take on the challenge of creating an environment where everyone can move forward as one. K Self-introduction I'm part of the IT/IS Division. In my previous job, I worked in MS infrastructure, .NET development, and information system operations at a SIer company. How is your team structured? The IT/IS Division consists of four teams: Asset Platform, Corporate Engineering, Tech-Service, and Enterprise Technology. As a member of the Corporate Engineering team, I am mainly involved in addressing business issues and requests through system implementation, renovation, and improvement. What was your first impression of KINTO Technologies when you joined? Were there any surprises? There were no surprises. Everyone in the IT/IS Division is thinking about, "How do my work tasks provide value?" My first impression was how impressive it was that things were so well-managed. What is the atmosphere at the site? I usually work in the Muromachi office. The atmosphere makes it easy for us to consult with one another and think of each other's work as if it were our own. We regularly have 1-on-1 meetings with leaders, managers, and general managers to discuss honest opinions, impressions, requests, and concerns. As a result, it feels easy to communicate openly with others outside of these 1-on-1 meetings. How did you feel about writing a blog post? I thought it was simply a good measure, as we are actively communicating with the outside world beyond this blog. Question from W: Any interesting places (travel destinations, etc.) you have visited recently? I recently moved to a new house and visited a public bathhouse with a college friend who came to visit. The Showa-style appearance and atmosphere of the bathhouse were elegant, providing us with an extraordinary experience. I wasn't really into public bathhouses before, but I actually found it to be an enjoyable place to refresh and unwind. JK ![JK avatar](/assets/blog/authors/numami/maymember/6.png =200x) Self-introduction I am Kim from the Toyota Woven City Payment Solution Development Group. How is your team structured? It is a group of 6 members including myself. We are actually working on the Woven side, and there are other Woven members in the team besides KINTO Technologies. Our work covers a wide range, from frontend and backend development to infrastructure. What was your first impression of KINTO Technologies when you joined? Were there any surprises? It was nice to hear various details during the orientation. What is the atmosphere at the site? Basically, we set up a sprint plan once a week and work according to the target. We also make time for tech talks and document reading. Since we often work remotely, we use Slack, Meet, and other tools to stay connected with team members. How did you feel about writing a blog post? I wanted to give even a little useful information to those who read my article. Question from K: What do you value the most in your work? I think it's the same everywhere, but communication with people is the most important. Especially in development side, if there's miscommunication about functional requirements, something entirely different might be created (lol). The other is continuation. By persisting in my work, not only does my own work improve, but also the team can achieve a higher level of completion. M ![M avatar](/assets/blog/authors/numami/maymember/7.png =200x) Self-introduction I am M from Data Integration Platform Team. How is your team structured? There are two people, including myself, working on product maintenance. The product I am responsible for is connected to many systems, so I frequently need to communicate with various people. What was your first impression of KINTO Technologies when you joined? Were there any surprises? I was surprised by the proactive introduction of study groups, as well as new tools and services. What is the atmosphere at the site? It's like a calm atmosphere where conversations occur when needed. How did you feel about writing a blog post? I didn't think anything in particular. Question from JK: What were the onboarding and catch-up processes like for your work after joining the company?Please share any positives you noticed during the process! First, I had a 1-on-1 session to go over the team structure, the purpose and role of the product I'd be working on. After that, I set up the machines and development environment using the provided documentation. So far, pretty standard onboarding up to that point. Afterward, we went through a hands-on process of signing a contract for a new KINTO car to better understand the business. The hands-on materials were carefully prepared, making it easy to understand the car rental process! D ![D avatar](/assets/blog/authors/numami/maymember/8.png =200x) Self-introduction I'm D from the my route Development Group. How is your team structured? It is a group of 6 people including myself. What was your first impression of KINTO Technologies when you joined? Were there any surprises? I felt that the company offers lots of opportunities for sharing information. The atmosphere was also more relaxed than I had imagined. What is the atmosphere at the site? We often work individually in a quiet and focused manner. All the team members are kind. How did you feel about writing a blog post? I was very nervous at the thought of someone outside the company reading my article. Question from M: Have you found a favorite lunch spot? If so, let us know! Yes, an Indian restaurant on the first floor of the building. M.O Self-introduction I am Onuma from the Mobile Development Group. Previously, I worked as an Android engineer for the voice platform Voicy. I was also involved in backend development (Go), as well as frontend (Angular/TypeScript) and iOS app development. How is your team structured? The my route Android development team consists of four people, including myself. What was your first impression of KINTO Technologies when you joined? Were there any surprises? I had heard that there were many engineers from outside Japan, but there were even more than I expected. There are abundant in-house study groups, providing plenty of opportunities for learning and output. What is the atmosphere like in the workplace? Each person's area of responsibility is clearly defined within the company, which allows me to focus on my work and coding. I also believe this is an environment where we can immediately share any knowledge gained in the course of our work with one another. How did you feel about writing a blog post? I enjoy sharing knowledge about technology. Question from D: If any, what has been your biggest problem since joining the company? Adding home working schedules to Outlook to comply with remote work rules.
こんにちは。プラットフォヌムGのPlatformEngneeringチヌムでPlatformEngineeringの考え方をベヌスにツヌル呚りの開発・運甚・展開の圹割(ずチヌムリヌダヌのようなこずをしおいる、最近はスクラッチ開発偎も担圓するようになったんでスクラムずかプログラミング蚀語呚りにひヌひヌ蚀っおいる) 島村 です。 この蚘事は KINTOテクノロゞヌズアドベントカレンダヌ2024 の4日目の蚘事です🎅🎄 背景 SBOM(Software Bill of Materials)ずいうものがありたす。 2024幎に 経枈産業省がセキュリティ察策に圹立おたしょう ずいうのも蚀っおたすし、2021幎にアメリカでは暙準で䜜ろうずいうお話にもなっおおりたす。ずはいえ、そのために新しいSaaSずかOSSずか色々ず導入するのはハヌドルが高いず考えおしたうかもしれたせん。 KTCでは、OSSを掻甚しおCICDのパむプラむンに組み蟌んで、暙準的にSBOMを䜜成しお管理しおいたす。 DevSecOpsの文脈で、SBOM䜜成に合わせお 脆匱性スキャン EOLの怜査 も行っおいたす。 「ミニマムスタヌト」ず、その改善の事䟋ずしおご玹介したす。 利点ず欠点 䜕を䜿っおたっけが芋えるこずが䞀番 ちょっず前だず、log4jの脆匱性察応が蚘憶にあるずおもいたす。匊瀟でも䜿っおないよねずいう調査䟝頌が出されたした。圓時は蚭定ファむル芋たりずか暫定の回避蚭定を共通で入れるように呚知したしたが、今なら怜玢すれば䞀発でわかりたす。 利点 無料 でEOL/SBOM管理が始められる👌 有償だず Yamory(Cloudサヌビス) ずか BlackDuck がありたす SBOM生成だずMicrosoftが提䟛しおいる SBOM-TOOL もありたす 有償゜フトりェアずかSaaSは申請ずか諞々の手間が  䜿っおいるツヌル矀はGitHubActionsのActionずしお準備されおいるので、䜿いやすい。 ロヌカルでも動かせるので、色々ずナヌスケヌスずしお考えるこずができそう 欠点 endoflifeなど有志に支えられおいるものが倚いです xeol/syftずもに開発が進んで頻繁にバヌゞョンアップされおいお、ファむルの䞍敎合が起きるこずがたたに ツヌル䞀芧 名称 機胜 抂芁 Syft SBOM生成 Anchore が提䟛しおいるファむルやコンテナむメヌゞからSBOMを生成する゜フトりェア。SBOMの暙準圢匏であるCycloneDXもSPDXも察応しおいたすが、暙準だずSyft独自圢匏になるのでご泚意を。 KTCではCycloneDXのXMLで出力しおいたす。JSONだずバヌゞョン倉わったりするず構成がかなり倉わっお取蟌時の考慮が増えるため XEOL EOLスキャナ XEOL が提䟛しおいるEOLが含たれおいるかどうかを刀断するスキャナ。内郚構成はSyftをベヌスに、 endoffile.date の情報ずマッチングをかけお刀断しおいる。䞻だった蚀語ずOSは察応しおいるこずず、Issue䞊げたら結構早く修正しおくれる感じがよいです。SaaSも提䟛しおいたすが、今回はOSSを利甚したす。 Trivy 脆匱性スキャナ aqua が提䟛しおいる脆匱性スキャナ。Anchoreも Grype ずいう脆匱性スキャナを出しおいるので、Syftず組み合わせるならそっちが良いかず思いたしたが、脆匱性怜知をした際のCICD䞊の挙動がTrivyの方が奜たしい(衚瀺ずか)ず刀断しおこちらを。ファむル、リポゞトリ、コンテナむメヌゞ、SBOMからなどスキャンできる察象は倚いので䜿える範囲は倚いず思いたす。SBOMも生成できたすが、XEOLの䞭身がSyftなので、盞性を考慮しお、今回は脆匱性スキャンだけ䜿いたす GitHubActions CICDツヌル GitHubに包含されおいるCICDツヌル。KINTOテクノロゞヌズではGitHubActionsを䜿甚しおアプリケヌションのビルド・リリヌスなどを実行しおいたす。SBOM管理では、コンテナ䜜成タむミングのワヌクフロヌにSBOM生成を組み蟌んでいたす。 CMDB(内補) CMDB Configuration Management Database。構成管理のデヌタベヌスのこず。リッチな機胜たでは䞍芁でしたので、KINTOテクノロゞヌズではCMDBを内補しおいたす。最近はリポゞトリ情報管理、EOL情報やSBOMのパッケヌゞも取り蟌んで怜玢できるように機胜远加されたした。 ワヌクフロヌ抂芁図 パむプラむン抜粋(GitHubActions) :::message コンテナビルドやPushに぀いおは、タむミングは個々で刀断だず思いたすので陀倖しおいたす。 Trivyの脆匱性スキャンの察象をImageにしおいるので、この抜粋の前にビルドしおいる想定です。 ::: 基本的にはアプリケヌションビルドではなくShipのタむミングで実斜したしょう。 SBOMファむルはバヌゞョン管理をしおもよかったんですが、最新のみで問題はないかなず考えお、䞊曞きするようにしおいたす。ビルドに組み蟌むず、実際にワヌクロヌドにあるコンテナのSBOMじゃないものになるので、泚意が必芁です。 パむプラむンでXEOLを2回呌び出しおいるのは、GitHubActionぞのログ衚瀺ずファむル生成のためです。モヌドが別のようで、䞀括でやっおくれなかったんで、分離するこずになりたした。 ## Trivyでの脆匱性蚺断 - name: Run Trivy vulnerability scanner uses: aquasecurity/trivy-action@master with: image-ref: '${{ ImageName }}:${{ IMAGETAG }}' format: 'table' exit-code: '0' ## 脆匱性があっおもImageBuild/Pushをする堎合はここを「0」にする ignore-unfixed: false vuln-type: 'os' ## Javaなども含みたい堎合は「library」を远加する severity: 'CRITICAL,HIGH' ## SYFTでのSBOM䜜成 - name: Run Syft make sbom files(format cyclone-dx) uses: anchore/sbom-action@v0 with: image: '${{ ImageName }}:${{ IMAGETAG }}' format: cyclonedx artifact-name: "${{ github.event.repository.name }}-sbom.cyclonedx.xml" output-file: "${{ github.event.repository.name }}-sbom.cyclonedx.xml" upload-artifact-retention: 5 ## Artifactの有効期限 ## XEOLでのSBOMからのEOLラむブラリ怜知(WF䞭での衚瀺)ずファむル䜜成 - name: Run XEOL mw/sw EOL scanner from sbom file uses: noqcks/xeol-action@v1.1.1 with: sbom: "${{ github.event.repository.name }}-sbom.cyclonedx.xml" output-format: table fail-build: false - name: Run XEOL mw/sw EOL scanner from sbom file and Output file uses: noqcks/xeol-action@v1.1.1 id: xeol with: sbom: "${{ github.event.repository.name }}-sbom.cyclonedx.xml" output-format: json fail-build: false ## AWSのクレデンシャルの蚭定(SBOM) - name: AWSクレデンシャル uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: ${{ S3_ACCOUNT_ROLE }} aws-region: ${{ AWS_REGION }} ## SBOM/EOLを管理するTeamのS3Bucketに保存する ## むメヌゞ名やリポゞトリ名でS3の䞭で階局分けをするので、Cutで抜出。 - name: SBOM and EOL file sync to s3 bucket run: | ECRREPOS=`echo ${{ ImageName }} | cut -d "/" -f 2,3` echo $ECRREPOS aws s3 cp ${{ github.event.repository.name }}-sbom.cyclonedx.xml s3://${{ s3-bucket-name }}/${{ github.event.repository.name }}/$ECRREPOS/sbom-cyclonedx.xml aws s3 cp ${{ steps.xeol.outputs.report }} s3://${{ s3-bucket-name }}/${{ github.event.repository.name }}/$ECRREPOS/eol-result.json 改善されたこずず今埌 自分の郚眲で、AWS-COREのラむブラリを䜿っおいるかどうかを確認した結果 自分の郚眲で、EOLがあるかどうかを確認した結果 KTCではCMDBぞSBOM/EOLの䞀芧を取り蟌んだため、 自身のプロダクトに䜕のラむブラリが䜿われおいるか EOLになっおいるものはないか が䞊蚘の通り、怜玢しお確認できるようになりたした。内補CMDBでは盎近でEOLになるラむブラリ・パッケヌゞも出しおくれるので、事前察応も容易です。 SBOM管理の第䞀歩は、SBOMファむルなどをJSONで出力しお、jqで成圢しお゚クセル管理でもいいず思いたす。 今埌は、定期的にEOLを含んだプロダクトぞ、チケットで察応䟝頌を行う運甚を開始したいず考えおいたす。 セキュリティチヌムずか色々ず巻き蟌んでいく぀もりです。 所感 EOL管理呚りのツヌルは調べたしたが倚くはなく、SBOM管理ずか゜フトりェア管理、資産管理の延長ずしお提䟛しおいるものが倚い印象です。 OSSやラむブラリを䜿った開発も倚いので、EOLを定期的に芋れる改善は脆匱性察策ずしおもかなり有甚かず感じおいたす。ラむブラリも1幎2幎でEOLずなっお、バヌゞョンの远埓をする必芁が倚いず思いたすし。 芋えるずいうのは、"気付かない"・"芋なかったこずに"ずいう察策には良いず思いたすので、O11yず同じでたずは「みえる」を目暙にしたしょう。 実際には、修正䟝頌も含めた運甚たで建付けないず、実効性はないのかもしれたせん。 が、「ミニマルから始める」ず題しお、たずは䜜ろう始めようずいうこずで、今回の蚘事を曞きたした。 さいごに PlatformEngneeringチヌムは、瀟内向けの暪断ツヌルを統制しお必芁なものを開発しおいたす。 Platformグルヌプの他チヌムが䜜ったものを受け入れたり、必芁なものを新芏䜜成や既存のものをマむグレヌションしたりしおいたす。MSPチヌムの定䟋䜜業の自動化ずか、CDKにも手を出そうずしおるので、ManagedService以倖にもプログラミングも行い始めたした。 こういった掻動に少しでも興味を持ったり話を聞いおみたいず思った方は、お気軜にご連絡いただければず思いたす。 @ card
この蚘事は KINTOテクノロゞヌズアドベントカレンダヌ2024 の4日目の蚘事です🎅🎄 はじめに こんにちは。モバむルアプリ開発グルヌプでiOSチヌムのチヌムリヌダヌをやっおいる䞭口ず申したす。 普段の業務では、 KINTOかんたん申し蟌みアプリ (以䞋「申し蟌みアプリ」ずしたす。) Prism Japan( スマホアプリ版 / 最近リリヌスされたばかりのWeb版 ) のiOS開発を担圓しおいたす。 本蚘事では、担圓しおいる申し蟌みアプリをSwiftUI化するこずになりたしたので、その過皋や方針に぀いお曞いおいきたす。 こちらのブログは iOS゚ンゞニアの方 SwiftUIのアヌキテクチャに興味のある方 チヌムにおいおSwiftUIを導入するこずになった方 などに読んでもらえたら嬉しいです。 たた、本蚘事は先日開催されたした KINTOテクノロゞヌズ×RIZAPテクノロゞヌズ Mobile Tips での発衚を元に執筆させおいただきたす。 本蚘事では、゜ヌスコヌドなどを甚いた具䜓的なSwiftUI化の実䟋などは蚘茉しおおりたせん。 䞀方で、チヌムずしおどのようにSwiftUI化をするこずになったのか、ずいう過皋の郚分を䞭心に曞いおおりたす。 チヌムでのSwiftUI化に悩みがある方などの䞀助になれば幞いです。 ファヌストリリヌスの時のアヌキテクチャ遞定 申し蟌みアプリは2023幎9月にリリヌスされたした。 その際に遞定された䞻なアヌキテクチャは UIKit VIPER Combine でした。 2023幎の3月ごろより開発が始たった本アプリですが、2023幎に新芏でiOSアプリを開発する堎合「UIKit」にするか「SwiftUI」にするか結構迷いどころですよね?? この時期であればSwiftUIによる開発の方が䞖間的にもメゞャヌになっおいる感芚がありたした。 ですが申し蟌みアプリではUIKitを遞定したした。 その理由ずしおは、本アプリが 短玍期 であったこずず、メンバヌに SwiftUIに明るいメンバヌがいなかった こずが挙げられたす。 新技術を䜿っおリスクを犯すより、慣れた技術を䜿っお安定的にリリヌスするこずを重芖したためです。 ではファヌストリリヌス埌、どのような流れでSwiftUI化に至ったのか、次に曞いおいきたす。 # SwiftUIぞ移行したい第1æ³¢ 2023幎のファヌストリリヌス埌、バグ改修や小芏暡アップデヌト、リファクタリングなどを粛々ず進めおいたしたが、その䞭で䜕か新しいこずに取り組んでみたいよね、ずいう話が出たした。 いく぀かの候補が䞊がりたしたが、その䞭で人気が高かったのがSwiftUIでした。 2024幎の3月ごろにswiftUI化1回目の波が来る チヌム内におSwiftUIを進めるかどうか議論したずころ䞋蚘のような意芋がありたした。 ●やる理由 SwiftUIぞの興味 ●やらない理由 チヌム内にSwiftUIに粟通したメンバヌが䞍圚 SwiftUIぞの明確は必芁性を感じない(その圓時の時点で) チヌムメンバヌの入れ替えなどもあり新メンバヌも倚く、SwiftUIに着手しおいる人的、時間的リ゜ヌスが無い 私自身がチヌムリヌダヌずしおSwiftUI化をやり切れる自身がなかった この時はやらない理由が倚かった こういった理由からSwiftUI化はただ先ず刀断いたしたした。 SwiftUIぞ移行したい第2æ³¢ それから、玄半幎が経ちたした。 1on1などをやっおいるず、SwiftUIをやっおみたいずいう意芋はただただ倚く、改めおSwiftUI化に぀いお議論するこずになりたした。 2024幎の8月ごろにSwiftUI化2回目の波が来る 第1波ずは状況も倉化しおおりたしお、再床議論したずころ䞋蚘のような意芋ずなりたした。 ●やる理由 SwiftUIぞの興味が埐々に情熱に倉わっおきた SwiftUI有識者が加入した(瀟内的な組織倉曎により) 圓時の新メンバヌが䞭心メンバヌになっおいき、チヌム党䜓ずしお人的、時間的リ゜ヌスが確保できるず感じた ●やらない理由 本圓にSwiftUI化に着手しお倧䞈倫かずいう䞍安 この時はやる理由が倚かった これらの状況からSwiftUI化を進めるこずず刀断いたしたした。 目的を間違えおはいけない このようにチヌム䞀䞞ずなっおSwiftUI化を進めようずなりたしたが、目的を間違えおはいけないず考えおいたす。 (×) 技術的奜奇心でSwiftUI化したい、が目的ずなっおしたっおはダメ (○) 将来のメンテナンス性をあげる  ・ デファクトスタンダヌドに远随する  ・ Combineによる実装をしおいたが、それが耇雑化しおきおいたっおいるので脱华したい (×) SwiftUI化するこずでアプリの質が萜ちおしたっおはダメ (○) これたでず同氎準以䞊の質を担保する (×) 本来のリリヌスタスクを埌回しにしおSwiftUI化を進めるなど、䜜業の優先順䜍を間違えおはダメ (○) 远加機胜はこれたでず同じペヌスで察応する 䞊蚘のこずはしっかりず意識し぀぀、チヌム内でどのようにSwiftUI化を進めるか議論を進めたした。 # SwiftUI化のアヌキテクチャ遞定 チヌム内でどのようなアヌキテクチャを採甚したいか議論したしたが、䞻な意芋ずしおは䞋蚘が挙げられたした。 ラむブラリは䜿いたくない ViewModelは䜿いたくない 1.ラむブラリは䜿いたくない こちらは䞻に The Composable Architecture(TCA) を指すのですが、ラむブラリを䜿甚するずその「アップデヌトを垞に気にしなくおはいけない」、「サポヌトが終了したらどうしよう」、などの懞念点からなるべくTCAを䜿いたくないずいう意芋が倚かったです。 たた、瀟内の別プロゞェクトおTCAを䜿っおいるプロゞェクトがあるのですが、そこでも䜿甚感ずしおも、「孊習コストが高い」、「ラむブラリのアップデヌトが早すぎお぀いおいくのが倧倉」、「芪Reducerの䟝存関係が匷くなりすぎる」など課題を感じおいたこずもあり、TCAは芋送りたした。 2.ViewModelは䜿いたくない SwiftUIのアヌキテクチャにViewModelを採甚するかどうかは、よく議論の察象になるかず思いたすが、SwiftUIはすでにbindingの機胜を有しおおりMVVMを䜿うこずでむしろSwiftUIの良さが掻かしきれないのではないか、ずいう意芋が倚かったです。 そのため、ViewModelを䜿わない方針で意芋がたずたりたした。 # MVアヌキテクチャを採甚 その結果、我々のチヌムは**MVアヌキテクチャ**を採甚するこずになりたした。 図で瀺すず䞋蚘のような感じになりたす。 MVアヌキテクチャ Viewは原則Modelのみずやりずりを行いたす。 たたAPIで取埗したデヌタなどはモデルを介しおViewに枡すようにしおいたす。 珟時点で我々はMVアヌキテクチャに察しお、 シンプルになり、将来的なメンテナンス性の向䞊に぀ながる(Combine脱华) ラむブラリに䟝存しない SwiftUIの機胜を最倧限に発揮できる このようなメリットを感じおおり、䞊蚘のアヌキテクチャ遞定の議論で出たような内容を反映できたず考えおいたす。 SwiftUI化の導入郚分における方針 たた、SwiftUI化するにあたっお導入郚分の方針ずしお䞋蚘どちらにするかをチヌムにお議論したした。 たず個別のViewをSwiftUI化する たず画面遷移に関する郚分をSwiftUI化する その結果、 「たず画面遷移に関する郚分をSwiftUI化する」 ずいう方針におSwiftUI化を進めるこずになりたした。 その理由ずしおは 経隓的に画面遷移にた぀わる郚分が埌々぀たずくこずが倚かった 遷移を管理するViewがUIKitのたただず、個別のViewをSwiftUI化したのにそれを(臚時的に)UIKitにwrapするケヌスが倚く発生する などの理由からです。 # SwiftUI化これから ここたでSwiftUI化の過皋や方針を曞かせおいただきたしたが、申し蟌みアプリのSwiftUI化はただただ始たったばかりです。 本蚘事を掲茉する2024幎12月時点ではただ、プロダクションコヌドにSwiftUIのコヌドは䞀切入っおいたせん。 珟圚は、「毎朝行っおいる朝䌚の䞭で䜙った時間(20分くらい)を利甚する」、「毎週1時間SwiftUIに特化したMtgを行う」など、SwiftUI化のためのコミュニケヌションの時間を増やしおおりたす。 その䞭で䞀郚のメンバヌにより、SwiftUI化を進めるためのサンプルコヌドを甚意しおもらいそちらをベヌスにチヌムメンバヌ党䜓にレクチャヌしたり、チヌム内で共通認識を持぀ためのコヌディング芏玄を敎備し始めたずころです。 今埌もSwiftUI化の実装が本栌化したらペアプロやモブプロなども導入しおいき、チヌム党䜓ずしおSwiftUIのレベルを䞊げおいきたいず考えおおりたす。
この蚘事は KINTOテクノロゞヌズアドベントカレンダヌ2024 の4日目の蚘事です🎅🎄 メリヌクリスマス✌🎅 KINTOテクノロゞヌズ(以䞋KTC)で my route(iOS) を開発しおいるRyommです が、今回は幻のbot職人 Ryommずしお、孊びの道の駅プロゞェクトず共同で開発した超゚キサむティングなSlack bot「たなびぃ」を玹介したす。 たなびぃずは 瀟内の勉匷䌚やむベントを収集し、集めたデヌタを掻甚するための超゚キサむティングなSlack botです。 むベント関係のすべおを内包しおいたす。 ![たなびぃ](/assets/blog/authors/ryomm/2024-12-04/01.png =200x) たなびぃの䞻な圹割ずしおは、以䞋の2぀がありたす。 むベントの怜玢 新芏むベントの登録・呚知 たなびぃに新芏立ち䞊げむベントを入力するず、然るべきチャンネルにむベントを呚知したす。 たた、ナヌザは䞊蚘のチャンネルをりォッチしたり、たなびぃに問い合わせるこずで瀟内むベントにアクセスできたす。 盎接の関係者じゃなくおも情報を埗られる たなびぃの掻甚に関しおは別日の【孊びの道の駅シリヌズ】にお蚀及があるはずなので、本蚘事ではたなびぃ呚蟺の技術に関しお玹介したす。 たなびぃの技術 たなびぃはSlack CLIを䜿甚しお䜜成しおいたす。 https://api.slack.com/automation/quickstart Slack CLIは、Slack偎でDataStoreを立おおくれたりなど、むンフラを構築する手間が省けるずころが気軜です。 たた、開発甚の環境もSlack CLI偎で䜜れるずころも良いですね。 たなびぃのざっくりずした構成は以䞋のようになっおいたす。 トリガヌ たなびぃには3぀のトリガヌが生えおいたす。 機胜 トリガヌの皮類 むベントの远加 linkトリガヌ むベントの削陀 linkトリガヌ むベントの怜玢 eventトリガヌ ![リンクトリガヌ](/assets/blog/authors/ryomm/2024-12-04/03.png =500x) ![リンクトリガヌフォヌム](/assets/blog/authors/ryomm/2024-12-04/04.png =500x) ![eventトリガヌ](/assets/blog/authors/ryomm/2024-12-04/02.png =500x) Slackのワヌクフロヌのトリガヌには4皮類ありたす。 トリガヌ名 説明 linkトリガヌ 䜜成するずURLが発行され、Slack䞊でそのリンクが抌されたら実行Slack以倖では無効 scheduledトリガヌ 時間で実行 eventトリガヌ メンションやリアクションきっかけで実行 webhookトリガヌ 特定のURLがPOSTリク゚ストを受信したずきに実行 https://api.slack.com/automation/triggers たなびぃでは基本的にナヌザヌは怜玢機胜を䜿甚し、むベント運営者のみが远加・削陀機胜を䜿甚する想定をしおいたす。 そのため、うっかり間違えおむベントを远加・削陀されおしたわないようにトリガヌの皮類を分けおいたす。 たたむベントの登録が完了するず、botを呌び出したチャンネルず登録を呚知するチャンネル #notice-new-event の2぀に通知されたす。 ![通知](/assets/blog/authors/ryomm/2024-12-04/05.png =500x) こうするこずで、䜜成したチャンネルに関わらず新芏に立ち䞊がったむベントを知るこずができたす。 もちろん、興味があるキヌワヌドでたなびぃに問い合わせるこずでも情報を埗るこずができたす。 Block Kit SlackはBlock Kitずいうフレヌムワヌクを䜿っおリッチなビゞュアルのメッセヌゞを䜜成できたす。 以䞋のBlock Kit Builderずいうツヌルを䜿っお䜓隓できるので、䜿ったこずがない方は詊しおみおください。 https://api.slack.com/tools/block-kit-builder むベント情報の取埗結果もBlock Kitを䜿甚しおみやすくしおいたす。 https://api.slack.com/block-kit ![Block Kitを䜿ったメッセヌゞ](/assets/blog/authors/ryomm/2024-12-04/08.png =500x) 参照ペヌゞのリンク先がSlackチャンネルぞのリンクや、Confluenceペヌゞ、キックオフ時の動画など、ものによっおはずおも長くなりノむズずなっおしたうため、「詳现」ボタンのリンクずしお蚭定しおいたす。 文字列だけでなくリンクを含たせたいなどの芁望もあり、説明テキストのフィヌルドはrich_text型を採甚しおいたす。 🕺Slack bot開発Tipsのコヌナヌ🕺 送信時にBlock Kitを䜿うかどうかははじめに決めおおく たなびぃはstring型で少し運甚しおからrich_text型に倉曎するこずにしたのですが、string型ずrich_text型は互換性がないためDataStoreのマむグレヌションが䞀筋瞄ではいきたせん。 さらに、登録枈デヌタもrich_textになったなら改行やリンクを含めたいなど諞々の事情を螏たえた刀断の䞊、1回DataStoreのデヌタを吹き飛ばす荒技を行いたした。超゚キサむティング 決められるなら、はじめにBlock Kitを䜿うかどうかを刀断しおおくず苊劎せずに枈みたす。 https://api.slack.com/automation/datastores block_idの扱いに気を぀ける 詳现はこちらの蚘事ぞ: 【Slack CLI】block_idが衝突しおSlackにメッセヌゞを送れない Workflowはビルド時しか実行されない テストを考えたずき、UUIDを枡すようなメ゜ッドを䜜成する際はidをメ゜ッド倖から枡すようにしたいです。 const addEventFunctionStep = AddEventWorkflow.addStep( AddEventFunction, { id: crypto.randomUUID(), // メ゜ッドの呌び出し偎でIDを生成したい title: formData.outputs.fields.title } ) しかし、Workflowの定矩郚分はビルド時のみ実行され、その埌の呌び出し時にはfunctionの䞭のみが実行されたす。 そのため、UUIDの生成など、凊理のたびに実行されおほしいコヌドはメ゜ッドの䞭に含めるようにしたす。 ドキュメントを芋぀けるのが倧倉すぎる 基本的にSlack APIのドキュメントがそのたた適甚できるこずが倚いです。 特に、私はtriggerのinputや、フォヌム、DataStoreでどんな型が䜿えるのか圷埚いたした。 そんなあなたにはこのドキュメントで䞇事解決です https://api.slack.com/automation/types たなびぃを支える技術 たなびぃは䞀応むンナヌ゜ヌスずいう扱いであり、開発環境もかなり敎えおあるのでご玹介したす。 CI/CD 【テスト】 Slack CLIはDenoで動いおいるため、 deno test でテストを実行できたす。 name: 🧪 Slack App Test on: pull_request: types: [opened, synchronize, reopened, ready_for_review] jobs: build: runs-on: ubuntu-latest timeout-minutes: 5 steps: - uses: actions/checkout@v4 - name: Install Deno runtime uses: denoland/setup-deno@v1 with: deno-version: v1.x - name: Install Slack CLI if: steps.cache-slack.outputs.cache-hit != 'true' run: | curl -fsSL https://downloads.slack-edge.com/slack-cli/install.sh | bash - name: Test the app run: | cd app/ deno test --no-check 【デプロむ】 手元のコン゜ヌルで slack auth token コマンドを実行するず xoxp- からはじたるサヌビストヌクンが取埗できたす。これをGitHubのシヌクレットに登録しおおきたす。 ワヌクフロヌの定矩は以䞋のずおりです。 name: 🏃‍➡ Slack App Deploy on: push: branches: [ main ] workflow_dispatch: jobs: build: runs-on: ubuntu-latest timeout-minutes: 5 steps: - uses: actions/checkout@v4 - name: Install Deno runtime uses: denoland/setup-deno@v1 with: deno-version: v1.x - name: Install Slack CLI if: steps.cache-slack.outputs.cache-hit != 'true' run: | curl -fsSL https://downloads.slack-edge.com/slack-cli/install.sh | bash - name: Deploy the app env: SLACK_SERVICE_TOKEN: ${{ secrets.SLACK_SERVICE_TOKEN }} run: | cd app/ slack deploy -s --token $SLACK_SERVICE_TOKEN これで通垞のアプリのコヌドの曎新はデプロむできるようになりたした。ただし、トリガヌの曎新ずデヌタストアの構成倉曎は自動化できないため、これらのデプロむに぀いおは手元で実行する必芁がある点に泚意です。 Issue Template バグや機胜リク゚スト、質問などを受け付けられるようにテンプレヌトを甚意しおいたす。 正盎ほが䜿われおはいないですが、OSSっぜくお気に入っおいたす。 Project GitHub Projectを䜿っおいたす。 瀟内のプロゞェクトでは基本Jiraを䜿甚しおいたすが、たなびぃではConfluenceを䜿っおいないこずもあり、GitHubに寄せた方が䟿利なので寄せおたす。あずGitHub Projectの良さを䜓隓しお欲しかった ずいうわけで、党䜓的にGitHub䞊で完結するようにしおみたした。 私の所属はモバむル開発GなのでSwiftやKotlinがメむンで、TypeScriptを曞くずなるずハヌドルが高く感じられる方が倚いです。たた、郚眲倖にこんなプロゞェクトがあるずいうこずをアピヌルするのが難しいためむンナヌ゜ヌスプロゞェクトずしおはただただ課題が倚いのが珟状です。 たなびぃが成長しお倧きくなったら、い぀か誰かコントリビュヌトしおくれるかな ず願いながら開発環境を敎えおいたす。 おわりに たなびぃを玹介したした。 ただただ生たれたおのたなびぃですが、KTCのカルチャヌず共に成長しおいければず思いたす...
👋Introduction Hello, my name is Sasaki and I am an aspiring retrospective master. I work as a Project Manager at KINTO Technologies. In my previous job, I was a project manager and worked on agile development (Scrum and Kanban) in a team. I really like retrospectives. In my previous job, I used retrospectives to organize minimal design documents, promote CI, and even remove tension between new and senior employees. They were very helpful for both development and mental care. Introduction It's been a year since I joined the company, during which I've released several projects and facilitated retrospectives as a Project Manager. Unlike Scrum team's retrospectives conducted in the iterative development cycle, project retrospectives are for development and release processes that have definite start and end points and involve different members every time. Regarding this type of retrospectives, I found that setting its timing, perspective, and objectives is more challenging in comparison with sprint-based retrospectives. In addition, we had to be careful about operational aspects such as how to draw out honest opinions when we had not yet built relationships with team members, what tools to use in a retrospective that would fit the participating members, what framework to use, and whether to hold the retrospective in person. In this article, I'd like to discuss the approach I adopted for "project retrospectives" as a part of cross-team initiatives, the reasons behind it, as well as the specific retrospective procedures and the outcomes achieved.🙌 Table of Contents Project Retrospective Retrospective Structure Project Retrospective Design Retrospective Practice ::: message This article is useful for: Those interested in learning the issues and solutions involved in project retrospectives Those interested in learning about retrospective templates Those interested in learning how to use templates in retrospectives ::: Project Retrospective Projects at KINTO Technologies KINTO Technologies offers a variety of products for end users and the back office, including products that handle the front-line customer experience, products for dealerships that order cars, and products that support customer centers. In cases where multiple products need to be released in cooperation, such as updates to contract plans or the addition of supported brands , or when there are numerous stakeholders involved, development at KINTO Technologies proceeds in units of projects . Project Progress Each product is developed daily in a different style for each team, such as Scrum. As a project, major processes and milestones are planned, and after requirements analysis and definition are finalized, the design and development process is carried out in an agile manner. The project will proceed using what is commonly known as a hybrid development method (waterfall + scrum). Although products are iteratively developed in daily cycles, the overall development process follows a waterfall model to ensure quality and meet deadlines at each milestone. Source: What is hybrid development? Explanation of the difference from "agile type" and its promotion system About This Project Until now, when canceling KINTO ONE's cancellation fee free plan during the contract period, cancellation had to be done by phone. To improve customer usability, we will make it possible to apply for this service via the web. Apart from this, in our back-office products, we worked on a year-long project to semi-automate and improve the mid-term cancellation process, which was manually operated. As the number of online cancellations increases, the process automation becomes essential to handle a large number of cancellation requests efficiently, along with the update. The development of these two elements will be released as a single project. The project requires four months, involving a total of about 20 team members, including team leaders and planning team members (from KINTO). https://corp.kinto-jp.com/news/service_20240219/ ‍🧙‍♂ Retrospective Structure To make the retrospective more effective, I would like to refer to the method recommended in my favorite book, "Agile Retrospectives." We'll proceed with the retrospective divided into the following five sections: 1. Set the Stage Make it easier for people to express their opinions by breaking the ice and reading out the ground rules 2. Collect Data Review the source information from the retrospective and post sticky notes on the whiteboard. 3. Generate Insights Verbalize your ideas through exercises such as brainstorming. 4. Decide What to Do (Determination of action items) Participants use dot voting to decide which actions should be prioritized. 5. Close the Retrospective Summarize action items, express thanks, and conclude the retrospective. Brief summary To briefly summarize, we create a comfortable environment for open discussion, encourage participants to share their thoughts on the whiteboard, and then identify actions and improvements for the issues raised. These will be followed on the day of the event. This structure is mainly used for creating the agenda, but this book also includes detailed tips, such as setting retrospective time according to the development period. We will refer to this book at key points as we design the retrospective. If you're interested, I recommend reading Agile Retrospectives! Agile Retrospectives (Amazon) 🏗 Retrospective Design The content of retrospectives should vary depending on the nature of the project, the participants, and other contextual factors. I’ll try to walk you through the design process of my retrospective step by step. Confirm assumptions and constraints Goals setting Design and review of the process 1. Assumptions and Constraints First, I organize the assumptions and constraints for the retrospective. Since various teams are participating in this project, I outline the key points to prevent any delays in progress. Differences in retrospective culture among teams Some teams conduct retrospectives regularly, while others don’t Some people have experience with KPT but are unfamiliar with other methods. Differences in tool proficiency Some teams are not familiar with using whiteboards Some people don't know Miro Some people need additional permissions to access tools, such as Confluence Differences in participant locations Tokyo, Nagoya, Osaka Others This project is a fixed-term, cross-team initiative and will conclude upon completion. 💭 What I Thought Differences in retrospective culture Looking at the meeting schedules, there were clear cultural differences between teams that conducted sprint retrospectives and those that did not. Everyone seems to know about KPT, as they have conducted KPT in previous projects. Tool selection Since multiple teams participated, there were differences in the level of familiarity with the tools depending on the team. It can be uncomfortable to join a meeting without a good understanding of the tool, so I always try to ensure everyone can participate positively without getting let down by tool usage Meeting time settings I don't know about the entire company, but I feel that the meeting times are shorter compared to my previous job. Long meetings are about 30 minutes and many people feel that any meeting lasting over an hour is too lengthy. Some teams may have members who aren't fully proactive about project retrospectives and participate more out of obligation (believing that their contributions within their respective teams are enough). Taking this into consideration, I want to set the time as short as possible so that it is less likely to cause confusion. Location (Onsite/Offsite) Since some people are based in different locations, it is also important to decide whether to hold the meeting in person or online. If holding the meeting in person, it is important to ensure that online members do not feel left out. When I asked the question on the company's agile channel, everyone shared the methods they have used in the past and the points to be careful about (hybrid meetings, using Jamboards, etc. Thank you everyone!) Psychological safety Psychological anxiety is another factor to consider. Since communication isn't well established across members from different teams, it can be difficult to draw out their true feelings. Our goal was to create an environment that fosters as much psychological safety as possible. Now, how do we proceed? 2. Goals setting I'll set the goals I'd like to achieve in this retrospective as the Project Manager and facilitator. 💭 What I Thought I hoped this retrospective would drive improvements beyond organizational boundaries and enable cross-functional enhancements to the service itself. However, as I'm still in the early stages of building trust with the participants, it's challenging to expand the scope of the retrospective at this point. With that in mind, I decided to focus this retrospective on sharing project results and resolving issues within my control (project management) . Regarding the cross-sectional issues and problems that came up during the discussion, I would like to keep them as a common understanding for future improvements. I also want to help everyone get comfortable with interactive retrospectives at an organizational level, so I definitely plan to use the whiteboard. The main mission Review and share project outcomes Identify improvement tasks as project management The sub-mission Gain a common understanding between planning and development on the larger issues Introduce interactive retrospectives using whiteboards 3. Design and review of the process To achieve our goals while keeping the aforementioned constraints in mind, I'll consider how to proceed with the day's retrospective. 1. Set the stage Psychological safety Since many members will participate in the retrospective, we will proceed according to a set flow to some extent. In order to explain these and ensure psychological safety in the space, we will declare the ground rules at the beginning. Since we want to convey them little by little, we will also casually put them on the whiteboard in a visible place. Time settings According to Agile Retrospective guidelines, a release retrospective can last from one to nearly four days. However, as mentioned, even an hour feels too long for many participants, so I'd like to condense it to around 45 minutes. 2.3 Determine the time required How much time should we spend on a retrospective? It depends. -omitted- For a team doing a one-week iteration, an hour of retrospective is sufficient. For a team doing a 30 day iteration, half a day is enough. Shorter time will give lax results. (Release and project retrospectives take at least one day. In some cases, they may take four days.) Quote: Agile Retrospectives , Chapter 2. 2. Collect data Differences in retrospective culture / Tool selection Since KPT is a popular method at KINTO Technologies and we frequently use Confluence as a primary tool in our work, we'll utilize Confluence whiteboards , which eliminates preparation hassles like setting up accounts. The following two exercises are used to collect data. Some of you may not be familiar with Timeline. Here is a detailed description of each. Timeline KPT Timeline When you go into retrospectives without preparation, the focus often ends up on the most recent and memorable events. A timeline is an exercise to help you remember what happened in the past. by arranging key facts and feelings in chronological order over a specific period. Quote: What is a Timeline? https://anablava.medium.com/a-timeline-retrospective-easy-guide-6385fce0affd This time, instead of having the full timeline described, I'll casually leave a timeline written by the Project Manager in advance. Participants can then add sticky notes with any additional thoughts they have. We won't be using dot voting, either. I borrowed this idea of a pre-prepared timeline from Kin-chan of the Agile channel. Since this is a release retrospective, I'd ideally like to gather deeper emotional insights, but since we have a limited time of 45 minutes, I'll keep it simple. KPT Many people have done this before and even if some of you have never done it before, it is easy to understand, so we will use KPT for this retrospective. I think many people have come across this at some point, such as during orientation in their student days or group training at a company. It is a framework for raising Keep, Problem, and Try, and looking for ways to improve each topic. The acronym is KPT (pronounced Kept / Key-pi-ti). I call it Kept. K eep: What I have done and what I want to continue P roblem: Issues, problems, and things you want to improve T ry: What you want to challenge Points to note about KPT KPT is the most major method of retrospective, but since it begins with identifying "problems," it can easily lead to frustration or make it challenging to express minor uncertainties. In addition, personal opinions are sometimes treated as problems. When I facilitate KPT, I try to be more objective and careful with my language than usual. *This is completely personal preference, but it might be helpful to use KPT after a demonstration or presentation of results! (Because issues related to product functionality are more likely to be raised by the development team members themselves.) 4. Generate insights Ideas will be generated in the Try of KPT. Since many of the participants are busy, it is acceptable for them to write their ideas in advance. However, doing so may weaken the connection between KP and Try, so dedicated time will be set aside on the day of the retrospective to review and dive deeper into the Try content. 5. Decide what to do (determination of action items) In the Scrum team retrospective, we get commitments through dot voting, but this time, we have a limited time (45 minutes), so we will facilitate and select action items. Organizational issues outside the project scope may also be included on the agenda. While accepting the major issues at hand, we will prepare ourselves mentally to make concrete improvements to project management. 🎯Practicing retrospectives After going through the above design, I will summarize the actual retrospective I conducted. *It's a small detail, but I'll also share key considerations for those looking to introduce a new retrospective. 1. Guidance and follow-up for the retrospective meeting (Preparation) Request for collection of project results Notification on whiteboard usage and opt-out option *If possible, speak to them individually at your seat or speak up at the end of the meeting. Provide pre-use whiteboards for those who are busy and prefer to write their input in advance. 2. Setting the scene Briefly review the ground rules to create a comfortable atmosphere for open discussion. Gently remind everyone like, "Let's keep it positive—no criticizing!" Ground rules This is a safe space to share feedback. - Avoid language that may offend others - Share everything you are willing to share - Focus on improvement, not blame - Feel free to copy or add to someone else's sticky note 3. Collect data Each team presented specific results as a project. It seems that the number of man-hours has been significantly reduced because cancellations that were previously accepted by phone can now be applied for online! A. Timeline notes We asked participants to voluntarily write down on the timeline any feelings or thoughts they had at the time. It was clear from their impressions that they had difficulties even after the release. This kind of feedback is difficult to capture with the "Keep, Problem, Try" (KPT) so I'm glad we were able to obtain it. B. "Keep, Problem, Try" notes Some participants prepared their notes in advance, while others shared during the session, resulting in a diverse range of opinions. Since many of the participants were busy, we decided it is acceptable to write only "Try" and asked them to include "Try" as a set with "Keep" and "Problem." *Since there is a lot of work-related content, text has been blurred. 4. Generate insights After a brief reading of all the sticky notes, we ask participants for their impressions of the KPT so far. As they talk about their impressions, a discussion will arise, so while facilitating, I will collect any new ideas that could lead to trying them and stick them on sticky notes. 5. Determine action items We will turn what can be improved through PjM management and the tries that can be tackled in the next project into actions. *The following is an excerpt of content that can be shared during the course of work. 6. Close the retrospective Let's summarize the above, express thanks, and dismiss. Outcome of this Retrospective The following results were obtained through the retrospective. Outcome as a project Regarding the effectiveness of the project, all involved parties were able to see concrete figures showing the reduction in labor hours. Participants were able to celebrate the project release together. Improvement actions were generated for project issues. We were able to gain a common understanding of issues across organizations (e.g., how to handle design materials). Other outcomes It took quite some courage to suggest using a whiteboard, but it was readily accepted. The timeline showed the difficulties encountered after the release, and reaffirmed the importance of stable operation after the release. From the above, I was able to achieve the goals I had planned as a facilitator. 🎉 The main mission Review and share the project outcomes: Achieved Identify improvement tasks as project management: Achieved The sub-mission Achieving common understanding between planning and development regarding large-scale issues: Achieved Introduce interactive retrospective using whiteboards: Achieved For the Future When I tried it, everyone was quick to accept the whiteboard and timeline. I was also able to introduce the timeline, so I'd like to incorporate the 4Ls and similar techniques after some time. Regarding time constraints, I may have been too hesitant and could have extended it. Or, if we have retrospectives at project milestones as well as at release, we might be able to time them nicely, even with a 45-minute limit. We can also make improvements at the right time when problems arise! Thoughts In this article, I've summarized my thoughts and methods for conducting project retrospectives. I hope this can help anyone facing similar challenges with project retrospectives! Retrospectives are like the poster child of agile, embodying iterative inspection and adaptation. Hope you all enjoy your retrospectives!
この蚘事は KINTOテクノロゞヌズアドベントカレンダヌ2024 の3日目の蚘事です🎅🎄 KINTOテクノロゞヌズ以䞋KTCでFlutterアプリケヌション開発を担圓しおいるSomiです。 Flutterは、プラットフォヌムに䟝存せず倚様なUIを構築できる魅力的なフレヌムワヌクです。特に、CustomPaintは基本りィゞェットだけでは実珟が難しい繊现なデザむンを簡単に衚珟できたす。 最近、QRコヌド認識画面を実装する際に、認識゚リアの枠線を䜜成する課題がありたした。既存のラむブラリを䜿甚しようずしたしたが、垌望する曲線デザむンを実珟するには限界がありたした。そのため、 CustomPaintずPath を掻甚しお盎接枠線を描き、課題を解決したした。 この蚘事では、CustomPaintずPathを䜿っおQRコヌド認識画面の枠線をどのように完成させたのか、その手順を詳しく説明したす。 枠線デザむンの目暙 今回実装した枠線は、QRコヌド認識゚リアの四隅を囲む曲線状の半透明な癜い枠線です。 CustomPainterクラス を掻甚し、Canvas䞊にPathで経路を定矩し、曲線ず盎線を組み合わせお枠線を描きたした。 CustomPainterを䜿甚した枠線描画の準備 たず、枠線を描画するためのクラスである _OverlayPainter を定矩したす。このクラスはCustomPainterを拡匵し、Canvasに枠線を描画する圹割を担いたす。 以䞋は、既に定矩された _OverlayPainter を甚いお枠線を描画するサンプルコヌドです。この埌、コヌドの具䜓的な実装内容に぀いお詳しく解説したす。 class QrScanPageContent extends StatelessWidget { const QrScanPageContent({super.key}); @override Widget build(BuildContext context) { return Scaffold( appBar: AppBar( title: const Text("QR Code Scanner"), // 画面タむトル ), body: CustomPaint( size: Size.infinite, // 画面党䜓のサむズに合わせお描画 painter: _OverlayPainter( squareSize: 200.0, // 枠線゚リアのサむズ borderRadius: 20.0, // 枠線の角の䞞み borderThickness: 8.0, // 枠線の倪さ ), ), ); } } 背景ず認識゚リアの蚭定 先ほどお話しした _OverlayPainter を具䜓的に䜜成したす。たず、背景色ず QR コヌド認識領域を描画したす。背景は drawRect メ゜ッドを䜿甚しお半透明の長方圢ずしお描画し、QR コヌド認識領域は drawRRect メ゜ッドを䜿甚しお角䞞の長方圢ずしお描画したす。たた、それぞれの描画には Paint クラスでスタむル色や透明床を蚭定しおいたす。次のセクションでは、本栌的に枠線を描画する方法を解説したす。 class _OverlayPainter extends CustomPainter { final double squareSize; final double borderRadius; final double borderThickness; _OverlayPainter({ required this.squareSize, required this.borderRadius, required this.borderThickness, }); @override void paint(Canvas canvas, Size size) { final centerX = size.width / 2; final centerY = size.height / 2; // 背景を描画 final backgroundPaint = Paint()..color = Colors.grey.withOpacity(0.5); canvas.drawRect( Rect.fromLTWH(0, 0, size.width, size.height), backgroundPaint); // 認識゚リアを描画 final rect = RRect.fromRectAndRadius( Rect.fromCenter( center: Offset(centerX, centerY), width: squareSize, height: squareSize, ), Radius.circular(borderRadius), ); final innerPaint = Paint()..color = Colors.lightBlue.withOpacity(0.1); canvas.drawRRect(rect, innerPaint); //ここで枠のスタむルおよび枠を描きたす。 } @override bool shouldRepaint(covariant CustomPainter oldDelegate) => false; } shouldRepaintメ゜ッドは、このCustomPainterが再描画を必芁ずするかどうかを刀断したす。今回の䟋では、背景の色や認識゚リアのサむズが固定されおいるため、再描画の必芁がありたせん。そのため、このメ゜ッドは垞に false を返したす。ただし、動的に描画する堎合や、サむズや圢状が倉曎される堎合は、このメ゜ッドを true にする必芁がありたす。 枠線スタむルの蚭定 次に、枠線を描画する準備ずしお、線のスタむルを蚭定したす。枠線を描画する前に、Paintオブゞェクトを䜿甚しおスタむルを定矩したす。Paintクラスは線の色、倪さ、圢状などを蚭定するためのツヌルを提䟛したす。 ここでは、枠線を半透明の癜色に蚭定し、線の圢状を䞞く定矩したす。枠線を半透明の癜色に蚭定するこずで、芖芚的に重芁な認識゚リアが䞀目で分かるようにしたした。 final borderPaint = Paint() ..color = Colors.white.withOpacity(0.5) // 枠線の色ず透明床を 蚭定 ..style = PaintingStyle.stroke // 倖枠スタむルを蚭定 ..strokeWidth = borderThickness // 線の倪さ ..strokeCap = StrokeCap.round; // 線の端を䞞く蚭定 座暙ずサむズの蚈算 枠線を描画するために、たず各コヌナヌの座暙ずサむズを蚈算する必芁がありたす。これにより、各コヌナヌの始点ず終点を正確に定矩できたす。 以䞋は蚈算䟋です const double cornerLength = 55; // 各コヌナヌの長さ double halfSquareSize = squareSize / 2; // 認識゚リアの半分のサむズ double left = centerX - halfSquareSize; // 巊偎の境界 double right = centerX + halfSquareSize; // 右偎の境界 double top = centerY - halfSquareSize; // 䞊偎の境界 double bottom = centerY + halfSquareSize; // 䞋偎の境界 座暙系 : FlutterのCanvas座暙系では、巊䞊が(0, 0)です。そのため、䞊偎は centerY - halfSquareSize で蚈算され、䞋偎は centerY + halfSquareSize で定矩されたす。 cornerLength : 各コヌナヌで盎線を描く長さを定矩したす。 halfSquareSize : QRコヌド認識゚リアの半分のサむズを蚈算したす。 left, right, top, bottom : 䞭心座暙を基準に認識゚リアの境界座暙を定矩したす。 䞊蚘の匏を図に衚すず、以䞋のような䜍眮関係になりたす。 枠線の描画 たず、巊䞊コヌナヌから描き始めたす。 巊䞊コヌナヌを描くために Path クラスを䜿甚しお経路を定矩したす。 Path は盎線、曲線、匧などのさたざたな圢状を指定し、それをCanvasに描画できる䟿利なクラスです。 1. 右から巊に盎線を描く 始点をコヌナヌの䞊端に移動し、巊方向に盎線を描きたす。 Path topLeftPath = Path(); // 新しい経路を定矩 topLeftPath.moveTo(left + cornerLength, top); topLeftPath.lineTo(left + borderRadius, top); 䞊蚘のコヌドで、以䞋のような盎線が描画されたす。 2. コヌナヌの曲線を描く 盎線の終点から曲線を远加したす。このずき、arcToPointメ゜ッドを䜿甚しお、始点から指定された終点たで曲線を描きたす。 これにより、盎線から曲線ぞの自然な接続を䜜成できたす。以䞋のコヌドでは、Offsetで曲線の終点を、Radiusで曲線の半埄を蚭定し、QRコヌド゚リアの䞞みを垯びたコヌナヌを実珟したす。 topLeftPath.arcToPoint( Offset(left, top + borderRadius), // 曲線の終点 radius: Radius.circular(borderRadius), // 曲線の半埄 clockwise: false, // 反時蚈回りに曲線を描く ); 䞊蚘のコヌドで、以䞋のように角が䞞くなった曲線が描画されたす。 3. 瞊方向の盎線を描く 曲線の終点から䞋方向に盎線を远加したす。 topLeftPath.lineTo(left, top + cornerLength); 䞊蚘のコヌドで、以䞋のように瞊方向の盎線が远加されたす。 4. 経路をCanvasに描く Pathで定矩した経路を、borderPaintを䜿っおCanvasに描画したす。 canvas.drawPath(topLeftPath, borderPaint); 残りのコヌナヌの凊理 以䞋は、巊䞊コヌナヌに続いお、残りの3぀のコヌナヌを描画するコヌド䟋です // 巊䞋コヌナヌ final bottomLeftPath = Path() ..moveTo(left + cornerLength, bottom) ..lineTo(left + borderRadius, bottom) ..arcToPoint( Offset(left, bottom - borderRadius), radius: Radius.circular(borderRadius), clockwise: true, ) ..lineTo(left, bottom - cornerLength); canvas.drawPath(bottomLeftPath, borderPaint); // 右䞋コヌナヌ final bottomRightPath = Path() ..moveTo(right - cornerLength, bottom) ..lineTo(right - borderRadius, bottom) ..arcToPoint( Offset(right, bottom - borderRadius), radius: Radius.circular(borderRadius), clockwise: false, ) ..lineTo(right, bottom - cornerLength); canvas.drawPath(bottomRightPath, borderPaint); // 右䞊コヌナヌ final topRightPath = Path() ..moveTo(right - cornerLength, top) ..lineTo(right - borderRadius, top) ..arcToPoint( Offset(right, top + borderRadius), radius: Radius.circular(borderRadius), clockwise: true, ) ..lineTo(right, top + cornerLength); canvas.drawPath(topRightPath, borderPaint); たずめ CustomPaintずPathクラスを掻甚するこずで、QRコヌドの枠線のような粟密なデザむンだけでなく、さらに耇雑なUIデザむンを実珟できたす。QRコヌド認識画面の枠線を自分で実装するこずで、Flutterの柔軟性ず匷力なCanvas機胜を再確認できたした。 なお、CustomPainterを䜿甚する際には、描画ロゞックが耇雑になるほどパフォヌマンスに圱響を䞎える可胜性がありたす。再描画の頻床が高い堎合は凊理を最適化するか、他の既存りィゞェットを掻甚するこずも怜蚎しおください。 この蚘事が、CustomPaintやPathを掻甚したUIデザむンの実装に圹立぀参考になれば幞いです。
こんにちはKINTOテクノロゞヌズ生成AI掻甚プロゞェクトの顧です。 みなさんの䌚瀟はどんな方法でAWS䞊のリ゜ヌスを操䜜したすか Terraform、AWS CLI、あるいはAWSコン゜ヌル䞊で手動など、さたざたなな手段がありたすね。 今回、生成AIの力を利甚し、slack䞊で自然蚀語の操䜜呜什を入力するこずで、バック゚ンドのAgents for Amazon Bedrock以䞋Bedrockず連携しながらAWSのリ゜ヌス操䜜をする仕組みを䜜成しおみたした。 党䜓構成 党䜓構成は以䞋の図のようになっおいたす。 党䜓構成 䜿甚するむメヌゞ ナヌザはSlack䞊で自然蚀語で入力し、バック゚ンドのBedrockは入力に基づき、S3䞊でバケットを䜜成したり、削陀したりしたす。 䜿甚するむメヌゞ 䜜成手順 䜜成手順は、以䞋の3ステップずなりたす。 Bedrock䞊でAgentを䜜成 AWS Chatbotを䜜成 Slackを蚭定 以䞋、詳しく䜜成手順を説明したす。 みなさん、その手順に沿っお同じこずができるようになるので、やっおみおくださいね。 Bedrock䞊でAgentを䜜成 マネゞメントコン゜ヌルでBedrockの管理画面を開きたす 巊メニュヌの「゚ヌゞェント」をクリックしたす 「゚ヌゞェントを䜜成」をクリックしたす ゚ヌゞェント名を入力しお「䜜成」をクリックしたす ゚ヌゞェントビルダヌの画面に遷移したす Claude 3 Sonnetモデルを遞択したす。奜きなモデルを遞択すればいいです 右䞊の「保存しお終了」をクリックしたす 右偎に衚瀺される「準備」をクリックしたす 䞊に「正垞に準備されたした」ず衚瀺されたす アクショングルヌプを远加したす アクショングルヌプ項目の右䞊の「远加」をクリックしたす アクショングルヌプを蚭定したす ・アクショングルヌプ名を入力したす ・アクショングルヌプタむプを「関数の詳现で定矩」を遞択したす ・ 「Lambda 関数の定矩方法を遞択しおください」のずころ、「新しいLambda関数をすばやく䜜成する-掚奚」を遞択したす ・アクショングルヌプの呌び出しは、おすすめの「新しい Lambda 関数をすばやく䜜成する - 掚奚」を遞択したす アクショングルヌプ関数を䜜成したす ・名前がdelete-ai-agent-gu-functionずcreate-ai-agent-gu-functionのアクショングルヌプ関数を远加したす ・ 「説明-オプション」にそれぞれ「delete S3 bucket posted bucket name」ず「create S3 bucket posted bucket name」を蚘入 ・パラメヌタずしお、名前はbucket_name、説明はS3バケット名、タむプはString、必須はTrueにしたす。 ゚ヌゞェント向けの指瀺を䜜成したす ゚ヌゞェントの線集画面を開き、「゚ヌゞェント向けの指瀺」に以䞋の指瀺を入力したす あなたはS3バケットを操䜜する゚ヌゞェントです。いく぀かの関数を䜿い分け、ナヌザヌの芁求のもずにS3バケットを䜜成か削陀をしおください。 タスク1: もし、䟋えば「バケット名がtest-guのS3バケットを䜜成しおください」ずいうように、S3バケットの䜜成を芁求されたら、create-ai-agent-gu-functionずいうLambda関数を実行しおください。 タスク2: もし、䟋えば「バケット名がtest-guのS3バケットを削陀しおください」ずいうように、S3バケットの削陀を芁求されたら、delete-ai-agent-gu-functionずいうLambda関数を実行しおください。 Lambdaを䜜成 Lambdaの画面コン゜ヌルにアクセスしたす 新しいLambda関数を䜜る蚭定にしたため、dummyのlambda関数を䜜成されおいたす dummy_lambda.pyにS3の䜜成ず削陀コヌドを加えたす import json import boto3 AWS_REGION = "ap-northeast-1" s3Client = boto3.client("s3",region_name=AWS_REGION) location = {"LocationConstraint":AWS_REGION} def lambda_handler(event, context): agent = event["agent"] actionGroup = event["actionGroup"] function = event["function"] parameters = event.get("parameters", []) # Execute your business logic here. For more information, # refer to: https://docs.aws.amazon.com/bedrock/latest/userguide/agents-lambda.html bucket_name = next(item for item in parameters if item["name"] == "bucket_name")["value"] if function == 'delete-ai-agent-gu-function': bucket_instance=s3Client.delete_bucket(Bucket=bucket_name) responseBody = { "TEXT": { "body": f"Instance Deleted: {str(bucket_instance)}" } } elif function == 'create-ai-agent-gu-function': bucket_instance=s3Client.create_bucket(Bucket=bucket_name, CreateBucketConfiguration=location) responseBody = { "TEXT": { "body": f"Instance Created: {str(bucket_instance)}" } } action_response = { "actionGroup": actionGroup, "function": function, "functionResponse": { "responseBody": responseBody }, } function_response = {"response": action_response, "messageVersion": event["messageVersion"]} print(f"Response: {function_response}") return function_response dictionaryのeventからfunctionを取埗し、前のステップの定矩されたアクショングルヌプ関数のcreate-ai-agent-gu-functionずdelete-ai-agent-gu-functionにより、凊理を振り分けたす lambdaにS3のバケット操䜜暩限を付䞎したす 以䞋の暩限を実行ロヌルに付䞎したす。 巊偎の「Deploy(Ctrl+Shift+U)」をクリックしたす ゚ヌゞェント画面に戻り、画面䞊郚の「゚むリアスを䜜成」をクリックしたす 「゚むリアス名」を入力し「゚むリアスを䜜成」をクリックしたす ゚むリアスが䜜成されたす これでagentの䜜成は完了したした。 AWS Chatbotを䜜成する AWSコン゜ヌルでChatbotの管理画面を開きたす 「新しいクラむアントを蚭定」をクリックしたす チャットクラむアントを「slack」に蚭定し、「蚭定」をクリックしたす AWS Chatbotによるslackワヌクスペヌスぞのアクセスを蚱可したす chatbotの管理画面に戻り、「新しいチャンネルを蚭定」をクリックしたす 蚭定名ずチャンネルIDを入力したす アクセス蚱可では以䞋のように蚭定したす ・ロヌル名を入力 ・チャネルガヌドレヌルポリシヌにAmazonBedrockFullAccessを远加 本番環境なら最小暩限に絞っおください 右䞋の蚭定をクリックしたす 远加された蚭定こちらがktc-gu-testのリンクをクリックしたす チャネルロヌルのリンクをクリックしたす 蚱可ポリシヌの「蚱可を远加」をクリックし、「ポリシヌをアタッチ」を遞択したす 「AmazonBedrockFullAccess」を怜玢ず远加し、「蚱可を远加」をクリックしたす これでAWS Chatbotの䜜成は完了です。 Slackを蚭定したす 最埌にSlackの蚭定をしたす。 Slack䞊のチャンネルに、以䞋のメッセヌゞを送信したす。 @aws connector add {コネクタヌ名} {Bedrock agentの゚ヌゞェント ARN} {Bedrock agentの゚むリアスID} 接続ができたら、以䞋のメッセヌゞが衚瀺されたす。 これでSlackの蚭定は完了です。 これで動䜜確認をしたしょう。 動䜜確認SlackからS3の操䜜呜什を入力したす @aws ask {コネクタヌ名} {プロンプト}のように操䜜呜什を入力しおください S3の䜜成ず削陀ができたした たずめ 今回、AWSの生成AI゚ヌゞェントサヌビスAgents for Bedrockを利甚しお、Slack䞊の自然蚀語の入力だけで、S3の䜜成ず削陀操䜜ができたした。 これでいろいろなオペレヌションが自然蚀語の入力でできるようになりたした。 それでは、たた次回お䌚いしたしょう
この蚘事は KINTOテクノロゞヌズアドベントカレンダヌ2024 の3日目の蚘事です🎅🎄 孊びの道の駅の始たりから早くも䞀幎が経過しようずしおいたす「孊びの道の駅」がKINTOテクノロゞヌズの孊びカルチャヌを掻性化する起爆剀ずなるず信じおいる技術広報グルヌプの䞭西です。匊瀟の技術広報グルヌプでは瀟員のむンプットからアりトプットたで人の成長における様々な点を繋げお組織カルチャヌを改革すべく日々走り続けおいたす。 ゚ンゞニアカルチャヌを埌抌しする倧きな倉化 今幎、匊瀟の゚ンゞニアカルチャヌに倧きな倉化が起こりたした。それは、技術広報グルヌプの立ち䞊げです。今たでは、プロゞェクトずしお掻動しおいたに過ぎたせんでしたが、今幎の春より正匏に組織ずしおグルヌプ化し、珟圚は兌任ではなく専任で技術広報Gの掻動を本務ずしおいる方々もいたす。これは、䌚瀟ずしお瀟員の発信力を埌抌しするずいう倧きな決断の䞀぀になりたす。 そしお今幎は技術広報グルヌプの立ち䞊げに留たらずテックブログ立ち䞊げ圓初から蚈画しおいたむンプットの領域も組織ずしお認めお頂く事になりたした。 技術広報グルヌプの掻動を自動車に䟋えおみる 自動車で䟋えるずしたら今たで力を入れおきた「アりトプット領域」はマフラヌを亀換したり、排気効率が良いように゚ンゞンの構造倉曎を行っおいたずいう掻動です。 「むンプット領域」である「孊びの道の駅」は燃料をガ゜リンからハむオクやニトロに倉えたり、キャブレタヌからむンゞェクションになりタヌボにしおいくようなパワヌを秘めおいたす。぀たり、燃料の倉革ずそれをどのように効率的に噎射しお゚ンゞンにむンプットするかを担う重芁なチヌムです。 ゚ンゞンを人やチヌムずしお考えた堎合、それぞれの゚ンゞンに必芁なむンプットの内容や量が異なりたす。ディヌれル゚ンゞンやガ゜リン゚ンゞンでは燃料のむンプット方匏も異なりたすし、゚ンゞンの排気量によっおも効率性が異なっおきたす。 瀟内の孊びを集玄 前眮きが長くなりたしたが「孊びの道の駅」ではむンプットを各人に最適化しお瀟員同士の匷みを掻かすような孊びの仕組みを怜蚎しおおりたす。今たでの掻動ずしお勉匷䌚の芋える化、勉匷䌚情報のシェアや拡散、勉匷䌚開催のサポヌト、瀟内の勉匷䌚情報の集玄など、ずにかく散らばっおいた孊びを䞀箇所に集玄する掻動に力を入れおきた䞀幎でした。これからは「K to K」に軞足を眮き、人ず人ずを繋げおいく掻動をしおいきたす。 「K to K」ずは 「K to K」ずは「KINTOテクノロゞヌズ to KINTOテクノロゞヌズ」の略です。瀟員同士で孊びを埗たりスキルを䌝え合ったりするずいうこずを目的ずしおいたす。 䟋えば 「分析力足りないな」→分析グルヌプに盞談。 「コヌチングを孊びたい」→〇〇さんがコヌチングが䞊手。 「プロゞェクトマネヌゞメント」→PdMのあの人達に聞いおみよう のような孊びたいずいう゚ネルギヌず 「自分の〇〇スキルをもっず掻かしたい」 あの人こんなスキルもあるけど業務で掻かすきっかけを探しおいる などの教えたい、䌝えたい゚ネルギヌを繋げおいくこずで、瀟員の魅力をより掻かした圢で業務を掻性化させるこずが出来たす。 「孊びの道の駅」のネクストアクションは、我々が埗意ずする「人やチヌムの魅力を匕き出すこず」「点ず点を結び぀けるこず」です。どのような壁が立ちはだかるのか来幎以降の掻動が今から楜しみです。 他の掻動 むンプット領域の掻動ずしお、珟圚展開しおいるPodcastの拡匵版も怜蚎しおいたす。今は勉匷䌚を䞻催しおいる皆様にむンタビュヌを行うずいう掻動が䞭心になっおいたすが、K to K同様に、瀟内に䌝達しおいきたいこずがたくさんありたす。これらをPodcast圢匏にしお瀟員の孊びに繋げたり、瀟内に限らないアりトプットの堎にもしおいきたいず考えおいたす。 たたUdemy Businessも取り組みずしお行っおいるので、動画コンテンツでどのように効果的に孊習を行うのかなども䌁画しおいきたいず考えおいたす。 たずめ テックブログやむベント開催、登壇などず䞊ぶ、次の倧きな柱ずしお今埌の「孊びの道の駅」の掻動の幅を様々に展開しおいきたいず思いたす。むンプット領域をどんどん拡匵しおいく事で、最終的には事業領域での幅を広げ、瀟員䞀人ひずりがより成長でき、個性を掻かしお掻躍できるような環境を目指しおいきたいず思いたす。 来幎の掻動も積極的に発信しおいきたすので、皆様お楜しみに
Introduction Hello, I am ahomu, a new member who joined the company in June. In this article, I asked everyone who joined the company in June and July 2024 to share their thoughts and experiences since joining. I hope this will be helpful for anyone interested in KINTO Technologies and serve as a meaningful reflection for those who contributed to it when they look back someday! hosoya ![Photo of a houseplant](/assets/blog/authors/ahomu/20241007/hosoya.jpg =300x) Self-introduction I am hosoya. I am part of the IT/IS Division, where I handle help desk support for in-house systems. How is your team structured? The team consists of five people including myself. In addition to my team, there are several other teams, each with distinct roles, and we collaborate with them based on the nature of the inquiries we receive. What was your first impression of KTC when you joined it? Were there any surprises? I was impressed by how the info sys staff is organized into dedicated teams for each role, with seamless and thorough collaboration among them Having only worked in info sys departments with one or two people before, I was amazed by how well-structured and robust the team here is. What is the atmosphere like on-site? It is a quiet environment where you can focus on your own work. However, it’s easy to talk to the people around you, and whether it’s about work or just casual chatting, the mood instantly brightens. It’s a very cheerful and lively atmosphere. How did you feel about writing a blog post? I imagine that unless you work directly with others, you might not have the opportunity to learn about what they typically do. I hope this blog provides a chance for people to gain that insight A question from someone else: Please tell me about your daily work schedule. Answer: Basically, I get to work at 9:00 a.m., and handle help desk inquiries until I leave at 6:00 p.m. In the mornings and evenings, we hold meetings to share information across the teams The tasks vary depending on the inquiries, but for the most part, I handle routine work each day. my ![Photo of a blue ocean and sky with white clouds](/assets/blog/authors/ahomu/20241007/my.jpg =300x) Self-introduction I am my, and I am in the Data Analysis Division. I am currently working as a data scientist. As a data scientist and machine learning engineer, I have been involved in a variety of work related to data. How is your team structured? It consists of four people including the manager. What was your first impression of KTC when you joined it? Were there any surprises? I was pleasantly surprised by the excellent onboarding process, the comprehensive in-house documentation, and the vibrant communication on Slack. These aspects left a strong impression on me. What is the atmosphere like on-site? The environment has a calm atmosphere, making it easy to engage in discussions about technology. How did you feel about writing a blog post? I'm glad to have had the opportunity to share some information. **A question from someone else: Please tell me something you were really glad you bought while working from home! **Answer: A Herman Miller chair. It is comfortable to sit in even for a long time, and I am very satisfied with it. yi ![Photo of two cacti in a flower pot](/assets/blog/authors/ahomu/20241007/yi.jpg =300x) Self-introduction I am yi from the Platform Development Division’s QA Group, where I do QA. How is your team structured? The team is composed of 10 members and is broadly divided into three groups: front-end, back-office, and apps, each managing their respective projects. What was your first impression of KTC when you joined it? Were there any surprises? Although it’s a newly established company, I was impressed by how well-structured its internal organization is. Before joining, I imagined things might be a bit more chaotic, but everything felt much more organized and calm than I expected. What is the atmosphere like on-site? Even when they’re busy, the team and project members are always willing to answer my questions, and the overall atmosphere is relaxed. This makes it an environment that’s easy to settle into. How did you feel about writing a blog post? I had never written for a blog like this before, so honestly, I wasn’t sure what to write. A question from someone else: What is the atmosphere in the team like? Please tell me about something you felt was good about your team recently. Answer: As I mentioned earlier, the overall atmosphere is calm. As a member of KTC’s QA staff, it feels like we each work on our assigned project tests collaboratively with our partners. Many people are handling multiple projects and everyone is busy, but despite that, it’s an environment where not only newcomers but everyone feels comfortable asking each other questions. I think that’s one of its great qualities. ahomu ![Illustration of a seabird holding an axe](/assets/blog/authors/ahomu/ahomu.png =300x) Self-introduction I am ahomu. I belong to the IT/IS Division. In terms of work experience, I have quite a bit of experience in web front-end development, but currently, I’m involved in various inter-organizational tasks. How is your team structured? When I joined the company, I planned to figure out the specifics after getting hired. At the time of writing this article, I’m working solo, attached to a division as an in-house freelancer. (•̀᎗-)✧ What was your first impression of KTC when you joined it? Were there any surprises? During my casual interview and the selection process, the head of my current division and the vice president openly shared insights about the business situation and the organization's atmosphere, so nothing has come as a surprise. If I had to mention something along those lines, being part of a large company means that internal controls are stricter compared to my previous experiences with mega-ventures and startups. I find this refreshing and quite positive. What is the atmosphere like on-site? While I mentioned working solo, I still get the chance to engage with managers and team members from various departments. I can clearly sense the weight of responsibility they carry in managing the business, yet they are always willing to engage in conversation, even with a newcomer like me reaching out unexpectedly. It’s incredibly helpful. How did you feel about writing a blog post? Now that I think about it, I was truly amazed by how actively people contribute to the Tech Blog within the company. What’s particularly impressive is that information is consistently shared without anyone needing to push for it. I feel this proactive approach holds tremendous potential for growth. A question from someone else: Please tell me about any differences you found between the Nagoya and Tokyo companies in terms of culture, atmosphere, and the like. Answer: Nagoya has a small, close-knit setup with around 20 people, many of whom are actively involved in a wide range of fields. It gives the place a unique and distinctive vibe. It feels quite connected to KINTO’s business, and there seem to be many people there who interact with the parent company as well. Recently, occasional drinking parties have started taking place at the Nagoya office. Tsuzura ![Photo of a sunset showing a river running through a foreign city and the townscape on both banks](/assets/blog/authors/ahomu/20241007/tsuzura.jpg =300x) Self-introduction I am a designer in the Marketing Planning Division’s Organization Group! How is your team structured? It consists of nine directors and four designers. What was your first impression of KTC when you joined it? Were there any surprises? Since the departments and teams are divided, I initially thought there might be limited interaction between employees. However, I’ve been able to connect with designers from other departments during lunch and at informal gatherings like private drinking parties. This has allowed me to exchange information and ideas effectively, which has been incredibly helpful. What is the atmosphere like on-site? In our team, we each focus on our own projects, so there isn’t much direct involvement with one another’s work. However, when we gather at the office, we take time to chat and connect while staying productive. Overall, it feels like a well-balanced dynamic. How did you feel about writing a blog post? Extremely excited. A question from someone else: Please tell me about any delicious lunches there are near your office! Answer: I belong to the Muromachi office, and I recommend Dedesuke Saigon Kitchen ! I always opt for their Half & Half option and get pho and curry. They offer about four flavors for each, and every single one is absolutely delicious. I highly recommend trying it! Naoki Uehara ![Profile photo of a cat with its eyes closed](/assets/blog/authors/ahomu/20241007/uehara.png =300x) Self-introduction My name is Uehara. I am part of the Project Promotion Division’s KINTO FACTORY Development Group. I work as a backend engineer. In my previous job, I did news media development at long-established ISP. My favorite programming language is Rust, and my favorite editor is NeoVim. How is your team structured? Back-end development is done by six engineers. If you include the front-end engineers as well, there are around 20 people. What was your first impression of KTC when you joined it? Were there any surprises? I initially thought I might be thrown straight into the deep end with little onboarding in place, but to my surprise, the onboarding process, one-on-one support, and other resources were incredibly well-organized. This made it much easier for me to transition smoothly into the work. The company has an atmosphere that encourages trying new things, which I find incredibly stimulating and inspiring What is the atmosphere like on-site? I think it is a very friendly atmosphere. I’m the kind of person who gets bothered when there’s something I don’t understand, but the other team members always answer my questions without hesitation or frustration, and I’m incredibly grateful for that. I now have more time to focus on development work and can think more deeply about the products from an engineer’s perspective. I feel it’s a great environment for that. **How did you feel about writing a blog post? ** Actually, before I joined KINTO Technologies, I was helped out by an article on its Tech Blog. So, it is a great honor to be joining the ranks of its bloggers myself now. Personally, I make a conscious effort to share my ideas through platforms like Slack and blogs. Moving forward, I aim to contribute more useful information to the Tech Blog. **A question from someone else: Please tell me what your best-ever vacation was! And why, if you do not mind! ** Answer: I guess that has to be my honeymoon in Ise-Shima! The Mawaryanse tickets offered by Meitetsu are incredibly convenient. They are hard to get if you live in Tokyo, but I recommend buying one on Jalan with no limited express ticket attached. Jinrong Liang ![Photo of a curry, fries, and a can of Sui (gin soda)](/assets/blog/authors/ahomu/20241007/jin.jpg =300x) Self-introduction I am Jinrong Liang, and I come from Taiwan. I belong to the Mobile Development Group, which mainly develops Android apps. How is your team structured? In the development team for the products I work on, there are six Android engineers, including me. What was your first impression of KTC when you joined it? Were there any surprises? The team I’m part of is full of energy and includes many Android engineers. Engaging with others on technical topics through study sessions and similar activities has been a highly stimulating and rewarding experience for me. What is the atmosphere like on-site? Depending on the development period, it is often busy, so it felt like quite a fast-paced development team. Even so, everyone on the team wants to make good products, so we spare no effort when it comes to communicating in detail. How did you feel about writing a blog post? Writing my first entry about joining the company gave me an opportunity to reflect on how I felt when I first started and consider how I want to grow and contribute at KTC moving forward. **A question from someone else: Are there any smartphone apps that you have been interested in lately? ** Answer: The PayPay app. I have been using it for many years since the service launched, and I am deeply interested in how it functions as a super app, continuously evolving while maintaining quality as new features are introduced. Dara Lim ![Photo of a car exhibited indoors](/assets/blog/authors/ahomu/20241007/daralim.jpg =300x) Toyota FJ25 Land Cruiser - Toyota Dealership in Bogota, Colombia Self-introduction My name is Dara Lim. I belong to the KINTO Global Development Group in the Business Development Department. My title is Business Development Manager, but the work I do relates closely to working as a business analyst. In my previous job, I worked as a financial analyst and business analyst in the insurance industry. How is your team structured? My team consists of three members, and we collaborate closely with the engineering team to develop software solutions for global full-service lease businesses. What was your first impression of KTC when you joined it? Were there any surprises? I really appreciate the orientation/onboarding process and the 1-on-1 meetings. They helped me to smoothly transition into work. My team was also very supportive. What is the atmosphere like on-site? I really enjoy the Jimbocho office space and its surroundings. My team sits close to each other so we are able to have discussions readily. How did you feel about writing a blog post? Actually, before I joined the company, I was helped by many articles on KINTO Technologies' Tech Blog, so I’m glad to write my initial experience on joining the company. A question from someone else: What is the best thing you have noticed since joining KTC? Answer: I have had the experience of traveling to Latin America to visit KINTO businesses in Peru, Brazil, and Colombia. These were very valuable experiences for me to understand the car leasing business, its profitability and best of all, to meet others fellow KINTO members. I think this is the best thing I’ve experienced since joining KTC. Ikuya Tani ![Illustration of a fluffy cat](/assets/blog/authors/ahomu/20241007/tani.jpg =300x) Self-introduction I am Tani from the KINTO ONE Development Division’s New Car Subscription Development Group, where I am a front-end engineer in the Osaka Tech Lab. I have done a wide variety of front-end development work ranging from production-related stuff to service development. How is your team structured? The team consists of four people. We are developing tools for dealers and in-house use with a small number of people. What was your first impression of KTC when you joined it? Were there any surprises? Before joining the company, I imagined it might be a chaotic environment, blending the atmosphere of a large corporation with that of a startup, and lacking a fully established work structure. However, once I started, I was pleasantly surprised to find a thorough onboarding process, flexible workload adjustments, a fully flextime system, properly reflected overtime pay, a generous welfare package, and a welcoming, friendly team. It turned out to be a collection of wonderful surprises. What is the atmosphere like on-site? I believe it’s an environment with a strong sense of psychological safety, where you feel comfortable actively asking questions about anything you don’t understand. Another attractive feature is that taking part in study sessions is recommended, and in addition, in the case of my team, there is a high degree of freedom in terms of selecting technologies, and rearchitecting and refactoring are also recommended. So all in all, it feels like an environment where it will be easy to level up my skills. How did you feel about writing a blog post? I wanted to convey a detailed and vivid picture of what KINTO Technologies is like, so I dedicated myself to typing away at the keyboard with all my effort. **A question from someone else: What is your favorite possession, and why? **Answer: My Sony noise-cancelling headphones (WH-1000XM5)! Thanks to these, even someone as sensitive to sounds as me can quickly get into the zone, so I really treasure them. Closing words Thank you everyone for sharing your thoughts on our company after joining it! There are more and more new members at KINTO Technologies every day! Stay tuned for more blog entries about joining the company, featuring perspectives from people across various departments in the future! KINTO Technologies is looking for people to work with us! For more information, please see the recruitment information . https://www.kinto-technologies.com/recruit/
この蚘事は KINTOテクノロゞヌズアドベントカレンダヌ2024 の2日目の蚘事です🎅🎄 はじめに こんにちはKTCでAndroid゚ンゞニアをしおいる 長谷川 です 本蚘事ではAndroid開発においお、Applicationクラスでやりがちなミスずその察凊法の䞀䟋を玹介したす。 Applicationクラスずは Androidにおける Applicationクラス ずは公匏ドキュメントを参考に、以䞋の説明ができそうです。 「Base class for maintaining global application state. It is instantiated before any other class for your application/package is created.」 ぀たりグロヌバルで状態を管理できるこず、他のどのクラスよりも先にむンスタンス化されるずいうこずです。 プロゞェクトによっお色々な実装をしおいるケヌスがあるず思いたすが、䞀般的には以䞋のようにアプリ内で䜿甚するラむブラリの初期化をしたり、DIの蚭定を行うこずが倚いず思いたす。 class MyApplication: Application() { override fun onCreate() { super.onCreate() // ラむブラリ初期化 // DIの蚭定 } } もしここでアプリケヌション起動時にサヌバヌからデヌタが欲しくお、API通信をした堎合どうなるでしょうか class MyApplication: Application() { override fun onCreate() { super.onCreate() // ラむブラリ初期化 // DIの蚭定 // APIコヌル } } 少なくずも私はこのようなコヌドを䜕回か芋たこずがありたす。 このコヌドはすぐには問題にならないですが、将来的に問題を匕き起こす可胜性がありたす。 本蚘事ではどのような堎合に、このコヌドが問題になりうるか、説明したす。 4぀のアプリコンポヌネントずApplicationクラスの関係 ApplicationクラスでAPIコヌルを行うず䜕が問題になるかを説明するためには、 Androidの4぀のアプリコンポヌネント に぀いおの理解が必芁です。 䞋蚘の画像は4぀のアプリコンポヌネントず、それぞれのコンポヌネントでよく䜿甚される機胜を衚しおいたす。 Activityは䞻にアプリの画面の責務を持ち、最も䜿甚されるず思いたす。 たた通知の機胜を持぀アプリはServiceを䜿甚するこずが倚いず思いたす。加えおWidgetの機胜を持぀アプリではBroadcast Receiverを利甚するこずになるず思いたす。Content Providerを䜿ったこずがある方は少ないかもしれないですが、自アプリのデヌタを他アプリに公開したい堎合などに䜿甚できたす。 泚意しお欲しいこずは、これらのコンポヌネントのどれかが動いおいる堎合、Applicationクラスがむンスタンス化されおいるずいうこずです。特にActivity以倖のコンポヌネントはナヌザヌが明瀺的にアプリを開いおいないこずがありたす。 䟋えば、Widgetを持぀アプリの堎合、端末の再起動などでりィゞェットが䜜成されたすが、この時にApplicationクラスはむンスタンス化される可胜性がありたす。 もしApplicationクラスにAPIコヌルが蚘述されおいる堎合、このタむミングでナヌザヌはアプリを開いおいなくおも(そしおほずんどの堎合、開発者も意図しないタむミングで)APIコヌルが行われおしたいたす。 通知の機胜を持぀アプリの堎合、push通知が届くタむミングでApplicationクラスがむンスタンス化される可胜性がありたす。 もし耇数のナヌザヌにたずめおpush通知を送信した堎合、ほが同タむミングでAPIコヌルを行っおしたい、ある意味DDoS攻撃のような状態になるリスクがありたす。 特にこの問題はナヌザヌ数の増加など埌になっお発芚するこずもあり、知識ずしお知っおおくこずが倧切です。 最初にAPIコヌルしたい堎合どうする 察凊方法はたくさんあるず思うので、正解はありたせんが䞀䟋を玹介したす。 デヌタは必芁な時に必芁な分だけ取埗するべきなので、4぀のコンポヌネント内でそれぞれ取埗したしょう。 その際に取埗したデヌタを4぀のコンポヌネント内で䜿いたわしたい堎合は、氞続化をしたり、デヌタをApplicationに保持させたり、DIでラむフサむクルスコヌプをSingletonに蚭定したクラスに保持させおおくこずが可胜です。 おわりに お疲れ様でした。短い蚘事ですが、今回はApplicationクラスのラむフサむクルず気を぀けたい実装に぀いお解説したした。 本蚘事ではApplicationクラスに蚘述されたAPIコヌルを䟋に説明したしたが、䟋えばアプリ起動のむベントなどをApplicationクラスで送信するこずもよくある間違いの1぀かなず思いたす。 䞊蚘で説明した通り、Applicationクラスのむンスタンス化は必ずしもナヌザヌが明瀺的にアプリを起動したタむミングずは䞀臎しないためです。 ナヌザヌがアプリを起動したむベントであれば、Activityに蚘述するべきです。もしマルチアクティビティを採甚しおいるアプリだずしおも、アプリの入り口の導線を正しく把握したしょう。 本蚘事がどなたかの助けになれば幞いです。 ※Android ロボットは、Google が䜜成および提䟛しおいる䜜品から耇補たたは倉曎したものであり、 クリ゚むティブ・コモンズ 衚瀺 3.0 ラむセンスに蚘茉された条件に埓っお䜿甚しおいたす。
こんにちは。 DBRE チヌム所属の @hoshino です DBREDatabase Reliability Engineeringチヌムでは、暪断組織ずしおデヌタベヌスに関する課題解決や、組織のアゞリティずガバナンスのバランスを取るためのプラットフォヌム開発などを行なっおおりたす。DBRE は比范的新しい抂念で、DBRE ずいう組織がある䌚瀟も少なく、あったずしおも取り組んでいる内容や考え方が異なるような、発展途䞊の非垞に面癜い領域です。 匊瀟における DBRE チヌム発足の背景やチヌムの圹割に぀いおは「 KTC における DBRE の必芁性 」ずいうテックブログをご芧ください。 この蚘事では、Amazon Aurora MySQL 2からAmazon Aurora MySQL 3ぞの移行の際に mysqldump コマンドで発生した゚ラヌメッセヌゞなしで凊理が終了する珟象に぀いおご玹介したす。少しでも参考になれば幞いです。 ゚ラヌの原因 たずぱラヌの原因に぀いお説明したす。今回の゚ラヌメッセヌゞなしで凊理が終了する珟象は、Amazon Aurora MySQL 2のデヌタベヌスのトリガヌに蚭定された照合順序が、MySQL 5系では未察応の utf8mb4_0900_ai_ci だったため、mysqldump がそれを認識できなかったこずが原因で発生したした。 原因が刀明するたでの調査過皋ず解決方法を、以䞋で詳しく説明させおいただきたす。 発生した珟象 Aurora MySQL 2からデヌタを゚クスポヌトするために、mysqldump コマンドを盎接実行したした際に、゚ラヌメッセヌゞが衚瀺されないたた終了しおしたう珟象が発生したした。 コマンドの実行埌に exit code を確認したずころ、2 Internal Error が返されたした。゚ラヌが発生しおいるこずはわかりたしたが、具䜓的な原因を特定できない状況です。 $ mysqldump --defaults-extra-file=/tmp/sample.cnf > sample.sql $ echo $? 2 原因調査 問題の原因を特定するために、以䞋を実斜したした。 たず、別バヌゞョンの mysqldump コマンドを実行した堎合の挙動を確認したした。 今回、Aurora MySQL 2に察しおMySQL 5.7系の mysqldump コマンドを䜿甚しおいたす。 $ mysqldump --version mysqldump Ver 10.13 Distrib 5.7.40, for linux-glibc2.12 (x86_64) 詊しにMySQL 8系の mysqldump コマンドで゚クスポヌトを詊みたした。 $ mysqldump80 --version mysqldump Ver 8.0.31 for Linux on x86_64 (MySQL Community Server - GPL) $ mysqldump80 --defaults-extra-file=/tmp/sample.cnf > sample.sql $ echo $? 0 結果は成功でした。このこずから、MySQL のバヌゞョン差異が゚ラヌの原因である可胜性が浮䞊したした。 さらに、mysqldump コマンド自䜓が内郚で゚ラヌを起こしおいる可胜性を考え、さたざたなオプションを詊しお゚ラヌメッセヌゞの有無を確認したした。その結果、 --skip-triggers オプションを付䞎するず゚ラヌが発生しないこずが刀明したした。 $ mysqldump --defaults-extra-file=/tmp/sample.cnf --skip-triggers > sample.sql $ echo $? 0 この結果から、トリガヌに関連する郚分で゚ラヌが起きおいるず掚枬されたす。そこで、トリガヌの蚭定を確認したした。 mysql> SHOW TRIGGERS FROM sample_database \G *************************** 1. row *************************** Trigger: sample_trigger Event: UPDATE Table: sample_table Statement: BEGIN SET NEW.`lock_version` = OLD.`lock_version` + 1; END Timing: BEFORE Created: 2024-10-04 01:06:38.17 sql_mode: STRICT_TRANS_TABLES Definer: sample-user@% character_set_client: utf8mb4 collation_connection: utf8mb4_general_ci Database Collation: utf8mb4_0900_ai_ci *************************** 2. row *************************** 以䞋省略 ここで、デヌタベヌスの照合順序Collationが utf8mb4_0900_ai_ci になっおいるこずに気付きたした。これは MySQL 5系では認識されない照合順序です。 ゚ラヌが発生しおいたテヌブルのトリガヌ定矩を utf8mb4_general_ci に修正し、再床 mysqldump コマンドを実行したした。 mysql> SHOW TRIGGERS FROM kinto_terms_tool \G *************************** 1. row *************************** Trigger: sample_trigger Event: UPDATE Table: sample_table Statement: BEGIN SET NEW.`lock_version` = OLD.`lock_version` + 1; END Timing: BEFORE Created: 2024-10-04 01:06:38.17 sql_mode: STRICT_TRANS_TABLES Definer: sample-user@% character_set_client: utf8mb4 collation_connection: utf8mb4_general_ci Database Collation: utf8mb4_general_ci *************************** 2. row *************************** 以䞋省略 $ mysqldump --defaults-extra-file=/tmp/sample.cnf > sample.sql $ echo $? 0 mysqldump が成功したした。MySQL 8系のコマンドで成功しおいた理由も、この照合順序の違いで説明できたす。 この調査により、トリガヌに蚭定されおいたデヌタベヌスの照合順序が MySQL 5系では存圚しない utf8mb4_0900_ai_ci だったため、mysqldump が倱敗しおいたこずが刀明したした。 Amazon Aurora MySQL 2 ず MySQL 5.7 の関係に぀いお Amazon Aurora MySQL 2は MySQL 5.7 をベヌスに構築されおいたすが、完党に同䞀ずいうわけではありたせん。AWS は Aurora に独自の拡匵機胜を実装しおおり、その䞭には MySQL 8.0 の䞀郚機胜今回問題ずなった utf8mb4_0900_ai_ci 照合順序なども含たれおいたす。 MySQL 5.7 にお utf8mb4_0900_ai_ci を照合順序に指定しようずするず、以䞋の゚ラヌが発生したす。 mysql> ALTER DATABASE sample_database CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ERROR 1273 (HY000): Unknown collation: 'utf8mb4_0900_ai_ci' 䞀方、Aurora MySQL 2では同じコマンドが正垞に実行されたす。 mysql> ALTER DATABASE sample_database CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; Query OK, 1 row affected (0.03 sec) mysql> SHOW CREATE DATABASE sample_database; +------------------+---------------------------------------------------------------------------------------------------------+ | Database | Create Database | +------------------+---------------------------------------------------------------------------------------------------------+ | sample_database | CREATE DATABASE `sample_database` /*!40100 DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci */ | +------------------+---------------------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec) 远加の調査 ゚ラヌの原因がトリガヌのみなのか怜蚌するために、他の MySQL のオブゞェクトも調査したす。 Aurora MySQL 2の環境でビュヌVIEWの照合順序Collationを utf8mb4_0900_ai_ci で䜜成し、そのダンプ時の挙動を確認したした。 CREATE VIEW customer_view AS SELECT customer_name COLLATE utf8mb4_0900_ai_ci AS sorted_name, address FROM customers; mysqldump コマンドを実行するず、゚ラヌなく成功したす。 $ mysqldump --defaults-extra-file=/tmp/sample.cnf > sample.sql $ echo $? 0 次に、Aurora MySQL 2の環境でストアドプロシヌゞャPROCEDUREの堎合も同様に確認したした。 DELIMITER // CREATE PROCEDURE sample_procedure() BEGIN DECLARE customer_name VARCHAR(255); -- 照合順序を指定した文字列操䜜 SET customer_name = (SELECT name COLLATE utf8mb4_0900_ai_ci FROM customers WHERE id = 1); -- 照合順序を䜿甚した比范 IF customer_name COLLATE utf8mb4_0900_ai_ci = 'sample' THEN SELECT 'Match found!'; ELSE SELECT 'No match.'; END IF; END // DELIMITER ; こちらも問題なくダンプが成功したす。 $ mysqldump --defaults-extra-file=/tmp/sample.cnf > sample.sql $ echo $? 0 Aurora MySQL 2では、MySQL 5系には存圚しない照合順序Collation utf8mb4_0900_ai_ci を䜿甚できたす。 しかし、mysqldump コマンドが MySQL 5ç³» ベヌスの堎合、この照合順序を認識できず、特にトリガヌに関連する郚分で゚ラヌが発生するこずがわかりたした。 ビュヌやストアドプロシヌゞャでは問題が生じないこずから、トリガヌにおける照合順序の扱いが原因であるず掚枬されたす。 解決方法 今回の問題は、トリガヌに蚭定されおいたデヌタベヌスの照合順序がMySQL 5系では未察応の utf8mb4_0900_ai_ci であったために発生しおいたした。 ゚ラヌぞの察応ずしおはデヌタベヌスの照合順序Collationを utf8mb4_general_ci に倉曎し、トリガヌを再蚭定したした。これにより、MySQL 5.7系の mysqldump コマンドでも照合順序を正しく認識できるようになり、゚クスポヌトが正垞に行えるようになりたした。 ALTER DATABASE sample_database CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; -- 必芁に応じおトリガヌを再䜜成 別の解決策ずしお、MySQL 8.0系の mysqldump コマンドを䜿甚する方法もありたす。MySQL 8.0 系のクラむアントは utf8mb4_0900_ai_ci を認識できるため、デヌタベヌスの照合順序を倉曎せずに゚クスポヌトが可胜です。 $ mysqldump80 --defaults-extra-file=/tmp/sample.cnf > sample.sql $ echo $? 0 環境や他の䟝存関係の制玄からクラむアントのバヌゞョンを簡単に倉曎できない堎合もありたす。 おわりに 今回の事䟋では、mysqldump コマンドが゚ラヌメッセヌゞを衚瀺しないたた終了し、exit code を確認するこずで初めお゚ラヌが発生しおいるこずに気付きたした。このような゚ラヌメッセヌゞなしで凊理が終了する珟象は、気付かないたた䞍完党なデヌタを゚クスポヌト・むンポヌトしおしたうリスクがありたす。そのため、デヌタベヌスのバックアップや移行をする際には、exit code を確認するなど、凊理結果をチェックするこずが重芁です。 Aurora MySQL 2系はすでに EOLEnd of Lifeを迎えおおり、サポヌトが終了しおいたす。ただ皌働しおいる環境があり、移行を怜蚎しおいるこずがあればお気を぀けください。
この蚘事は KINTOテクノロゞヌズアドベントカレンダヌ2024 の2日目の蚘事です🎅🎄 はじめに掻動の背景玹介 こんにちは。孊びの道の駅チヌムの「きんちゃん」です。普段はコヌポレヌト゚ンゞニアずしお「党瀟で利甚するITシステムの維持管理」を行っおいたす。 最近は「生成AI掻甚プロゞェクト」や、「技術広報グルヌプ」ずいう組織にも所属し、色々ず掻動しおいたす。 さお、 以前のテックブログ で「孊びの道の駅」の成り立ちに぀いおご玹介したした。 その䞭に「瀟内Podcast」の掻動に぀いお蚘茉しおいたした。今回の蚘事では、このPodcastぞの取り組みに぀いお詳しくご玹介したす。 このPodcastの取り組みは、孊びの道の駅メンバヌであるHOKAさんのこんな想いから始たりたした。 瀟内の色々な取り組みを、Podcastで発信しおいきたい ずおもシンプルなモチベヌションだったこずに加えお、基本的に「Noを蚀わないメンバヌ」が集たっおいたこずもあり、孊びの道の駅チヌムの掻動ずしお取り組んでみるこずになりたした。 もちろん、孊びの道の駅チヌムの取り組みなので、「孊びのための情報発信」ずうたく組み合わせる必芁がありたす。 あれこれ議論の䞊で、以䞋の圢にたずたりたした。 瀟内で勉匷䌚を䞻催・運営・参加しおいる人にむンタビュヌをする。その内容を配信する ねらいは、以䞋の通りです。 「瀟内に倚くの勉匷䌚があるけど、どんな人がどんな想いで開催しおいるんだろう」ずいう疑問に答えられる 実際に参加した人のナマの声を聞いお、䟡倀を感じおもらえる もし興味を持っおくれる人がいたら、勉匷䌚参加のきっかけにできる 色々な勉匷䌚の存圚を芋える化聎こえる化しおいくず、瀟内に「孊びの文化」が根付いおいく 「Podcastっお䜕だっけ」 Podcastをやろうず決たったものの、「䜕をどうやるずPodcastになるんだっけ」ずいう疑問が出おきたす。 むンタヌネットラゞオの圢で公開するもの瀟倖の人も聎くのかな 専甚のアプリで配信しなければならないもの配信する偎も聎く偎も準備の手間が  蚭備ずか、どういうものが必芁なんだっけ 考えれば考えるほど色々な壁が出おきたす。 ずは蚀え、我々はシンプルに「瀟内の情報を瀟内に届ける」こずを䟡倀ずしたいので、「たずは出来る仕組みでプロトタむプを䜜っお手觊り感を詊す」「その埌のフィヌドバックを受け、カむれンしおいく」ずいう「アゞャむルなマむンド」で進めるこずずしたした。 さぁ、最初のむンタビュヌだ そうず決たれば、むンタビュヌすべき勉匷䌚の遞定です ちょうど良いタむミングで、瀟内で「合同勉匷䌚」ずいう倧型の勉匷䌚が開催される予定があったため、初回はその勉匷䌚ぞず参加し、運営チヌムの皆さんぞむンタビュヌを実斜する事ずなりたした。 しかし、参加圓日にバタバタしおしたい、圓日の録音はできず 。 結果、代替案ずしお「埌日、運営メンバヌの皆さたに集たっおもらい、むンタビュヌする圢匏」を取る事ずしたした。実は、この代替案が今埌のPodcastのカタになっおいくのでした 実際のむンタビュヌの堎はずおも盛り䞊がり、無事に収録が完了できたした。 しかし、そこで新たな難関が 実は、「どのようにPodcastコンテンツを䜜るか」「どうやっお配信するか」をたったく決めないたた、ここたで来おいたのです。 チヌム内で議論しながら詊行錯誀の結果、以䞋のような圢に萜ち着きたした 録音したデヌタの加工 ClipchampMicrosoft365ファミリヌ補品を利甚し、音声メむンの動画ファむルずしお仕䞊げる 配信方法 瀟内のSharepointにファむルを眮いお、それを皆さんにPCやスマホ䞊で開いお再生しおもらう 最終的なPodcast公開フロヌは、 コンテンツを完成させる 孊びの道の駅チヌム内レビュヌを実斜 むンタビュむヌのレビュヌを実斜 䞊長レビュヌを実斜初回実斜した䞊で、倧きな懞念がなければ2回目以降は我々に刀断を移譲しおいただく 瀟内アナりンス公開 ずなりたした。あくたでも瀟内向けコンテンツずいう事を前提に、シンプルなフロヌを敎備したした。 その埌、すべおのチェックが通った䞊で、晎れお瀟内に公開できたした ![](/assets/blog/authors/ktc-taku-yajima/2024-12-02/started-a-podcast001.png =700x) その埌のPodcast 初回のPodcast公開で自信を付けた我々は、2回目、3回目の䌁画を進めおいきたす。 むンタビュヌを繰り返すたびに、我々の䞭に知芋が貯たっおいき、䞀定のカタ化ができるようになりたした。 䌁画のカタ 瀟内の勉匷䌚や、情報発信の掻動の情報を集める 孊びの道の駅チヌムから運営メンバヌぞアプロヌチをしお、むンタビュヌを実斜する むンタビュヌした結果をPodcast化する 運営チヌム、むンタビュむヌのレビュヌを経た埌に、公開瀟内アナりンスする 録音・線集・配信のカタ むンタビュヌはZoomで行うメンバヌがそもそも倚拠点に散らばっおいるため マむクは各人のPCマむク、䌚議宀のマむクを利甚する。音質はいったん劥協する Zoomの録画デヌタを音源ずする 音源デヌタはClipchampを利甚しお線集・加工する 音源デヌタを線集埌、瀟内のストレヌゞMS SharePointに保存する 芖聎者はMS Stream経由で配信を聎く このカタ化ができたこずで、スムヌズに仕組みが回るようになり、珟圚たでで11本のコンテンツを配信できたした。 今埌に぀いお このPodcast配信掻動を続ける䞭で、我々の䞭に「もっずこういう拡がりを䜜っおいきたい」ずいう気持ちが湧いおくるようになりたした。 勉匷䌚以倖にも、色々な圢で瀟内掻動をされおいる方々にむンタビュヌしたい マネゞメント局の方々にむンタビュヌしお、普段考えおいる事を瀟内の皆さんに聞いおもらいたい 瀟内に限らないアりトプットをしおいきたい 来幎以降も、孊びの道の駅チヌムは積極的に情報発信しおいきたすので、皆様お楜しみに
この蚘事は KINTOテクノロゞヌズアドベントカレンダヌ2024 の2日目の蚘事です🎅🎄 はじめに こんにちは 新車サブスク開発G、Osaka Tech Lab 所属の high-g @high_g_engineer です。 最近は、type-challenges ずいう TypeScript の型パズル問題集を業務前に取り組むこずを日課にしおいたす。 本蚘事では、TypeScript の型システムの䞭でも少し癖のある infer の Tips をいく぀か玹介したす。 たずは、infer の解説の前に、infer を利甚する䞊で必須の Conditional Types に぀いお説明したす。 Conditional Types ずは Conditional Types は、条件型、型の条件分岐ずも蚀われ、型レベルで条件分岐を可胜にする型システムの機胜です。 以䞋のように蚘述したす。 type ConditionalTest<A> = A extends 'a' ? true : false 䞊蚘の右蟺は、以䞋のような意味になりたす。 型 A が リテラル型 'a' に代入可胜な堎合、true 型ずなる 型 A が䞊蚘以倖の堎合、false 型ずなる 䞀般的なプログラミング蚀語の䞉項挔算子ず同じような挙動ですね。 ちなみに、ここでの extends キヌワヌドは、䞀般的なオブゞェクト指向プログラミングにおける継承ずは異なる意味を持ちたす。 この堎合の extends は型の互換性assignabilityを確認するキヌワヌドになりたす。 infer ずは inferずは、「掚論する」を意味し、Conditional Types 内でのみ利甚できるキヌワヌドで、TypeScript 2.8 から導入されたした。 以䞋のように蚘述したす。 type InferTest<T> = T extends (infer U)[] ? U : never 右蟺では、Conditional Types を利甚し、extends の右偎で取埗したい型を infer ◯ で蚘述したす。 䞊蚘の型の堎合、型 T が「任意の芁玠型の配列」であれば、その芁玠の型を返すずいう意味になりたす。 ※ここでの never は、条件に合臎しない堎合に返される型です (infer U)[] は、任意の芁玠型の配列を衚す型なので、string[]、number[]、boolean[] などあらゆる配列型が該圓したす。 なので、型 T が number[] だった堎合、型の解決は以䞋のようになりたす。 type Result = InferTest<number[]> // number あくたでここに瀺したのは䞀䟋で、これ以倖にも infer の利甚方法は倚数存圚したす。 infer を利甚した関数型の操䜜 戻り倀の型を取埗する堎合 const foo = (): string => 'Hello, TS!!' type MyReturnType<T> = T extends (...args: any[]) => infer R ? R : never type FunctionReturn = MyReturnType<typeof foo> // string 先皋ず同じ芁領で Conditional Types を蚘述し、extends の右偎で、取埗したい型を蚘述したす。 今回は、戻り倀の型を取埗したいので、extends の右偎に関数の型を蚘述し、戻り倀の郚分に infer を蚘述しお完了です。 これは TypeScript の組み蟌みナヌティリティ型 ReturnType<T> ず同じ挙動になりたす。 匕数の型を取埗する堎合 const foo = (arg1: string, arg2: number): void => {} type MyParameters<T> = T extends (...args: infer Arg) => any ? Arg : never type FunctionParamsType = MyParameters<typeof foo> // [arg1: string, arg2: number] 匕数はタプル型になるため、残䜙匕数スプレッド構文を利甚するこずで、匕数が任意の数の堎合でも察応できるようになりたす。 Conditional Types + 取埗したい型 + infer を蚘述するこずで型を抜出できたす。 これは TypeScript の組み蟌みナヌティリティ型 Parameters<T> ず同じ挙動になりたす。 infer を利甚した配列型タプル型の操䜜 末尟の芁玠を取埗したい堎合 タプル型の先頭芁玠の型を取埗する堎合、以䞋のような型定矩で解決したす。 type Tuple = [number, '1', 100] type GetType = Tuple[0] // number しかし、タプル型の末尟の芁玠の型を取埗したい堎合、 Tuple[length-1] の様な蚘述は TypeScript では出来たせん。 この解決方法ずしお、ベストなのが infer です。以䞋のような型定矩になりたす。 type ArrayLast<T> = T extends [...infer _, infer Last] ? Last : never [...infer _, infer Last] で、型 T が配列型たたはタプル型の堎合に、末尟の芁玠の型を Last ずしお抜出したす。 type Test1 = ArrayLast<[1, 2, 3]> // 3 type Test2 = ArrayLast<[string, number, boolean]> // boolean type Test3 = ArrayLast<[]> // never infer を利甚したリテラル型の操䜜 リテラル型の先頭の文字の型を取埗する堎合 type LiteralFirst<T extends string> = T extends `${infer First}${string}` ? First : never ${infer First}${string} は、文字列の先頭の文字を First ずしお抜出し、残りの郚分を string ずしお扱いたす。 リテラル型の先頭を倧文字にしお取埗する堎合 type FirstToUpper<T extends string> = T extends `${infer First}${infer Rest}` ? `${Uppercase<First>}${Rest}` : never 䞊蚘は先皋ず同じ様に、先頭ずそれ以倖に分けお文字列を凊理し、 Uppercase<First> でナヌティリティ型を䜿甚しお、先頭の文字を倧文字に倉換し、残りの文字列ず結合したす。文字列が空の堎合は never 型を返したす。 リテラル型の先頭ず末尟から空癜文字、改行文字などを取り陀く堎合 type Space = ' ' | '\n' | '\t' type Trim<S extends string> = S extends `${Space}${infer T}` | `${infer T}${Space}` ? Trim<T> : S; Space ずいう空癜文字、改行文字を栌玍した型を䜜成し、Conditional Types の条件に圓おはたる堎合、型 Trim を再垰的に適甚するこずで、文字列の先頭ず末尟の空癜文字を取り陀くこずができたす。 たずめ これらの䟋のように、infer を利甚するこずで、ある型から欲しい郚分を抜き出せるため、型を衚珟する際の自由床が栌段に䞊がりたす。 少し癖があるため、慣れるたでに時間がかかりたすが、非垞に䟿利な機胜です。 型を利甚するこずで堅牢な開発が実珟できたすが、型を正しく衚珟しきれないず以䞋のようなリスクが生じたす。 䞍芁な型定矩によるコヌド可読性の䜎䞋 䞍必芁に耇雑な型定矩によるメンテナンスコストの増倧 型安党性の䜎䞋 infer をはじめずした TypeScript の型システムを適切に掻甚するこずで、簡朔か぀明確な型衚珟を実珟し、開発生産性ず品質向䞊を垞に心がけられるようになっおいきたしょう。
Introduction Hello, I am Ueyama, a new member who joined the company in April. In this article, I've compiled the reflections and thoughts of everyone who started with me in April 2024. I hope that it will be useful for everyone who is interested in KINTO Technologies, and for everyone who took part in this article if they look back at it someday. 🌞 Matsuno ![Golf](/assets/blog/authors/K.Ueyama/Newcomers/golf.jpg =250x) Self-introduction Nice to meet you, everyone! I am Matsuno, a new member who joined the company in April 2024! I belong to the MSP Team in the Platform Development Division’s Platform Group. In my previous job, I was responsible for maintaining and operating systems built on AWS. How is your team structured? The MSP Team I belong to consists of four people. I am mainly responsible for routine work we have taken over from other teams. What was your first impression of KTC when you joined it? Were there any surprises? I got the impression that there are lots people who seem to be outstanding, including the people who joined when I did. Also, finding there were lots of frank people here was a surprise in a good sense. What is the atmosphere like on-site? Basically, the atmosphere makes it easy to ask questions and consult people anytime. In addition, when people are working, they concentrate silently on what they are doing, and when they are chatting, they are very friendly. So in that sense, it is nice and balanced. How did you feel about writing a blog post? I already knew about the Tech Blog and was interested in it as well, so I thought it was a perfect opportunity! m ![Sea](/assets/blog/authors/K.Ueyama/Newcomers/sea.jpg =250x) Self-introduction I am m from the Creative Office. In my previous job, I was a UI/UX designer at an SES IT company. How is your team structured? There are 10 directors and designers. What was your first impression of KTC when you joined it? Were there any surprises? I was struck by how clean the office was, and how comfortable, too, since it even has a free drink server. What is the atmosphere like on-site? The age group is mostly 30s to 40s, and everyone is extremely knowledgeable and experienced. The office is often surprisingly bustling. How did you feel about writing a blog post? I think it is good that there is a forum where we can share our own thoughts and knowledge! Rassel ![Castle](/assets/blog/authors/K.Ueyama/Newcomers/castle.png =250x) Self-introduction I am Rassel from Bangladesh, and I joined the company in April 2024. I am an iOS developer in the Prism Team in the Platform Development Division’s Mobile App Development Group. How is your team structured? The team consists of around 14 people, and includes engineers, designers, and POs. What was your first impression of KTC when you joined it? Were there any surprises? I am interested in mobility services. I was very impressed by KTC’s mission of leading Toyota’s mobility services. There was nothing in particular that was a surprise for me. What is the atmosphere like on-site? The people are kind and helpful. There are no barriers to using the latest technology. It is also easy to talk about technical problems. How did you feel about writing a blog post? This is the first time I have written a blog post in this context, but I think it is a really cool and fun idea. Ueyama ![Pasta](/assets/blog/authors/K.Ueyama/Newcomers/pasta.jpg =250x) Self-introduction I am Ueyama from the Work System Group. In my previous job, I did system development at an SIer. How is your team structured? Our team includes seven engineers. What was your first impression of KTC when you joined it? Were there any surprises? I was able to talk to the same team members as in my consultation and interview, so I did not feel all that surprised by anything. What is the atmosphere like on-site? It is an environment where everyone is really kind and easy to talk to. How did you feel about writing a blog post? The format of managing self-introduction articles on GitHub and publishing them with pull requests was a surprise. R ![Catandfish](/assets/blog/authors/K.Ueyama/Newcomers/catfish.jpg =250x) Self-introduction I am R, and I belong to the Member Platform Team in the Development Division’s Common Services Development Group. The ratio of front-end to back-end development is around 6:4. How is your team structured? There is one product manager (PdM) and four engineers. What was your first impression of KTC when you joined it? Were there any surprises? Seeing up close outstanding people who are involved in multiple projects, events, and so on both inside and outside the company, I got the impression that it is a very free environment. Before I joined KTC, I had attended a study group held by it, and although most of the people taking part were young, I got to know a bit about its atmosphere beforehand. So, There was nothing in particular that was a surprise for me. What is the atmosphere like on-site? The back-end work is done in silence, and with the front-end work, things sometimes get very lively, with everyone talking about their views, impressions, and so on about a screen with it being implemented on. How did you feel about writing a blog post? I didn't have any worries when reading it, but when it came to writing it myself, I was troubled because I didn't know what to say. It looks like I need to hone my verbalization and communication skills. kasai ![Chick illustration](/assets/blog/authors/K.Ueyama/Newcomers/chickicon.png =250x) Self-introduction I am kasai from the SRE Team in the Platform Development Division’s Platform Group. I was an SRE in my previous job as well. How is your team structured? There are lots of people in the group, but the SRE Team consists of just two! An article about the team is going to be posted on the blog at a later date, so stay tuned for that! What was your first impression of KTC when you joined it? Were there any surprises? I got to thoroughly talk things over and get on the same page as the company in my consultation, interview, and so on, so I did not get any surprises! What is the atmosphere like on-site? Very friendly indeed! How did you feel about writing a blog post? At last...my time...has come! https://blog.kinto-technologies.com/posts/2022-12-03-ktc_club_introduction/ Closing words Thank you everyone for sharing your thoughts on our company after joining it! There are more and more new members at KINTO Technologies every day! Please look forward to more company-joining blog entries by various people from various departments in the future, too. 🍻 KINTO Technologies is looking for people to work with us! For more information, please see the recruitment information . https://www.kinto-technologies.com/recruit/
Introducing the Team and Its Work Our team is the Woven Payment Solution Development Group. However, before I tell you about our team, I need you to know a bit about Woven City . Woven City is both a test course for mobility and a city for conducting demonstration experiments, where Toyota Motor Corporation is developing technologies with the aim of “mass-producing happiness.” The development of Woven City is led by Woven Planet Holdings, a member of the Toyota Group. Our team is working with members of Woven Planet’s Payment Solution team and other teams to develop payment services to be used in Woven City. KINTO Technologies and Woven Planet are separate companies, but when it comes to the development work, we are working as one team without particularly being conscious of that. Woven City is a mobility test course for inventing the commonplace things of the future, and we are also required to develop features that will contribute to that. In Woven City, all the residents and other people involved are either inventors who create new value in some form or other, or people who create inventions together with them. That means those inventors must be provided with the features and data that they need to create better products, services, and the like. This is a big difference between general payment services and the ones we make. For example, for how a given service accepts payments from users, we are thinking about UX aspects such as making it easier to consider things like whether the best option is prepaid, postpaid, recurring payment, or some other method. We are also looking at the data provision aspects, and thinking about providing not just the payment information but that combined with other Woven City data, in a form that will enable things to be considered from multiple angles. Of course, these kinds of data are not only provided to inventors, but also used to kaizen the system that is Woven City itself. (Of course, we never obtain people’s personal information without their consent.) How We Work The Payment Solution team, including the members from Woven Planet, is doing the development work remotely from home. However, we come to the office once a week on Wednesday, giving us an opportunity to communicate directly with each other. We use Google Meet and Slack for our communication tools. In Woven Planet, the basic premise is that communication is in English, so we converse in that, especially if there are non-Japanese speakers present. Also, on Slack and in documents, communication is done in English even when it is between Japanese people. We also use English for postings that are like talking to ourselves, so if we write about something we are concerned about, it sometimes leads to getting advice from other teams or sparks a discussion. Besides that, other teams also sometimes consult us, and sometimes, that can lead straight into starting up an oral chat via Huddle, for example. So, there is lively communication even though we are working remotely. When we come to the office, we enjoy the stimulation you can get from actually meeting people in person, such as discussing things face-to-face and eating the company food together if our lunchtimes coincide. Our development work also gives us opportunities to visit the planned site for building Woven City. Woven City itself is currently under construction, so it looks different depending on when we visit, and although there are still many vacant areas, it is a useful experience for expanding our mental image of it actually being used. Technologies We Are Using Programming language Kotlin Our team’s scope is server-side applications, and we use Kotlin to develop them. A major reason why we chose Kotlin is its high interoperability with Java. There are already a great many Java engineers in KINTO Technologies and the group, and we are hoping this will induce them to join our team quickly. I myself have experience of using Java in the past, and had a go at building simple web applications with Kotlin several times as part of introducing it. Through this, I became able to code in it about as smoothly as in Java and with no real problems just by referring to the official documentation a bit. Some of the members have experience of server-side development in other languages like Go, C#, and Ruby but none in terms of Java itself, but they can all use Kotlin with no real problems now, too. Initially, we used Kotlin as a better version of Java, but now, we are starting to forget about Java and consciously use Kotlin for its own merits. Additionally, we use Gradle for project management and write the configuration files in Kotlin Script. The main libraries we are using Ktor, Koin, Exposed, Kotest, MockK, etc. Our services consist of several application services, many of which are web services with a REST API. You can use Spring MVC and Spring Boot with Kotlin as well, but we chose Ktor instead. We chose not to use Spring because we wanted to avoid code that is heavily annotated and feels like magic. However, we still wanted to use a dependency injection mechanism for testing and dependency management, so we adopted Koin as our DI library. Koin also has an annotation-based configuration method like Spring, but it has a DSL-based configuration method as well, and we are using that one. Although it requires knowledge of Koin and of DSL itself, DSL can be incorporated into normal Kotlin code more naturally than annotations, so I feel you can express your intentions clearly in it. In addition, we use various FOSS libraries, such as Exposed for ORM and Kotest and MockK for testing. Ktor official website Koin official website Exposed GitHub repository Kotest official website MockK official website This is more of a personal interest than a team one, but since Ktor also works in GraalVM , I would like to try doing a native build with GraalVM if I get the chance. Reference: https://ktor.io/docs/graalvm.html#prepare-for-graalvm Application Infrastructure Kubernetes The applications we are developing are deployed on Kubernetes, and for the services we are developing ourselves, we write the configuration files ourselves in YAML. Another team is in charge of the development and operation of the Kubernetes environment as a whole, but this team has also prepared a CD mechanism. Basically, if we turn the new configuration data into PRs then review and merge them on GitHub, everything right up to deploying the apps gets done automatically. The team also responds to requests from us about configuration, architecture, and so on, so they are always a tremendous help. How We Do Development Because of the project’s unprecedented nature of creating a city that functions as a test course, there are many unknowns not just in the parts that our team is working on but in the whole thing, too. So, using as a foothold the features that will be required as a matter of course, we are coming up with rough hypotheses and development plans, and are learning about our own services ourselves as we create them, and about Woven City, too. Specifically, the process we are following is to set a big theme for each quarter, add or update features as needed for that, then check them by running small demos in the office. For this reason, we adopt an agile development method, we do the development iteratively with two weeks as the timeboxes, while managing the backlog with Jira. We are not following strict Scrum practices, but are seeking to adapt to the facts that come to light and changes in requirements that arise along the way as we develop things. Conclusion What is difficult about this project is that, at this point in time, the real test course that is Woven City still does not exist, and of course, the users are only potential ones, too. This goes for all teams and not just ours. It often happens that another team wants to use a feature that is still in development, but it is still unstable. On the other hand, you could also say that since there are no general users, it does not matter (at least now) if things are unstable to a certain extent. While being in this unstable state can be taken as grounds for not using each other’s creations, it can also be relished as an opportunity to improve them by respectfully but frankly pointing out their defects, all in the spirit of forging and honing them together through use. We definitely want people who think in the latter way to take part in our project.
こんにちは、ヒロダ (@___TRAsh) です🎅 今幎のモバむルアプリ開発グルヌプはアりトプットに力を入れた幎でした。 iOSDCやDroidKaigiでのスポンサヌドや倖郚登壇、このテックブログの執筆など、様々な圢でアりトプットを行っおいお、みなさんにも知っおいただける機䌚が増えたかなず感じおいたす。 今幎の最埌の締めくくりずしお、 KINTO TechnologiesのAdvent CalendarでAndroid/Flutter/iOSでシリヌズ投皿したす🎉 https://qiita.com/advent-calendar/2024/kinto-technologies 匊瀟のAndroid/Flutter/iOS゚ンゞニアが頑匵っおシリヌズ曞き切るので、ぜひチェックしおみおください🎅 本日はそんなAndroid/Flutter/iOSのアプリ開発をしおいるモバむルアプリ開発グルヌプのこずを玹介させおいただきたす。 モバむルアプリ開発グルヌプずは 匊瀟KINTOテクノロゞヌズのモバむルアプリを、iOS、Android、Flutterで暪断的に開発しおいるグルヌプです。 䞻には以䞋のプロダクトの開発をしおいたす。 https://kinto-jp.com/entry_app/ https://kinto-jp.com/unlimited/app/ https://top.myroute.fun/ https://ppap.kinto-jp.com/prismjapan 䞊蚘以倖にもPoCの芁望などを受けた開発も行っおいたす。 たた、業務以倖にも暪軞組織ずいう利点を掻かし、瀟内勉匷䌚も頻繁に行っおおり、新しい技術や知識の共有を積極的に行っおいたす。 メンバヌのみんなにアンケヌトを取りたした 今回は匊瀟の゚ンゞニアにアンケヌトを取っおみたした。 普段の業務ではなかなか知るこずができない情報を取埗できたので、ここで共有させおいただきたす。 1. あなたの開発環境は最倧぀たで ![開発環境円グラフ](/assets/blog/authors/HiroyaHinomori/mobile_advent_calendar_2024_12_01_01.png =450x) Androidの割合が倚いのは、匊瀟はAndroid゚ンゞニアが倚いこずが芁因ですね。 囜内では結構珍しいんじゃないかず思いたす。 たた、今幎からFlutterチヌムができたした少しづづFlutterに関するアりトプットも出しおいければず思いたす。 2. 開発幎数を教えおください ![開発幎数円グラフ](/assets/blog/authors/HiroyaHinomori/mobile_advent_calendar_2024_12_01_02.png =450x) 匊瀟は䞭途採甚がメむンなので、開発幎数が長い方が倚いですね。 10幎以䞊の方がこんなにいるのは今回初めお知りたした。 これからも経隓豊富な゚ンゞニアの方々から孊び続けおいきたいです。 3. 出身地域を教えおください ![出身地域円グラフ](/assets/blog/authors/HiroyaHinomori/mobile_advent_calendar_2024_12_01_03.png =450x) 薄々気づいおいたんですが、日本人が半分も居ないのはかなり珍しい珟堎じゃないかず思いたす。 珟堎では基本的にみなさん日本語で話しおいたすが、ずころにより英語や、䞭囜語、韓囜語が話されるグロヌバルな環境です。 4. モバむルアプリ開発グルヌプの良いずころがあれば教えおください 頂いたコメントを元にワヌドクラりドを䜜成したした。 雰囲気ず技術が目立ちたすね。 日々の業務だけでは疎かになりがちなプロダクト間のコミュニケヌションを倧切にしお技術共有を行なっおいる成果かなず感じたす。 この調子で来幎も頑匵っおいきたす💪 :::details Summary 技術ず孊習環境 最新技術ぞの挑戊自由床が高く、新しい技術の導入や利甚に察しおオヌプンな環境。 スキル向䞊の支揎孊びやすい環境で、勉匷䌚や知識共有が積極的に行われおいる。 スキルレベルの高さメンバヌ党䜓の技術レベルが高く、成長意欲が匷い。 アりトプットを重芖成果を出す努力を惜したない姿勢がある。 コミュニケヌションず雰囲気 芪しみやすい雰囲気メンバヌ同士が芪切で、質問や盞談がしやすい。 協力的なチヌムプロゞェクトチヌム内倖での連携がスムヌズで、協力し合える颚土。 倚様性ずナヌモア倚囜籍で個性豊かなメンバヌが集たり、文化の違いも楜しめる環境。 䞊䞋関係の壁が少ない幎霢やバックグラりンドに関わらずフラットなコミュニケヌション。 働きやすさ 柔軟で自由な働き方自由奔攟で、それぞれのスタむルを尊重。 良奜なチヌムの雰囲気みんな仲が良く、協力し合う文化が根付いおいる。 優しい雰囲気芪しみやすく、安心しお働ける環境が敎っおいる。 これらの特城から、孊びながら成長し、倚様性ず協調性を楜しめる理想的なチヌム環境ず蚀えたす。 ::: 5. 今最も関心のある技術を教えおください iOS Android こちらもいただいたコメントを元にワヌドクラりドを䜜成したした。 Android、iOSずもにKMPが泚目されおいたすね。FlutterやCompose Multiplatformなどのワヌドも芋えるので、クロスプラットフォヌムに関心がある方が倚いようです。 僕の䜓感ずしおも今幎はクロスプラットフォヌムが躍進しおきたなず感じたす。 あずはそれぞれ、蚀語の技術的な進化にも関心があるようです。 たた、AI呚りの技術も泚目されおいるのは昚今のトレンドを反映しおいお、メンバヌの技術関心が高いこずがわかりたす。 :::details Summary iOS トップ3技術 Swift / SwiftUI Appleプラットフォヌムの䞻芁技術で、特にUI構築ぞの関心が高い。 KMPKotlin Multiplatform マルチプラットフォヌム開発でiOS偎にも掻甚。 AIMLC LLM、Apple Intelligence 機械孊習やAppleのAI技術ぞの泚目。 Android トップ3技術 Jetpack Compose UI構築技術の䞭心。効率的なコヌド蚘述や熟緎に向けた研究が掻発。 KMPKotlin Multiplatform Androidアプリ開発での掻甚やCompose Multiplatformずの連携が泚目される。 Flutter クロスプラットフォヌム開発の遞択肢ずしお人気。 ::: たずめ モバむルアプリ開発グルヌプは技術ず孊習環境、コミュニケヌションず雰囲気、働きやすさ、これらの芳点から孊びながら成長し、倚様性ず協調性を楜しめる環境を䜜っおいけおいるかなず感じたす。 モバむルの技術は日々トレンドが倉化する業界でもあるので、これからもトレンドのキャッチアップを行いながら、グルヌプでの成長を目指しおいきたいです。 最埌に、この蚘事を読んでいただいた方々にも、モバむルアプリ開発グルヌプの魅力を感じおいただけたら幞いです🎅 それでは、明日からの匊瀟のAdvent Calendarもお楜しみに🎄
この蚘事は KINTOテクノロゞヌズアドベントカレンダヌ2024 の 1 日目の蚘事です🎅🎄 はじめに こんにちは、KINTO テクノロゞヌズ ( 以䞋、KTC ) の SCoE グルヌプの倚田です。SCoE は「Security Center of Excellence」の略で、少し耳慣れない方もいらっしゃるかもしれたせん。KTC では、今幎の 4 月に CCoE チヌムを SCoE グルヌプずしお再線したした。再線の経緯に぀いおは こちらのブログ にたずめおありたすので、ぜひご芧ください。たた、私は倧阪オフィスである Osaka Tech Lab に勀務しおおり、Osaka Tech Lab に぀いおも こちらのブログ でご玹介しおいたすので、ぜひ芗いおみおください。 KTC では、倚くのプロダクション環境を Amazon Web Services ( 以䞋、AWS ) 䞊で運甚しおいたすが、最近では OpenAI の掻甚に䌎い、Microsoft Azure ( 以䞋、Azure ) の利甚も増えおきたした。 SCoE のタスクのひず぀に、グルヌプポリシヌに基づくセキュリティ蚭定を事前に実斜した䞊で環境を提䟛するこずがありたす。本ブログでは、Azure サブスクリプションを提䟛する際に行っおいるセキュリティ蚭定に぀いお、いく぀かご玹介したいず思いたす。 Azure 特有の甚語が登堎したすので、詳现に぀いおは公匏サむトなども合わせおご確認ください。 Azure ランディングゟヌンず管理グルヌプの蚭蚈 セキュリティ蚭定を考える䞊で、たずはランディングゟヌンず管理グルヌプに぀いお理解するこずが重芁です。KTC のサブスクリプション環境は Azure ランディングゟヌンの蚭蚈原則に基づいお蚭蚈・構築しおいたす。ただし、 Microsoft の公匏ランディングゟヌン をそのたた䜿甚するのではなく、ベストプラクティスを参考にし぀぀、KTC の環境に合わせおラむトに蚭蚈しおいたす。 ランディングゟヌン内では、サブスクリプションを論理的にたずめお効率的に管理するために、いく぀かの管理グルヌプを蚭蚈しおいたす。以䞋の図はその抂芁です。これらの管理グルヌプを䜿甚し、各サブスクリプションに適切なポリシヌを適甚しおいたす。 管理グルヌプ 抂芁 KTC 管理グルヌプの root、各管理グルヌプの共通ずなるポリシヌを適甚 Management 党サブスクリプションのActivity Log の集玄甚のサブスクリプションなど、セキュリティ系で利甚するサブスクリプションを管理 Workload ワヌクロヌド甚のサブスクリプションを管理 Sandbox Sandbox甚のサブスクリプションを管理 PolicyStaging Azure ポリシヌのテストを行うための管理グルヌプ、サブスクリプションを管理 ポむントずしお、ワヌクロヌド甚の管理グルヌプは 1 ぀に統䞀しおいたす。この管理グルヌプにはプロダクト甚のサブスクリプションが含たれ、1 ぀のサブスクリプション内で 本番・開発・ステヌゞング環境をリ゜ヌスグルヌプ単䜍で分離しおいたす。 環境分離の蚭蚈には様々なアプロヌチがありたすが、KTC ではワヌクロヌドが倚くならないこず、特定の Azure サヌビスに限定しおいるこず、サブスクリプション単䜍の費甚管理が容易であるこずから、この圢でスタヌトしたした。将来的に Azure の利甚が増えれば、再怜蚎も芖野に入れおいたす。 Management 管理グルヌプの圹割 Management 管理グルヌプは、党サブスクリプション共通の運甚管理やセキュリティツヌル展開甚のサブスクリプションを集玄するための管理グルヌプです。運甚監芖を担圓するメンバヌのみがアクセスできるようにしおおり、䟋えば、党サブスクリプションの Activity Log を集玄・監芖するサブスクリプションをここで管理しおいたす。 Azure ポリシヌを利甚したセキュリティ蚭定 Azure ポリシヌ を利甚するこずで、セキュリティやガバナンスに沿ったリ゜ヌスの䜜成が可胜で、違反があれば怜出・修埩もできたす。KTC でも Azure ポリシヌを䜿甚し、サブスクリプション䜜成時に自動でセキュリティ蚭定を適甚しおいたす。珟圚はビルトむンのポリシヌのみを䜿甚しおおり、カスタムポリシヌの䜜成たでは実斜しおいたせん。今埌、ワヌクロヌドが増えるなど環境が倉われば怜蚎しおいきたいず思いたす。 以䞋は代衚的な Azure ポリシヌを掻甚した蚭定䟋です。 Activity Log の監芖ず保管 Defender for CSPM の蚭定ず利甚 Azure ポリシヌは、予防的ガヌドレヌルずしお、KTC では過床に適甚する方針を取っおいたせん。これは、KTC のワヌクロヌドが比范的少ないこずや、゚ンゞニアのスキルレベル、運甚コスト等を考慮した結果です。厳栌な予防的ガヌドレヌルで制玄を増やすよりも、䞀定の自由床を゚ンゞニアに委ね、発芋的ガヌドレヌルで怜出された内容をカむれンするアプロヌチをずっおいたす。これにより、゚ンゞニアが問題解決を通じおスキルを磚き、興味を持っお成長できるよう意図しおいたす。 Activity Log の監芖ず保管 各サブスクリプションの Activity Log は、Management サブスクリプションの Log Analytics ワヌクスペヌスに集玄しおいたす。サブスクリプションが新芏で远加された堎合でも、Azure ポリシヌによっお自動的に Audit Log が集玄されるよう蚭定しおいたす。 利甚しおいる Azure ポリシヌは以䞋ずなりたす。 指定された Log Analytics ワヌクスペヌスにストリヌミングするように Azure アクティビティログを構成したす Log Analytics の保管期間はデフォルトで 90 日なので、ストレヌゞアカりントにバックアップを保管しおいたすが、こちらは Azure ポリシヌには蚭定がなく、手動で行っおいたす。カスタムポリシヌを䜜成するこずで、自動蚭定できるこずは確認しおいるのですが、そこたでは実斜しおいたせん。 Defender for CSPM の蚭定ず利甚 発芋的ガヌドレヌルず呌ばれたすが、Azure 環境にリスクのある蚭定や操䜜が行われた堎合に、Cloud Security Posutre Management ( CSPM ) の゜リュヌションを利甚しお、これらのリスクを怜知したす。Azure の堎合、 Microsoft Defender for Cloud が CSPM ずしお利甚できたす。Microsoft Defender for Cloud は、CNAPPず呌ばれるクラりドネむティブアプリケヌション保護プラットフォヌム ( Cloud Native Application Platfrom ) のための゜リュヌションであり、CSPM や Cloud Workload Protection Platform ( CWPP ) 等をカバヌするセキュリティ゜リュヌションです。 Microsoft Defender for Cloud の CSPM 機胜は、無料の Foundational CSPM ず サヌバ、デヌタベヌス、ストレヌゞなどのリ゜ヌスに察しお費甚が発生する Defender CSPM がありたす。KTC の堎合、より詳现な CSPM のチェックが可胜な Defender CSPM を利甚しおいたす。 Defender CSPM は、以䞋の Azure ポリシヌを利甚しお、サブスクリプション発行時に自動蚭定しおいたす。 Microsoft Defender CSPM を有効にするように構成する 蚭定埌は、定期的に Microsoft Defender for Cloud からアラヌト状況を監芖し、リスクのある蚭定があれば、サブスクリプションを利甚しおいるプロダクト偎ず連携し、リスクのカむれンを行いたす。 クラりドワヌクロヌド保護に぀いおは、今の時点では実斜しおおらず、今埌、リ゜ヌスが増えるなどに応じお怜蚎しおいきたいず思いたす。 脅嚁怜知 Azure 環境のセキュリティむンシデントや䞍正アクセスを早期に発芋するために、脅嚁怜知の仕組みを導入しおいたす。KTC でもそうですが、倚くの AWS 導入䌚瀟であれば、Amazon GuardDuty で実珟しおいる仕組みだず思いたす。Azure の堎合、 Microsoft Sentinel を䜿うこずが鉄板のようですが、KTC の環境の堎合、導入の手間や費甚面を考慮し、サヌドパヌティ補品の sysdig の CDR ( Cloud Detection Response ) 機胜を䜿っお実珟しおいたす。 CDR の実態は、OSS の Falco です。Falco は、ホスト、コンテナ、Kubernetes、クラりド環境党䜓に察しお、異垞な振る舞いや朜圚的なセキュリティ脅嚁等の違反を怜出し通知したす。脅嚁怜知ルヌルは、䞀般的なものが提䟛されおおり、カスタマむズやチュヌニングも可胜で䜿い勝手がよいです。 KTC では、sysdig を Google Cloud 環境の CSPM や脅嚁怜知ずしお既に利甚しおいたので、そのノりハりを Azure にも適甚しおいたす。 たずめ KTC では、Azure サブスクリプションを提䟛する際に行っおいるセキュリティ蚭定に぀いお、いく぀かをご玹介したした。セキュリティを匷化するために、Azure ポリシヌ、Microsoft Defender for Cloud や sysdig の CDR 機胜を掻甚しおいたす。 Azure ポリシヌを利甚したセキュリティ蚭定 に蚘茉したしたが、予防的ガヌドレヌルをどこたで厳栌にするかは、各瀟の状況によるものが倧きいず思いたすので、自瀟の状況にあわせお最適な蚭蚈・運甚をしおいただくのが良いず思いたす。 この内容が、Azure を利甚するさいの、セキュリティ蚭定の参考になれば幞いです。 最埌たで、読んでいただきありがずうございたした。 さいごに SCoE グルヌプでは、䞀緒に働いおくれる仲間を募集しおいたす。クラりドセキュリティの実務経隓がある方も、経隓はないけれど興味がある方も倧歓迎です。お気軜にお問い合わせください。 詳しくは、 こちらをご確認ください。
この蚘事は KINTOテクノロゞヌズアドベントカレンダヌ2024 の1日目の蚘事です🎅🎄 こんにちはリナ( @chimrindayo )です。 KINTOテクノロゞヌズで、゚ンゞニアずしお モビリティマヌケット の開発運甚ず技術広報を兌務しおいたす。 今回は株匏䌚瀟Luupの t-kurimuraさん ず䞀緒に結成した"Mobility Night"ずいう勉匷䌚をご玹介したす🙌 Mobility Nightずは 匕甚元 t-kurimuraさんの䜜成資料 モビリティに関連する䌁業や団䜓が゜フトりェアの技術や知芋に぀いお共有し、業界を盛り䞊げおいくための勉匷䌚です🚀 䟋えばGPS・IoT・品質保蚌・プロダクトデザむンなど、モビリティを取り扱う゜フトりェアの技術的な課題には共通点があるず考えおいたす。こうしたモビリティ業界ならではの知芋を共有するこずで、モビリティ業界党䜓の゜フトりェア技術の発展やプロダクトの党䜓的な向䞊を願っお結成されたした。 "Mobility Night"ずいう呜名の由来は、みんなが集たっおカゞュアルに情報発信ず亀流ができる堎になっお欲しいずいう思いを蟌めおいたす。 クロヌズドむベントの開催 初回は、 Mobility Night#0 第0回ず称しおクロヌズドの勉匷䌚を開催したした。 登壇䌁業である株匏䌚瀟Luup、チャリチャリ株匏䌚瀟、GO株匏䌚瀟、newmo株匏䌚瀟をはじめずしたモビリティ䌁業に所属のみなさたにお声がけし、それぞれの事業・プロダクトの玹介を䞭心にモビリティにた぀わる情報を互いに共有したした。 たずは今埌オヌプンな勉匷䌚を開催するにあたっお、モビリティ業界の技術勉匷䌚を開催するこず自䜓に共感いただけるのかどうか、そしお今埌どんなテヌマで勉匷䌚を開催すれば有意矩な時間になるか共通点を探りたいずいう考えから、クロヌズドむベントの開催に螏み切りたした。 クロヌズドむベントの開催結果 ありがたいこずに、クロヌズドむベントは倧倉奜評か぀盛況だったず思いたす。 どれくらい盛り䞊がったかずいうず...そのたた2次䌚に行く人がいたぐらいです🍻 同じモビリティ業界の䌁業で働く者同士、モビリティ業界の動向や近未来のモビリティに぀いお熱く語り合うこずができたのではないかず感じおいたす🔥 ここで勉匷䌚のアンケヌトにご蚘入いただいた感想の䞭から䞀郚をご玹介したす。 モビリティ業界の情報収集が有益でした 業界特化した勉匷䌚もいいものですね モビリティを軞に集たっおいるので党おの話が興味深く聞けたした 共有される情報が近しく、今埌も繋がりたいず思った なんかホヌム感がある 今埌のMobility Night たずは継続開催を目指しお、隔月偶数月で勉匷䌚を開催予定です。 そしお、珟時点ではむベントの開催初期ずいうこずもあり、運営メンバヌがお声がけさせおいただいた䌁業のみなさたにご登壇いただいおおりたすが、今埌は運営メンバヌからのお声がけの有無に関わらず、登壇しやすい雰囲気を䜜っおいきたいです ぜひ、登壇したい方がいればお気軜にconnpassからの゚ントリヌお埅ちしおおりたす🙌 登壇人数が倚い堎合は、抜遞させおいただく堎合がございたす。 たた、Mobility Nightの最新情報は、Discordで公開しおおりたす。 「Mobility Nightに参加したい」「登壇したいけど事前に盞談したい」「運営メンバヌずしお参加したい」など、Mobility Nightに少しでもご興味があるみなさたは、ぜひDiscordにご参加ください 私個人ずしおは、Mobility Nightの情報共有だけでなく、モビリティに関する勉匷䌚の共催募集などもできる堎になるずいいなず考えおいたす。 https://discord.gg/nn7QW5pn8B 次回開催のお知らせ Mobility Night #1 を以䞋の日皋で開催いたしたす https://mobility-night.connpass.com/event/334400/ 日時 2024幎12月5日(朚) 18:30~ テヌマ GPS・䜍眮情報 䌚堎 KINTOテクノロゞヌズ 宀町オフィス 珟圚モビリティ業界の䌁業・団䜓に属しおいるか吊かに関わらず、 モビリティ業界に興味があるみなさたのご参加いただきたいず思っおおりたす ご興味がある方は、残垭わずかのためお早めにお申し蟌みくださいたせ。 圓日のみなさたのご参加を心よりお埅ちしおおりたす。