【iOS】GitHub Copilot for Xcode の Agent modeを使ってみた

概要

弥生でiOSアプリ開発を担当している市毛です。

2025年5月19日、GitHub Copilot for Xcode の「Agent mode」機能がパブリックプレビューとして公開されました 🎉

github.blog

早速使ってみたので、弥生のiOS開発に活用できるかどうかをレポートします。

前提

弥生ではUIKitを用いてiOSアプリを作っています。

また、UIKitのViewを扱いやすくするために、独自のViewクラスでラップしています。

今後紹介するコードでは、そういった独自のViewクラスや実装が登場しますが、今回の記事の主旨から外れるため、詳細な説明は割愛させていただきます 🙇‍♂️

同様に、独自に定義したViewクラスを使っていたり、標準的でない実装スタイルでアプリを開発されている方にとっては、参考になる点が多いと思います。

  • 環境
    • macOS Sequoia 15.4.1
    • Xcode 16.3
    • GitHub Copilot for Xcode 0.35.0
      • モデル GPT-4o

Agent Modeの概要

Agent Modeの説明を見ると下記の記載があります。 ​

  • Get intelligent code edits applied directly to your files
  • Run terminal commands and view their output without leaving the interface
  • Search through your codebase to find relevant files and code snippets
  • Create new files and directories as needed for your project
  • Get assistance with enhanced context awareness across multiple files and folders
  • Run Model Context Protocol (MCP) tools you configured to extend the capabilities

日本語訳

  • ファイルに直接適用されるインテリジェントなコード編集
  • ターミナル・コマンドを実行し、インターフェイスを離れることなくその出力を表示
  • コードベース内を検索して、関連するファイルやコード・スニペットを見つける
  • プロジェクトに必要な新しいファイルやディレクトリを作成
  • 複数のファイルやフォルダにまたがる強化されたコンテキスト認識による支援
  • 機能を拡張するために設定したモデル・コンテキスト・プロトコル(MCP)ツールの実行

今回の検証について

以下の観点で、実際に弥生の開発現場において活用可能か検証していきます。

1. ファイルに直接適用されるインテリジェントなコード編集

  • タスク: バグ修正の依頼
  • 評価ポイント: 修正の正確性と安全性

2. ターミナル・コマンドの実行と出力確認

  • タスク: ブランチ変更、ライブラリのインストール
  • 評価ポイント: コマンドの理解力と正確な実行可否

3. コードベースの検索機能

  • タスク: 呼び出し先の一覧化 、仕様の説明
  • 評価ポイント: 検索の網羅性、わかりやすさ

4. 新しいファイルの作成

  • タスク: 新機能用の ViewController を新規作成
  • 評価ポイント: 社内コーディングスタイルへの準拠

5. コンテキストをまたぐ支援機能

  • タスク: モデルの特定プロパティの型変更
  • 評価ポイント: 型変更が複数ファイルに正しく伝搬されるか

※各機能は上記の評価ポイントから筆者の主観をもとに5段階で評価しています。

検証に使うデモアプリ

一覧画面と、セルタップで詳細画面が開くシンプルな構成のアプリを使用します。

検証結果

1. ファイルに直接適用されるインテリジェントなコード編集

1-1. セルをタップすると毎回同じ詳細画面が開く

埋め込んだバグ
for document in self.documents {
    // セルの追加
    sections.add(LabelTableCell.self) {
        // 見た目の実装
    } select: { _ in
        // タップ処理  
        guard let firstDocument = self.documents.first else { return }
        self.navigationController?.pushViewController(
              DocumentDetailViewController(document: firstDocument)
        )
    }
}

for文でループしているにも関わらず、firstDocument で常に同じdocumentの情報が表示されるようになっています。

想定の修正
for document in self.documents {
    // セルの追加
    sections.add(LabelTableCell.self) {
        // 見た目の実装
    } select: { _ in
        // タップ処理  
        self.navigationController?.pushViewController(
              DocumentDetailViewController(document: document)
        )
    }
}

for文で回しているdocument を使用するような提案を期待します。

使用したプロンプト

セルをタップすると、常に同じドキュメントの詳細画面が表示されてしまいます。リストの各セルに対応した正しいドキュメント詳細が開くように修正してください。

AIの提案内容
for (index, document) in self.documents.enumerated() {
    // セルの追加
    sections.add(LabelTableCell.self) {
        // 見た目の実装
    } select: { _ in
        // タップ処理  
        self.navigationController?.pushViewController(
              DocumentDetailViewController(document: self.documents[index])
        )
    }
}
評価

★★☆☆☆(2/5)

方向性は良いが、今回はindexの概念は不要であるため、よりシンプルなfor文での提案をしてほしい。

1-2.ドキュメントが更新されても画面が更新されない

埋め込んだバグ
var documents: [Document] = []
想定の修正
var documents: [Document] = [] {
    didSet {
        self.reloadViews()
    }
}

