2025/10/24に開催されたInnovationDayの資料と動画になります。
※アクセス権限がない方は、リクエストをお送りください🙇
カテゴリー: 資料BOX（ITS）
-
【ITS】2025/7/25 Innovation Day Q&A
7月開催のInnovation Dayでいただいた質問への回答です。
■営業チームからの報告について、質問や思ったことがあれば教えてください。
1.市況感について、「人が飽和している」とは、開発案件に限った話でしょうか？それとも保守運用やテスター参画も含めてなんでしょうか。
また、Javaにおけるアジャイル開発の割合と、そういった案件に参画するにはどのようなスキルが求められるかも知りたいです。
⇓
開発・保守運用・テスターを含め、ジュニア層のエンジニアは市場的に供給過多の状況にあります。
一方で、上流工程や高いスキルを持つエンジニアの需要は依然として高く、特にマネジメント能力を備えた人材が強く求められています。
会社としては、ラボ型の案件獲得を進め、上流工程に参加・経験を積める機会を増やしていく方針です。
また、上流工程に触れられる案件に参画できそうな機会があれば、ぜひ積極的に挑戦してください2.市場感の共有は毎回行ったほうが良いと思いました。
⇓
いただいているとおり、市場感の共有は一度きりではなく、
定期的に行っていくことが重要だと考えています。
今後は InnovationDay 以外の機会でも、
こまめに市場状況や案件傾向を広報していけるよう取り組んでいきます。3.PHP案件が減少傾向にあると聞いており、今後を見据えてJavaの勉強を検討しています。
また、Reactの学習も始めたところですが、今後の案件の差し替えなどに不安があります。
社内プロジェクトに参加する際の流れや、事前にどの程度の知識が求められるかについて知りたいです。
⇓
各社内プロジェクトの問い合わせについては、上長に確認してみてください。
■ 採用チームからの報告について、質問や思ったことがあれば教えてください。
1.なぜ佐賀大学なのか、背景が気になります（誰かのルーツなど？） また、社外では「AIをどの程度活用しているか」が話題になることが多いため、会社としてのAI活用のビジョンがあると紹介時の強みになると思います（有料ツールの活用など）
⇓
佐賀大学を選んだ理由としては、国立大学として企業提携・共同研究を積極的に行っているためです。AI活用に関しては、事業部として盛り上げられるように施策検討中です。2.リファラル採用を積極的に発信したいと思います。個人のSNSなどでも情報を公開してもOKですか？
⇓
【#拡散希望】など不特定多数に向けた広報はお控えいただけますと幸いです。
知人・友人へSNSを通じての直接的なやりとりは大歓迎です！
■バックオフィスからの報告について、質問や思ったことがあれば教えてください。
1.行きと帰りで快速の有無が異なるため、遅延がなくても別経路で帰れるとありがたいです。
⇓
合理的理由があるのであれば経路の変更可能です。
バックオフィスへの事前共有と、申請時の補足記載を忘れずにお願いいたします。2.子供の急なお迎え対応のために半休を取ると不利益になることがあるため、対応後に不足分を働いて調整できる仕組みがあると助かります。
⇓
ありがとうございます。今後の制度改善に向けて参考にさせていただきます。3.面談場所が把握できておらず、カフェで実施されることがあると知らなかったのですが、案件概要や会社説明など機密性のある内容を扱う場面もあるため、公共の場での面談は避けた方がよいのではと感じました。
⇓
基本的には個室推奨です。
詳細はこちらをご確認ください。
https://infotest.cin-test.info/division_info/its_info/post-13083.html
■森脇さんからCINサポーターズの知見共有 について質問や思ったことがあれば教えてください。
Q1.CINサポーターズへの連絡方法がわかりません。また、他の人の質問を参照することは可能でしょうか？
⇓
A.サポーターズの方への質問については、
asanaのこちらのチケットにコメントいただければと思います。
https://app.asana.com/1/1201365740112696/task/1208721397288768
また、過去の回答はこちらで確認可能です。
https://app.asana.com/1/1201365740112696/project/1207156468518667/task/1208721397288768?focus=trueQ2.DBのカラムや変数の命名規則としてflgは推奨されておらず、
is_○○やhas_○○がいいと勉強した記憶があるのですがどうなのでしょう？
⇓
A.ご指摘の通り、近年の命名規則としては
is_○○ や has_○○ のようなプレフィックスが推奨されるケースも多いですが、
今回は ○○_flg という形を採用しています。
これは、チームやプロジェクト内での慣習として flg を使った命名が定着しており、
可読性や理解の面で特に問題がないと判断したためです。
命名にはさまざまなスタイルがあり、
チームやプロダクトの文化に合わせて最適な形式を選ぶのが大切だと考えています。Q3.サポーターの方が経験豊富なのは分かったのですが、人柄やレスポンスの速さはどうなんでしょうか？何度も質問する申し訳なさやレスポンススピードを考慮したら、AIの方が良いように感じるのですが、サポーターに質問する利点は何でしょうか？
⇓
A.サポーターの方についてですが、レスポンスは非常に早く、
こちらからの質問に対しても丁寧に対応していただいています。
何よりありがたいのは、質問の意図や背景をくみ取って、
こちらが想定していなかった観点まで広げて答えてくれる点です。
とても献身的にサポートしてくださっており、安心して相談できる存在だと感じています。
AIも気軽に使えて便利なのですが、
どうしてもハルシネーション（もっともらしい誤情報）があるため、
質問の背景や前提を正確に伝えないと、誤った方向の回答が返ってくるリスクがあります。
特に設計のように「これが絶対に正解」とは言えない場面では注意が必要です。
また、AIが提示する内容はセキュリティや
汎用性を重視した理想形（ベストプラクティス）になることが多く、
プロジェクトの規模やリソース、
納期の兼ね合いといった現実的な制約まではなかなか考慮しきれません。
その点サポーターの方は現場での経験をベースにした判断軸を持っていて、
複数の正解がある中から実行可能な選択肢を示してくれるので、非常に参考になります。
もちろんAIも便利な選択肢のひとつですが、知識の幅広さや即時性と、
現場に即した判断や経験に基づく助言は役割を切り分けて考えるべきだと感じています。
そのうえで、人の経験や視点から得られる気づきは、やはり大きな価値があると実感しています。Q4.命名規則に関して、以前どこかでdel_flgではなくisDeleteなどisを使った方がわかりやすいって聞きましたが、どっちがいいんでしょうか。
⇓
A.isDeleted のようなプレフィックス形式は、近年の命名規則でよく推奨されているスタイルで
変数が真偽値であることを明示的に表現するという点で確かにメリットがあります。
一方で、私たちのプロジェクトでは、del_flg のような形式が長年使われており、
チーム全体で共通認識があるため、今回もその命名を採用しています。
可読性や理解に問題がないと判断したことも背景にあります。
命名には明確な「正解」があるわけではなく、
チーム内で一貫していて意味が通じることが最も重要だと考えています。
将来的に命名ルールを見直すタイミングがあれば、
isDeleted 形式も選択肢として検討するかもしれません。Q5.アクティブユーザー、インフラのスペックにもよると思いますが、 どの程度のユーザー数であれば、セッション認証／トークン認証のどちらが適しているのか知りたいです。
⇓
今回に関しては、ユーザー数というよりシステム構成上の理由から、
トークン認証（JWT）を選択しています。
というのも、今回の構成ではサーバーとフロントエンドを完全に分離しており、
API はステートレス（状態を持たない）な設計を採用しています。
セッション認証の場合、サーバー側でセッション状態を管理する必要があるため、
スケールアウト（サーバーの横展開）時にセッションの共有や同期が課題になります。
その点、トークン認証であればリクエストごとに認証情報を自己完結で保持できるため、
API のスケーラビリティとの相性が非常に良いという判断です。
ご質問の通り、アクティブユーザー数やインフラのスペックが影響する部分もありますが、
セッション認証とトークン認証の選択は、ユーザー数そのものよりもシステム構成や設計方針に基づいて判断されることが多いと感じています。
たとえば、セッション認証でも Redis などで適切にセッションを管理すれば、
大規模なユーザー数にも十分対応可能です。
一方で、API とフロントエンドが分離されていてステートレスを前提とした構成であれば、
ユーザー数に関係なくトークン認証が選ばれるケースも多いと思います。
つまり、「何人からはトークン認証」といった明確な基準があるわけではなく、
構成・拡張性・セキュリティ要件に応じて柔軟に判断するのが良いと考えています。
■竹本さんによるSwitchの管理システムを構築した経験談について質問や思ったことがあれば教えてください。
Q1.Switch利用枠がユーザAに予約されている状態で、同じスケジュールでユーザBが後から予約した場合はパスワードは上書きされるのでしょうか？
⇓
A.パスワードは上書きされません。どちらのパスワードでも使用可能です。
-
【ITS】2025/04/14 Innovation Day Q&A
4月開催のInnovation Dayでいただいた質問への回答です。
Q1.SP等級とS等級は両立できないという認識であっていますでしょうか。
⇓
A. 両立はできない認識であっています。ただS等級とSP等級の行き来は可能です。
Q2.SP等級について、レイヤーが3以下の場合は現場を変える必要があるということでしょうか。
⇓
A.SP等級になるためには案件を変える必要があります。
Q3.SP等級に関して レイヤーが足らない場から案件変えたいみたいなことはできるのか？
⇓
A.可能です。まずは営業に確認をしてください。
-
【ITS】2024/12/20 Innovation Day Q&A
12月開催のInnovation Dayでいただいた質問への回答です。
■ラボ振り返りについて
Q1:仕様の把握が難しかったとのことですが、年末調整自体の内容を理解する必要があったのですか？
⇓
A.年末調整の用語や国税庁が公式で出している仕様、それに合わせてシステムでデータの条件を作成するのが難しく時間がかかりました。
Q2:Vue.jsとJqueryを併用しているのは何か理由があるのでしょうか？
この構成を見たことがなかったので、強みなどがあれば教えていただきたいです。⇓
A.jQueryはajaxの処理で使用されていて、vueはフォームの共通パーツとして利用されているようです。
Q3:ラボ型案件に参画できるようになるにはどれくらいのスキル感が必要なのでしょうか？
⇓
A.要件定義～結合テストの作成まで一人称でできればよいかと思います。また、工数の見積やスケジュール管理も併せてできればなおよいかと思います。
■CINサポーターズについて
Q1:クエリビルダ関連の質問です。Eloquent、クエリビルダ以外に素のSQLを実行する方法があるかと思います。素のSQLを実行した方が結果的には早いって話を聞いた事があり、正直可読性も高いのかな？って思うこともあります。実際のところどれがいいのかな？って思うんですがいかがでしょうか？
⇓
A.実装するアプリの規模感や構成にもよると思いますが、基本的にはEloquentで開発する方が良いそうです。
複雑なSQLを書く場合には、Eloquentでは難しい時があるのでその時には、クエリビルダを使うと良いです。
素のSQLを使うときには、データの集計やバッチ処理など、高パフォーマンスが求められる処理には素のSQLを使用するのを検討するのが良いそうです。
ただ、素のSQLはコードに直接SQLを記述するため保守性が高くないので、使用しすぎると開発後に困るかもしれません。Q2:サポーターズは社外のスタッフの方に技術的な相談などができるという認識であっていますでしょうか？
⇓
A.認識あっています。
全ての相談や質問の対応ができるわけではないので、その点は注意をしていいただければと思います。Q3:ベテランエンジニアの貴重な経験なお話を聞けてためになりました。技術面とはべつの業務を進めていく上でのタスクの時間管理やチーム内で活動で意識することをがあれば知りたいです。
⇓
A.メンバー目線ではないですが、リーダー目線での質問を過去に行ったためそちらの回答を送らさせていただきます。
Q.メンバーのモチベーションやパフォーマンスの管理のコツなどはありますか？
A.定期的にMTGを行うことです。
順調に進んでいる案件は週1、うまくいっていなかったり、忙しい案件であれば、毎日短時間でいいので、MTGの機会を設けるのが良いです。
MTGで、進捗冗長、困ってることなどを共有し、その場で解決できることは解決します。またメンバーが今どういう状況がなんとなく把握できるので、サポートもしやすくなります。
忙しいと、MTGしている時間がもったいないと感じる時もありますが、1人で数時間悩んでいたことが、MTGで即解決することも多いので、案件が佳境な時ほどMTGはした方がいいです。上記回答からの考えになるのですが、メンバーの目線からですと、詰まったらすぐに相談を行うなど報連相やコミュニケーションを意識すると良いと思います。
■技術共有（丸瀬さん）について
Q1:AWSであればCloudWatch で同じことができるのでは？
⇓
A.AWSに詳しくはないので知らなかったのですが、調べてみると同じことができると思います。
FluentdやKibanaなどはサーバ上で環境構築(エージェントのインストールやFW申請等)する必要があるので、
AWSを使用している場合は、CloudWatchを使うユーザが多そうですね。■事業部からの各報告について
Q1:名古屋支店と福岡支店のお話が出ていたが、例えば東京で勤務している人間が異動願いなどを出して通るのか知りたい
⇓
A.現状は地方から東京への異動は許可しておりますが、東京から地方へは許可していません。
ただ今後の状況次第では東京からも地方に異動できるようにしていきたいと考えています。
Q2:今後の方針としてはSESから受託開発やラボ型の受注に切り替えていく方針なのでしょうか？
⇓
A.積極的に受注は目指していきますが両軸で事業は拡大していきます。
Q3:中抜けについて連絡があったとのことでしたが、もし自分に対して現場から何かしらのFBがあった場合、教えてもらえるのでしょうか？（良いことも悪いことも）
⇓
A.現場からＦＢがあれば、随時お伝えします！
また、評価アンケートもあるので、より詳細にFBもらえるかと思います！
■全体を通しての質問
Q1:福岡・名古屋のメンバーは帰社日に参加されていますか？
⇓
A.参加予定です。
Q2:knowledge制度について、現場が忙しい場合（いつも残業確定）の時は取るべきではないですよね？
⇓
A.現場の業務に支障がない範囲での取得をお願いします
Q3:新オフィスの「J6と比べてここが素晴らしいぞ！」って部分があれば知りたい。
⇓
- 個人用のMTGスペースがある
- 他事業部とのスペースが隔離されているため静かで集中できる
- 綺麗なカフェスペースがある
Q4:佐藤さんの発表の際にDXについての項目があったと思うのですがこちらはサロンソリューション事業とまたがって運用しているものでしょうか？
⇓
A.開発・保守ともにITSのほうでおこなっております！SSの方と定例を行い意見回収したり、利用されている方に定期的にアンケートを行ったり、エラー通知があればバグ改修をしたりと対応してます！共同作業でサービスを育ててます
-
【ITS】2024/12/20 InnovationDay資料
2024/12/20に開催されたInnovationDayの資料と動画になります。
◯発表資料
https://drive.google.com/drive/folders/1L7futspQKJ795fQiaj_cWl5x242StI54
◯動画
-
【ITS】2024/09/20 Innovation Day Q&A
9月開催のInnovation Dayでいただいた質問への回答です。
■SP等級制度の概要説明 について質問や思ったことがあれば教えてください。
Q1.SP等級がどのくらいスキルに寄ったモノになるのか、評価されるスキルは自身で自由に選択可能なのか気になる。現在のS等級から分かれていく形になるのでしょうか。⇓A.SP等級の質問に関しては12月のInnovation dayにて再度進捗の広報を行います。Q2.愛好会と部活ではどのような違いがありますか？⇓A.愛好会は会社として正式に設けていません。■技術共有（本間さん）について質問や思ったことがあれば教えてください。
Q1.クライアントと直接やり取りしたいなと思うことはありますか？⇓A.直接やりとりしたいと思ったことはあります。例えば、不具合が発生した際、すぐリカバリ対応を開始したいのですが、対応前にクライアントに確認を取る必要があるため、窓口の方を挟む必要があるのは、少しもどかしく感じました。ただ、窓口の方を挟む事で、クライアントへのコメントをダブルチェックする形で進行できるので、可能ならこのやり方が望ましいのかなと思います。ちなみに窓口の方が不在の場合は、私が直接対応したりもします。■AppRouterの話（大柴賢和さん）について質問や思ったことがあれば教えてください。
Q1.server componentsとclient componentsの違いについてお聞きして、SGやSSRと似たものなのかな？と思った。⇓A.SG: ビルド時にHTMLファイルを事前に生成する方法SSRとSCは似たように思えますが少し異なります。・SSR：ページ全体をレンダリング・SC：コンポーネント単位でレンダリング■事業部からの各報告について質問や思ったことがあれば教えてください。
Q,teamTRYのスキル問題の効果測定はその後何かに活用される予定でしょうか？⇓A.スキルの計測は、チームSMRのチーム編成の参考などに活かされる予定です。■タスク管理ツール について質問や思ったことがあれば教えてください。
Q1.Slackの「後で」の欄でのタスク管理との違いがいまいち分からなかった