Google Docs API を使った手順書の自動化

こんにちわ。freee でコアエンジンという金融機関とのデータ連携部分を担当するチームに所属している mine です。 今日は「アウトプット→思考デー」ということで、普段の業務でのちょっとした困り事を解決してみました。

本番作業手順書

freee では本番環境でのオペミスを撲滅するため、本番環境で作業を行う場合は必ず手順書を作成し、事前準備・自己管理を行っています。 この本番作業手順書は作業種類ごとにテンプレートが用意されていて、所定の Google Form から必要事項を記入するとテンプレートを元に最低限必要な情報が埋められた作業手順書が自動で作成される仕組みが既に作られています。

通常の頻度で本番作業を実施する分には何も問題がないのですが、コアエンジンチームでは金融機関とのAPI接続を今後100近くリリースすることになっており、同じようだけどちょっと違う手順書をリリースごとに作成する作業が煩雑になってしまっていました。 そこで、Google Docs API を使って手順書の作成を完全に自動化してしまおうというものです。

Google Docs API とは?

Google スプレッドシートを操作する Google Sheets API は使ったことがある方も多いと思います。 Google Docs API はその名の通り、Google ドキュメントを操作するための API となります。

現時点では API v1 ということで、必要最低限な仕組みだけ用意されている感じです。 リファレンスの Overview を見てもらえばわかりますが、ドキュメントを作成する create コマンド、取得する get コマンド、更新する batchUpdate コマンドだけです。

実際に使ってみる

OAuth での認証については一般的な Google の API と同じですし、create / get コマンドについてはわかりやすいと思いますので、今回は batchUpdate コマンドを使ってみます。

例えば最終的に作りたい手順書が下記のようなものだったとします。

作りたい手順書のスクリーンショット。手順ごとに内容が箇条書きされている。1つめの項目は確認項目がアルファ銀行、ベータ銀行、ベータ銀行(法人)、ガンマ銀行とある
作りたい手順書

ここで、アルファ銀行〜ガンマ銀行まではそのときどきで異なる金融機関が入る上に件数もまちまちだったりします。

  var documentId = 'xxxx'

  var requests = []
  for (var i in banks) {
    requests.push({
      'insertText': {
        'location': {
          'index': startIndex
        },
        'text': banks[i] + '\n',
      }}, {
        'createParagraphBullets': {
          'range': {
            'startIndex': startIndex,
            'endIndex':  endIndex
          },
          'bulletPreset': 'BULLET_DISC_CIRCLE_SQUARE',
        }
      }
    )
  }
  Docs.Documents.batchUpdate({'requests': requests}, documentId)

startIndex の取得にひとくせあったり、 batchUpdate は基本上から順に適用されるため渡す順番を気にしたりと、ありますがプログラムでドキュメントを自動的に作成することができます。

まとめ

リスト以外にもドキュメントで使われるような一通りのものは作成可能です。 Requests  |  Google Docs API  |  Google Developers

また、GAS での実装例が少ないですが以下に公式 (?) のサンプルがあります。 github.com

自動的にドキュメントを生成する機会の多い方は是非試してみてください。Hack Everything★

五反田のランチ事情について考える(2020年版)

おはこんばんちは、ソフトウエアエンジニアの橋本(GitHub: @af12066)です。

「アウトプット→思考デー」にちなんで、この記事では、かつて私が社内のLT大会である「真剣.js」向けに「五反田のランチ事情について考える」というタイトルで話した内容を、公開できる範囲でアウトプットしてみます。「真剣.js」の概要および過去の内容については、以下の記事をご参照ください。

developers.freee.co.jp

developers.freee.co.jp

続きを読む

アウトプットすることの素晴らしさを感じ続けていたいから、今日3月19日は”アウトプット→思考”記念日。

こんにちは。 freeeでICXという社内コミュニケーションデザインをやっているanikiこと関口です。

freeeには、メンバー全員の意思決定や判断の拠り所となる2つの原則と5つの価値基準があり、私はICXの傍ら、その価値基準が社内でも意識し続けられるように様々な部署の人達と一緒に施策を打ったり、実際の意思決定で使われているかどうか調査したりしています。

