学生と一緒にFirebaseを学んだ一日
SCRUM FEST OSAKA の興奮が冷めやらぬ翌24日、福井本社のアジャイルスタジオ福井で行われた学生向けのプログラミング体験イベントに参加してきました。普段エンジニアが開発を行っている「まさにその場所」で、実際にプログラミングすることにより、エンジニアという仕事をリアルに体験してもらえたらな、というコンセプトです。
私は、自分の部署の採用面談を担当しているので、参加してくれた学生が応募してくれると嬉しいなぁ、と思いつつも、いち参加者として真面目にFirebaseを触っていたのでした（内容については、下記リンク先も見てみてください）。
※ ちなみに、ESMCというのは、 永和システムマネジメントの魅力を外部発信するための部門横断的な活動で、社内外の人を対象としたイベントを実施したり、広報誌を編集してたりします 。
プログラミング経験のある学生を対象としたイベントは初めてだったのですが、それぞれのスキルに応じた学びを得てくれたみたいで良かったです。何より、みんな楽しそうだった！とても好評だったので、2回目3回目と企画していきます。
おまけ：
SCRUM FEST OSAKA 2019 に参加しました ~ 大阪ラプソディ
プロポーザルには落ちたものの、会社がスポンサーになってくれたおかげでチームのメンバーと一緒に参加することができました。このようなカンファレンスに参加するのは本当に久しぶりのことで、ワクワクです。
Day１：アジャイラー平鍋健児
1日目の最初のセッションは、弊社社長の「野中郁次郎のスクラム〜The New New Product Development Game と知識創造理論と海兵隊」を選択しました。SECIモデルとアジャイルプラクティスの相似、そして、ワイガヤ合宿の重要性等。（ちなみに、The New 「New Product」だってこと、実は初めて知りました・・）
スマホで撮影した野中先生の動画を始めてみたいのですが、妙にライブ感とレア感があり良かったです。私が最近接している経営者・社長とも違う、「アジャイラー平鍋」としての顔を久しぶりに見た気がして嬉しかったかも。
そのあとは自分のワークのネタとして参考にしたいという下心もあり、川口さんのピンポンを使ったワークショップを楽しみ、アジャイルスタジオ福井も「顧客名のカンバン」等で参考にさせてもらっているCI&T、中村さんの「新卒日系ブラジル人がリーン＆アジャイルなメトリクス管理に出会った話」にて基本的な統計の重要性を再確認し、弊社の若手も参加している LED-camp に関する樋口さんの「組込み開発☆合宿イベント「LED-camp」でスクラムやってみた」では、30分でスクラムを教えるための工夫にうなずき、最後は、原田さんの「A little history of Scrum / スクラムのちょっとした歴史のお話」。Japan as No1 時代に生まれた米国の日本への関心を背景としたスクラムのディープでマニアックな歴史の勉強で締めです。
Day2：基調「公」演 ~ 大阪ラプソディ
楽しい懇親会の余韻が残る中、きょんさんと及部さんによるキーノートです。「公」演なので、生演奏のBGMにアンコール、メイキングビデオまで！完璧な演出です。このように書くと奇をてらったと感じられるかもしれませんが、お二人のメッセージはストレートに胸に届く王道でした。それぞれのチームに関する成功、だけではなく、失敗と改善にまつわるエモーショナルなストーリー。
もう一つユニークなのは、このキーノートには演題がなく、参加者がそれぞれで決めること。私は「大阪ラプソディ」と名付けました。ラプソディ（狂詩曲）は「自由奔放な形式で民族的または叙事的な内容を表現した楽曲。異なる曲調をメドレーのようにつなげたり、既成のメロディを引用したりする」楽曲。及部さんから始まりきょんさんにつながる、再演不可能なまさに自由奔放メドレー。確かに勇気と元気受け取りました。
そのあとの根岸さんの「会社組織を丸ごと心理的安全漬けにする方法」も素晴らしかった！最近はやりの心理的安全性についてのある意味究極の形かも。戦略や戦術に先立ってカルチャーを作る。ポイントは徹底的に仕組み化すること。
その後、吉羽さんの「スクラムチームは改善する問題を正しく選んでいますか？」にメンバーと一緒に参加して自分たちのチームはどうだろうか？と議論し、川島さんの「プロダクトマネージャーは、エンジニアリングマネージャーになれるのか」では、もしかして、アジャイルスタジオ福井のディレクターって、エンジニアリングマネージャなのでは？という気付きを得て、オーラスは、椎葉さんの「スクラムフレームワークを使用する具体的な方法。僕の場合。」です。大きな組織の大きな計画の中に、アジャイルを組み入れていったヒストリー。様々な取り組みやフォーメーションを1枚でまとめた手書きのビジュアルがわかりやすく美しかった！
これにて、あっという間の二日間が終了です。次は自分たちが発信できるよう、次回のプロポーザルはもっと頑張る。
イベント全体を通じて流れていた「世界を変えるには自分から」というテーマは、私もずっとそうありたいと思っていることですが、時間が経つにつれ、少しずつゆがんでいくんですよね。今は、整体で矯正してもらったような、すっきりとした気分です。講演者、スタッフ、そして参加者の皆様、ありがとうございました！
地方でのアジャイル開発ビジネス
先日札幌の吉田学園さんで講演する機会をいただき、札幌のIT企業経営者・管理者の方々と交流することができました。ありがとうございます（資料公開します）。
資料は「アジャイルとは」から始まっていますが、参加されていた方はアジャイルについてある程度の前提知識をお持ちでしたので、実際には「地方でアジャイル開発をビジネスにするってどうよ？」的なお話を、福井でリモートアジャイル開発をしている立場からさせていただきました。
資料中に引用しているレポートが古く、日本におけるアジャイルの浸透具合は欧米に比べまだまだ感満載となっていますが、今は相当状況が変わったという実感があります。
何より、アジャイル開発を必要としている会社が増えています。投資欲も引き続き強く、大都市圏でのエンジニア確保の難しさからリモート開発へのニーズは高まっています（クラウドを前提とした開発では、リモートであることの不便さはほとんどなく、お客様から「リモートだからダメ」とのご指摘はありません）。
また、アジャイル開発を実施するうえで我々が問題に感じてきたのは、「アジャイル違い」というか、単に安く早くする手段でのみアジャイル開発を求められる方々への対応ですが、最近は仕事を選べる状況になってきていると感じます。受託における発注者側の理解と学びも深まり、「POとしてどうふるまうと開発が成功するか」を意識されている方が増えている印象です。
今後は、ウォーターフォールで開発してきた製品やサービスを、アジャイルチームによる開発に移行するというニーズがさらに増えそうです。これは簡単なことではありませんが、お客様の理解・協力の下でチームが主体的な改善を続けることで達成できます。ごく簡単ですが、公開した資料でも事例紹介しているので参考になれば幸いです。
GASとCloud SQLのSSL接続
Google Apps Script（GAS）から Google Cloud SQL にSSLで接続する方法に関して、日本語の情報があまりない気がするので簡単にまとめました。
１．Cloud SQL 側でやること
以下マニュアルの手順に従って、次の3つのファイルを準備します。（コンソールから簡単な手順でダウンロードできます）
２．GAS 側でやること
GAS から SSL 接続するためには、１．の手順で取得した3つの認証情報を、getConnection メソッドのパラメータに文字列として渡す必要があります（サンプルコードではコピペしています。ちなみに、コピペに失敗してパラメータが違った場合は、「実行に失敗: サーバー エラーが発生しました。しばらくしてからもう一度試してください。」のエラーが発生するようです）。また、接続時のURLに useSSL=true パラメータを追加することも忘れずに。
もちろん、
に情報あるんですが、説明が簡素過ぎてちょっとわかりにくいんですよね。
Google Apps Script が突然動かなくなったときにすべきこと
今回も、Google Apps Script（GAS) の話題です。GASは手軽なのに、かなり高機能なシステムを組むことができるプログラミング環境です。もし、職場でG Suiteを使っているのであれば、あなたや同僚の仕事を効率化することができるかもしれません。例えば 、Google Calendar の予定を自動手的に登録したり、定例レポートをスプレッドシートに吐き出してチームに自動的に共有するようなタスクが簡単に作成できます。
ただし、重要な業務を担うシステムを組む場合は注意が必要です。テストでバグをすべて解消したとしても、システムが突然動かなくなるリスクが、GCPやオンプレミスで組んだシステムに比べると高いことを知っておく必要があります。
私もこの5年で様々な困った状況にぶち当たりました。そこで、どのように対応をしてきたのか、システム開発を請け負うベンダーとしての立場で、まとめてみます。
GAS はサポート対象外であることを知っておく
まず知っておくべきことは、GAS はサポートを受けられないことです。これは、有償の G Suite 契約者でも受けられません。私も何度か困ったときにGoogleに問い合わせているのですが、答えは「UI から再現できないことはサポート外です」です。以前、CalendarのAPI（CalndarApp）で特定のシチュエーションで通知メールが飛ばない挙動があったのですが、UI から再現できず、サポートを受けることはできませんでした。基本的にGASのAPIでできることはUIでもできる（一部UIでのみ可能なことはある）のですが、サポートを受けられるかどうかは無関係です。
これに関しては、Googleに文句を言ってもどうしようもありません。それに納得してGASを利用する必要がありますし、お客様に対しても、それを納得してご利用いただく必要があります（私たちは、請負開発の契約書で明記しています）。
情報収集（＆提供）は Google の IssueTracker で
Google 側のバグかな？と思ったときの情報ソースとしては、Google Issue Tracker が一番です。GAS に限らず様々なバグ報告や要望が集まっているので、似たようなケースが見つけられることが多いです。
私が体験した中で一番大きかったのは、GAS のJDBCのバグで、「コネクションタイムアウトが常に0になってしまうことで、ほとんどのSQLがエラーになってしまう」問題です。
これも、今だから上記が原因だとわかるわけですが、ユーザーに表示されるエラーメッセージは直感的でなく、まったく見当が付きません。私のところにも複数のお客様から問い合わせがあったのですが、ワークアラウンドすら見つからず、とても苦労した記憶があります。
上記のような派手な問題は、世界中のユーザーからの報告や問い合わせ、改修要望が相次ぐため、比較的見つけやすいです。類似のIssueを見つけたら、手持ちの情報を補足するか、「同じ現象が起きてる！ASAPで対応して！」などのコメントを送りましょう。
お客様へは事実ベースでこまめに報告を
GAS内部で発生した問題は「放っておけばいつか修正される」「こちらでできることが少ない」とはいえ、お客様に対しては事実をこまめに報告すべきです。上記JDBCの問題は解決するのにほぼ1日必要でしたが、その間にお客様には複数回の状況報告を行いました。報告内容も、Issue Tracker から引用します。
- 問題が発生したと思われる日時（報告が上がり始めた日時）
- Google からそれを認識した日時（Google のエンジニアがIssue Tracker 状で問題を認めた日時）
- 問題解決に向けてステータスが更新された日時と内容
ちなみに、以下が実際の報告内容の一部です。
事実ベースであることが肝要です。こちらで対応できることが少ない分、正確な情報を出しつつ、その間に運用回避策を検討します。
βサービスは極力本番では使わない
ここまでは、ある意味Google内部で発生したバグが原因の突発的な事象です。一方、サービス終了に伴う、「予期できるシステム停止」もあります。Google のサービスやAPIは割とスパっと終了します。もちろん猶予期間はありますが、システムで利用していた場合は、それに合わせた改修が必要となります。
例えば、FusionTables 。これは結局βのまま終了が決定し、もうすぐ利用できなくなります。 Realtime API は正式リリースされましたが終了しました。大きなところではGoogle+も終了しますね。
もちろん、サービスの終了は予想できるものではないのですが、せめてβサービスの本番利用は避けるなどの手堅さは持ちましょう。以下、G Suite の最新状況ヘルプページが役に立つことも多いので、こまめにチェックします。
まとめ
当たり前のことなのですが、情報をこまめに収集し、無理な使い方はしない、ということですね。あと、Google Issue Tracker の使い方に慣れておくと良いでしょう（Google へのログインが必要です）。
いろいろ怖そうなこと書きましたが、基本的なサービスのAPIは安定していますし、大きなインパクトのあるサービス終了も1年程度前から予告が入ります。お客様ともGASのメリット・デメリットを共有し、賢く便利に利用していきましょう。
GoogleAppsScript でのシステム構築 ～ 事例とハマりどころ
この5年、一番たくさん書いたのはGoogle Apps Script（GAS)です。一人で使う小さな仕組みから何千人が利用する本格的なシステムまで、たくさん開発しました。Access や ColdFusion からの移行とか、とんでもなく大きなサイズのExcelからスプレッドシートへの移行とか。
GASはネットで手に入る情報も比較的多く、個人でプログラミングをする分には困りません。ただ、本格的なシステムを組もうとすると、ハマりどころも多く、苦戦している人も多いかと思います。
2017年の G Suite ユーザー会で発表した時の資料なのですが、一部見直してアップしました。事例をもとに、典型的なアーキテクチャというかシステムの型を紹介しつつ、それぞれのメリットとデメリット（ハマりどころや限界）をまとめています。
何かお役に立てれば幸いです。GAS （G Suite）関連のご相談も、今はAgile Studio Fukui で受け付けておりますのでどうぞ。
受託開発ビジネスをスクラムで回す
スクラムは要は改善フレームワークであり適用範囲が広く、それを学びプロジェクトで実践するうちに、ソフトウェアの開発だけでなく、部署や会社などの組織的活動にも適用したくなるかと思います。
もちろん、私もその一人で、今日は自分の取り組んでいる活動をご紹介させてします。
活動をサービスとして考える
私は、アジャイルスタジオ福井（ASF）のディレクターという肩書ですが、やっていることはプロダクトオーナー（PO）だと自覚しています。スタジオを立ち上げるまでには、次のようなことをやってきました。
- 名前を決めた（構想段階では「福井アジャイル開発センター」と呼ばれていました）
- 部屋のコンセプトを決めた（「和洋折衷」をコンセプトとした部屋）
- サービスのビジョンやコアバリューを決めた
- 顧客（ターゲット）を想定し、サービスの具体内容（リモートでのアジャイル・クラウド開発）を決めた
- 「ディレクター」という呼び名を決めた（「スタジオ」だから「ディレクター」だよね、という安直さなんですけども）
要は「アジャイルスタジオでの開発サービス」のPOとして、「なぜと何」に注力しているわけです。逆に、働きやすさに直結する机やいすやモニターなどを選ぶことはメンバーの仕事ですし、ビジョンやサービス内容をまとめたパンフレットやランディングページの実装も、それが得意なメンバーや外部の業者さんに任せます。
会社と事業部をステークホルダーとして考える
実は、アジャイルスタジオ福井は組織ではなく、そこに「配属される」ものではありません。シンプルに、「リモートアジャイル開発の作業場所がASFである」にすぎず、私にメンバーを選ぶ権限はありません。メンバーはほぼ全員がITサービス事業部に所属していて、それゆえ、ASFでのビジネスの売り上げも経費もITサービス事業部※につきます。
※ちなみに、私もITサービス事業部の一員であり、ASF立ち上げのタイミングでエンジニア職にシフトしています。それまでは部長という肩書の管理職でした。ASFのPOという役割がこなせているのは、諸々の管理業務が減ったことも大きいです。
このように、ASFは「ITサービス事業部の事業」という位置づけなのですが、根本には、「ビジネスを加速するソフトウェアづくりを、お客様と一緒にアジャイルチームを作ってやりたい。福井でやりたい。」という全社（社長）ミッションがあります。
さらには、「福井でのリモートアジャイル開発」というモデルを浸透させることによって、当社で働きたいというエンジニアを増やすという狙いもあるので、POとしては「働きやすさの実現とアピール」も優先度の高いバックログアイテムになっているのです※。
※ すでに満杯になっているのですが、2月24日に
をASFで開催します。
活動はスプリントで改善
「アジャイルスタジオ福井という部屋」のキャパは16名で、ありがたいことに現時点ではすべて埋まっている状況です。ただし、アジャイル開発に対応できるチームはASF以外にももちろんあり、「リモートアジャイル開発サービスとしてのASF」をもっと広めるためにマーケティング活動をスクラムチームで継続中で、これが今一番力を入れている活動ですね。
このチームのメンバーは、私とマーケティング・営業担当と社長で、私はPOとして重要なステークホルダーである社長の思いをくみ取りつつ、スプリントゴールや優先度を決めています。
スプリントは1週間で、デジタルなカンバンツールを利用しながら、イベントやプロモーションといったタスクにサインアップし、集まって成果をレビューし改善し、というスクラムチームの動きです。
あと、チームの営業担当に、私から直接指示も評価もできないのがミソでだと思っています。彼も私と同じITサービス事業部なのですが、私はあくまでPOでありエンジニアであり、彼の上司ではないのです。彼の個人ミッションや目標は上司である事業部長から与えられていて、それをどう実現するかは彼のマターであり、私は優先度を与えたりアドバイスすることはあれ、直接的に指示することはありません。
いろんな仕事を組み合わせて相乗効果を出す
他にも、見学への対応や外部発信、採用への協力や事業部所属のエンジニアとしての役割などASFのPO役以外の仕事もありますが、今のところ良い相乗効果が出ていると考えています。これらについても紹介したいところなのですが、、長くなってきたのでまたの機会に。