ViewController で保持している documents プロパティが更新されたタイミングで、画面を再描画する処理を実装しています。 バグの埋め込み段階ではこの実装を削除します。

使用したプロンプト

ドキュメントのリスト(documents)を更新しても、UI が更新されません。画面を自動的に再描画するよう修正してください。

AIの提案内容
var documents: [Document] = [] {
    didSet {
        self.reloadViews()
    }
}
// 更新処理をメインスレッドにラップされるような修正もされた
DispatchQueue.main.async { [weak self] in

}
評価

★★★☆☆(3/5)

必要な修正は含まれていたが、副作用が大きそうな修正も併せて提案されたため、そのまま採用するのは難しいと判断しました。

1-3.タイトルと内容が逆に表示される

埋め込んだバグ
cell.labelTitle.text = document.content
cell.labelDetail.text = document.title

cellのlabelに設定する値をそれぞれ title content と逆に設定される状況にします。

想定の修正
cell.labelTitle.text = document.title
cell.labelDetail.text = document.content
使用したプロンプト

リストのセルに表示されるタイトルと詳細が逆になっているようです。正しい内容が表示されるよう修正してください。

AIの提案内容
cell.labelTitle.text = document.title // 修正: タイトルを表示
cell.labelDetail.text = document.content // 修正: 詳細を表示
評価

★★★★★(5/5)

完璧な修正。コメントをそのまま採用するかはさておき、親切で変更点が明確になっていて助かります。 ​

1-4.メモリリークが発生しているように見える

埋め込んだバグ
// TableViewの見た目更新
self.tableView.beginUpdates { 
    // 内部でselfを強参照している
}

上記のコメントにもありますが、クロージャ内部でselfのViewControllerを強参照するような実装にします。

想定の修正
// TableViewの見た目更新
self.tableView.beginUpdates { [weak self] in
    // 内部でselfを弱参照になるように修正
}
使用したプロンプト

この画面を表示したあとにメモリリークが発生しているようです。selfの強参照が原因かもしれません。適切に weak self を使って修正してください。

AIの提案内容
// TableViewの見た目更新
self.tableView.beginUpdates { [weak self] in
    guard let self = self else { return }
}
評価

★★★★★(5/5)

ViewController全体の中から、selfを強参照しているクロージャを見つけ、修正までしてくれました。 修正内容も適切だったため、今回はそのまま採用することができました。

2. ターミナル・コマンドの実行と出力確認

以下の操作をCopilot Agentで実行してみます

  • ブランチの作成、checkout
  • CocoaPodsでのライブラリインストール

ブランチの作成、checkout

プロンプト

issue/branchChangeTest というブランチを作って、checkout したいです。ターミナルでその操作をお願いします。

AIの提案内容

「Continue」を押下

評価

★★★★★(5/5)

Copilotのターミナル上からブランチを作成することができました。

Podライブラリのインストール

プロンプト

CocoaPods のインストールを行いたいです。bundle exec pod install を実行してもらえますか?

返答

「Continue」を押下

今回の環境では rbenv によって Ruby のバージョンを管理しており、Copilot Agent が使っているシェル環境と、普段使用しているターミナル環境とで Ruby バージョンが異なっていたことで pod コマンドでエラーが発生してました。

バージョンを一致させることで動作可能になりますが、今回は本題から外れるため、詳しい説明は省略いたします。

評価

★★★★★(5/5)

上記ブランチ作成のプロンプトと合わせることによって、Xcodeと統合されたCopilot上からブランチ作成〜ライブラリインストールまで実施可能であることがわかりました。

3. コードベースの検索機能

実際に弥生で開発している Misoca プロダクトにて以下のようなケースを用いて検証を行いました。

検証ケース

  • 文書に関する設定のモデル(DocumentSettings)を使用している箇所を検索
  • ステータス更新ロジックのバグ調査のため、呼び出し箇所に関する仕様把握

DocumentSettings モデルの使用箇所を検索

プロンプト

DocumentSettings モデルを使用しているすべてのファイルを一覧にしてください。

返答

評価

★☆☆☆☆(1/5)

一部では DocumentSettings というモデルクラスではなく DocumentSettingsViewController のクラスを検索している箇所もありました。

文言の一致で検索を行っているようですので、Xcode のIDE上でできる検索の結果と大きな差は見られませんでした。

Xcode の検索では該当のソースコードへタップで移動できるため、この用途においては、Copilot Agent の検索はあまり有用ではないと感じました。

ステータス更新の呼び出し箇所に関する仕様把握

プロンプト

ステータス更新のロジックにバグがあるかもしれないので、Documentのステータスを更新している箇所を一覧にしてください。Documentのsectionの変更がステータスの変更です。

要約した返答内容