「freeeはマジ価値を届けきる集団である」「マジ価値2原則『社会の進化を担う責任感』『ムーブメント型チーム』」「マジ価値指針『理想ドリブン』『アウトプット→思考』『Hack Everything★』『あえて共有』『ジブンゴーストバスター』

これら7つの行動指針は2012年の創業からまもなく全員で議論が開始され、議論→決定→見直し→議論→決定…と幾度となくブラッシュアップされてきており、無くなったものや追加されたもの、マージされたものなどいろいろあるのですが、その中でも創成期の頃から存在し、マイナーアップデートはあったものの基本的な考え方は当初から変わっていない価値基準の ひとつに、 「アウトプット→思考」 というものがあります。

まずアウトプットする。そして考え、改善する
まずアウトプットする。そして考え、改善する

今年からfreeeでは、3月19日を「アウトプット→思考デー」として社内の記念日にすることにしました。なぜなら7年前この日は会計freeeがローンチした日だから。freeeとして最初のアウトプットの日。それから数え切れない思考を繰り返し、人事労務freeeや開業freeeなどのプロダクトも誕生しビジネスが拡大。去年末にはマザーズ上場までさせてもらい、今では本当に「なにかのアイデアやパッションがある人がスモールビジネスを始めて、成長させるためのプラットフォーム」になってきています。だから今日をアウトプット→思考の記念日にしたというわけです。

実際何やるの?

社内で記念日と言っても、ただ設定しただけでは何も感じられないですよね。だから今日は全社的に「1時間〜2時間を自由に使って何かをアウトプットしましょう」ということにしています。事前に「どんな理想に対し、どんなアウトプットを目指すか」をフォームで集めていて、現在グループでの取り組みも含めて70件近くのアイデアが集まっています。それを今日どこかで自由に時間設定してもらってアウトプットして→結果を共有しあってフィードバックしあう一日にしています。夜には参加者全員を招待して巨大なオンライン飲み会(今全員リモートですからね)を設定していて、そこでみんなのアウトプットをみて互いにフィードバックしまくる予定です。

アウトプット→思考で新しい職種ができたりする

せっかくの機会なのでここで少し私の話をさせてください。

例えば私が現在取り組んでいるICXというロール、おそらくこれはfreeeが日本で初めて作ったかもしれない「 社内コミュニケーションを専門に設計する人 」という新しい役割なんですが、これが生まれた背景には、自分で言うのもなんですが私の"アウトプット→思考"があったと思っています。

実は私、元々UXとして2014年にfreeeに仲間入りしました。当時まだ20名足らずでその殆どがエンジニアで構成されていたfreeeにUXとして呼ばれ、まだデザインをやる人間が一人もいない中でUXという概念を浸透させ、開発プロセスにUXを組み込む方法を模索したりしながら、同時にUXを採用してチームにしていくということに取り組みました。(懐かしい)

type.jp

それから3年後の2017年、全員野球でUX採用に取り組みUXメンバーも10名を超えたころ、社内にはセールス、マーケ、バックオフィスのメンバーも増え、freeeは総勢200人を越えようとしていたころ…

私は誰よりもこのfreeeという組織の文化的側面にこだわりを持ち、誰よりもよりよく進化させたいと思っているという"自負"みたいなものがあったので、人数が10倍になり、これからもどんどん大きくなる組織の中で如何にしてこの独特な文化をスケールさせていくか悩んでいました。1ヶ月ばかり考えた挙げ句、UXという所謂"生業"を一旦捨て、自分が持っている「体験設計」というスキルを組織開発に活かせないかと思い、各方面に相談しこのInternal Communication & experience(略してICX)というロールにスイッチしようと考えたのがすべての始まりでした。

アウトプットすることで物事の確実性が劇的に上がる

例えばこの話も、一人でうにうに考え続けていても周りのだれにも伝わらないし、理想も共有できない。まず動いて、思いを共有して、自身の専門領域UXを捨ててでも作りたい世界の話をする。そうすることでフィードバックを受け、自分の中にしかなかったものがより洗練され、周りにとってもリアリティが増す。これを繰り返していって、最終的にfreeeという組織が「よっしゃICXやっちゃいなよ」という判断をしてくれた。こんなことがアウトプット→思考の価値なのかなと、自分では思っています。

大きなことも小さなことも、一歩目は同じ

