ソースコード検索エンジン・OpenGrokを構築しよう

この記事は 弥生 Advent Calendar 2021 の24日目の記事です。

こんにちは。弥生でエンジニアをしている、たけです。
突然ですが、この記事を読んでくださっているみなさんは、ソースコードの検索をどのように行っていますか?

普段から道に迷いやすい私ですが、ソースコードを読んでいるときにも迷子になることが多々あります。 そのうえ極度の面倒くさがりなので、「IDEを立ち上げるのもちょっとな…」と思うことがあります。

そこで、「OpenGrok」というソースコード検索エンジンを自分の開発用PCに構築することにしました。
私は普段デスクトップアプリケーションの開発を行っているのですが、Webアプリケーションの基本の勉強になりそうだと思ったことも、OpenGrokを使ってみようと思った理由の一つです。

目次

OpenGrokとは?

oracle.github.io

  • 高速のソースコード検索・相互参照エンジンです。
    • "A wicked fast source browser" (めちゃくちゃ速いソースブラウザ)です。
  • 複数のプロジェクトのソースコードを一括で検索することができます。
  • 以下のような様々な言語に対応しています。
    • C / C# / C++ / Golang / Java / JavaScript / Json / Kotlin/ Python / Ruby / Rust など

環境構築手順

公式的な環境構築手順は以下のページに記載されていますので、詳細はこちらをご参照ください。
How to setup OpenGrok · oracle/opengrok Wiki · GitHub

このブログでは、私が実際に自分の開発用PCのWindowsに構築した手順を簡単にご紹介します。

1. 事前準備

2. Ctagsをダウンロード

※Ctags:ソースファイル・ヘッダファイルの名前のインデックスファイルを生成するためのプログラム。

  • Universal Ctags をダウンロードし任意のディレクトリに展開する。
  • Path にctags.exeのパスを追加する。

3. OpenGrokの環境作成

  • OpenGrok > Download TAR Ball から「opengrok-XXX.tar.gz」をダウンロードし任意の場所に展開する。
  • OpenGrokの展開先にある、\lib\source.warを展開する。
  • 展開したsourceの配下にある、WEB-INF\web.xmlにCONFIGURATION、SRC_ROOT、DATA_ROOTを設定する。
  • sourceを、%CATALINA_HOME%(Tomcatの展開先)\webapps\にディレクトリごとコピーする。
  • %CATALINA_HOME%\conf\server.xmlの要素内に以下の行を追加する。
 <Context path="/source" docBase="source" debug="0" />

4. ソースコードを解析

  • 「3. OpenGrokの環境作成」でweb.xmlのSRC_ROOTに指定したパスに、解析したいソースコードを配置する。
  • コマンドプロンプトでOpenGrokの展開先\libに移動し以下のコマンドを実行する。
java -jar opengrok.jar -W [configuration.xmlへのパス] -c  [ctags.exeへのパス] -P -S -v -s  [ソースツリー(SRC_ROOT)へのパス] -d  [解析結果出力先(DATA_ROOT)へのパス]

5. OpenGrok を表示

  • Tomcatを起動する。(%CATALINA_HOME%\bin\startup.bat)
  • ブラウザから http://localhost:8080/source にアクセスする。
  • 以下のようなOpenGrokのトップページが表示されていれば環境構築成功です!

f:id:yayoi_ntake:20211220103905p:plain

OpenGrokでできること

  • SRC_ROOTに配置したすべてのファイルについて、以下の表の項目から検索を行うことができます。
  • 「Projects」から検索対象のプロジェクトを絞り込むことも可能です。
検索項目 検索対象
Full Search すべてのトークン
Definition シンボルの定義
Symbol シンボルの定義と参照
File Path ファイル・ディレクトリの名前
Type ファイルの種類
  • 検索結果を選択することで、ヒットした部分が含まれるファイルを開くことができます。
  • 開いたファイルの変数などをクリックすると、その定義にジャンプすることもできます。

使いどころ

上記に記載したOpenGrokの機能を使うと、

  • 複数のプロジェクトのソースコードの検索を、一括で高速に行うことが可能です。
  • 複数の条件を組み合わせた検索を簡単に行うことができます。
  • したがって、巨大なプロジェクトのソースコードを理解するのに便利です(もう迷わない)!

感想

実際にOpenGrokを使ってみて、「やはり速い!」と感じました。
私の所属するチームでは、複数の製品の開発を行っています。
そのため、「このクラス/メソッドは他にどこで使っているんだろう?」と思ったときに、複数のプロジェクトを気軽に検索することができるのはとても助かります。

また、Webアプリケーションのごく基本的な構成について、実際に環境を構築しながら学ぶ良い機会になりました。
OpenGrokを構築する環境がWindows、かつ日本語で書かれている参考情報があまり多くなく情報収集に少し苦労しましたが、それもまた良い勉強になりました。

今後やりたいこと

GitやSVNなどのバージョン管理システムとOpenGrokを連携させることで、変更履歴や差分も見られるようになるので、そちらも対応するとより便利になりそうだと思っています。

お知らせ

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

マイクロサービスのAPIをRESTからGraphQLへ段階的に移行した話

こんにちは。弥生の内山です。
この記事は弥生 Advent Calendar 2021 23日目の記事です。

qiita.com

はじめに

現在、弥生では新しいサービスの開発を行っており、今後主流となりうる技術を積極的に取り入れる方針で進めています。
本記事のタイトルにあるマイクロサービスアーキテクチャやGraphQLもそのようにして取り入れてきました。
ただし、それらの技術を実際にプロダクトに適用するのは一筋縄ではいかず、いろいろな遠回りを行った末にどうにか適用できた、というのが実際のところでした。
その過程については、前回12/16のもくテクにてお話させていただきました。

mokuteku.connpass.com

この過程の中で特に苦労したのが、既にREST APIとして構築したサービス群をGraphQL APIのサービス群へ移行させることでした。
もくテクの発表では、かなりの駆け足で移行の全体をお話ししたため、このGraphQLへの移行についてあまり詳しくご説明することができませんでした。
そこで本記事では、RESTからGraphQLへ移行した過程について、少し掘り下げてご説明したいと思います。

移行前のシステム構成

移行前のシステム構成は、以下の図のようになっていました。

f:id:ucho_yayoi:20211220173234p:plain

技術構成は以下のようになっていました。

  • フロントエンド:Next.jsを使用。API RoutesにGraphQLサーバーを立ててBFFとしている。
  • バックエンド:C#(ASP.NET Core)を使用。REST APIとして各種機能をフロントエンドに提供。

この構成において、BFFは以下のような役割を持っていました。

  • フロントエンドからバックエンドのアクセスを1箇所にまとめる
  • バックエンドが提供しているREST APIを集約・変換し、GraphQL APIの形でフロントエンドへ提供する