回答結果が長かったため、評価ポイントが判断できるくらいのボリュームに要約させていただきます。

  1. Document の参照は多いが、主に 画面 および API クラス内にあり。
  2. Documentクラス にステータス関連のプロパティが多数存在。
  3. section プロパティがステータス変更に関与している可能性あり。
  4. APIクラス の change メソッドが更新処理を担当。
  5. バグがある場合は、APIレスポンスの処理方法に潜んでいる可能性がある。
評価

★★★★★(5/5)

仕様の把握から、バグの可能性がある箇所の特定まで、丁寧に説明してくれました。 このように、 DocumentSettings などの特定クラスを指定するのではなく、全体の仕様理解や関連箇所の調査を目的としたプロンプトを用いることでの Copilot Agent の活用は、非常に有効であると感じました。

参考:Askモードでの同一プロンプトへの返答

Documentのsectionが変更されることでステータスが更新される箇所を探すには、Xcodeで以下のようなコードパターンを検索する必要があります。 (以下略)

→ IDE検索の方法を教えてくれますが、ファイルを跨いだ推論・構造の把握まではできなかったです。ここが、冒頭にも書いたAgentの魅力ですね。

4. 新しいファイルの作成

デモアプリのプロジェクトに 設定画面 を追加してみました。

プロンプト

独自のコンポーネントを使った UIKit ベースのアプリです。
社内標準では以下のクラスを使用しています
- ViewController: 独自の共通ベースクラス
- TableView: 標準の UITableView を拡張したラッパークラス
各種カスタムセル(例: LabelTableCell、LabelDetailTableCell など)
以下の仕様で、新機能用の SettingsViewController を作成してください。
【要件】
ViewController を継承し、TableView を使って構成してください
viewDidLoad() でタイトルやレイアウトを設定し、複数セクション・セルを使って構成し、画面の構成要素を整理
コーディングスタイルは [参考のViewController]を参考にしてください

自動生成されたファイル

class SettingsViewController: ViewController {

    private let tableView = TableView()

    override func viewDidLoad() {
        super.viewDidLoad()

        title = "Settings"
        view.backgroundColor = .systemBackground

        tableView.delegate = self
        tableView.dataSource = self
        tableView.translatesAutoresizingMaskIntoConstraints = false
        view.addSubview(tableView)

        NSLayoutConstraint.activate([
            tableView.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor),
            tableView.leadingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.leadingAnchor),
            tableView.trailingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.trailingAnchor),
            tableView.bottomAnchor.constraint(equalTo: view.safeAreaLayoutGuide.bottomAnchor)
        ])
    }
}

評価

★☆☆☆☆(1/5)

独自コンポーネントの実装は考慮されておらず、そのまま採用できるのはクラス名程度にとどまっておりました。 また、ビルドが通らない状況であったことに加え、新規作成されたファイルがXcodeのプロジェクトファイルに自動で反映されていない点も確認されました。 これらの点から、Copilot Agent Mode における当該機能は、現時点では完成度が十分とは言い難く、弥生の開発環境において実用するのは難しいと判断いたしました。

5. コンテキストをまたぐ支援機能

プロンプト

Document モデルの content プロパティの型を String から Date に変更したいです。 プロパティ名を contentから createdDate に変更してください。 それにより影響を受ける他のファイルも合わせて修正してください。

修正されたファイルの差分 ( git diff コマンドの抜粋)

class Document {
-    var content: String
+    var createdDate: Date
}

class DocumentListViewController: ViewController {
-                        $0.labelDetail.text = document.content
+                        let dateFormatter = DateFormatter()
+                        dateFormatter.dateStyle = .medium
+                        dateFormatter.timeStyle = .none
+                        $0.labelDetail.text = dateFormatter.string(from: document.createdDate) // Format Date to String
}

評価

★★★☆☆(3/5)

一部ビルドエラーがあり修正が必要な箇所はありますが、型変換やプロパティ名の修正に伴う影響範囲の特定、およびそれに対する大まかな修正が行われており、手作業で行うよりも工数を削減できると感じました。

まとめ

GitHub Copilot Agent Mode は、エディタを離れることなく開発作業を支援してくれる新しいアシスタントとして非常に魅力的です。

特に「ファイルをまたぐコード修正」「クラスやプロパティに関するアプリ全体での使われ方の把握(仕様理解)」「ターミナル操作」といった日常の開発業務に対して、想定以上に高精度かつ実用的な支援を得ることができました。

一方で、「画面全体を作成する」などは弥生社内で使われているUI構成のスタンダードがあるため、それに沿った提案までは現時点ではできていない印象でした。

GitHub Copilot for Xcode最大の魅力はIDEに付随したAIがいることだと思っているので、開発者が詰まったときや困ったときの取っ掛かりとして、使用してみるのは非常に有用であると感じました。

弥生では一緒に働く仲間を募集しています。
herp.careers
弥生のエンジニアに関するnote記事もご覧ください。
note.yayoi-kk.co.jp

エンジニアの育休で再発見:育児に活きるスクラムの考え方

