今時の議事録事情
4月1日、永和システムマネジメントにも7名の新入社員が入社しました。みんなフレッシュで良い刺激になりますね。
うちの場合、これからマナーなど共通的な教育があり、その後、配属先に分かれての教育に切り替わっていくわけなんですが、議事録の書き方を教える機会はないようなので、今時の事情を踏まえつつ、大事な点について、あらためて書いてみたくなりました。
ソフトウェアの現場で昔ながらの議事録を書く機会は減っている？
対面コミュニケーションを重視するアジャイル開発が増えているのが理由なのかどうかわかりませんが、少なくともこの5年間、私は「昔ながらの」議事録を書いていませんし、書かせたこともありません。
「昔ながらの議事録」は概ね以下の内容で、昔はWordとかで書いて参加者にメールで回覧してました。内容的には、単なるメモではなく、目的と結論が大切です。
- 日時
- 場所
- 出席者
- 目的
- 結論
- アクション
- 議論の内容
- 次回予定
今はみんなで議事録を書きながらのミーティングが主流？
じゃあ今はどうしてるのと聞かれると、Google Docs などのコラボレーションツールを活用することで共同編集し、打ち合わせが終わった段階では書き終えているスタイルでしょうか。専用のサービスも増えていますね。
私も、（ツールを使ったコラボレーションに慣れている）社内の仕事ではよく使います。複数の部署が絡んでいて主導権が固まってなかったり、要望がふわふわの状態だけどキックオフが始まっちゃうことって、実は結構あるんですけど、そんな場合は次のようなステップで進めています。
- Googleスライドで最低限のアジェンダを3分で書いて即参加者に共有する
- 集まった目的とかゴールをアジェンダを見ながらレビューというか意識合わせし
- 事実関係をヒアリングしながら最新状況として皆でメモしつつ
- 最低限、「今の課題は何で、次までに何をアクションすべきか」までを皆で認識する
- 打ち合わせ終了予定の5分から10分程度前から、口に出して、「皆さん、次のアクション見えましたか？」「今日のゴールに満足ですか？」など、締めに向けたまとめに入っていく。
こうやって、皆の意識を議事にフォーカスしてもらい、目的達成に向けた課題や手順をクリアにしていきます。コラボツールを使ってみんなで編集することで効率化することでタイムボックス守りつつ、「結論出なかったので次回持ち越しね」を断じて避けるのがポイントです。
コラボで効率よくタイムボックス云々って難しくないです？
ここまで読んだ新入社員の人が「理屈はわかったけど、スピード感もった意識合わせとか課題出しとか、難しくないですか？」といいたくなる気持ちはわかります。うん、多分、難しい。それは、議事録とか打ち合わせ以前に、仕事そのものに対する慣れが必要になるからです。
社会人になると、作業ではなく仕事を期待されます。自分の頭で目的を考えたり課題を発見する必要があるし、もちろん、具体的な行動と成果が期待される。
私は、会議という場には、仕事の要素が濃縮されていると思います。なので、まずは「昔ながら議事録」を身に着けて、仕事のスキルアップの一助にしてみてください。質の高い議事録スキルは仕事をするうえで、とても価値があります。
今でも議事録を書く機会はあります。チャンスがあれば議事録係に手を挙げてください。以下の記事が役に立つと思います。
一括の受託開発でアジャイル
スクラムのコーチとしてトレーニングに参加したりすると、必ず契約の話題になります。（質疑応答で100％でてきます）
- 「うちは一括でしか契約できないのですが、スクラムではどうしますか？」
- 「リリース日を約束しないとなると、契約上の納期に遅れそうな場合どうしますか？」
- 見積もりした結果に利益加算して契約するかと思うのですがスクラムでの契約はどうするんですか？」
などなど。よく言われているように日本のエンジニアは受託開発に従事されている方が多いので、そりゃ質問したくもなるだろうなぁ、とは思います。ただ、身もふたもない言い方をしてしまえば、今のところ答えは「準委任契約ですね」となってしまいます。
もちろん、契約モデルについては様々な試行錯誤がされています。価値創造契約も一つの形ですね。ものすごく細かく（それこそスプリント単位で）請負契約を分割するやり方も実践されています。
ただ、従来のウォーターフォールで慣れ親しんだレガシーな企業の契約形態はそうやすやすと変わることはありません。たとえお客様担当者に理解があったとしても、法務や調達部門の壁を壊すのは、なかなかムズイ。
そこで今日は、私の知る限りで、「一括請負でアジャイルやれているケース」について説明してみます。
ベロシティ実測してリスク取る
まず、ウォーターフォールでもよくある形なのですが、要件定義を準委任でやって、基本設計以降を一括で、というパターンの応用です。
要件定義フェーズで要件定義を行う（要件定義書を書く）のではなく、実際にスプリントを回すことでベロシティを計測し、残りのバックログの開発に関しては、このベロシティを前提とした費用（必要な期間と人数をはじき出す）見積もりを行い、一括での契約を行います（もしくは、プロトタイプ開発を準委任契約範囲で行い、本開発を一括で行います）。
なので、「アジャイル開発に理解はあるが、諸々の事情で一括契約しかできないお客様」にしか使えませんし、当然、開発会社のリスクはなくなりません。一括契約なので事前に要件を洗い出す必要があるため（じゃないと検収できない）、やりたいこと（バックログ）が、安定している必要はあります。
持久戦に持ち込み徐々にアジャイルトランスフォーム
次は、比較的大規模なシステム構築をアジャイル化していくパターンで、いわゆるハイブリッドなアジャイルを経由し、元々ウォーターフォールな開発を、時間をかけてアジャイル化していくことになります。相当根気が必要ですが、実はこれが最も現実的な取り組みです。
当社でこの取り組みをうまく続けているチームを観察すると、いくつかのポイントを見つけることができます。
１．しっかりウォーターフォールを成功させチームを安定化させる
顧客との信頼関係を築くのはもちろん、安定したチームを作るためにも、ウォーターフォール開発を成功させます。この成功体験を持ったメンバーで、徐々にアジャイル化をしていくことになります。正しくウォーターフォールすることでドキュメントも揃うため、業務知識の形式知化も進みます。
2．リリースを3か月から6か月程度にステップ分けする
大規模なシステムの場合、ファーストリリースされた後に追加開発が行われることは多いでしょう。もしくは、最初から「機能ごとに、段階的にリリースしていきましょう」などという提案を行います。それぞれのリリースはすべて一括契約で行うため、これにノーを出すお客様は少ないかと思われます。
もちろん、一括の範囲を狭くすることでリスクを下げることが狙いですが、リリース期間を短く繰り返すことで、アジャイル開発のリズムに慣れてもらうという効果もあります。
3．プロジェクトファシリテーションからスタートし改善の癖付けする
ここから徐々にハイブリッド化させていきます。取り組むプラクティスはふりかえりと朝会からがやりやすく、スクラムマスター候補にファシリテーターを任せたり、スクラムのトレーニングを受けてもらったり、アジャイル開発をしている別プロジェクトのメンバーとの交流も開始します。
ただしこの時点ではウォーターフォール前提のため、タスクはサインアップではなくリーダーによるアサインであったり、報告のためにガントチャートを作成しています。
自己組織化と機能横断的チームについては、次で説明する育成とワンセットで時間をかけて取り組みます。
4．育成には時間をかける
アジャイル化に向けた大きな課題はいわゆるT字型人材の確保・育成です。ウォーターフォール組織の場合、設計とプログラミングで担当が分かれてしまうことになりますが、アジャイルチームでは全員が設計とプログラミング両方できる必要があります。
これを実現するには、エンジニア本人がそうなりたいと思えないと本当にダメで、チームのサポートだけでなく、部署・会社組織としての取り組みが必要です。年間を通じた個人面談や各種勉強会の開催、資格取得に対する支援など、組織としてやれることは多いです。
5．ウォーターフォールの中に本物のアジャイルチーム
メンバーの意識とスキルが整い、お客様の信頼も高めた状態になってから、プランニングやサインアップ、バーンダウンチャートなど、その他のプラクティスを導入していくことで、ウォーターフォールの中に本当のアジャイルチームを作り出すことが可能です。
ちなみに、今回引き合いに出したプロジェクトは、ここにいたるまでに約2年かけています（ただし、「バーンダウンからガントチャートへの変換」は継続中ですが、必要コストとみているようです）。
6．要件定義という名のバックログリファインメント
今でも要件定義は実施しており、要件定義書もしっかり作成します。ただし、今では要件定義作成と開発期間をオーバーラップさせることで、すぐに次のステップの開発に入れるようになってきています。スクラムにおけるバックログのリファインメントとは意味合いは違いますが、そのステップに盛り込みたいストーリーすべてを「Readyの定義Done」にしておくイメージです。
7．お客様にアジャイルの良さをアピールし続ける
こうして時間をかけて実績を積み重ねながら、お客様にはアジャイル開発の意義をご提案というか啓蒙し続けます。 そして実は、時間をかけることのもう一つのメリットは、「世の中が追い付いて偉い人の耳にもアジャイルが届くようになってくる」こと、かもですね。
本当に大事なものは何？
現在はプロセスとしてはハイブリッド状態であり、完全なアジャイル化にはまだ時間がかかると考えています。ただ、安定し、自己組織化されたチームが実現できたことは、何事にも変えられない成果だと考えますし、ゆくゆくは、契約を一括から準委任に切り替えていくことも可能だと思えます。
ずいぶん長くなってしまいました。。いろいろ他にも書きたいことはありますが、もしよろしければ、続きは是非現場に見学に来て、実際のチームにいろいろ質問してください！ということで、宣伝しつつ締めたいと思います。（以下ページに見学申し込みフォームがあります）
企画や講演なんかのネタ作り用テンプレート
企画を手早くまとめたいときや、講演で発表するネタを考えたり整理するときのテンプレートです。スライド1枚に収まります。まずはこのレベルで上司にネゴったり、主催者に確認したり、誰かに意見求めると良いと思います。別段私が思いついたものではありませんが、若いころ企画のプロジェクトをしていたときに沁みついたもので、今でも使えるんじゃないかなと思います。
- 外部要因（経済環境、技術トレンド、競合状況など）
- 内部要因（当社・自分の強みや相手の困りごとなど）
- Why？（外部内部要因をふまえた、相手の嬉しさとか自分のモチベーションをシ一言で）
- What？（内容をシンプルに。展示会なら何を展示するのか）
- How？（どのように伝えるか。講演ならスライド使う／使わないなどのスタイルや演出方法）
- キャッチコピー（企画ならテーマ、講演ならタイトル案）
- 目標（獲得したい具体的なもの。営業の企画ならリード数など）
まとめると、、
「今はこんな時代背景で〇〇に困っている人が多く、一方当社にはこんな強みがある。そこで私たちこそが〇〇のために〇〇すべきだ！なので、こんなものを、こんな方法で作りたいのです。キャッチコピーは〇〇！この企画通してくれたら、〇〇を得ることができますよ」
といった感じでしょうか。
一通り書き終えたら、セルフチェックをしてみましょう。
- かけがえのなさはあるか？自社（自分）以外に置き換えられるようでは刺さりません。
- 時代性はあるか？今この時代・時期・このイベントだからこそ企画したり語りたい内容になっているか。
- エレベータピッチできるか？「要は〇〇ですね」と偉い人に5~10秒程度に圧縮して話せるか。
チェックにパスしたら、周りにいる有識者に意見求めて洗練させていきましょう！
学生と一緒に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 パラメータを追加することも忘れずに。
もちろん、
に情報あるんですが、説明が簡素過ぎてちょっとわかりにくいんですよね。
