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=true
Q2.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.パスワードは上書きされません。どちらのパスワードでも使用可能です。