まぁこの話は私自身の人生を変えた話なので若干重いかもしれませんが、みなさんの中にはそれぞれ自分の取り組んでいる事に対する理想は大なり小なりありますよね。それはすでに言語化できて自分やチームで動けているものもあれば、まだ自分の中にしかないものもある。そんな”アナタの理想”をまず手を動かしアウトプットしてみる。そうすることで自分や周りが気づくことがあって、より明確な形になっていく。そんな価値の出し方をみんなしていけたら、freeeも、あなたの周りにも、もっとすごいことが起きそうですよね。

だから、今日3月19日「アウトプット→思考デー」が始まることに、ワクワクしています。

そんなワクワクできるfreeeですが、エンジニアやUXを採用しています。興味ある人は是非ご連絡ください。

jobs.freee.co.jp

freeeのQAの目指す姿-2/3

先に公開した私の考えるfreeeQAの目指す姿に続いて、QAが目指すべきことを実現させるためのfreeeの開発体制について、私が理想だと思っていることを書きます。といっても、書くことは開発体制の中でのQAチームの位置付けについてだけです。

私の理解したfreeeが開発で目指していること

freeeの開発が目指していることは、スピード重視だと理解しています。前回も書きましたが、価値をできるだけ速く届けることがとても大事だからだと思っています。なので、きっと、開発として重要になるのは、スコープを小さくし、スピードを速くすることであり、そのようなことを実現する、例えばマイクロサービスアーキテクチャーへの進化だと思います。開発で考慮しなければならない4つの要素である、スピード、スコープ、コスト、品質をレーダーチャートにするとこんな感じだと思います。

スピード、スコープ、コスト、品質のレーダーチャート。スピードを速く、スコープを小さくしていく

4つの要素を小さくしていくことで、スピードが速くなってきます。

ただ、前回も書いたように、traditionalなQAを続けることで起きてしまうと思われる懸念が、松プランのテストによって、コストだけがバランスを崩すことです。

品質とコストが大きくなっていくレーダーチャート

どこでも起きてること

誤解を恐れず書いてしまいますが、こういう懸念は、スタートアップのITサービス企業がみんな通る道なのではないかと思っています。

  • まずはサービスを立ち上げるために、あまりQAについては考えないで、どんどんプロダクトをアウトプットする。
  • サービスが世の中に受け入れられると、利用者が増えるので品質をちゃんと考えないといけないフェーズに入る。
  • 今まであまり品質について考えてこなかったので、単純にQA=テストになってしまい、traditonalなビッグバンテストを行なってしまう。

ここでなんとかしないと、

  • traditonalなビッグバンテストが常態になり、スピード、スコープ、期間といった他の要因からみてバランスができないほどコストがかかりすぎてしまう。

ってなってしまうかもしれません。QAにかけるコストがテストだけでいっぱいいっぱいなので、アーキテクチャーも泥団子になってしまいます。

古い体質のITは、すでに最終段階の「バランスができないほどコストがかかりすぎてしまう」という局面に入っている開発をしているところもあります。その理由のほとんどはテスト工程でコストがかかりすぎることです。対応策として最初はテスト、そのうちテストだけでなく開発全体でなるべく安い人材に切り替えていくというコストだけ気にして生産性が全くおかしくなる深みにはまっていきます。

現時点から進化していき、理想としてたどり着く、QAと開発の関係の目指す理想像はこう考える! と言うイメージは以下のとおりです。

QAと開発の理想像の図。詳細はこのあと説明される。

左側が、現在の典型的なQAチームとの関係を表していて、右側が目指す理想の姿へ移行していくことを表しています。ただ、このイメージ図だと、想定よりも小さくなってしまって何が書いてあるかわかんないですね(笑)

現時点の体制と期間のイメージ

現時点の部分だけ切り抜いて、再掲します。今から書くことはちょっと極論かもしれず、全部が全部そうではないとは思いますが、典型的な例として捉えてください。

