ギグワークによるシステム開発

１．ギグワークとは

（１）ギグワークとは

英語のギグとワークを合わせた造語です。ギグは一度だけの演奏やセッションを表すスラングです。ワークは皆さんご存知の通り「仕事」の意味です。

そのためギグワークは単発の仕事という意味になり、一般的にはスキマ時間に働く事が出来る、専門性も低い仕事を指す事が多いです。

（２）システムズのギグワークとは

弊社のギグワークは上記のような単発のアルバイトのようなものではなく、社員の技術力及び働きがいを向上させるものと考えています。

具体的には、ギグワークを始めるにあたり、下記目標を設定しております。

【ギグワーク導入の目的】

• 社内副業により、新しい技術や普段実施しない作業に触れる機会を創出する。
• 経験があまり無いメンバーでもリーダーや管理者の作業を体験でき、モチベーションのアップに繋げる。
• 他部署のメンバーとの交流により、社内の活性化につなげる。
• もっと働きたい（収入を増やしたい）社員に対して就業の場を提供する。

（３）実施内容・結果

①　取り組み案件

自社向けに作った「業務報告書システム」を外販に向けて改修。

弊社ではその月にどんな業務をしたか、そこで何を思ったかなどを業務報告書にまとめて、毎月上長に提出しています。この業務報告書を作成、提出、承認という一連の業務を自社で作成した「業務報告書システム」で行っておりました。

今回はこのシステムを外販するため、サーバーレスアプリケーションとして再構築し、認証機能の追加やメール通知機能の追加やデザインの変更を行いました。

②　規模・期間

案件の規模は下記の通りで、無理せず実施可能である作業量の想定でした。

　案件規模：約2.5人月
　メンバー：６人（リーダー1名、開発担当（若手）5名）
　期間：5カ月（開発担当が1日1時間弱の作業実施）

実際に始まってみると、各メンバーの通常業務が多忙になり作業に従事できなくなったり、未経験の内容で進捗が滞ったり等の課題が発生し、無事完了させる事は出来たもののメンバー間で負荷の偏りが見られ、課題も出てきております。

ただ、課題もありましたがプロジェクトやチームの垣根を越えて結成されたメンバーで、普段業務で関わることのない社員と業務を遂行するという今までにない体験ができ、得るものも多かったのではないかと思います。

【作成システム（一部）】

２．サーバレスアプリケーションとは

サーバレスアプリケーションとは、開発者がサーバを準備せずクラウドサービスを利用して構築されたアプリケーションです。サーバの準備が不要で、メンテナンスしたりする手間がないのがメリットです。

反対にクラウドサービスの仕様や制約に強く依存するところがデメリットになります。今回のギグワークではクラウドサービスとしてＡＷＳを利用しました。

ＡＷＳには様々なサービスがあります。サーバレスアプリケーションを作る際は、それらを組み合わせて構築していきます。今回は以下の構成でした。

３．苦労した点

（１）ギグワーク

業務の大半を在宅で非同期的に行っていたため、メンバーの状況が見えず、作業の遅延に気づくのに時間がかかりました。

チャットでお互いに進捗を確認したり質問しあったりしていて、オンライン会議も月一で行っていたのですが、やはり月一では少なすぎるのかなぁと思いました。今後は、もう少し密にメンバー間で連携をとっていきたいと思います。

また、今回は初めてのギグワークということで働いた時間を残業扱いにしておりましたが、各メンバー共に実際にコーディングした時間は良いが、調査の時間に関してはどこまでが業務でどこまでが自己啓発になるのか悩んでおり、この辺りも改善の必要があると思います。

今後の案件では実働時間ではなく、成果物に対して報酬を設定（社員マスタメンテ画面を製造したら〇〇万円等）と考えていますが、報酬の妥当性や経理処理をどうするのか等、まだまだ考える事が一杯あるなと思っています。

（２）サーバレスアプリケーション

①　覚えることが多い

これは新しい技術なので当たり前ですが、覚えることが多かったです。まずAWSの各サービスを学ぶ必要がありました。

メンバーにAWS 認定Developer Associateの資格を保持している社員がいたため、その社員にAWSの設定や構築を担当してもらいましたが「資格取得のために学んだことを活かせる部分も多くあったが、実際に業務でＡＷＳを触ってみてわからなくて改めて勉強したことがたくさんあった」と言っていました。

弊社では、ＡＷＳパートナーのプレミアティアを目指して社員のＡＷＳ資格取得に取り組んでいるところです。試験勉強ももちろん必要ですが、実際の業務でＡＷＳに触れることも大事だと感じました。

②　セキュリティ問題

OWASPというWebやソフトウェアのセキュリティに関する情報共有や普及啓発をしているコミュニティが、「OWASP Serverless Top 10」というサーバレスアプリケーションが含んでいるセキュリティリスクトップ１０を発表しているように、サーバレスアプリケーションは普通にアプリケーションよりもセキュリティリスクが高いとされています。