はじめに:育休は“学び”の時間でもある

エンジニア7年目、0歳児子育て中のeastereggloverです。 昨年5月から産休・育休を取得し、今年5月に職場復帰しました。スクラム開発の経験は1年ほどです。

育休に入る前は、正直なところ「しばらくはエンジニア業から離れる期間になるな」と思っていました。仕事とはまったく違う世界に飛び込むようなイメージです。 しかし、実際に育児が始まってみると、それは“まったく別のもの”ではありませんでした

むしろ、これまで仕事で学んできた価値観や習慣が、思わぬかたちで育児にフィットする場面が多くあることに気づかされました。

特に、スクラムの考え方──チームで進める開発手法として学んできたマインドセットが、育児においても多くのヒントになったように思います。育児をする中でスクラムの考え方についてようやくしっくり来たところもあったので、ブログにすることにしました。

育児は夫婦で回すスプリントの連続

実際に育児をしてみて、夫婦はスクラムチーム、子育ては子供という顧客の要求にこたえながら進める長期的なライフワークで、1日のスプリントの連続であるように感じました。

育児においては、日々のルーチンや突発的なトラブルをこなしながら、長い目で見てチームをどう維持し、柔軟に動けるようにするかが重要になります。

日々の子供の成長により要求されることは日々変化していくので、まさに短スプリントのスクラムが効果を発揮しやすいライフワークだと思います。

経験主義と機能横断型のチーム

育児において短期的な効率を重視するなら、「得意なほうが同じタスクをまとめてこなしたほうが早い」という場面もあります。 しかし、それを続けてしまうと、どちらかが体調を崩したときや他のことで手一杯になってしまったときに、途端に回らなくなってしまいます。

恥ずかしい話ですが、私もお風呂に入れるのをパートナーに任せきりだった結果、パートナーが体調を崩していざ自分が風呂に入れるとなった際、シャワーの出力調節を誤り、子どもを泣かせてしまったことがありました。元気なときにもっとやっておけばよかったと後悔しましたし、勘所はやってみないとわからないものだとも思いました。

この経験を通じて、「お互いが様々な家事・育児タスクをできるだけ経験しておく」ことの重要さがわかりました。 これはまさに、経験主義に基づいて機能横断型のチームを構成することがチームワークを高めるというスクラムの考え方に通じるものだと感じています。

そして、この「相手がやったことがないことを任せる」「自分がやったことがないことにチャレンジする」という行為には不安が伴い、「勇気」が必要だということもわかりました。 スクラムの考え方は全て繋がっているんですね。

尊敬や日々の改善──スクラムとの接点はほかにもたくさん

そのほかにも、スクラムで学んだ価値観や習慣が、育児チーム(=自分とパートナー)を円滑に回すために役立ったなと思う場面がありました。

「ありがとう」を言葉にする習慣

日々お互いがやったことに対して感謝やねぎらいをちゃんと口に出すことが、チームとしての雰囲気を良好に保つ原動力になっていました。 これは、スクラムの価値基準のひとつである「尊敬」に関連することだと思いました。

睡眠が取れず疲れが出ているとこういったことを忘れがちで、自分の都合ばかりを重視して物事を考えてしまうとも思いました。 開発チームにおいてもこれは同じで、切迫した状況だとPOの立場や他の作業をしている人の立場を考えず行動してしまうと思ったため、相手への敬意を持つことはより意識していこうと思います。

日々のふりかえりと改善

もともとうまくいっていたことでも、子供が成長していくことではまらなくなることが多くありました。
そんな中で大人が寝る前の時間に「今日ちょっとうまくいかないことがあったね」「あそこはこうすればよかったかも」といった小さなふりかえりを行っていました。

運動成長に合わせて生まれたてから使っていたベビーベッドを廃止し寝室のレイアウトを変更する、身長が伸びたことに合わせてお風呂から上がる際の待機の手の向きを変えてみるなど、ふりかえりの会話から具体的な改善策が出てくることも多くありました。

変わりゆく状況のなかでは事前に完璧な計画を立てるというのは無理だということ、だからこそ短いサイクルでふりかえりをしながら改善していくことが大事であることを、経験から身をもって実感しました。 また、日々のこうした積み重ねが、チームとしての連携力を少しずつ高めていくのだと知りました。

育休を終えて思うこと

今回私はスクラムのプラクティスを育児に導入した、というわけではありませんが、仕事で学んだ価値観を、育児の中で実感を伴って理解できました。

育休中は、キャリアが一時停止する不安もゼロではありませんでした。しかし今振り返ると、自分なりに多くの学びを得られた時間だったと感じています。

おわりに

エンジニアにとっての育休は、「チームって何だろう?」を見直す時間でもあるのではないかと思います。

これから育休を取ろうと考えている方や、育児とキャリアの両立に悩んでいる方にとって、この記事が少しでも励ましになれば嬉しいです。

