Open5

SES 勤め始め

cgccgc

SES面談用逆質問シート

プロジェクトの詳細

  1. 役割と責任について、求められる人物像
    • 「私がプロジェクトに参加するに当たって、求められる具体的な役割と責任についてお聞かせいただきたいです。」
  2. プロジェクトのスコープ管理
    • 「プロジェクトについて、具体的な成功目標を数字などで定義されてらっしゃいますか」
    • 「プロジェクトのスコープ外作業が発生する見込みについて、教えていただきたいです。もし発生した場合のリソースを割り当てる見込みはありますか。」
  3. 使用されている技術スタック、ツール
    • 「詳細設計書や基本設計書を作成される際にどのようなツールを利用されていますか。またどのような理由でそのツールを選定されていますか。」
    • 「使用されている主な技術スタック、ツールやフレームワークについて教えていただけますか。
    • 「バージョン管理ソフトの運用について、具体的なルールやこれまでの運用について教えていただきたいです。」
    • 「開発環境やコラボレーションツールはどのようなものを利用されていますか。」
    • 「コードの品質を保証するための取り組みについてどのような手法やツールを利用されていますか」
  4. メンバやチーム構成

チームの連携、コミュニケーション

  1. 方法と頻度
    • 「チーム同士の連携に際してどのようなツールを利用されて、頻度はどの程度を想定されていますか」
  2. マネジメントスタイル、カルチャー
    • 「具体的にマネジメントを行う方は決定されていますか。またマネジメントの方針についてどのようなものを採用されていますか。」
  3. コンフリクト
    • 「(風通しの良い前提で)チーム内でコンフリクトが発生した際に解決する方法は取り決めされてますか。」
  4. チーム同士のサポート体制
    • 「新しいメンバーが入った際には、どのようにサポートされますか。そのためのドキュメントなどは整備されていますか」

スケジュールと期間について

  1. マイルストーン、デッドライン

    • 「具体的なマイルストーンについてはどのように設定されていますか。」
  2. 勤務時間、オンコール

    • 「緊急のタスクが発生した際どのような決定プロセスを経て、どなたが作業の配分を行われますか。」
    • 「オンコール対応について発生する見込みはありますか」
    • 「残業が必要となった場合、その決定は個人の判断となるか管理者の判断になりますか」
  3. プロジェクトのビジョンについて

評価とフィードバックについて

  1. パフォーマンスの評価方法
    • 「稼働パフォーマンスの評価プロセスはなにか具体的なルールは策定されていますか。」
  2. フィードバックのプロセス及び頻度
    • 「成果物に対する納品プロセス、評価基準など具体的な取り決めは存在しますか。」
    • 「プロジェクトに対する予定の遅れなどに関するフィードバックはどのような頻度・プロセスで行われますか。」
  3. 成長の機会やスキルアップのサポート

なんとなく聞きにくいやつ

  1. メンバーの稼働時間(平均残業時間)について聞かせていただけますか
  2. クライアントとのコミュニケーションが必要になる可能性は想定されていますか
cgccgc

過去の案件情報について内容を掘り下げておくこと

cgccgc

理解はしてても自信を持って回答できなかった技術スタックについて、勉強しておくこと

cgccgc

見送り理由対策

APIのセキュリティ
応答上APIのセキュリティに関して答えたケースがなかったと思われるが体系的に語れる分野ではないため勉強しておく

以下、愚痴のようなもの

Kotlin Flow が業務未経験であったため?

だとしたらそれは、セキュリティ要素関係ないのでむしろ見送りで良かった案件だと思う

APIを使用せずネイティブAndroidアプリを開発していたこと?

ストアに公開していた社内向けアプリ(あわよくば商用として)
少し複雑な要素が絡んでいるため、説明不足か。
APIサーバーを立てるほど目標が高くなかったのも事実

業務でOAuth認証の実装経験がある

だが、OAuth認証では足りないと判断されたか。
どちらにせよ当時の基準では業務要件は満たされていたと思う。

一応GPT-4さんに調べてもらってみた

OAuth(オーオース)認証は、Webサービスの共有が一般的になっている現代において、APIアクセスの権限認可に必要なプロトコルとなっています​1​。しかし、OAuthのセキュリティに関しては、いくつかの課題があり、特に非常に高いセキュリティと相互運用性を達成することが歴史的に困難であるとされています​2​。

2023年において、OAuthのセキュリティに関する状況は進化しています。OAuth Security Workshop 2023では、OAuth 2.1やOpenID FoundationによるFAPI1およびFAPI2セキュリティプロファイルのような最新の開発が紹介されています​2​。これらの進歩は、OAuthのセキュリティと相互運用性の向上を目指しています。

さらに、APIセキュリティのトレンドに関する記事によれば、OAuthは依然として適切なAPI認証と承認を実装するための有効な方法とされています。組織はカスタムコードやアドホックな解決策に依存せず、確立されたセキュリティ標準に基づいてAPIセキュリティシステムを構築することが推奨されています。この枠組みの中で、OAuthはトークンベースのアプローチを使用して堅牢な承認を実現する手段として示されています​3​。

しかし、セキュリティ脆弱性も報告されています。例えば、脆弱性CVE-2023-27490は、OAuthの認証フローに関連し、OAuthセッション中に認証用URLが攻撃者に傍受され、操作される可能性を示しています​4​。

これらの情報から、OAuth認証のセキュリティは進化し続けている一方で、新しいセキュリティ脆弱性や課題も存在していることが明らかになります。したがって、OAuthを使用する組織は、最新のセキュリティベストプラクティスを遵守し、関連するセキュリティリスクを評価し続けることが重要です。

OAuth認証を技術として選んだことが理由であれば、少し早計であると感じる

cgccgc

だが、OAuth認証では足りないと判断されたか。
どちらにせよ当時の基準では業務要件は満たされていたと思う。

業務用リソースへの連続的なアクセスを想定していたので、やはり適切に感じる