また、サーバレスアプリケーションという概念は最近できたものなので、セキュリティを確保するノウハウもまだ普及していません。そんな中で外販に耐えうるセキュリティ性を確保に苦労しました。

サーバレスアプリケーションでは、ステートレスな実装を求められます。そのため基本的には通信の際にトークンと呼ばれる認証情報を、ユーザから受け取りそれが改ざんされていないトークンであれば処理を行う形でセキュリティを担保します。

このトークンを発行したり送ったり改ざんされていないかを調べたりするというのが結構大変でした。今回は、それらを代行してくれるAmazon Cognitoを利用することで認証機能の構築にかかる負担を軽減しました。

しかし、Amazon Cognitoの仕様を理解したりCognitoの機能をシステムに組み込んだりといったところでかなり苦労しました。

そのおかげで、サーバレスアプリケーションにおける認証に関するノウハウを蓄積することができたので、今後どこかでこの知識を活かして、またサーバレスアプリケーションの構築に挑戦したいと思っています。

４．楽しかった点

チームやプロジェクトの垣根を越えてギグワークのメンバーを募集したことで、普段のプロジェクトでは関わらない人と一緒に仕事ができました。他のプロジェクトの良い文化を取り入れるきっかけにもなり通常業務にも良い影響があったと思います。

今回サーバレスアプリケーションやAWSといった普段の業務では触れることのなかった技術に触れて、良い刺激になりました。

AWSの資格を持っているメンバーも「実際に業務で触れて資格取得のために学んだことが活かせたり反対にまだまだ分からないことがたくさん出てきたりして楽しかった。引き続き上級の資格取得に励みたい」と言っていったのでAWSを実際の業務で利用できたことは、資格取得へのモチベーション向上になったと思います。

ギグワークやサーバレスアプリケーションとは直接関係ないですが、今回は外販向けに改修するということでメンバーと話し合って仕様やデザインを決めて取り組みました。普段の業務では自分たちで仕様を考えて決めるということがあまりないため、業務内容的にも新鮮な気持ちで取り組めました。

特にデザインに関しては、２年目の若手社員が熱心に取り組んでくれました。ギグワークがきっかけでUI/UXに興味を持ち現在も社内で開催しているセミナーで勉強中です。どこかでその社員にUI/UXに関する記事を書いてもらおうと思っているので、ご期待ください。

５．今後ギグワークをやる人にアドバイス

①　成果と報酬の関係は明確に

苦労した点でも書きましたが、通常業務であれば勤務時間という客観的な尺度で給料を算出することができますが、ギグワークでは難しいと思います。外注するときと同じように「この画面を作ったら〇〇円」等の明確な設定をしましょう。

②　コミュニケーションは密に

週に一回リモートで会議をするなど、少なくとも会議体はしっかり決めておきましょう。また、リモート会議だけでなくメンバー同士でチャットができるシステムや進捗管理ができるシステムを導入しましょう。

今回我々は、チャットシステムとしてChatOps(https://chatops.jp/)というサービスを利用しました。チャットなのでメールと違って気軽にメッセージを送れる上に、メンバー同士のやりとりが周りからも見られるため今誰が何をしていてどんなことで困っているかが把握できて便利でした。

進捗管理はRedmineで行いました。Redmineは各業務をチケット単位で管理し誰がどのチケットを担当していて、期限はいつまでかがすぐにわかるため便利でした。

また、各チケットについて予定工数と実工数を入力できるため、この画面の製造は報酬として５時間分の残業としたが実際は３時間で出来たり反対に８時間もかかったりなど、各作業の予定と実績の差分を取ることもできるため、今回設定した報酬の妥当性を検証するのに便利でした。

上記以外にも便利なツールはありますので、色々試して結果をフィードバックしてもらえたらなと思います。

③　サーバーレスアプリケーションについて

サーバレスアプリケーションという観点では、やはりまずセキュリティを意識することが大切だと思います。通常のアプリケーション開発であれば各サーバに用意されているフレームワークを利用することで容易にセキュリティを確保できる場合もありますが、サーバレスアプリケーションではそうはいきません。

ＡＷＳにおけるAmazon Cognitoなどクラウドサービスがそういったサービスを提供している場合があるので、まずは利用するクラウドサービスが提供している認証機能の利用を検討してみましょう。

また、性能についても気にする必要があります。サーバレスアプリケーションの性能はベンダーが提供しているサービスに強く影響するため、まずは、今から作るアプリケーションはどの程度の性能を要求されるものか、利用するサービスがどの程度の処理速度を出せるのかを調べましょう。

要求される性能によってはサーバレスアプリケーションでは、実現不可な場合もありますのでその際はサーバの導入も検討しましょう。

今回は、業務報告書システムということであまり応答速度が要求されず処理するデータ量もそこまで多くはないだろうということで、AWSを利用してサーバレスアプリケーションを構築しました。

サーバレスアプリケーションは、銀の弾丸ではなくあくまでも選択肢の一つです。実現したいアプリケーションに応じて最適なアーキテクトを選択していきたいですね。