私自身スクラム開発についても育児についてもまだまだひよっこではありますが、引き続き頑張っていきたいなと思います。

弥生では一緒に働く仲間を募集しています。
herp.careers
弥生のエンジニアに関するnote記事もご覧ください。
note.yayoi-kk.co.jp

『2025クラウドガバナンスはこう変わる!マルチアカウント運用のre:Invent最新情報と活用例』に登壇しました!

インフラチームでAWSの運用保守をしているねぎです。こんにちは。

1月30日(木)開催の『2025クラウドガバナンスはこう変わる!マルチアカウント運用のre:Invent最新情報と活用例』にて登壇をしました。

aws.amazon.com

はじめに

本イベントや、発表のきっかけについては、先日のブログで公開をしておりますので、そちらも一読いただければと思います。

tech-blog.yayoi-kk.co.jp

登壇前練習

弊社の発表枠は30分をいただいており、私含めて登壇する3人で自社の会議室に籠って、2時間30分ほど練習を行いました。

  • はじめに30分ほど各々イメージトレーニング
  • 発表練習+振り返り/休憩を3セット

上記の流れで練習を進めて、1回目の発表練習では30分枠のところを20分程度で終わってしまい、みんなだいぶ早口で時間に収めようという気持ちが強かったことを確認しました。
2回目の発表練習では、1回目を振り返って各自少しゆっくり話をしました。25分でした。。。まだ早いw
だいぶ余裕があることが確認できたので、各々もう少し特に発表したいポイントを肉付けした話そうという振り返りを行いました。
そして3回目の発表練習、28分!!
本番は緊張で早口になりがちなので、3回目の発表練習イメージを各自意識しながら登壇に臨もう!と練習を終えたのでした。

イベント直前

イベント開始の30分前、18時30分に会場到着しました。
早々に用意した資料が投影できるか、などの事前チェックを終え、発表台の真ん前の席を取らせていただきましたw
イベント開始までAWSさんが用意してくれたお菓子で糖分補給をしながら、ドキドキが増していきます。
イベント開始時間が間際には、会場となっていたStartup Loftの会場スペースが奥の方まで参加者でいっぱいに埋まっていた状況でした。(緊張度MAX)

イベント詳細

当日の各イベントですが、各セッション弥生の取り組みに活かせそうな内容が多く参考になりました。

「ビジネス成長を阻害しないために新しく AWS アカウントを作成した人がやるべきこと」

AWS様スピーカーセッションで、タイトルの通りアカウントを作成した後にやっておく基本ポイントを網羅的に聞けるセッションとなっていました。
「ルートユーザーアカウントの常用は絶対止めましょう」というコメントを何度もお話されてたのがとても印象的でした。

「re:Invent 2024 から見る AWS マルチアカウントガバナンスのこれまでとこれから」

AWS様スピーカーセッションで、マルチアカウントを実現する上で便利なAWSサービスである「ControlTower」に関する紹介がありました。
re:Invent 2024の新機能の紹介もあり、RCPや宣言型ポリシーによるガバナンス強化や使い分けで実現できることをわかりやすく学べました。

「少数精鋭で200+アカウントを支える!弥生の「CSGO活動(Cost、Security、Governance、Other)」とは」

弊社スピーカーセッションになります。資料は以下で公開をしております。

speakerdeck.com

時間を計ることを失念してしまったのですが、19時40分くらいから発表をはじめて、20時10分ごろに終わったので練習の成果が発揮出来た、はずです(汗)

「AWS Organizations で実現する、マルチ AWS アカウントのルートユーザー管理からの脱却」

STORES株式会社様スピーカーセッションで、一番最初のAWS様スピーカーセッションで何度も強調されていたルートユーザーアカウントをマルチアカウントから削除するまでに行ったことを具体的に紹介されていました。
弥生でのやろうとしていた内容だったので、とても参考になりました。

「スタートアップとセキュリティ対策」

SecureNavi株式会社様スピーカーセッションで、ISMS認証、Pマークなどを取得する際に取り組むポイントなどを紹介されていました。
AWSのマーケットプレイスでも提供されているということで、気になりました。

「持続可能なクラウドガバナンス運用: スモールステップと生成AIで始める運用効率化」

AWS様スピーカーセッションで、弥生がこれからやろうとしていることが一部盛り込まれている内容でした。
そのため非常に参考になり、生成AIでよりセキュリティやガバナンス強化が目指せると感じました。

イベント後

イベントが21時10分ごろに終了し、21時30分の会場退出時間まではQ&Aタイムということで、弥生の発表内容について各参加者の興味を持っていただいた方からご質問をいただきました。
ありがたいことに非常に好評をいただきまして、会場退出時間ギリギリまで色々な参加者の方とQ&Aを通じて、困っていること悩んでいることなどお聞きすることも出来ました。
AWSをシングルアカウント構成で活用している方、すでにマルチアカウントで運用されている方にも興味を持ってもらえた発表に出来たのかと思います。