以上の構成において特に問題となっていたのが、BFFにてREST → GraphQLへのプロトコル変換を行う処理の実装が開発スピードを落としているということでした。
そこで、この部分を見直し、今後の開発スピードを高める策を検討しました。

移行方針

GraphQLは使いたい

フロントエンドとBFFの接続にはGraphQLを使用していましたが、これはそのまま使いたいと考えました。
GraphQLのメリットは様々なところで語られていますが、クライアント側で取得するデータを決定できるという特徴が、やはりフロントエンドとの相性が良いということを実感していました。
そこで、BFFより後ろのプロトコル変換部分を見直すことにしました。

プロトコル変換は無くしたい

プロトコル変換処理を作成するのは大変ですが、APIスキーマ等から自動生成を行う等の手段によって、ある程度はその労力を削減することはできると思います。
しかし、プロトコル変換を行うレイヤーが存在すること自体が、開発のボトルネックになるのではないかと考えました。
そこで、バックエンドサービスがREST APIを提供するのをやめて、変換後のGraphQL APIを直接提供するような構成にすることにしました。

移行のための技術選定

Apollo Federation

GraphQLは、クライアント側から見えるエンドポイントを1つにするのがベストプラクティスとされています。
各バックエンドサービスがGraphQL APIを提供するのであれば、BFFの位置でそれらをまとめて1つのGraphQL APIにすることが望ましいです。

複数のGraphQL APIを束ねて1つのGraphQL APIにしたい、というときに有力な選択肢となるのが、Apollo Federation仕様です。
Apollo Federationは、Netflixが採用したことで有名になった技術で、APIを束ねるゲートウェイが各APIの関連を理解して自動的にクエリの分配・結果の統合を行ってくれます。
現時点でGraphQLのマイクロサービス構成を作るならばこれだろう、と考え、Apollo Federationを採用することにしました。

www.infoq.com

zenn.dev

Apollo Federationでは、各APIが他のAPIとどのように関連しているかをゲートウェイに示すために、独自のスキーマ拡張仕様が定義されています。
この仕様をサポートしていないとゲートウェイにぶらさがることができないため、APIの実装にはApollo Federationに対応したライブラリを使う必要があります。

C#でのGraphQL(不採用)

さて、ではC#のサーバーで実装されたREST APIを、GraphQL APIに置き換えていこうと思ったのですが、ライブラリの選定時点で頓挫してしまいました。
C#のGraphQLライブラリで最も人気があったのはgraphql-dotnetですが、以下のような理由で我々にはマッチしていないと考えました。

  • APIが難しい
    • 非常に高機能な一方で、どう書けば目的を達成できるのかを理解するのが難しかった
    • 公式のドキュメントがあまり充実しておらず、Webにも情報が少なかった
  • Federationへの対応が中途半端
    • Federation対応のAPIを書くにはSchema Firstモードを使う必要があるが、Schema Firstモードの使い方に関する情報はさらに少なく、これを調査しながら使い続けるのは現実的ではないように感じた

ちなみに、一般的にGraphQL APIを定義する方法は大きく分けてSchema First(まずスキーマを作成し、それに対応するリゾルバを実装する)とCode First(クラス定義等からスキーマが生成される)があり、世の中の多くのライブラリはSchema Firstを採用しています。
どちらの方法も一長一短ですが、API実装者がAPI定義も行う場合は、Code Firstの方がスキーマ定義と実装との不一致が起こらないため、有効だと感じます。
なお、graphql-dotnetはSchema FirstとCode Firstの両方をサポートしているライブラリです。

また、graphql-dotnet以外には実用レベルに至っていると感じられるライブラリが見つけられませんでした。
このため、C#でFederation対応のGraphQL APIを実装することは困難であると考えました。

NestJS + GraphQL

C#での実装が難しいということがわかったため、他の選択肢を検討しました。
GraphQLのサポートが強力なのはやはりJavaScript/TypeScriptベースのライブラリでした。
その中でもNestJSは、Code FirstモードでFederation対応のAPI定義をサポートしているため、我々の要求にピッタリ合うという印象でした。

docs.nestjs.com

また、NestJSを採用すれば、フロントエンドもバックエンドもTypeScriptで開発できるようになるため、1つの機能を開発する際のオーバーヘッドが削減できそうです。
以上のことから、バックエンドの各サービスはNestJSを用いて開発することにしました。

お試し移行

しかし、既にC# + RESTで開発したAPI実装を、NestJS + GraphQLのAPIに変更するということは、つまりバックエンドサービス群を新しい技術スタックでまるごと書き直すということになります。
さすがにそれをいきなり実行するのはリスクが高すぎるため、まずは新規機能のために開発するAPIサーバーを、この新しい技術スタックで作成してみることにしました。