PM1人にエンジニア数人の開発チームと、人数をたくさん抱えるQAチームに分かれている。開発よりもQAに時間がかかったり、開発完了からすぐQAに入れなかったりする問題を抱えている

  • 開発とQAは同じチームではありません。開発から依頼を受けた別チームがQAのためのテストを行います。開発のある中間の時点から入って、品質を保証するために、より安全な方向に傾き、テストをリッチでゴージャスな松プランにする傾向になります。そうなると、開発よりもQAが人数が多くなることがあります。特に、安全第一になるあまりに、変更内容や品質リスクの検討も不十分なままとにかく網羅だけを考えると、常に松プランになってしまうことが多いかもしれないです。
  • そのため、開発よりQAによるテストの期間の方が長くなってしまうといったことがおきることもあるようです。そしてQAへの依頼が殺到すると、テスト担当者の人数が不足して、QA待ちの状態という空白の期間ができてしまいます。
  • もし本当に松プランが必要であり、開発の関係者全員の合意の上での松プランであれば問題ないかもしれませんが、コストは膨らむばかりです。松プランを選ばなくても大丈夫な体質にしていくのが本来論だと思います。

あるべき理想の体制と開発期間イメージ

理想的な将来の方も切り抜いて再掲します。 PM1人にエンジニア数人のチームにQA機能が内包されている。それとは別にSET QAチームが存在し、横断的な支援を行う。自動化されたリグレッションテストで開発とQAは同時に行われる

  • QAへテストを依頼するということはなくなり、開発の中にQAとしてのテストを行うロールを持ちます。QAとしてのテストをする人は、別のテスト専任者がチームにいてもいいですし、開発担当者の誰かがテスト担当者を兼任してもいいと思います。会計、人事労務、申告だと、QAのためのテスト専任者が数名チームにいた方がよいかもしれません。プロダクトの特徴によって臨機応変にしていくんだと思います。
  • 開発期間はこれまでよりも長くなるかもしれませんが、QAを含めたトータルのデリバリー期間としては短くなります。
  • QAと開発の区切りはないので、改めてコミュニケーションを取るための時間を削減することができ、臨機応変に開発チームの意思でQAのためのテストを始められます。
  • 品質はmoving targetです。その時その時で求められるものごとは変わります。QAとしてテストを行うメンバーだけでなく、開発関係者全体がチームとしてそのタイミングで充分だと思える品質を検討して、コストとスコープと開発期間に合わせたテストを行うのが得策です。そんな中、チームが品質リスクを検討し、テストで網羅すべき箇所を限定するのは非常にイマドキなよいやり方です。そしてテストの結果からライクリフードリスクを鑑みてテストを追加するのが良いでしょう。この場合、テストケースをちゃんと書くより、テストチャーターを書いた方が良いです。
  • インパクトリスクだけが大きいテストを人ではなく機械(つまり、自動テスト)にやってもらうことで、QAの期間が短縮します。インパクトリスクだけが高いテストは総じてリグレッションテストにできることが多いです。リグレッションテストを自動化するためにはちゃんとテストケースをかいたほうがよいです。また、リグレッションテストは、リリースとは非同期に常に行うようにすると、さらにQAの期間が短縮します。
  • そのかわり、非同期に行うリグレッションテストで見つかったハッピー(リグレッションハッピー)はgo liveの後でもできるだけ早く修正して本番へデプロイすべきで、このような理想の姿は、速攻デプロイができるかにかかってきます。
  • QAチームやSETが持っていた役割は全て開発チームへ大政奉還し、開発チームが自分たちでQAをするのがうまくできるために、横断的支援をするチームへと変化するべきだと思います。つまり上記したようなテストをしていけるように支援をするということです。また、QAチームは、組織として品質をどう捉えるかを取りまとめる係になり、品質に関する情報集約、分析をして、組織が求める品質のために注力すべきところを特定して改善推進をしていくべきだと思います。そして、開発チームのみんなが自分たちのチームでQAやテスト自動化ができるようになり、他チームからの支援も不要になれば、最終的にはQAだけを専任で行う部署は不要となります。開発者、開発チームが自分たちでQAできるようになるからです。究極はこれを目指したいです。

いきなりジャンプはできない

こんな理想ばかり書いてきましたが、現状から理想のイメージにすぐに変わるのは現実的ではないと思っています。また、いきなり変えると品質確保もままならなくなる可能性もあり、危険です。ただ、freeeには、理想ドリブン と言う素晴らしい言葉がある通り、理想に向けて、さまざまなアクションが必要であり、それを経て到達できるのだと思います。さまざまなアクションにはどんなことがあるか、現時点で思いつくことを次回分として書いていきます。