登壇した感想

ねぎ

登壇する前までは、ただ弥生が取り組んで来た内容がメインで、この内容でイベントに参加された方に興味を持ってもらえるか不安がありました、 いざ終わってみると反響がすごく大きく、同じような悩み・取り組みをやっていきたいというお声を多く聞くことが出来ました。 今までやってきた方向性が正しかった、他の方にも響くような内容だった、という点が非常に嬉しかったです。 また登壇する機会をもらえるようによりAWSをフル活用して、より安全で快適な環境を作り上げていきたいと思います。

五十嵐

自分たちがやってきたことに対して、参加者からポジティブなリアクションいただけたので非常に励みになりました。 また、AWSさんのセッションや弥生以外の事例紹介では、弥生が今後取り組んでいく施策に活かせる内容が盛りだくさんで非常に有意義な時間となりました。 また登壇できるよう精進していきます!

今泉

今回の登壇はre:Invent 2024に参加した際に現地でお話をいただき、参加させていただく運びとなりました。 私個人ではこのような登壇は初めてで緊張しましたが、CSGO活動について皆様にお伝えできてできてよかったです。 登壇後には、参加者の皆様からマルチアカウント環境やSIEMについての質問をいただき、意見交換ができました。非常に有意義な時間を過ごせたことに感謝しています。 また、このような機会があれば、ぜひ積極的に参加したいです!

今後

今後の展望として

  • 「プラットフォームエンジニアリング」

  • 「生成AIの活用」

  • 「SIEM」

といった3点をチャレンジしながら、4つの軸としている

  1. 「コスト最適化」

  2. 「セキュリティ強化」

  3. 「ガバナンス強化」

  4. 「未来を実現するためのインフラ基盤整備」

のさらなるレベルアップを、引き続き少数精鋭で実現していきたいと思います。


弥生では、一緒に働く仲間を募集しています。
herp.careers
弥生のエンジニアに関するnote記事もご覧ください。
note.yayoi-kk.co.jp

QAエンジニアがFindy Job LTの「QAエンジニア特集」に登壇します

こんにちは、開発本部の kanai です。

2月25日(火)開催のFindy Job LTの「【QAエンジニア特集】プロダクト成長を支えるQA 品質保証の取り組みと課題」に、開発本部QAエンジニアの奥野 賢一が登壇します。
このブログは、告知です。

お話するもくにゃん

「【QAエンジニア特集】プロダクト成長を支えるQA 品質保証の取り組みと課題」

QA(Quality Assurance)は年々取り上げられるシーンが増えており、スタートアップなど規模を問わずQA組織の立ち上げが行われる程重要視されています。また、品質保証(QA)の役割は単なるバグ検出にとどまらず、プロダクトの信頼性や開発プロセスの最適化、ユーザー体験の向上まで広がっています。

そこで本イベントでは各社のQAエンジニアの方をお招きし、自社における品質保証の取り組みや品質において重視しているポイント、現場での課題や今後の展望を具体的な事例を交えながらお話しいただきます。

(イベントページより)


名 称:  Findy Job LT
主 催:  ファインディ株式会社
開催日:  2025年2月25日(火)12:00 - 13:00
会 場:  オンライン

こんな方におすすめです!

  • 各社のQAの取り組みや今後の展望を知りたい方
  • QAの役割やその重要性について理解を深めたい方
  • 今後のキャリアを考えているQAエンジニアや開発者の方

参加申し込み