作成してみて、これまでの技術スタック(C# + REST、BFF内でGraphQLへ変換)で開発していたときと比較し、機能が完成するまでのスピードが明らかに早くなったと感じました。
単純に記述するコードの量が減りましたし、言語やプロトコルを頭の中で切り替える必要がなくなったので、作業効率もアップしたのだと思います。
この新しいGraphQL APIの実装方法に手応えを感じたため、これまでに作成してきた機能についても、新しい技術スタックへの置き換えを進めることにしました。

APIのマージ

さて、新しくGraphQL APIを立てたものの、このAPIを既存のシステムにうまく接合することができていませんでした。
この新しいAPIもBFFにぶらさげる形としたかったのですが、以下のような理由によりそれができませんでした。

  • Apollo ServerはREST API等の複数のデータソースを変換して1つのGraphQL APIにまとめることはできるが、GraphQLのデータソースはサポートしていなさそう
  • Apollo Gatewayは、複数のGraphQL APIをまとめることはできるが、GraphQL以外のAPIをまとめることはできなさそう

そのため、実は新しいAPIはフロントエンドから旧APIと別に呼んで、フロントエンドで結果をマージするという、かなり乱暴な暫定処置を行っていたのでした。
(新しいAPIとこれまでのAPIがそれほど結びつきが強くないということも幸いし、この処置でどうにかなったのでした)

しかし、このままではフロントエンドが複数のAPIエンドポイントを呼ぶ形になってしまい、複雑さが高くなってしまうのは明白です。
また、これまで作成したREST API群をGraphQL APIに置き換えていくときに、全てのAPIを一気にGraphQLにするのではなく、APIサーバーを順番にGraphQLに書き直してシステムに接合していけるような方法が採れないと、移行のリスクが高くなってしまうと考えました。
そこで思いついたのが、「REST APIをまとめてGraphQL APIにするサーバー」と、「各GraphQL APIをまとめるサーバー」の2段構成にするアイデアでした。

移行ステップ

以下のようなステップを経て、REST API群をGraphQL APIへ置き換えていきました。

1. REST APIを集約する部分を切り出す

今まではNext.js上のAPI RoutesにApollo Serverを配置し、これがREST APIを集約してGraphQL APIを提供していました。
このApollo ServerをBFFから切り離し、独立したサービス(API Gateway)として動作させるようにしました。

f:id:ucho_yayoi:20211220173237p:plain

2. GraphQLをまとめる

システム上に、2つのGraphQL APIサーバー(API Gatewayと、新規機能開発で作成したGraphQL APIサーバー)が存在する状態になるので、これらをApollo Gatewayを使って集約し、1つのGraphQL APIにします。
Apollo Gatewayは、いったんAPI Routesに配置します。
これによって、フロントエンド側からは1つのGraphQL APIだけが見える状態になります。
(新APIがフロントエンドに直結されてしまう問題もこれで解決できます)

f:id:ucho_yayoi:20211220173239p:plain

3. REST APIサービスをGraphQL APIサービスに移行する

この状態であれば、REST APIサーバーの1つをGraphQL APIサーバーに書き直しても、API RoutesのApollo Gatewayの下にぶらさげれば、フロントエンドから見たGraphQL APIとしては変化しないということになります。
これによって、REST APIサーバーをひとつずつGraphQL APIサーバーに書き直して、順次システムに接合する、ということが可能になります。

f:id:ucho_yayoi:20211220173242p:plain

4. API Gatewayを切り出す

REST APIサーバーをすべてGraphQL APIサーバーに書き直した後は、REST APIを集約していたApollo Serverが必要なくなります。
また、各Next.jsアプリのAPI Routesに置いたApollo Gatewayがほとんど同じことをやっているため、これらを1つにまとめたいです。
そこで、API GatewayにApollo Gateway(名前が紛らわしいですね)を配置するようにします。
ここまで実施すれば、GraphQLなマイクロサービス構成への移行が完了です。

f:id:ucho_yayoi:20211220173231p:plain

まとめ

こうして振り返ってみると、なんだか非常に遠回りをしたような気がします…。
しかし、結果としてすっきりした技術構成へ移行することができましたし、移行過程でGraphQLまわりに関する知見を深めることができたと思います。
この記事が、GraphQLへの移行を試みる方の参考になればうれしいです。

お知らせ

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

コロナ禍入社のエンジニアが技術イベントを頑張る話

この記事は弥生 Advent Calendar 2021の22日目の記事です。

情報システム部エンジニアの飯田です。昨年に引き続きAdvent Calendarの記事を書いていきたいと思います!テーマは弥生の技術イベント「もくテク」を頑張っているよというものです。

もくテクについてはAdvent Calendarの8日と9日にもエントリーがありますので、興味のある方はそちらもぜひ見てください!

qiita.com

自己紹介とこれまでのお話

昨年5月、コロナ禍でちょうどリモートワークへ完全移行した後に弥生へ中途入社しました。これまでと全く異なる働き方に戸惑いつつも社員の皆さんのサポートのおかげで仕事にも慣れ、今では要件定義からリリース作業に保守・運用まで幅広く担当させてもらっています。

それに加えて今年は全社的な活動に関わる機会も増え、前回投稿した部署の全体会でのLT川本さんが書かれたBacklog移行プロジェクト、そして今回のテーマであるもくテクの登壇および運営と、自分なりに色々と動いてみました。

ちなみに全体会でのLTの話を投稿した4月の時点で3回だった出社回数は8回に増えていますが、そのほとんどはオフィスリニューアルのための荷物の梱包&開梱など普段の業務とは異なる理由でした。私の周りは自宅の作業環境も整備され、リモートワークがすっかり定着しているように思われます。(ただ、せっかくリニューアルして快適な空間となったので、オフィスも何かで活用したいなと思っています。)

きっかけ

私がもくテクに関わるようになったきっかけは、今年の6月頃にチームリーダーから登壇者の募集があったことでした。テーマは業務効率化で、ちょうど私がプロジェクトで取り組んでいたことをネタにできそうだったこともあり立候補しました(実際に登壇した会のイベントページはこちらです)。同時にもくテクの運営メンバーも募集していたのでそちらにも手を挙げました。(ここだけの話ですが、私は最初、「もくもく会」のイメージもあって「もくテク」の「もく」は「黙」だと思っていました。正しくは「木曜日」の「もく」です。)

運営については前職で社内の勉強会の活動に携わっていたのでその経験を活かせそうだと思ったのですが、登壇については実は初めてでした。自分でもどちらかというと裏方が向いており、発表も決して得意ではないと認知しています。それでも登壇者に立候補してみたのにはこれから書くような考えがあったからでした。

立候補した理由その1:弥生の技術をアピールしたい!

時は遡って昨年の3月、私が転職活動のために転職エージェントとの面談を受けた日のことでした。私のこれまでの経験や今後の方向性などを伝えた後、エージェントさんから勧められた企業の中に弥生株式会社があったのですが、その時私の頭に浮かんだのは「弥生会計の会社…かな?」でした。これ以外のことは思い浮かびませんでしたし、同じように思う人も多いのではないかと思います。

しかしそこから面接で弥生のビジョンや事業内容などに惹かれて入社を決め、実際の業務を見てみると、技術の会社として弥生はとても面白いということに気付きました。

まず、弥生会計を含む「弥生シリーズ」は30年以上の歴史を持つデスクトップアプリケーションで、これだけ長く続くソフトウェアは珍しいと思います。もちろんメンテナンスの大変さなどの負の側面もありますが、お客さまからの要望を取り入れた様々なこだわりがあり、技術の活かしどころなのではないかと思っています。(こういったこだわりの話は社内教育の他、もくテクで知ったものもあります。)

次にクラウド(オンライン)アプリケーションです。プラットフォームは以前から使用しているMicrosoft Azureに加え、佐々木さんが書かれたように最近はAWSの利用も広がっています。私が所属している新課金チーム(弥生製品の契約や請求を管理するシステムを開発・運用しています)とも深い繋がりがあり、また私も前職でAWSを使ってきていたので、個人的にこの流れは嬉しいです。(これからは私の時代だな!)

他にもYAYOI SMART CONNECTでは現在ホットなトピックである機械学習を扱っていますし、将来へ向けて最新の技術を使った次世代のサービスの開発も進んでいます。

これだけ幅広い領域を1つの会社で扱っており、しかも全て自社の製品やサービスです。弥生というと会計ソフトの老舗ということもあってお堅いイメージを持たれがちかも知れませんが、そんなことはなくて色んな技術を使っているんだよというのを多くの方に知っていただきたいと思っています。(そして私たちと一緒に働くメンバーを増やしていきたい!(笑))

立候補した理由その2:アウトプットの楽しさを広めたい!

もう1つの理由は内部向けのものでもあります。

発表は得意ではないと書いた私ですが、7月の最初の登壇以降、運営に携わりつつ9月と12月にも登壇させてもらっています(12月の会については後日開催報告がありますのでお楽しみを!)。発表自体は5分や10分と短いものですが、それでも準備にはそれなりの時間と手間がかかりますし、発表本番は緊張するものなので、ハードルは決して低いものではありません。

ただ、やり遂げた後の達成感は大きいですし、自分の普段の漠然とした考えを具体化することによって理解が深まったり気付きがあったりして、仕事の楽しさやモチベーションの向上にも繋がると感じています。

個人的な考えですが、イラストレーターは絵を描くことによって、俳優は役を演じることによって自己表現しますが、エンジニアは記事を書くことや登壇することによって自己表現ができるのではないかと思っています。(ちなみに私は大学のサークルで演劇をやっていました。最初に書いた通り表舞台には向いておらず役者は2回だけしかやりませんでしたが。)

登壇も経験した運営メンバーとして、これからは自身の経験を活かして登壇者をサポートし、アウトプットすることの楽しさを広めると共にもくテクを盛り上げていきたいと思っています。

次回もくテクのご案内

ということで、次回2022年1月のもくテクは私がメインの運営を担当します!

mokuteku.connpass.com

テーマは「新年の抱負を語ろう!LT」で、色んなチームのメンバーに2022年の抱負を語ってもらいます。周りのエンジニアがどんなことを考えどんな目標を立てているのか、また弥生がどんな技術を扱っているのかを知っていただける内容となっていますので、ぜひお気軽にご参加ください!

お知らせ

弥生では一緒に働く仲間を募集しています! チャレンジしたいことがあれば応援してくれる環境があるので、興味のある方はお気軽にお問い合わせください!

herp.careers

音声系システム担当のカスタマーセンター移転で得た学びの話

この記事は 弥生 Advent Calendar 2021 の21日目の記事です。

はじめに

弥生株式会社の石原です。
情報システム部のCRMチームに所属しています。

弥生は、札幌と大阪にカスタマーセンター(コールセンター)があり、CRMチームはカスタマーセンターの業務システムの導入支援・開発・運用保守を主に担当しています。
私は、CRMチームの中で主に音声系(テレフォニー・自動応答系)システムの担当をしています。

ちょうど1年前の年末年始期間中(2020年~2021年)に「お客さまへの安定したサポート体制と従業員が働きやすいオフィス環境づくりを目指す」というコンセプトのもと、札幌オフィスを移転しました。

今回は、音声系システム担当としてオフィス移転に携わり、普段と違った業務の中で、大変だったこと、学びになったことをお話します。

今回移転対象となった札幌カスタマーセンターは、400席を超える規模の大きいカスタマーセンターです。
私は、音声系システム担当としてアプリケーション側の業務を主に担当していて、オフィス移転の実務は未経験でした。
(大阪カスタマーセンターは2016年5月にオフィス移転をしていますが、私は参画していませんでした。)

オフィス移転プロジェクト開始前、私は漠然と以下のような移転作業を行うイメージでした。
1. 旧オフィスで業務が終了したら機器の電源を落として新オフィスに運ぶ
2. 新オフィスでは回線開通工事をしておいて、運んだ機器を設置する
3. 設置した機器の電源入れてテストしておわり!

ですが、実際やってみるとそんな簡単な話ではありませんでした。
様々な点で考慮する必要がありましたので、その点をお話していきます。

移転作業の方針・プロジェクトとして考慮すること

今回の移転プロジェクトでは音声系システムに限らず、移転プロジェクト全体で以下の2点を考慮する必要がありました。

  • 移転作業が年末年始期間中であること
    年末年始期間中のため、引越業者やシステム担当ベンダーの稼働日が限られ、移転作業も出来ることが限られました。移転作業は、ただ引越作業をするだけでなく、何か問題が発生したときの対処も含みます。
    そのため、移転先の新オフィスに「可能な限りシステム環境を整えて事前にテストを行う」という方針で進めることが決まりました。
    事前テストは2020年12月上旬開始ということも決まり、音声系システムも事前テストに合わせて環境を整えることになりました。

  • 新オフィスの引き渡しから営業開始日までの期間が3か月であること
    新オフィスの引き渡しは2020年10月で、新オフィスの営業開始日は2021年1月です。
    電話回線の開通工事に必要な、電源やサーバーラック設置などの電気設備工事はすべて、新オフィス引き渡し後の10月から着手で、完了が事前テスト開始直前の予定でした。
    そのため、事前テスト開始直前は、音声系システムだけでなくシステム系すべての回線開通工事とサーバー機器設置工事が立て込むことが想定され、各システム担当で密に連携をとりながら工事日を調整する必要がありました。
    システム工事以外である什器搬入や内装工事、空調設備工事も新オフィス引き渡し後の10月からの開始なので、移転プロジェクトはすべての作業が非常にタイトなスケジュールで進んでいきました。

私のタスク

今回のオフィス移転で、私は以下の4つのタスクを担当しました。

  • 電話回線の移転契約
  • PBX(電話交換機)の構成と番号設定の設計
  • 通話録音環境の構成と録音設計
  • 電話機・ヘッドセットの機器選定

また、オフィス移転はシステム設計課題の改善や機器更改のチャンスなので、課題の改善を意識しながら作業を進めました。

電話回線の移転契約

まずは旧オフィスの電話回線契約内容と実機の確認を行い、旧オフィスの電話回線の契約内容と機器構成を完全に理解するところから始めました。
その上で新オフィスに必要な環境と、旧オフィスの回線契約をどうすべきかを考えました。
「可能な限りシステム環境を整えて事前にテストを行う」ため、新オフィスで必要な回線をすべて新規契約で開通させて、旧オフィスの業務終了後に番号ポータビリティを行いました。

PBXの構成と番号設定の設計

ハードウェアの更改と、旧オフィスの複数回の増床により煩雑になっていた社内の内線番号と転送設定の最適化を行いました。
担当ベンダーとの密な連携で特に大きな問題もなく作業を進めることができました。

通話録音環境の構成と録音設計

旧オフィスは、通話録音の際に電話機と電話機設置エリアに依存関係がある課題がありました。
オフィス移転のタイミングでどの電話機をどのエリアに設置しても通話録音ができるように改善しました。

電話機・ヘッドセットの機器選定

旧オフィスの増床のたびに追加購入していたので機種の統一ができておらず、古いものも継続して利用している状態でした。
利用する側は席によって電話機が違うため不便さがあり、私のように機器管理する側は統一出来ていないことによる保守性の低さが課題としてありました。
「従業員が働きやすいオフィス環境づくりを目指す」というコンセプトのもと、新オフィスでは気持ち良く仕事ができるように400席分新品購入することとしました。

大変だったこと

移転プロジェクトが未経験で、一つ一つが挑戦で大変ではあったのですが、その中でも特に印象に残っている大変だったことが3つありました。

電話回線契約の取りまとめが完了し発注目前の段階で見積金額に誤りがあり、費用が増額することが発覚したこと

電話回線契約の内容を決めるまでに時間がかかっていたため、事前テストに間に合うように電話回線開通するための発注期限が迫っている状況でした。 発注期限が迫っている状況と予算の範囲もあって焦ってしまい、費用を抑えることができる別の契約内容を再検討することも考えましたが、「お客さまへの安定したサポート体制」と「可能な限りシステム環境を整えて事前にテストを行う」という方針のもと契約内容を変更せず費用増額で社内調整を実施しました。調整の結果、費用増額での発注も承認され、契約内容を変更せずに進めることができました。

発注した400台の電話機が、納品前に突然販売停止となり、在庫もない、追加製造予定もないことが発覚したこと

製造メーカーに在庫も追加製造予定もない以上、発注した電話機と同じく、ヘッドセットとの互換性や必要機能を満たす別機種を再発注する以外に手はありませんでした。
今回はその別機種の在庫があり、無事400席分の新品購入を実現できました。

ルーター/ゲートウェイの設置工事日に、サーバールームの電源・サーバーラック設置工事が完了していないことが発覚したこと

電話回線は、開通工事日までにアクセス工事・ルーター/ゲートウェイの設置工事をする必要があります。
開通工事日の調整に気をとられすぎて、電源工事とサーバーラック設置工事の完了前に、ルーター/ゲートウェイの設置工事を行うスケジュールになってしまいました。
後続スケジュールのこともあり、開通工事日は延期できないため、キャリア側に相談をしたところ、電源は仮設電源、機器設置はラックがある想定でケーブル長を調整する形で工事を実施していただけることになりました。
工事日当日は、延長コードと電源タップを駆使した仮設電源を何とか用意し、工事を予定通り完了させることができました。

学んだこと

移転プロジェクトを通じて、音声系システムの契約内容と構成を完全に理解できたことも良かったのですが、前述の大変だったことから普段の業務では学べないことを学ぶことができました。

見積の内容確認の際は、金額に誤りがないことの再確認の依頼もするようにする

見積の工事単価に誤りはないだろうという思い込みがありました。
未経験なこともあり、見積内容をキャリア側と対面で認識合わせをして、決定した電話回線環境が構築できるか、工事内容に認識違いや過不足がないかの確認ができて満足していました。
今後は、工事単価の見積金額にも誤りがないか確認することを学びました。

発注時の在庫の有無はしっかり確認する・万が一の回避策も用意しておく

見積を受け取り、発注もできた製品なので、在庫はあるだろうという思い込みがありました。
今回は、ヘッドセットとの互換性や必要機能を満たす別機種があったから良かったです。
別機種の在庫がなかったら、旧オフィスの電話機を継続して使用するしかないため課題解決できず「従業員が働きやすいオフィス環境づくりを目指す」ということが実現できないところでした。 今後は、見積と発注のタイミングで確実に納品できる在庫があるのか確認すること、万が一の回避策となる第2案も用意しておくことを学びました。

自分が実施する作業の前提条件をしっかりと確認する

自分が実施する作業と、その前提条件の洗い出しができていませんでした。
実施する作業と前提条件を洗い出した上で全体スケジュールに反映しないと、プロジェクトの進捗管理も正しくできず、プロジェクト全体に迷惑がかかることになります。
今後は実施する作業と前提条件を洗い出した上で、全体スケジュールにはめ込んで、工程管理していくことを学びました。

おわりに

迎えた札幌カスタマーセンター移転後最初の営業日である2021年1月4日。 無事にお客さまからの電話が着信していることを見届け、一安心したと同時にとても大きな充実感がありました。
オフィスが一からでき上がっていく過程に携われたことも、なかなか得られない非常に恵まれた経験をすることができたと思っています。

ふりかえると、学びになったことは「自身の思い込みや考慮不足により問題が発生すると後々になって大変になってしまう」ということで、今現在も良い教訓となっています。

f:id:taku_ishihara:20211210101812j:plain
2020/10/05 新オフィス引き渡し直後
f:id:taku_ishihara:20211210102524j:plain
2020/12/21 移転作業を待つだけの新オフィス

お知らせ

弥生では一緒に働く仲間を募集しています!
https://herp.careers/v1/yayoi/s2GGF_cUe8qt

エンジニア100人でAWS学習コンテンツ<DevAx Academy MONOLITHS TO MICROSERVICES>を受けてみた(※日本初)

開発本部 Chief Technical Leaderの佐々木です。 2021年6月~9月にかけてDevAx Academy MONOLITHS TO MICROSERVICES という学習イベントを実施しました! 本記事ではイベントについてご紹介しようと思います。

DevAx Academyとは?

以下からの引用&翻訳ですが、「DevAxチームがお客様の開発チームと長期間直接連携して、ワークショップと共同開発セッションのカリキュラムで社内の開発コミュニティをスキルアップします」とのこと。 workshops.devax.academy

具体的には以下のようなものでした。

  • AWSのDevAx講師による全8回の勉強会
  • 今回はC#/.NETの環境で実施(ほかの言語の選択肢もアリ)
  • 勉強会は講義とHands onを織り交ぜたもの
  • Zoomによるオンラインでの開催(コロナの関係で・・・)

尚、DevAx Academy MONOLITHS TO MICROSERVICESのデリバリは弥生が日本初とのこと。 多い日では100人を超えるエンジニアが参加したのですが、100人という参加者数はAWS社内でも話題になるくらいの規模の大きさだったそうです。
私は2021年3月入社なのですが、弥生規模の会社で研修にここまで投資する会社は初めて見ました。100人×6.5時間×8回=約32人月って凄いですよね

尚、弥生では講師を呼んで大規模に実施しましたが、コンテンツは公開されているので自習も可能です

Monoliths To Microservices :: DevAx::Academy - Monoliths To Microservices

テーマは以下の8つです

  • 第1回:モノリスを移行する:6.5時間
  • 第2回:アプリケーションリリースの自動化:6.5時間
  • 第3回:マイクロサービスを作成する:6.5時間
  • 第4回:データのリファクタリング:6.5時間
  • 第5回: メッセージングとイベント駆動:6.5時間
  • 第6回:マイクロサービスのための認証認可:6.5時間
  • 第7回: コンテナ Immersion Day:6.5時間
  • 第8回: GameDay:4.5時間

※ 第7回の本来のテーマはAI/MLでしたが、弥生のエンジニアからコンテナの学習希望者が多く上がったため内容を差し替えました

それぞれの内容について簡単にご紹介します。

学習した内容

1. モノリス を移行する

IIS で稼働しているウェブアプリケーションを Elastic Beanstalk を利用して、AWS 上へ移行します。移行後の変更を AWS Toolkit for Visual Studio や AWS CLI を利用して、デプロイします。 とりあえず、オンプレミスやAzure上で動作しているアプリケーションを最小限のコストでAWSへ移行したい場合には、特に参考になります。また、Windows OS や Azure での開発に慣れていて、AWS 環境を試してみたいという場合にも良いと思います。

2. アプリケーションリリースの自動化

「 1. モノリス を移行する 」 で、Elastic Beanstalk へ移行したアプリケーションを CodePipeline や CodeDeploy などのサービスを利用して、デプロイを自動化していきます。 アプリケーションのデプロイを自動化するには、どのようなサービスをどのように利用すればよいのかについて参考になります。継続的インテグレーション/継続的デリバリー(CI / CD)に興味がある場合にも良いと思います。

3. マイクロサービスの作成

このモジュールでは、Lambda というサーバーレスを実現するサービスで、関数の作成していきます。また、S3 といった他サービスとの連携して、関数を起動したりします。そして、前のモジュールのアプリケーションの一部機能をLambda に移行します。 Lambda というサービスについて知りたい、Lambda を利用したマイクロサービスの作成方法について知りたい場合には、参考になります。また、AWS サーバーレスアプリケーションモデル (SAM) について知りたい場合も参考になります。

4. データのリファクタリング と ワークフロー

単一のRDB(Relational DataBase)に保存されているデータをマイクロサービスにアーキテクチャに適したデータストアに移行していきます。移行するデータストアには、DynamoDB を使用します。また、AWS Step Functions を利用したマネージドワークフローを作成していきます。 単一のデータストアに保管されたデータを分割について知りたい場合は参考になります。分割したデータを同期などするために AWS Step Functions の利用も検討することができます。

5. マイクロサービスメッセージング & EVENTING

このモジュールでは、Amazon SNS、SQS、Kinesis のような非同期にメッセージを交換するサービスについて学んでいきます。

異なるサービス間で非同期に情報を受け渡す際、AWSのサービスを使ってどのようにすればよいのか知りたい場合に適しています。

6. 認証された単一ページアプリケーション (SPA) の作成

Amazon Cognito を使って、Webアプリケーションに認証を追加する方法について学んでいきます。また、マイクロサービスであるLambda関数へのCI/CDの導入について学んでいきます。 Amazon のサービスを使って、Web アプリケーションやモバイルアプリケーションに認証を追加する方法について知りたい場合や、CI/CDの導入の仕方について知りたい場合に適しています。

7.コンテナ Immersion Day

このワークショップでは、Amazon ECS (Elastic Container Service)、Fargate、EKS (Elastic Kubernetes Service) というマネージドなコンテナ実行サービスの利用方法について学んでいきます。 コンテナ技術をつかって、ウェブサービスの構築を検討していて、AWS でのコンテナ実行するサービスを比較したい場合に参考になります。

8.GameDay

詳細な内容についてはネタバレ防止のために伏せますが、4名のチームに分かれてマイクロサービスをデプロイ、修正、運用します。 ある条件を満たすと点数が加算されて、ゲーム終了までの得点を競うゲーム形式のWorkshopです。

ゲーム中は様々な障害が発生するので実際の運用をイメージしたトラブルシューティングの技術について学ぶことが出来ます。

実施してみてどうだったか

弥生はオンラインサービスやデスクトップアプリ等の様々なエンジニアが在籍しており、AWSやマイクロサービスについての理解度についてもまちまちです。 今回DevAxを実施したことにより、エンジニアのAWSに対する理解度の底上げを図ることが出来たと感じています。理解度についてのアンケートを見るとDevAx実施後は平均値が向上し分散が小さくなっていました。 今回は大人数でのオンライン開催でサポートに不安を感じていたのですがAWSのSAの皆さんのサポート、弥生の部署を跨いだエンジニア間の助け合いが活発に行われたことにより回を重ねるごとにスムーズになっていった事が印象的でした。

お知らせ

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

社内のタスク管理ツールをTracからBacklogに移行した話

この記事は 弥生 Advent Calendar 2021 の17日目の記事です。

弥生の川本です。開発本部でQAを担当しています。
昨年の 弥生 Advent Calendar 2020 でも17日目を担当したので、今年もゲン担ぎで同じ日を選択しました!テーマも昨年同様PowerBIよもやま話にしようかと直前まで考えていました。

が、弥生はここ最近、以前にも増して新しい技術やツールの導入が盛んでして。私もBacklog移行プロジェクトに参画して新しいタスク管理ツール導入に取り組んだので、今年はそのよもやま話を書くことにました。
(※Backlogはタスク管理機能を持ったプロジェクト管理ツールと記載した方が適切ですが、本記事内では便宜上タスク管理ツールと記載しています)

ちなみに、PowerBIと類似したサービスでAWSのQuickSightというサービスがありますが、そちらについて1日目にgarusanさんがQuickSightでかんたんに視覚化を寄稿されているので、BIツールに興味がある方はそちらもチェックして頂ければ幸いです。


~目次~

タスク管理ツールとは

読んで字の如くタスクを管理するツールです!

これだけだとヒンシュクを買うこと間違いなしなので、私なりの考えを述べさせて頂くと、「プロジェクトを遂行するために割り振られた担当業務の進捗や状況を見える化し、コントロールするためのツール」だと考えます。 (参考までにWikiの「タスク管理」の説明は以下リンクです)

タスク管理 - Wikipedia

一般的にはタスク管理は担当者一人ひとりの裁量に任されている要素も多く、「ちゃんと予定した期日までに計画通りに完了してくれれば良い」と考える方もいらっしゃるでしょう。
しかし、皆さんもこれまでに手痛い経験をしたことがあるように、全てのタスクが計画通りに進むなんてことはそうそうありません。
様々な事情(見積工数とのギャップ、その他の割り込み作業、解決に時間を要する課題に遭遇、等々…)によって、タスクは当初思い描いていた理想とはまったく異なる状況になることも多いですよね。

そのような状況をいち早くキャッチアップするための仕組みを提供してくれるのがタスク管理ツールであると思います。
とは言え、当然のことながら、タスク管理ツールを導入すればそれで万事OK!とはいきません。
ツールはあくまでツール。目的達成のための手段の一つでしかなく、結局はどのようにそのツールを運用するのかが重要です。

なぜBacklogに移行するのか

さて、上記の言い回しだと疑問に思われた方もいるでしょう。

タイトルにも記載した通り、弥生では「Trac」というタスク管理ツールをすでに運用しているのです。
しかも十数年に渡って活用してきた歴史があるので、弥生の開発においてTracの利用は「当たり前」という価値観が定着しています。

そんな「当たり前」を壊して、あえて別のツールに移行するのはなぜかと言うと、「プロジェクトを遂行するために割り振られた担当業務の進捗や状況を見える化し、コントロールする」ことがTracでは難しいケースが出てきたからです。

少し話題が逸れますが、弥生のプロダクトは技術の循環サイクルによって進化してきました。 以前はいわゆるデスクトップアプリケーション単体で独立していたものが、クラウドアプリケーションの台頭によって連携することが当たり前な時代になってきました。

そうなると当然ながらプロダクトを作るプロジェクトも単体で独立したものから、複数のプロジェクトが関わりあって一つの大きなサービスを作り上げるという形に変化していきます。 そしてTracの構成だと「複数のプロジェクトから割り振られた担当業務を確認しにくい」ため、いろいろと不都合が生じ始めたのです。

他にも細かい理由はいろいろありますが「複数のプロジェクトの横断的なタスク管理を自分で行えるようにする」、これが新ツールに移行した最も大きな理由です。

苦労したこと

新しいツールを導入するから皆使ってねー!で済めば話はかんたんですが、さすがにそういうわけにもいきませんね。 あらためて運用ルールを定めたり、困ったときのFAQを準備したり、いろいろやることがある中で、私がいちばん苦労したのはTracのデータをBacklogに移行するためのツール作成でした。

Backlogのヘルプセンターには、RedmineからBacklog、JiraからBacklogに移行するツールは公開されていたのですが、残念ながらTracからBacklogに移行するツールはない模様。
そんなわけで移行ツールの自作を決意し、担当として手を挙げました。
ただ正直言って私の見通しは甘かったですね・・・。Office製品のVBAマクロ作成の経験はありましたが、外部のAPIを使う際のイロハをわかっておらず何度も躓きました。 いくつか躓き事例を挙げると、

  1. Backlogは設定する項目の値を内部的にIDで持っていて、しかもプロジェクトごとに値が異なる。Excelのセル代入のように単に登録したい値(文字列)を渡せば良いというものではない
    ・「そんなの当たり前じゃん!」と思われる方もいらっしゃるでしょう。でも私は関数リファレンスを確認するまで勘違いしていました。
    ・「まだ慌てる時間じゃない」と気持ちを落ち着けて、登録したい値の内部IDをプロジェクトごとに照合する関数を用意する方針に切り替えました。

  2. 課題登録時にカスタム属性を指定するとエラーになる
    ・関数リファレンスにサンプルコードがないため、正しいリクエストパラメータの書き方がわからず検索しまくりました。
    ・蓋を開けてみれば難しいことはなく、リクエストパラメータに「&customField_{カスタム属性自体の内部ID}=登録したい値」を加えるだけでした。

  3. Tracのチケットの担当者と、Backlogの課題の担当者をどうやって紐づけるか
    ・それぞれのアカウント名が異なるので紐づけテーブルを別で用意することを考えていました。
    ・が、ある日Backlogの関数リファレンスを確認していたら、メールアドレスを取得できることに気づきました。天啓がおり、メールアドレスを照合することで無事解決。

  4. TracのWikiformat形式を、BacklogのMarkdown形式にどのように更新するか
    ・試行錯誤しましたが、「複数個の表」がある場合の変換ロジックを実現できませんでした。。。
    ・諦めて表の置き換えについては別のExcelアドインを用意しました。WikiFormat形式の表を一度Excelの表に置換し、Excelの表をMarkdownの表に置換するアドインで、ユーザー自身に更新を依頼しました。

いま思い返すとただの知識不足や思い込みもありますが、躓いた分だけ担当する前よりスキルや知識が向上したので、挑戦した甲斐があったなーと思っています。
そして、出来ることが増えてきたので、さらに欲が出てきました。

これから実現していきたいこと

一言でいえば、「プロジェクト管理ツールとタスク管理ツールの連携による業務効率化」を実現したいと考えています。

弥生ではプロジェクト管理ツールとして、Microsoft Project(通称MSP)を利用しています。このツールではいわゆるWBSを組み立ててプロジェクト全体の進捗を見える化します。
したがって、プロジェクト管理ツールとタスク管理ツールの関係性は、言わば親子関係みたいなもので、プロジェクト管理ツール上の最小単位であるタスクを、タスク管理ツールでもっと詳細なサブタスクに細分化して管理していく、といった運用が基本です。
つまり、プロジェクト管理ツール(MSP)で計画したタスクを、タスク管理ツール(Backlog)に登録していくことになるわけですね。

f:id:takuya_windsurf:20211213174523p:plain
プロジェクト管理ツールとタスク管理ツールの関係(イメージ図)

現行のMSPとTracの運用では、MSPで計画したタスクを主に手作業でTracに登録していました。
MSPを確認しながら、タスクのタイトルを記載して、担当者・開始日・終了日などの項目を埋め、1件1件Tracに登録していくのです。
また、もしもMSPの方でスケジュールを再計画した場合は、当然ながらタスク管理ツールの日付も見直す必要が出てきます。

このタスク管理ツールに登録する作業や日付を見直す作業は、TracからBacklogに移行しても残念ながら無くなりません。
そして、この作業には相応の時間が必要なので、以前からどうにかして効率化できないかなーと思っていたのです。

まだ検討段階ではありますが、移行ツール作成で得たノウハウを活用することで、プロジェクト管理ツール(MSP)から直接Backlogの課題を登録することや、再計画したプロジェクト管理ツール(MSP)の日付でBacklogの課題を自動更新する、といった業務効率化を実現できるのではないかと考えてワクワクしている今日この頃です。

お知らせ

弥生では一緒に働く仲間を募集しています!
チャレンジしたいことがあれば応援してくれる環境があるので、興味のある方はお気軽にお問い合わせください!

herp.careers

個人作業好きなエンジニアもハマるチーム開発手法

はじめに

こちらは弥生アドベントカレンダー2021の16日目の記事です。

こんにちは。新卒1年目エンジニアの田邊慎史と申します。
SMARTという、銀行の明細や紙の領収書などの様々な「取引データ」を「会計データ」に変換する機能を開発しているチームに所属しています。

入社してからまだ8ヶ月ですが、以下のように過ごしてきました。

2021年4月:新卒として弥生に入社。  
2021年6月:開発本部システム開発部に配属。導入教育・開発研修を受ける。  
2021年9月:SMARTプロジェクト業務を開始。  


さて突然ですが、皆さんは個人作業とチーム作業のどちらが好きですか?

人それぞれだと思いますが、私は個人作業の方が好きで、黙々と一人で没頭するのがとても好きなタイプです。
しかし、開発本部配属直後の開発研修において、チーム全員での作業(モブプログラミング)をすることになりました。
最初は正直あまり乗り気ではありませんでした。しかし、実際にやってみたら奥が深く、楽しみながら学ぶことができました。そんなモブプログラミングの面白さについてお伝えしたいと思います。

研修の内容

モブプログラミングの話に入る前に、少しだけ研修の説明をします。開発研修は以下の3つのフェーズに分かれていました。

f:id:s_tanabe:20211202172325p:plain
研修内容

今回はチーム開発に焦点を当ててお伝えします。10営業日にわたり、他の新卒2人を含めた3人チームで、モブプログラミングによるECサイト改修を行いました。既に完成している、最低限の機能をもつECサイトを改修するというチーム開発でした。

モブプログラミングとは?

モブプログラミングとは、複数人で1つの画面を共有し、同時に1つの作業を行う開発手法です。

f:id:s_tanabe:20211202172308p:plain
モブプログラミング
とはいえ、全員で一斉に実装を書いていくわけではありません。以下の役割に分かれます。

  • タイピスト:1人。キーボードを持ってコードを書く人。
  • モブ:他の全員(今回のチーム開発では2人)。画面を見ているがキーボードは持たない。タイピストに指示を出す人。

モブが「このコントローラーにこのメソッドを追加してください」や「このメソッドの引数を修正してください」などの指示を出します。タイピストはその指示を受けてコーディングを進めます。

このロールを3人で15分交代で行いました。

やってみて感じたメリット

モブプログラミングを初めて知ったという方は、「こんな方法、非効率じゃないの?」と思った方もいるかもしれません。ちなみに私はそう思いました。 最初に書いた通り、私は一人で黙々と作業するのが好きなタイプなので「全員でやるのはどうなんだろう......?」というのが第一印象でした。

しかし、そんなタイプの私でも、実際にやってみるといくつかのメリットに気づきました。

知識習得・定着がしやすい

常に一緒に作業しているので、分担作業に比べ、チーム内での質問も多くなります。質問はする側、される側両方にメリットがあります。質問する側は疑問に感じたことをすぐに聞くことができます。質問される側は、質問に答えることで理解が深まり、自分の理解不足に気づくこともできます。

特に「質問される側」という点がポイントです。通常の研修であれば、受講生が質問されることはあまりありません。しかし、質問されることでアウトプットの機会を得ることができ、理解を深めることができます。

私も、「理解したつもりになっていたが質問されると答えられない」という場面から、改めて公式のドキュメントを確認して理解しなおしたり、自分の勘違いに気づいたりすることがよくありました。逆に、他の人のコーディングのやり方も見ることができるので、「他の人はこうやって考えるのか」「こういう実装の方法があるのか」などと勉強することもできました。

情報共有のコストが低い

分担作業を行っていると、事前の打ち合わせで合意したはずなのに、完成したものを見せたら相手と認識がズレていた、ということはありませんか?どうしても分担する場合は情報共有を入念に行わないと認識がズレることがあると思います。

しかし、モブプログラミングでは、同じ作業を皆で行うので、そのような認識のズレが起こりづらいです。もし起こったとしても、その場ですぐに修正することができます。そのようなコミュニケーションコストがかかりにくい点は大きなメリットになります。

実際に作業をしていて、UI上どこにボタンを配置するか、またあるメソッドをどこに配置するかなどで意見が分かれることがありました。そのような際に、言葉だけで自分の想定を伝えようとしても伝わりにくかったり、間違って伝わったりしてしまうことがあります。しかし、モブプログラミングであれば、全員で同じ画面を見ているため、実際に実装してみて見比べるなどができます。そのようなコミュニケーションの齟齬を防ぎやすいことも含めて、モブプログラミングにはコミュニケーションコストを減らすメリットがあると感じました。

品質の高いコードを書ける

常に複数人でコーディングするので、間違いに気づきやすいです。いわば、常にレビューしあいながらコードを書いているという状態です。

実際に作業していると「そのメソッドの引数の型がおかしい」「その条件分岐だと正確に分岐できない」などと、指摘がチーム内で出ることでミスを減らすことができました。さらなるメリットとして、他人から指摘されることで、「自分はこういうミスをしやすいんだな」と気づけることもあります。

難しかったこと

そんなモブプログラミングですが、もちろん良いことばかりではありません。良い部分だけ抜き出してお伝えしてもフェアではないので、難しいと感じたこと、どう対処すればよいと思ったかについて以下でお伝えします。

詰まりやすい

これは初心者の研修特有の現象かもしれませんが、分からないことに詰まってしまうことが頻繁に発生していました。

通常のモブプログラミングでは、集団でコーディングすることでみんなの知識を総動員させることができるので、問題を解決しやすいというメリットが挙げられることが多いです。

しかし、我々新卒3人のチームでは、それぞれ持っている知識が広くはないため、分からないことを全員で解決させることが難しかったです。基本的に全員持っている知識に差がほぼ無いので、詰まったときに誰かが解決できるということは少なかったという印象でした。

もちろん今回は研修だったので、詰まったときにどう調べて解決するかという点も含めて勉強になりましたが、実際の業務では、技術面をリードできる人がいたり、知識のプールが異なる人と一緒に実施したりすると良い形になるのではないかと感じました。

意思疎通ができないと困る

常に一緒に作業する以上、コミュニケーションを取りながらの作業になります。意思疎通の機会の多さは、上記のように質問しあえるという大きなメリットにつながります。しかし、逆に言えば、コミュニケーションがうまくいかないとモブプログラミングの利点を活かせません。

今回の新卒チームは4月から一緒に研修を受けてきたので、すでにコミュニケーションを取りやすい関係性が構築できていました。そのため、モブプログラミングを進める上で困ることは殆どありませんでした。しかし、そのような関係性が無い状態で行う場合は、指摘しづらい、質問しづらいなどの原因で、モブプログラミングが進めにくくなる可能性があります。

業務でモブプログラミングをやる場合、関係性ができているチームメンバー同士では特に問題ないと思います。ただ、これまで関わりがあまりなかったメンバー同士でやる場合は、アイスブレイクなどを通してコミュニケーションを取りやすい関係性を構築することも重要だと思います。

まとめ

モブプログラミングの良かったところ、難しかったところについて、私の体験で感じたことを紹介してきました。

自分の知識を深めることができ、さらに他人の持つ知識も得ることができます。また、煩雑なコミュニケーションコストを低減でき、そしてバグの少ないコードを書ける、そんなモブプログラミングの面白さが皆さんに伝われば嬉しいです。

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

herp.careers