以下のリンクの「イベントに申し込む」からお申し込みください。
[https://findy-code.io/events/0A7KrNpGFUvwP

弥生では一緒に働く仲間を募集しています。
herp.careers
弥生のエンジニアに関するnote記事もご覧ください。
note.yayoi-kk.co.jp

AWS re:Invent 2024 参加報告会 開催します!

こんにちは!弥生でエンジニアをしている中尾です。

皆さん、もくテク はご存知ですか?
もくテク は弥生株式会社が主催している社外向け勉強会です。

久しぶりにもくテク運営より開発者ブログを書いてみました。
好評であれば継続していこうと思います!
よろしければしばらくお付き合いください!

イベントの概要

mokuteku.connpass.com

2025年1月29日()19:00 から、もくテク1月会「AWS re:Invent 2024 参加報告会」を開催いたします!

「AWS re:Invent」はAWSが毎年開催している全世界規模の学習型カンファレンスになります。
例年ラスベガスで開催されていますが、実は弥生の選抜メンバーが毎年現地まで行き参加しています!

今回のもくテクでは、LT&座談会形式で実際に参加したメンバーに「AWS re:Invent」の思い出や普段の業務でのAWSの利用シーンについて語ってもらいます!

LTの概要

もくテク定番のLT(Lightning Talk)になります!
タイトルを紹介するので気になる発表があった方はぜひお申し込みください!

LT1

「フロントエンドとバックエンドの非同期連携パターンと弥生Nextの事例紹介 (仮)」になります。
発表者の木村さんが re:Inventの記事を投稿しているので、ぜひご一緒にご覧ください。

tech-blog.yayoi-kk.co.jp

LT2

「Amazon OpenSearchのコスト最適化とZeroETLへの期待」になります。
発表者の今泉さんも re:Inventの記事を投稿しているので、ぜひご一緒にご覧ください。

tech-blog.yayoi-kk.co.jp

LT3

「re:Inventで学んだWebシステム運用のBad Dayへの備え方(仮)」になります。
発表者の宮崎さんも re:Inventの記事を投稿しているので、ぜひご一緒にご覧ください。

tech-blog.yayoi-kk.co.jp

LT4

「AWS re:Inventで感じた世界に見る生成AIの競争」になります。
re:Inventとは別ですが、発表者の髙瀬さんが社内の勉強会について記事を投稿しているので、ぜひご一緒にご覧ください。

tech-blog.yayoi-kk.co.jp

座談会

本イベントではLT登壇者による座談会を行います。
イベント中に視聴者の皆様から質問を募集しますので、遠慮なくご質問ください!

イベント申込ページ

イベントの申し込みはconnpassのイベントページからお願いいたします!
ほかの媒体は取り扱っておりませんのでご了承ください。 mokuteku.connpass.com

過去のイベント

もくテクでは、過去のイベントをYou Tubeで公開しています。

一覧はこちら もくテク配信アーカイブ - YouTube

昨年度のre:Invent回はこちら

youtu.be

弥生では、一緒に働く仲間を募集しています。

herp.careers

AWSイベントに登壇します

インフラチームでAWSの運用保守をしているねぎです。こんにちは。

1月30日(木)開催の2025クラウドガバナンスはこう変わる!マルチアカウント運用のre:Invent最新情報と活用例にて、登壇をします。

aws-startup-lofts.com

このブログは告知です。

2025クラウドガバナンスはこう変わる!マルチアカウント運用のre:Invent最新情報と活用例 とは

タイトルにもありますが、昨年行われたAWS最大規模のイベント「re:Invent」の最新情報をAWSさんからお話いただき、その後各社の事例として今回は「マルチアカウント運用」をテーマに活用事例をお話するイベントとなっております。

イベント前日にはもくテクで、弥生社員が昨年参加したre:Invent参加報告会も予定されています。こちらも是非ご参加いただければと思います。

発表のきっかけ

2022年5月のもくテク発表です。この時に「マルチアカウント運用」に関して発表していました。

mokuteku.connpass.com

その時の発表資料をAWS社内でも活用いただいているということで、今回のイベントテーマにも沿っていて、その後2年間でどういう進化を遂げたかをお話して来ようと思っています。

speakerdeck.com

発表概要

タイトル:「少数精鋭で200+アカウントを支える!弥生の「CSGO活動(Cost、Security、Governance、Other)」とは」

2年前のもくテク発表時は、AWSアカウントが100アカウント近くなってきた時のお話でした。

そこから倍以上のアカウント数となりました。。。(あっという間に)

2年前までは私一人で運用をしていましたが、今では私含めて3人!!(人数は3倍に)

それでも少人数だと思いますので、少人数でこの規模を運用していくポイントとして4つの取り組んだ内容をイベントでは紹介します。

  • コスト最適化(Cost)
  • セキュリティ強化(Security)
  • ガバナンス強化(Governance)
  • 未来を実現するためのインフラ基盤整備(Other)

上記4つのポイントはCSGO活動(Cost、Security、Governance、Other)として、それぞれの頭文字を取って勝手に社内で呼んでいます。

これからAWSでマルチアカウント環境を検討されている方、すでにマルチアカウント環境を運用されている方の気づきやヒントになると思っています。

弥生では、一緒に働く仲間を募集しています。
herp.careers

弥生のエンジニアに関するnote記事もご覧ください。
note.yayoi-kk.co.jp

弥生アドベントカレンダー2024ふりかえり

この記事は弥生 Advent Calendar 2024のシリーズ2、25日目の記事です。

プレゼントもらえた?
こんにちは、かとあず(@kato_az)です。
弥生でQAエンジニアをしている傍ら、弥生開発者ブログの運営や弥生株式会社エンジニア情報X(旧Twitter)の中の人をやっています。

弥生アドベントカレンダー2024 とは

今年もQiitaの「Organization」カテゴリーでアドベントカレンダーを作成し、弥生メンバーがブログリレーをしました。
「業務に直接関係あること、ないこと」を書いた弥生エンジニアのたくさんのブログが公開されました。
ぜひご覧ください。
qiita.com

ふりかえり

「弥生アドベントカレンダー2024」を「弥生アドベントカレンダー2024」でふりかえる件について

弥生アドベントカレンダー2024ふりかえり

当初は、アドベントカレンダーが12月25日に完了後、外部発表として弥生の取り組みを紹介する予定でした。
しかし、急遽12月23日に開催した弥生社内の部門でのLTでお話しすることになりました。

「12月25日までアドベントカレンダーが続くのに23日にふりかえりをテーマにLTをするの?」と感じる人もいたかもしれません。
それでも、「鉄とふりかえりは熱いうちに」。タイミングを逃さないことをモットーに、 実行しながらふりかえっていくスタイルです。

部門でのLTに関しては、弥生アドベントカレンダー2024の20日目と23日目で、新卒入社1年目の野溝さんと矢谷さんが紹介されています。
ぜひこちらの記事もご覧ください。 tech-blog.yayoi-kk.co.jp

tech-blog.yayoi-kk.co.jp

弥生アドベントカレンダーの参加者情報

去年2023年までは「シリーズ1」25記事の登録が完了するのが11月の最後だったのですが、今年2024年は11月12日に25記事の登録が完了していました。すごい。
このため、弥生のアドベントカレンダーとしてははじめて「シリーズ2」を作成し26記事以上の参加を募集することになりました。

アドベントカレンダー記事数と参加者数(見込み)
大盛況のアドベントカレンダー、弥生は2018年から参加しています。
最初の2年は複数の会社が合同で実施しているところに参加している状態で、3年目の2020年から主体となって実施しています。
アドベントカレンダー実施は連続7年
年々アドベントカレンダーが浸透していって参加が増えている印象がありました。しかし、数値で見ると、2018年と2024年ではエンジニア人数が約2倍、アドベントカレンダー参加人数も約2倍ということで、参加割合の推移はあまり変わっていないということがわかりました。
2018年から2024年でエンジニア数が2倍、アドベントカレンダー参加者数も2倍
何年か続けているうちに「常連だけの内輪ネタお祭り」になりそうですが、「弥生アドベントカレンダー2024」は参加者のうち、過半数は初参加でした。
初参加が半分以上

運営メンバーがやってきたこと

寄稿者に向けての取り組み、運営内の取り組み、それぞれ3点紹介します。

寄稿者に向けての取り組み

  1. とにかく周知
    複数の場で周知し、社内でアドベントカレンダーを全員が知っている状態を目指しました。
  2. 個別にアプローチ
    「●●さんのあのLTについて、もっと読みたい」「社内で表彰されていたこと詳しく教えて」などなど、普段のみなさんの活動を見ながらブログに書いてほしいことをお願いしました。
  3. Slack、はてなブログで盛り上げ
    公開後には意識的にリアクションして社内での盛り上げを意識しました。ブログを書いてよかったと思えるようにしていきました。
    寄稿者に向けての取り組み3点紹介

運営内での取り組み

  1. 準備は10月から
    「弥生でアドベントカレンダーやると思わず他のアドベントカレンダー登録しちゃった」や「急に周知されてもブログ書くのが間に合わない」ということにならないよう、入念に準備し、11月早々に参加表明してもらえるように準備しました。
  2. みんなで参加を
    エンジニアだけのお祭りに閉じないよう、全社のSlackで見えるようにしたり、絵が描けるメンバーにカバー画像をかいてもらいました。
    もくにゃんかわいい。
  3. 接点を増加
    弥生開発者ブログやアドベントカレンダーの存在に気づいてもらうため、弥生株式会社エンジニア情報Xにてブログ情報を投稿しています。
    まだまだフォロワー数の少ないアカウントではありますが、知っていただくために試行錯誤しています。
    運営内の取り組み3点紹介

偶然発生したこと

運営が狙っていたわけではないことでもよいことがたくさんありました。
特に、フルリモートワークを採用している弥生では部門が異なる人同士のコミュニケーションが難しいと感じます。
ブログをとおしてレビューアーとレビューイーでZoomミーティングをしたり、投稿記事のリアクションから話が広がったりしたのは、よいことだったと感じています。
今後、業務上で連絡を取り合うときに「ブログのあの人」と思い出すことでスムーズに会話が進むかもしれません。

狙っていたわけではない、よかったこともたくさん。

今後の取り組み

12月以外のブログ投稿数が増えていないこと、公開までのフローが煩雑になってしまっていること、運営メンバーの交代が発生するので引継ぎが必要なことを挙げています。
2025年改善ネタです。

次の施策を考えないといけない
完成形ではない状況ではありますが、それでもアドベントカレンダーは大盛況でした。

まとめ

弥生開発者ブログ運営で、弥生開発者ブログとアドベントカレンダーの取り組みをふりかえりました。
2025年はどんな1年になるでしょうか。お楽しみに。

弥生アドベントカレンダー2024まだ読んでいないという人は、ぜひ気になるタイトルの記事を1つ読んでみてください。
qiita.com

また1年後!



弥生では、一緒に働く仲間を募集しています。
herp.careers

弥生のエンジニアに関するnote記事もご覧ください。
note.yayoi-kk.co.jp