Regional Scrum Gathering Tokyo 2024 Day2, Day3 参加記録
こんにちはswampです。
今年もRegional Scrum Gathering Tokyo 2024 に参加してきました。アジャイルマインドあふれる空間で色々な方とお話しできてとても楽しかったです。
3部構成で私がRSGT2023に参加した感想と私が聴講した各セッションの簡単なレポートをお届けできればと思います。
- Regional Scrum Gathering Tokyo 2024 Day1 参加記録
- Regional Scrum Gathering Tokyo 2024 Day2, Day3 参加記録 (この記事)
- Regional Scrum Gathering Tokyo 2024 に参加してきた話 (全体の感想まとめ、近日執筆予定)
今回はDay2, Day3で聴講したセッションのまとめや感想をお届けします。
目次
- 目次
- Solving The Value Equation
- ビジネスとチームと組織が自律的に連携と成長するフレームワーク
- 約30年の時を超えたデザインパターンの価値 -現代のスクラムチームの開発者がGoFのデザインパターンを学び直し得たもの-
- 激録・開発密着10ヶ月!!〜消えたスプリントゴールの行方〜
- みんなでギャザってふりかえりカタログを作ろう!~おすすめ手法、体験談、みんなで集めよう!~
- Quality and Attractive Quality Creation Learning from the Kano Model - Kano Modelと魅力品質理論
Solving The Value Equation
ざっくりとしたまとめ
「価値」にフォーカスしたお話でした。まだまだ知識不足で正直理解できていない部分が多いので私のメモをもとにNotion AIさんに要約してもらいました。(違いそうだなと思う部分は修正していますが、私自身が間違った解釈をしていたら申し訳ありません…)
Notion AIによる要約(一部改変)
価値の創造については、開発者の生産性を測定するだけでは不十分(価値や生産性を計測することが目的になってしまうと悪い副次効果がでてしまう)で、生産性はチーム全体から生まれるという考えが重要です。 価値の種類には顧客、ビジネス、技術、社会/倫理、イノベーション/学習、ROIなどがあり、これらを組み合わせて価値を最大化することが求められます。価値の最大化には顧客とのアライアンスを取ることや距離の近さという観点も重要です。 また、価値創造のためには、制約とうまく付き合う必要があり、それぞれの会社のカルチャーや外圧によって新たなビジネスが生まれることも考慮しなければなりません。 最終的には、価値創造のための新たな価値を生み出すことを意識し、それらの相乗効果を見つけ、持続的な成長を実現するための価値のはしごを作ることが重要です。
感想
価値創造のための新たな価値を生み出すことと言う中で、真にイノベーションを起こすには、お客様の満足を一番の課題に考えるのではなく、価値をどのように作るか。新たな価値を生み出すことを意識するということをおっしゃっていて印象に残りました。例えばAmazonはECの会社だったがクラウドコンピューティングという新たな価値を生み出しています。
最後の質問では、プログラマーとして課題解決に向き合うときは、どういう背景が存在しているのかよく調べて学ぶことで、よりよい問題解決手法を目指すことができる。技術的な能力を伸ばすことも必要だけど他の業界のことも知ったほうがよい。好奇心をもって問題解決をするんだという意識を開発者としても持っておくとよさそうといったことをおっしゃっており、プロダクトやプロジェクトにかかわる全員が好奇心を持ち、全力で関わることが重要そうだと感じました。
全体的に、価値って何って考えさせられる内容でした。価値を指標にするのではなくて、価値を生み出していく過程やそれをはしご的に繰り返していくことが継続的なイノベーションに重要だと強く思いました。
ビジネスとチームと組織が自律的に連携と成長するフレームワーク
感想
これからヒト・モノ・カネ・エネルギーがどんどん少なくなっていく枯渇先進国日本の中では、少ないリソースで社会貢献していかなければならないという話は目から鱗でした。
これから各領域の専門家を雇って分業でやっていくのは困難な時代になってくるので、プロダクトに関わるどのような立場であっても、どう売るのかなどのビジネス的な観点や指標を持つことは非常に重要だと感じました。
ビジネスサイドの方と仕事をすることも最近増えてきましたがどうしても開発と言う側面で考えてしまっている部分は多いので、常に全体を見たプロダクト開発というものを意識していきたいです。自分たちでも工夫しながらどういったプロセスや手法を使えばそれが実現できるのか考えていきたいです。
約30年の時を超えたデザインパターンの価値 -現代のスクラムチームの開発者がGoFのデザインパターンを学び直し得たもの-
感想
CSD研修(認定スクラムデベロッパー研修)で研修の半分がデザインパターンの様々な問いから理解を問われるという内容だったことでその価値を実感し、GoFのデザインパターンを学ぶ直す過程を発表いただきました。
効果的な学び方として以下のことが紹介されていました。
- 似ているパターンを比較する
- さまざまな設計原則の適応方法を学ぶ
- 同じパターンの異なる実装例を学ぶ
- パターンを適応していく過程を学ぶ
- 自分の理解を人に説明する
特に自分の理解を人に説明する(なんでもいいのでアウトプットしてみる)という部分は、技術を自分のものにしていく中で非常に重要だと思いました。
物事の本質を多角的な観点から深く学んでいくというのは、たとえ世の中から古いと言われている技術でも大事なことなのだなあと感じています。僕もGoFのデザインパターンを学んでみたくなりました。
激録・開発密着10ヶ月!!〜消えたスプリントゴールの行方〜
感想
スプリントゴールが消えていた状態から意味のあるものに進化させていく過程をお聞きできて非常に有益でした。 私のチームでもスプリントゴールは一応決めていましたが、タスクがそのままゴールとなっていて、意味のあるスプリントゴールとは言えないものでうっとなりました。 チームメンバー、ステークホルダーが1つの方向を向けるスプリントゴールを工夫して作っていくこと、それをプロダクトのコミットのために活用していくことが非常に重要だと感じました。 自分のチームにもあうような意味のあるスプリントゴールが作れるようにしていきたい。
みんなでギャザってふりかえりカタログを作ろう!~おすすめ手法、体験談、みんなで集めよう!~
感想
コミュニティ版のふりかえりカタログをみんなで見て、気になるところは周りの人と話しながらどんな思い出を書いたり好きな手法に投票したりしてました。 ふりかえりカタログにはいつもお世話になっているので改めてみることができて良かったです。
Quality and Attractive Quality Creation Learning from the Kano Model - Kano Modelと魅力品質理論
ざっくりとしたまとめ
- 漢字はアルファベットと比較するものではない。単語と比較するもの。
- ImportantはImport(輸入したもの、舶来品)から来ている → そこから転じて大事なもの
- 漢字の「質」の字源に学ぶ「品質」の意味
- 「斤(おの)」は重さの単位。2つの「斤」があるからバランスが取れる(価値として釣り合っているという意味もあるらしい)
- 「貝」はお金の単位。貨幣
- モノを載せてどこで「貝」(お金)と釣り合うのか
- 意訳:金銭の対価としてバランスが取れるモノが質が安定しているとか良いものってこと?
- 「質屋」、「人質」→品質につながる
- 競合優位としての品質の歴史的変化(品質の3レベル)
- 自動車を例にすると
- 昔はエンストが多かった(自動車を動かす基本的な機能が不足)→ 窓の開閉ができない(客からの要求に応えられていない)→長距離運転(しょっちゅう路肩に車を止めてルートを確認する→それは車の問題と考えられていなかったが、ナビの登場で顧客歓喜)
- 顧客歓喜だけを追求してもダメ。顧客苦情解決や顧客満足は前提となる。
- 品質についての狩野さんの疑問
- 子供のころの品質の思い出
- B: すぐに壊れる玩具 → 「良い品質とは壊れにくいもの」という期待をもって育つ
- 大学での講義(石川馨教授)
- A: 「消費者を満足させる品質」を学ぶ
- Bは石川先生が説くAに対して必要であるが十分ではない。
- 「不満をもたらす品質と満足を与える品質は異なるのではないか」と考え始める
- 子供のころの品質の思い出
- ハーズバーグ理論
- アリストテレスの品質論
- 品質とは、ある事物に関して、2つの品種が存在する時、その種差を指す。
- Q: ソフトウェアを扱う以上、品質統制、品質管理、魅力品質創造の境目があいまいじゃない?
- A: 品質のライフサイクル。リモコン=出てきたときは魅力品質、今では当たり前品質だけで10年かかった。
- 携帯電話で色々な機能が付いたのは早かった。数か月
- 何か月を追いかけるのか?年単位で追いかけるのか?基礎研究、応用研究?どの辺の滞留期間を設けていく?感性の問題で変わってくる。
- 物の品質とは何かを考えることは、ものをどう認識するかと密接に関わってくる
- Primary Quality:客観的に明らか(横軸、物理的充足状況)
- Secondly Quality:感覚的なもの(縦軸、使用者の満足感)
- 品質の変化
- 魅力的品質が時間によって当たり前品質に
- 品質のライフサイクルについて学生の理解度が悪かった。
- 学生が理解できないのは教える側が悪い。
- 「MaryとJohnの物語」(恋に例えることで理解力向上)
- Q:某メーカー品質本部の方。論文のまとめに、「製品企画の方向性を明確にできる」とあった。会社でも価値の高いプロダクトの企画をしたいが、企画段階で品質を計画していこうという流れになっている。方向性を明確にするというのは何をどれくらい決めていくものなのか?
- A:魅力品質は認識論の話。私個人はエンジニアで、そのスピリットを叩き込まれている。何か新しいものを作る時に魅力品質のあるものを当然作りたい。
- コニカ:1960年代まではトップカメラメーカーだったが、1960年代にブームにうまく乗れなかった。
- カメラについては色々とインタビューしているが撮影については聞いていない。
- 撮影者、どういう撮影をするのかをインタビューすればいいのでは?
- 顧客の写真について調べるとピンボケと露出不足が発覚→カメラの問題ではなく撮影者の不注意だった。
- 撮影者の体験をよくするために、フラッシュ内蔵やピンボケ補正しなければ
- 魅力品質が出ると大喜びする。でもこれからやっても他社もやっているので競争に追いつけない。
- 無関心品質に着目することが大事。無関心から新しいイノベーションを生み出すべき
- 潜在的要求の発見が魅力品質創造につながる
- Q: 逆品質から魅力的品質に切り替わるターニングポイントは?
- A: 新製品は5年で打ち切って成功したものはない。投資を続けなければならない。単に技術屋に何かやれというだけではだめ。
- Q: 長く魅力的品質を持っているところは、ブランドも関連しているのではないか。魅力的品質とブランドの関係を教えてほしい。
- ブランドはそのメーカーから出荷された製品を使用した多くのユーザから得られた評判の累積
- ブランドは変わる。Made in Japanは1970年代ぐらいまでは粗悪品。今はMade in Japanはいいと思っている。昔は粗悪品の代名詞だった。
- ブランド力 = ブランド力 + 営業力+製品価値 + [ブランド方針]
- 今年の努力によってリカーシブルに増えていく
感想
品質とは何かということを「質」の語源から知ることができて、今まで聞いたこともない話だったので大変興味深く引き付けられました。 狩野モデルについては何となくこんなグラフがあるかぐらいは知っていましたが、内容についてあまり把握できていなかったですが、無関心品質、魅力的品質、一元的品質、当たり前品質のそれぞれの品質について納得できる内容でした。 一言に品質と言っても奥が深く、何を観点としていくのか、何を目指していくのかで観点も変わるのかなと思いました。 新たなイノベーションを生み出すためにはユーザが無関心であることに目を付けて魅力的品質を見つけていかなければならないという部分はなるほどなと感じました。よりユーザに対してインタビューや観察をすることにより潜在的要求の発見し、魅力的品質を創ることを目指していかないといけないなと思いました。そのうえで日頃の開発でも前提となる品質を担保していくことが大事だなと思いました。
Regional Scrum Gathering Tokyo 2024 Day1 参加記録
こんにちはswampです。
今年もRegional Scrum Gathering Tokyo 2024 に参加してきました。アジャイルマインドあふれる空間で色々な方とお話しできてとても楽しかったです。
3部構成で私がRSGT2023に参加した感想と私が聴講した各セッションの簡単なレポートをお届けできればと思います。
- Regional Scrum Gathering Tokyo 2024 Day1 参加記録 (この記事)
- Regional Scrum Gathering Tokyo 2024 Day2, Day3 参加記録 (近日執筆予定)
- Regional Scrum Gathering Tokyo 2024 に参加してきた話 (全体の感想まとめ、近日執筆予定)
今回はDay1で聴講したセッションのまとめや感想をお届けします。
目次
- 目次
- Dynamic Reteaming, The Art and Wisdom of Changing Teams
- Badプラクティスを選んで失敗しながら進めた新規プロダクト開発
- 【あなたにとって】全員正解クイズ〜相手の価値観を引き出す方法〜【スクラムとは?】
- 証券取引所のサービスをアジャイルに開発し続ける上での学びと取り組み〜信頼性とアジリティの両立を目指して〜
- 仮説→実験→検証→学び...プロダクト開発を前に進めるためにMobius Outcome Deliveryを学び、実践していること
- ベロシティ Deep Dive
- エンジニア組織の経営論 〜エモい開発と売上数字は両立するか〜
- Day2, Day3に続く...
Dynamic Reteaming, The Art and Wisdom of Changing Teams
ざっくりとしたまとめ
Dynamic Reteamingに関する話でした。
- 時間がたっても同じチームを維持できるのであれば素晴らしい成果が出るかもしれないが、現実Reteamは頻繁に起こる。
- なぜチームが変わる?
- 成長
- 新しい仕事が生まれる
- ナレッジ共有(冗長性があるなど)
- 新しいもの事を学ぶ
- 衝撃的な出来事(Surprise reasons)
- 新しいリーダーを連れてくるなど
- Dynamic Reteamingの5パターン
- One by One(誰かが入社した、退社した)
- オンボーディング、オフボーディングのサポート
- Work in Pairs(2人で作業することで組織への帰属意識をもたらせることができる。1人ではないのだという形、オンボーディングの効果的)
- Market of Skills Activity
- 自分の自己紹介的なもの(Skill、Hobbies、何学ぶなど)を作って関係性を構築しなおす。お互いの違いを認識できる
- Grow and Split(成長して分割する)
- Merging
- 複数のチームが1つになっていく
- Story of our team activity
- これまでの歴史を共有するために何ができるのか。個人個人が順番に並べる。そのチームに参加した日時と時間を書く。
- どんなことを達成したのかをチームで共有する。
- Lsolation(隔離)
- チームの脇に作る。他のチームと違う仕事をする自由を与える。
- 緊急の問題を解決するため、本番でインシデントがあったら隔離されたチームを作る、新しいプロダクトを作るためになど
- 他チームと隔離されていると集中できる。他チームと同じルールを守る必要がない。
- プロセスの自由を与えることが大事。ただし、何をやっているのかを共有することは大事
- サイロ化は必ずしも悪ではない。
- Switching
- One By Oneと似ているが、知識を広げることややりがいを求めるなどで意図的に人をSwitchingする。
- 知識の重複を共有する。
- 別チームを試すことができるようなプログラムもある。
- One by One(誰かが入社した、退社した)
- リーダーは忍耐を持つことが重要、ただ指示することはできることはできるかもしれないけど変化に皆にオーナーシップを持たせることも必要。オープンにリチーミングすることも重要
- チームをまたぐコミュニティを作ることも大事。リチーミングされたときも初対面ではないというのはハードルが低くなる。
- リチーミングは人のレイヤーにフォーカスして実施することが重要
感想
Reteaingが起こった時にどのように、それぞれの種類ごとに、どのようなパターンでどう振舞っていけばよいのかという部分について知れて勉強になりました。
仕方ない時もあれば、戦略的にReteamingすることもあるのかなと思いますが、普段から横のつながりを持って相互理解をして仕事をしていくことがいざReteamingとなったときも重要なのだと感じました。
QAの中でエンジニア側はスクラムのアジャイルの編成が取れているが、ビジネスサイドは中々チーム編成していくべきかという質問があり、回答として、エンジニアが、ビジネスから遠ざかった形で仕事をしている可能性はあり、ビジネスサイドがどのようなプレッシャーを感じているのか、どうやったらビジネスサイドが成功を収められるかを知り、共感を持ち、団結して手柄を作ることが重要と話されており、印象的でした。 自分たちの考え方を押し付けて、勝手に落胆するのではなく、寄り添って共感を持つこと、互いに相互理解をすることは今後、働いていく中で重要にしたいなと思います。
Badプラクティスを選んで失敗しながら進めた新規プロダクト開発
ざっくりとしたまとめ
- 新規開発では分かっていないことがたくさんあり、開発中にも新しい情報がたくさん入ってくる。前もって決めてもうまくいかないから、Readyを待たない、見積りをしないことで、「分かっていないこと」を解決しながら「新しい情報」にも素早く対応
- 役だったのは全体マップ
- 全体像を把握できたことで、初期の段階からMVPを削ることができた
- チーム作り
- 「良いチームが良いプロダクトを作る」を体現するドリームチーム→技術力×顧客価値
- 初期開発では開発コストを抑えることが重要。むやみに人を入れてオンボーディングコスト、日常のコミュニケーションコストなどを増やさない
- スクラムマスターとして
- チームの置かれた状況に応じてチームの動きを変化させていく
- Readyを待たない・見積りをしない
- 分かっていないことが多かったけど、調査しながら並行して実行
- 新しい情報にも対応しつつ一番早い方法で土台構築
- スプリント内でタスクが終わらない
- タスクを1つずつ終わらせることに重きを置く。毎日のデイリースクラムで今日何をやるべきかを毎朝プランニング
- スプリントと言う区切りよりも今日何をすべきかを大事にした。
- 仕掛中のユーザーストーリーがたくさんあった
- バックエンド開発は2回実装した。
- 実現可能性を早い段階でチェック、全体を見ながら本番レベルの実装ができた
- 進める中で一番意識したこと
- 毎週のスプリントレビューで「動くもの」を見せること!
- 毎週チームで全体マップで現在地を確認できた
- 早い段階でステークホルダーにモックを見せることで早い段階で方針転換
- 再計画
- 計画が常に正しいわけではない
- 現状の延長戦でゴールを考える
- スケジュール見直しは大胆に1回で
- スケジュールの見直しは何度もやるもんじゃない。
- 計画づくりに時間がかかる
- ステークホルダーへの説明コスト
- スケジュールの見直しは何度もやるもんじゃない。
- スケジュールの見直しに必要な条件
- やらなければいけないことが全て洗い出せているか。
- チームのベロシティが安定しているか。
- チームの危機感は十分に上がっているか。
- 再計画づくり
- 全体マップを眺めながら、ストーリーの洗い出し・確認
- 三点見積法(楽観値、最頻値、悲観値)により、機能開発の着地点を算出
- リリース準備期間も含めて1か月のバッファを取る
- リリース予定日の肌間のすりあわせ
- ステークホルダーへの説明
感想
今後、新規開発に携わる可能性もあり、興味深く拝聴しました。
プロダクトの全体像を俯瞰してみることができる全体マップはとても有用そうに感じたので、是非取り入れてみたいです。
Badプラクティスと呼ばれている手法を使ったとしても、毎週のスプリントレビューで「動くもの」を見せることができている点が非常に重要な点であると感じました。やはり動くものができればステークホルダーが開発チームに信頼感を持てるポイントではないかと思います。
一方で、経験、技術力、コミュニケーション能力が高い開発者が2人が集まったことが功を奏している部分も感じました。自組織では、自分も含め若いエンジニアが大半なのでこの講演の内容をどう応用していけるかは考えていかないとなと感じました。
【あなたにとって】全員正解クイズ〜相手の価値観を引き出す方法〜【スクラムとは?】
感想
質問する人が「これは全員正解クイズです。何を答えても間違いではないです」と相手にしっかりと伝えましょう。回答者が答えたら「正解!!!」と言うということで価値観を引き出す全員正解クイズの紹介でした。
「あなたにとってスクラムとは?」という一見答えずらい問いについて、必ず「正解!!!」とすることによって心理的負荷を下げた状態での質問は、実際に答えてみて確かに答えやすいなと感じました。
人それぞれの価値観を測るような質問をする場合には使ってみたいです。
証券取引所のサービスをアジャイルに開発し続ける上での学びと取り組み〜信頼性とアジリティの両立を目指して〜
ざっくりとしたまとめ
高い信頼性が必要な機関投資家向けのサービス開発(受託開発)で試行錯誤しながら開発を進めていったケースの講演
未知のユーザへのサービス提供のため適切な要件が分からないという課題感の解決のため、リーンスタットアップアジャイル開発を採用
リーンスタートアップアジャイル開発は、ユーザに対する仮説検証をくりかえしながらアジリティをもってプロダクトを開発し続けるリーンXPをバランスチームの中で実践すること。
これを実現するために、価値探索と価値検証のサイクルを経てニーズが確認できたものから開発するユーザ中心設計や重視すること。受託開発ではあるが、受託元の企業のメンバーも開発チームに入ることで、会社の垣根なくフラットな関係性で頻繁なコラボレーションを行うことを重視されている
以下のような学びがあった
- 信頼性とアジリティの両立
- ユーザにとって意図しない取引が発生することがこのプロダクトで最も防ぎたいこと
- それをチームの共通認識として持ち、品質担保の活動を絶対に守るべき部分に部分的に強化して手厚く実施している
- 部分的な強化をすることでアジリティを確保した品質保証の取り組みを実施している
- 大規模開発への対応
- 大きな機能に集中して長期間新規リリースができなかった経験から、大きな機能と並行して小さな機能をリリースし続けることが重要と認識した。
- そのために、FeatureブランチからFeatureフラグに変更、UX改善につながる小さなストーリーを毎月リリースするなどの工夫をした。
- 小さな機能でもユーザに価値を提供し続けることで営業やリサーチのきっかけにもつながった。
- チームイベントの継続的な改善
- チームメンバーの変化などでチームイベントに対する考え方が変わることでレトロスペクティブなどが形骸化するなどの影響
- 定期的にイベント自体を振り返る活動をすることで、プロダクトやチームを取り巻く環境の変化に適応することができた
感想
受託開発かつ品質や信頼性を強く要求されるプロダクトにおけるアジャイル開発の一例で印象に残りました。そのような状況の中でも信頼性の向上やユーザに価値を提供し続けること、アジャイルやスクラム自体の改善を両立して進めることができるのは強みだと感じました。リサーチを通してユーザ価値検証を実施している点や顧客と同じ空間で協調しながら進められて点は羨ましかったです。品質に関しては自分のプロジェクトでも課題になっているので、発表にあったような品質担保活動は参考にしたいです。
仮説→実験→検証→学び...プロダクト開発を前に進めるためにMobius Outcome Deliveryを学び、実践していること
感想
Mobius Navigator 初めて知りました。
普段やっている開発が、点になってつながっていないのではないか、学びを将来に生かせられていないのではないか、どこがボトルネックになっているのかが特定できていない、やったことがチーム内に閉じていて知見をチーム間で活かせていないのではないかという問いには心当たりも大きかったです。Mobius Navigatorもう少し自分でも学習して取り入れられるところからはじめてみたい。
ただフレームワークを取り入れるだけでなく、「仲間とやること」、「細かく検査と適応すること」、「やってもらうのではなく一緒にやること」を意識されていることは、どんな施策を実施するにしても意識が必要ではないかと強く感じました。
ベロシティ Deep Dive
感想
ベロシティを生産性の指標にしたり、報告したり、評価に使ったりするのは無意味。あくまでスクラムチームのために使うものだということが強く伝わってくる講演でした。
私自身も生産性と言う軸で見ていたり、数字の上下に一喜一憂したり、目標ベロシティを設定して、届いていないことを問題とみなしていたような気もするので反省しなければなと感じました。
そもそも、アジャイルやスクラムが目指すのはプロダクトの生み出す価値(アウトカムやインパクト)であるため、「付加価値生産性」を重視する必要である。ベロシティという物的生産性が高いだけでは意味がないということは、うまく言語化できていない部分だったのでなるほどなと感じました。
ベロシティというプロダクトの価値を生まない数字を作るよりも、プロダクトの価値を最大化することがアジャイル/スクラムの本質ということを意識してうまくベロシティを使ってチーム自身の予測と改善に役立てていきたいです。
エンジニア組織の経営論 〜エモい開発と売上数字は両立するか〜
ざっくりとしたまとめ
- お金や資本 VS ヒトやチームを取り上げる
- 「超一流」の研究 (Ecpert on Experts)
- 天賦の才能はない
- 共通していること
- 10000時間以上、夢中で没頭している
- 限界的練習を続けている
- 新しい方式を学ぶ続けフィードバックを受けている
- 一流エンジニア組織に必要な環境を整えることが経営
- 「夢中」の研究(エモさ)
- 長期にわたって活躍できる人は、内発的動機が強くシンプルな人
- 夢中だからエモく没頭する!没頭するから上達する
- 夢中でエモいやつの特徴
- 外発的動機を長期的に凌ぐ
- 圧倒的な没頭力で熟達する
- ココロが健康、幸せ
- 内発的動機同士惹きつけあう
- 報酬の研究
- アンダーマイニング効果
- 報酬で釣りすぎると内発的動機が毀損する。
- 自発的に行っていた行為に報酬を与え続けると、仕事の目的がやりがいから報酬になる
- エンハンシング効果
- 機械的なルーチン作業にきわめて有効。報酬の1回目は有効
- アンダーマイニング効果
- お金や資本で支配した気になっている経営陣が言う「報酬制度」ってエモさを壊しかねない劇薬!「会社は伸びるが現場は不幸」なのが過去のダサい経営
- 夢中な人の最高な報酬はエモい仲間と価値ある仕事。そして自身の成長!
- 成長の研究
- 記憶力と年齢の関係
- 「夢中」を維持すれば何歳でも成長できる!新技術もビジネスもマスターできる
- 勉強方法の研究
- アウトプットすることが最も重要
- フルスイングを技術を社会実装する。ビジネス側に全力で投げ込む
- 外とのつながり「外部」へ発信する。異なる人へのアウトプット+フィードバック
- 良質なアウトプットがエモさを維持する。エモさ最高
- ビジネス側はお金が全てなの?
- ビジネス側とは数字ばかり聞くから、お金の話になってしまう。
- 外発的動機っぽい匂いがする
- ビジネス側にもエモい事を聞こう!
- 何が好きですか、どれだけ好きですか?
- デジタルビジネスの先にエモい「魂」がある
- オタク同士感動できる。ビジネス側ともエモくつながれる。どちらも本気で真剣!!
- 技術屋はビジネスサイドに合わせすぎ。エモさを共有することが必要
- エモいエンジニア組織の経営:カネ中心からヒト中心にシフトする!!!
- 資本市場を意識せず、内発的動機を邪魔させない環境を撤廃、売り上げ目標撤廃、営業組織廃止、顧客満足絶対、エモい仕事のみ受注する…
- ヒトも売り上げ/利益も着実に上がる
- エンジニアこそがビジネス側に飛び込もう!
- スクラムマスター的な人はここのかけわたしをする
- 数字に従属せずに本気にエモく生きよう!
感想
エモい発表で自分も頑張らなきゃなと思う発表でした。
超一流、夢中、報酬、勉強方法、成長のそれぞれの研究結果をもとにエンジニア組織を経営していくための理論を探求されており非常に興味深かったです。
特に印象に残ったのはエビングハウスの忘却曲線が20代と60代で大して変わらないということです。結局は何歳になっても夢中を維持することができれば新しいことに挑戦して成長できるのかと思いました。
最近、ただ漫然と仕事や生活をこなしていて、夢中になって本気で何かをするという機会は少なくなってきている実感があります。ビジネス側の人とも強調して、もっと夢中で本気にプロダクト、プロジェクトに向き合って成長していきたいと感じました。ワクワクして生活、仕事していきたい!
そのためには色々なことに興味をもって勉強することも大事です。それだけではなくまずは、RSGTのブログを書くなど何でもいいからアウトプットして自分のものにしてフィードバックを受けることから始めていきたいです。
Day2, Day3に続く...
Regional Scrum Gathering℠ Tokyo 2023に初参加した話
こんにちは。swampです。(このブログもずいぶん放置していました。)
記事を書くのが随分遅くなってしまいましたが、2023年1月11日~13日に開催された『Regional Scrum Gathering℠ Tokyo 2023』(以下RSGT2023)に初参加しました。アジャイルマインドあふれた空間でとても楽しかったです。
この記事では、私がRSGT2023に参加した感想と私が聴講した各セッションの簡単なレポートをお届けできればと思います。
目次
- 目次
- 全体的な感想
- Five Practices for Building Software with Scrum
- 三歩進んで二歩下がるスクラム〜一歩ずつ変化する開発組織〜
- Effective Retrospective++~楽しいだけじゃない、次の一歩を自分で踏み出し続けられるふりかえりへ~
- スプリントレビュー Deep Live
- どうすれば新しいアイデアが生まれるのか
- The Agilists’ Emerging Superpower and Our Planetary Challenge
- ログの書き方がチームの生産性を爆上げする話
- 自治体DXにアジャイルなマインドとスキルはどれほど役立つのか
- 「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法
- The Stable Team - 機能する安定したチームをつくる -
- なぜ変化を起こすのが難しいのか? - 数年以上に渡って難しさに向き合い考え取り組んできたこと / The reason why changing organization is so hard - What I thought and faced for more than several years
- 最後に
全体的な感想
各セッションのレポートはとても長くなりそうなので、先に全体的な感想を書いておきます。 今回初めてRSGT2023に初参加させていただきました。オフラインで数百人超の大型カンファレンスに参加するのも久しぶりで前日から非常にワクワクしていました。どのセッションも大変勉強になるものばかりで、明日から業務に生かしたいと思えるものも複数ありました。また、普段社外でスクラム開発を実践している方とお話する機会はないので、色々な方とコミュニケーションをとれて楽しく学びになりました。
初参加なので知り合いがいるわけでもなく、楽しめるかなと少し不安でしたが、オープニングでPACMAN Ruleが紹介されるなど初めての人にもウェルカムな雰囲気を感じました。 実際に1日目のランチを一人で食べていたときに話しかけてくださった方がいらっしゃり楽しく様々なお話をすることができました。 また、スポンサーブースの方々とも普段それぞれの企業でどうやってスクラム開発を進めているのかといったお話などざっくばらんに様々なお話ができて楽しかったです。 いくつかのセッションで周りの人と話して感想や思っていることを共有してみるという機会もあり、強制的に周りの人とコミュニケーションを取る機会があったのも、あまり積極的な方ではない私にとってはありがたかったです。 ここまでコミュニケーションが取りやすいなと感じたカンファレンスは初めてでした。
RSGT2023を通して、様々な業種、観点からお話をお聞きすることができたのが普段できない経験でした。普段知りえないこともプラクティスを多く知ることができました。また、皆さん強いアジャイルマインドを持っていて共感することばかりでした。
顧客に価値のあるプロダクトをどう考えていくのか。プロダクトを自分事としてとらえて、どうやったら価値のあるプロダクトを自分自身も楽しくパワーを持って生み出せるのか。価値あるプロダクトを作るチームにするにはどうすればいいのか、そういったことを考えさせられる3日でした。
セッションで話されたことだけが正解ではないと思いますが、セッションを聞いたことによって実際に議論したり実践したりする良いきっかけになったと思います。
そして、終わった後、むっちゃワクワクしていて、すぐに色々なことを実践してみたいなと学んだことを感じました。 誰も知り合いもおらず、RSGTに参加するのも少し怖かったですが、勇気を出してコンフォートゾーンを飛び出したからこそ得られた学びや楽しさだったかなと思います。
ここで学んだことを少しずつでも私の周りにも広げていきたいです!
次の章からは私が実際に聴講したセッションについて簡単にレポートしてみたいと思います。
Five Practices for Building Software with Scrum
Five Practices for Building Software with Scrum(スクラムでソフトウェアを構築するための5つのプラクティス)という題目でTo Be AgaileのDavid Bernsteinさんよりお話いただきました。
ソフトウェア開発のプロジェクトの中で成功するのは3つに1つで更に作った機能のうち43%は使われない。更にスクラムを成功させているプロジェクトチームはとても少ないという頭出しからスタートしました。
そんな中でスクラムでソフトウェアを構築するために必要な、5つのプラクティス(継続的な統合、コラボレーション、CLEANなコードを書くこと、TEST First、レガシーコードのリファクタリング)を紹介いただきました。
継続的な統合という面では、CI Serverが常に稼働状態であることは非常に重要ということでした。「アジャイルで最も重要なのはCIサーバからのフィードバック」という言葉は印象的でした。 また、Doneの定義には以下の3種類があるという概念も初めて知り勉強になりました。
- 機能が開発者のコンピュータ上で動く=Done
- 機能がBuildに統合されている=Done-Done
- 開発者のマシンで機能、ビルドに統合、保守できる=Done-Done-Done
自分が関わっているプロジェクトではDoneの定義すら怪しいですが、Done-Done-Doneといった状態になるようにしていきたいです。
コラボレーションという面ではXP(エクストリームプログラミング)やペアプログラミング、バディプログラミング(初めて知った)、モブプログラミングが紹介されました。チームメンバーが機能横断的であるべきであり、ペアリングやモブはチーム全体に学びを増やすことにつながります。一番良い学びは他の人に教えることです。「常にだれかをメンタリングし誰かのメンタリングを受けなさい。」という言葉は印象に残りました。
CLEANなコードを書くという面では、以下の5つのポイントが重要で良いコードの核となるということでした。意識できていない項目も多いので気を付けなければと感じました。
- Cohesive (凝集性が高い)
- 1つのコードは1つのことしかしない
- Loosely Coupled(疎結合)
- Encapsulated(カプセル化)
- 隠すことができればできるほど後で壊さずにできる。
- どのようにやるのかを隠したい。見せるのは何をやるのか。
- Assertive(断定的)
- オブジェクトの状態は自分自身で管理すべき
- Non-Redundant(冗長ではない)
- Dupulicationが最も顕著
- コードが同じでなくても冗長は冗長
- 同じことを別の場所でやろうとすると冗長
- Dupulicationが最も顕著
まずはテストを書くという面では、TDD(テスト駆動開発)の重要性について再認識できました。TDDのポイントはその機能の「ふるまい」を作っていくことで、テストコードを書くことによってどのようなふるまいをさせたいのかということを意識して書くことがポイントで、それによりドキュメントの数も減るということでした。良いテストを書くことがアジャイルの本質という言葉にも合った通りTDDは非常に重要だと感じました。自チームもテストに感染していけるように改善していきたいなと感じました。
レガシーコードのリファクタリングという面ではリファクタリングの重要性やそのテクニック(テストの固定化、システムのストラングリング、ブランチの抽象化)をご紹介くださいました。一度作ったら終わりではなく、継続的に改修していかなければいけません。技術的負債をなるべく「リボ払い」しないようにプロジェクトを進めたいとかんじました。
真のアジャイル精神はアジャイルマニュフェストの第1原則にあるとおり「顧客満足を最優先にして価値のあるソフトウェアを早く継続的に提供する。」ことです。このセッションでご紹介いただいたプラクティスをうまくチームに適応できるように施策を進めていきたいなと思いました。
三歩進んで二歩下がるスクラム〜一歩ずつ変化する開発組織〜
株式会社カオナビさんのスポンサーセッションでした。 カオナビでのスクラム開発の紆余曲折をお聞きすることができました。文字通り三歩進んで二歩下がりながらも一歩ずつ変化していく様子をお聞きできて参考になりました。 「スクラムのWhy」に関心が生まれないチームになっていたという点では、アウトプットのティーチングばかりしていた。学びの過程にある気づきを還元できていなかったというお話がありました。私も自チームのスクラムを振り返った時にスクラムマスターとして学びの過程にある気づきをチームに還元できているのかと言われると自信がないのでこれは意識していかなければと思いました。 機械化されたスクラムという点ではマニュアルを量産して機械化してしまったという部分も印象的でした。 私もクロスファンクショナルなチームを目指して少しずつでも開発組織を変えていけたらなと思いました。 セッションの後、スポンサーブースで色々と情報交換できたのも楽しかったです。ありがとうございました!
Effective Retrospective++~楽しいだけじゃない、次の一歩を自分で踏み出し続けられるふりかえりへ~
NRI 森さんによるふりかえりに関するセッションでした。いつも「ふりかえりカタログ」や「ふりかえりガイドブック」を普段から活用させていただいており、森さんのお話を直接聞けるということで非常に楽しみなセッションの一つでした。
ふりかえりの目的という部分が印象的でした。様々な書籍を引用し、一口にふりかえりといってもそれぞれの書籍ごとに色が違うことに驚きました。 特に『エッセンシャルスクラム』にあるクマのプーさんからの引用が、私の胸に刺さりました。
そうら、クマくんが、二階からおりてきますよ。バタン・バタン・バタン・バタン 頭を階段にぶつけながら、クリストファー・ロビンのあとについてね。 二階からおりてくるのに、クマくんは、こんなおりかたっきり知らないのです。 もっとも、ときには、かんがえることもあるのです。このバタン・バタンをちょっとやめて、かんがえてみさえしたら、ほんとは、またべつなおりかたがあるんじゃないかな・・・とね。それから、いややっぱり、そんなおりかた、ないのかな、とも思ってしまうのです。 ー-『クマのプーさん』(岩波少年文庫、石井桃子訳) スプリントレトロスペクティブはスクラムチームにしばらく「バタン・バタン」とするのをやめて、考える機会を与えるものである。
クマのプーさんができなかった「一度立ち止まって考える機会を作ること」をスプリントレトロスペクティブで大事だということがすっと頭の中に入ってきました。 早速、RSGT後のレトロスペクティブのチェックインでこの話を紹介してみました。非常に受けもよく、チームで「一度立ち止まって考える機会を作ること」の意義を再確認でき、これからクマのプーさんのようにならないためにはどうすればいいか考えることができたのは非常に良かったなと思いました。
それ以外にも様々な観点で目的をとらえることができよい機会となりました。 まずは「立ち止まる」ことから始めていければよいなと思いました。
ふりかえりの7ステップについてもご紹介いただきました。このステップが全てではないことはわかっていますが、自チームのレトロスペクティブはあまりこの型にはめられていないという面もあるので1回このステップを忠実に守って実施してもいいのではないかとは感じました。特にStep6 ふりかえりをカイゼンする。Step 7 アクションを実行するというのはできていないことが多いので実施しなければと思いました。アクションを作ったら即時実行。後回しにせずにチームのパフォーマンス向上につなげようという言葉はチーム全体で共有して肝に銘じたいです。
ふりかえりの成長段階とよくある悩みについても取り上げられ、QAを読むだけでも非常に参考になるものばかりでした。特にアクションがだせないことがあり不安という問いに対して、話が盛り上がりすぎてアクションが出なかったは大丈夫であり、共通の話題・問題について話し合いをしたという行為がチームに新たな行動をもたらすという部分は印象的でした。
私は、レトロスペクティブでは必ず次につながるアクションを出さなければいけない(上長からも強く求められている)と思っていたので、必ずしも継続的にチームのパフォーマンスを向上させる場として、ふりかえりを最大限活用してよい。チームビルディングする時間がないのであればふりかえりのなかでやってもよいという話を聞いて、チームをよくするために自分なりに工夫してレトロスペクティブを進めていきたいなと思いました。
スプリントレビュー Deep Live
スプリントレビューを深堀りしたセッションでした。私自身も顧客と協調した意味のあるスプリントレビューをしたいなと常日頃から思っているのですがただの成果物披露になってしまっているという悩みがありました。このセッションでスプリントレビューについて深堀りしていくにつれて、できていない部分がまだまだ多いなと感じ、見つめなおしていかなければと思いました。
ステークホルダーには影響度合いや関心度合いに違いがあるので、スプリントレビューに呼ぶ頻度や時期、参加の必要性も異なることやプランニングでスプリントゴールが決まった段階で誰を呼ぶか決めるという点、プロダクトオーナーがスプリントレビューをリードすべき(POはレビュワーではない)、スプリントでやったことではなく達成したことをレビューする、デモに使うデータは中途半端ではならない、ステークホルダーへの質問を事前に用意しておくなどが特に印象に残りました。
スプリントレビューはスクラムチームとステークホルダーのワーキングセッションでです。顧客の価値を最大化できる一方的でないスプリントレビューを目指していきたいなと思いました。
どうすれば新しいアイデアが生まれるのか
「どうすれば新しいアイデアが生まれるのか」ということでおもちゃクリエイターの高橋さんからのセッションでした。RSGTでおもちゃクリエイターのお話を伺うことができるとは思っていなかったので楽しみにしていたセッションの一つでした。
新しいアイデアは、現時点で満たされていない人の欲求を満たすアイデアであり、新しいもの、ここにしかないものは実行者や顧客を行動させます。そしてものづくり、製品開発においてはまず「自分」あるいは「身近な大切な人」がユーザーとして欲しいプロダクト、サービスを生み出すことが重要です。自分事としたときには、なんとしても実現してやろうという行動力が違うというのはなるほどと思いました。
日々のプロダクト開発でもいかに「顧客に価値のあるプロダクト」を生み出すかというところを意識して日々スクラム開発を回していますが、もし自分が使うのだったらどう思うだろうという観点は非常に重要だと思いました。色々な業態のプロダクト開発があるので、中々難しいなと思いつつも、自分事にするというのはチームにも伝搬させていきたいなと思いました。
アイデア発想法の一つとして「お題の拡大解釈できないが一度考えてみる。(ある事象の的を大きくしてみること)」ということをご紹介くださいました。スプリントレトロスペクティブでもスクラムのカイゼンのためのアイデアを出しますが、ある問題だけに注目して議論していることも多々あったなと感じました。的を広げてみるというのも実践してみたいと感じました。
高橋さんは、アイデアを実現する行動力を出すために、「遊びにすること」ということを挙げていらっしゃいました。ゆとりをもって楽しんで仕事をすることで良いプロダクトを生み出せるのかなと感じたので楽しくわくわくして仕事ができるチームを作りたいなと思いました。
The Agilists’ Emerging Superpower and Our Planetary Challenge
組織が機械のようであった時代から今は熱帯雨林にとらえられるようになったという頭出しから全体通して非常にエモーショナルなセッションでした。
印象的だった言葉をいくつかご紹介します。
- アジャイルはVUCA時代に対応していくものである。
- Volatility(変動性)・Uncertainty(不確実性)・Complexity(複雑性)・Ambiguity(曖昧性)のことを指しています。一言で言えば、先行きが不透明で将来が見通せないということらしいです。
- アジャイルは変化を代謝する。変化を受け入れる、歓迎する、楽しむことで、私たちのスキルで栄養に変えていく。
- 変化を代謝して私たちのスキルで栄養に変えていくというのはなるほどなと思いました。
- これまではマネージャーが意思決定していたが、これからはチームが意思決定しなければならない。素早く失敗して学んでいく
- チームが意思決定しなければならないという考え方は重要だと感じました。
- Change Edge
- edge theory modelをご紹介いただきました。現在から変化を起こすためには、三角形の頂点であるEdgeを越えなければならない。
- 我々がEdgeを超えるためには会話が重要。会話から何を生み出したいのか、意図や目的を明確にし(Innner work)、それから実際に話す練習をしてみること (Outer Work)を実施し会話に対してしっかりとした準備をすることで会話のスキルを上げていくことが重要
- 私も思いついたことを思いついたまま話し相手に意図が伝わらないことが多々あるので、会話の結果、相手にどうしてほしいのか、自分は何を成し遂げたいのかといったところを準備して望まないとなと思いました。それはアジャイルチームをChange Edgeさせるためにも重要だと感じました。
英語のセッションを日本語同時翻訳でお聞きしたのですが、やっぱり英語で聞けるようになりたいなと思いました。感情に語り掛けるような内容が多かったので、抑揚などが全く分からなくなって意味が取れないみたいなことや、日本語には訳しにくいような概念も理解できるようになりたいなと思いました。正直完全に意図を咀嚼できている気がしないので、英語できるようになりたいと強く感じました。
ログの書き方がチームの生産性を爆上げする話
www.slideshare.net
マイクロソフトの牛尾さんによるログの重要性に関するセッションでした。
ログは、開発環境・本番環境の問題解決、システムの振る舞いの観察・理解、ログを活用して生産性を爆上げするために重要とのことでした。ログは第三者がログを使う場面と目的を想定し、対象者が目的を達成できるような情報を提供することが重要です。 特に自動化を前提にログを書くという言葉は意識しなければなと思いました。自動化を前提に書いておけば自動的な復旧もログを活用することで実行できます。
今関わっているシステムでも、ログが分かりにくくなってインシデント調査が難航するなんてことも頻発しているのでご紹介いただいたベストプラクティスも参考にしながらログをより良いものにしていきたいと感じました。まずは、トレースIDを付与するところから始めたい。
自治体DXにアジャイルなマインドとスキルはどれほど役立つのか
福井県CDO補佐官の岡島さんから、自治体のDX支援の経験がアジャイル実務や培った経験がどう役立っているかについてお話いただきました。
特にPOの経験や学びから生きている「ツボ探求力」では、システムのレバレッジポイント(介入点)をつかむ力が重要で、まずは「情報の流れ」に注目し、情報の流れをよくする施策をとって自己組織化を進めようとしていました。フェーズによってフォーカスするポイントを変えていくということも重要だということでした。その他にも右腕力や民間活力が自治体DXの活用では重要で、どれもこれまでのアジャイル開発の経験を応用して取り込んでいけているということで興味深い話でした。
最後にお話しされた、組織の中から「変革遺伝子」を浸透させようという話も印象的でした。私たちは、生体内のミトコンドリアのように、組織の成長のために形骸化した習慣を打破し、自分らしさを保ちつつワンチームで事に当たることを意識して日々のプロダクト開発もできたらよいなと思いました。
「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法
プロダクト開発が進んでいけば、どうしても考える人と作る人が別になってしまい分業や経験のギャップが生まれ、プロダクトマネージャーと開発者が分断していきます。そちらの方が効率がよく心地よいですが、スケールしていったときにコミュニケーションがとれなくなるなど、ソフトウェア開発は上達したがプロダクト開発に失敗した状態になっています。それを防ぐためにプロダクトマネジメントが当たり前になるチームを作ろうというお話でした。
プロダクトは「より価値の高い問題」(What)を解消し、その「解決の質の高さ」(How)を高めていく必要があります。この順番が逆であれば、いくら質のよいものを作っても問題解決にはなっていないので品質の高い売れ残りになってしまいます。私もカッコよさから見た目を重視したいなと思うこともあるのですが、やはり顧客の目線にたつといかに顧客の問題を解決するかが一番重要だと再認識できました。そのうえで「はやい・やすい・うまい」を目指していかなければなと思いました。
プロダクトの成長を加速させるためにもプロダクトマネージャーがボトルネックになってはいけません。特定の個人に依存すると問題の解決に間に合いません。しかし、安易に分業して手抜きでプロダクトバックログを量産してしまうとチームがくずされ「私考える人、あなた作業する人」になってしまいます。そうならないためにプロダクトマネジメントが当たり前になるチームを目指していく必要があります。そのためには経験が必要です。説明責任の機会、育成と人脈の機会、意思決定の機会が必要です。特に説明責任の機会(顧客と直接話す、役員にプロダクトの話をしている、他の部署の人たちと自分から話す)という部分はできていないなと感じています。顧客と話すことをチームに移譲せず、私や上長ばかりが話している気がします。別の講演を聞いていても感じましたが、顧客に話す機会を作ることでチームメンバーにプロダクトを自分事としてとらえてもらえるのではないかなと感じました。
具体的な施策としてモブプロダクトマネジメントやプロダクトさんぽ、ウィークリープロダクト道場をご紹介いただきました。そういった機会を増やしていったときに「ぼくは本当にプロダクトを作りたいのだろうか」という問いにたどり着きます。そこからがプロダクト開発チームのはじまりということなので、まずはここを目指せるようなチームにしていかなければなと感じました。
The Stable Team - 機能する安定したチームをつくる -
一口に機能する安定したチームと言いますが、安定したチームとは何なのかということから、ただ実際には流動的なチームが必要になるという現状があります。そんな制限のある中機能する安定したチームを実装していくためにはどうすればよいのかという話でした。
チームが高いパフォーマンスを維持していくには様々な分野における経験値を積むことや安定性が重要です。しかしながら、様々な環境要因や組織的な判断から完全にメンバーを固定化することは難しいため流動的なチームとなることもあります。ただし、Dynamic Reteamingという考え方などのようにあえて流動的なチームに挑戦するという事例もあるようです。流動的なチームは、安定したチームを否定するものなのかと今まで考えていたので勉強になりました。ただし安定したチームが高いパフォーマンスを発揮できない組織では流動的なチームで成功する可能性はほぼないということでした。
人の移動を減らすだけで安定したチームを作れるのであれば簡単ですが、機能する安定したチームはそれだけでは実現しません。(事実3年を超えたチームはパフォーマンスが悪くなるという結果も出ている。)
機能する安定したチームとは、チームに起こる逃れることのできない様々な変化が起きてもパフォーマンスが発揮できる状態にすぐに回復できるレジリエンスがチームに備わっていること重要です。この動的平衡なチームが機能する安定したチームと言えるとのことでした。
そんなチームのレジリエンス力を高めるためにモブプログラミングでSECIモデルを回したり、YOW(やったこと、起きたこと、わかったこと)を考えていくことが重要です。モブプロで同じ体験をする時間を増やし、個人個人が同じ体験からなにを感じ取り、どのようなアクションをしてそこからなにを学んだのかをチームで共有するそうすることで、表出化(暗黙知⇒形式知)につながります。
最近モブプログラミングする機会が少なくなっているのでやっぱりSECIモデルを回して機能する安定したチームを目指すためにもそういった機会はスクラムマスターとして増やさなければなと思いました。
なぜ変化を起こすのが難しいのか? - 数年以上に渡って難しさに向き合い考え取り組んできたこと / The reason why changing organization is so hard - What I thought and faced for more than several years
NTTコミュニケーションズの岩瀬さんより、組織内での変化を起こすための考え方やプラクティスについて、そして岩瀬さん自身が組織を変えるために実践してきたことをご紹介いただきました。
組織には技術負債と同様に組織的負債があり、それを返済していく=組織を変化させることには非常に時間がかかります。そんな中で変化を起こすためのプラクティスとして、システム思考、プロダクトマネジメント、目標設定とメトリクス、人を巻き込む方法をご紹介くださいました。
システム思考はレバレッジポイントを意識してシステム系のどこを変えていけばいいのか探ることが重要です。プロダクトマネジメントは、「誰の」「何を」解決するのか?を意識すること。下手に多くの人を狙うのではなくターゲットは絞ることが重要ということは学びになりました。
目標設定とメトリクスでは「たどり着きたい目標の状態」、「現在のベースライン」、「現在のトレンド(現在のベロシティを表している)」、「時間の区切り」を組み合わせたものにすることでできるだけ定量的に決めることが重要です。また、ベースラインのメトリクスを含めた相殺目標を設定することより、解決策を絞り込んだ目標を設定することができるということでした。 よくレトロスペクティブなどでもSMARTな目標をたてることが重要と言いますが、上記のようなポイントをもって長期的でも短期的でも目標を立てられるとよいなと思いました。自分自身の目標やチーム目標、次のスプリントのゴールなど様々な部分で応用できたら良いなと感じました。
また、KPIの定量値はハックできる前提で自分たちのために使おうというのは印象的でした。
それらを人に巻き込み広げていく方法として、アイデアを組織に広めるための48のパターンの内容や説得戦略の6モードを知っておくことを紹介いただきました。特に相手を説得するときは相手に対してもメリットを提示しないと上手くいかないよというお話はその通りだなと思いました。
また、岩瀬さん自身の経験も大変興味深いものでした。と同時に私はまだまだ組織を変革していくために行動できていないなと感じました。より良い形でアジャイルマインドを組織に広げていくためにも、コンフォートゾーンを出るとか迷ったらつらい方を選ぶという考え方は大切にしていかなければなと思いました。一歩踏み出して色々な人を巻き込んでいきたい!
最後に
全編通して、普段味わうことができないアジャイルマインドがあふれた雰囲気で非常に楽しいひと時を過ごすことができました。 スポンサー、運営など関わってくださった方々ありがとうございました!来年も是非参加させていただきたいです!
5年間の高専生活を振り返ってみる
この記事は高専 Advent Calendar 2020 22日目の記事として書いています。
今更ですが、2020年3月、5年間通った高専を卒業しました。
高専生活は、非常に充実していて楽しい5年間でした。
そんな私の高専生活を振り返っていきたいと思います。
僕の経験を通して、あの時こうしておけば良かったなという思いも書いています。
少しでも後輩の皆さんの参考になれば幸いです。
ここから先の文章は自分への忘備録という側面が強く、とくにまとまりもないので、非常に長い文章となっていますが、ご容赦ください。
1.高専の推薦入試、推薦入試合格
2015年1月、ずっと行きたかった高専の推薦入試のチャンスを頂きました。
本番の日は、中学校が設定していた集合時間を完全に忘れてしまい先生方にご心配をおかけしたこと、適性面接が思ったより簡単で驚いたことなどが昨日のように思い出せます。
そして、忘れもしない1月某日、担任の先生に合格を告げられたときはとても嬉しかったのを覚えています。
2.1年生
2015年4月、中学校を無事卒業し、高専生活をスタートさせました。
私の高専では、1年生の頃は全学科混合のクラスで一般科目の授業を受けていました。
正直、1年生の頃のことはほとんど覚えていません。でもそれなりには過ごしていたと思います。
情報技術に漠然とした興味はありましたが、部活や日々の勉強に精一杯で特にあまり活動はしていませんでした。
授業でやるプログラミングが楽しくて、僕に合っているなと思ったぐらいです。
強いて言えば、9月にITパスポートをとってみたぐらいだと思います。
あと猫を飼い始めました。猫はかわいい、癒し(写真は成長した3匹)
3.2年生
少しずつ情報分野の活動も始めるようになりました。
まず、この年の春に基本情報技術者試験を受験し、合格しました。
また、島根県が主催しているRuby合宿に参加しました。
ここで初めてRubyやGitの使い方、チーム開発などに取り組むことができました。
3月には、Ruby合宿で知った「スモウルビープログラミング甲子園」に出場しました。
スモウルビープログラミング甲子園は、簡単に言えばブロックプログラムでゲームAIを作成し、対戦しあうというものです。
予選はギリギリ通過でしたが、3位になることができ、とても驚きました。
その他の活動としては、BPOの青少年モニターをやったことぐらいでしょうか。
月に1回、TVやラジオ番組を見たり聞いたりして感想を書き提出することで図書カードがもらえるというものです。
1年間の集大成として東京で行われた会議では、日本テレビを訪問し、某番組のディレクターと意見交換をする機会がありました。
バラエティ制作における熱意を非常に感じることができました。その後に某芸人さんにお会いできて興奮してのも覚えています。
4.3年生
少しずつ様々な活動をスタートさせたのが3年生です。僕の人生の中でも大きな年になりました。
3年生の1年間はSecHack365の1期生として1年間活動を行いました。
SecHackとの出会いやその活動はかけがえのないものになり、今につながっています。
大きなイベントとしては、情報オリンピック夏季セミナーとセキュリティキャンプ九州in博多2018、CTF for Buginers長崎に参加したことだと思います。
あと、担任の先生に誘われて高専機構が主催するセキュリティの勉強会みたいなのにも行きました。
また、学校では学生会の活動に関わり始めました。
私はメイン部署というところに属し、高専祭のメイン企画を担当していました。
メイン企画とは高専の学園祭である高専祭に来てくださった皆さんに、3学科の力を結集して楽しんでもらう企画です。
簡単に言えば、遊園地のアトラクション的なものを作っていました。
3年生の時は、Wiiリモコンを使った大掛かりなシューティングゲームを作りました。
WiiリモコンとUnityの連携ができずに悩みまくった日々でした。(後にライブラリで簡単にできることが分かりますが)先輩と一緒に夜遅くまで開発するのは非常に楽しかったです。
ゲームだけでなく皆で作業してアトラクションを作り上げていきました。
最終的には多くの人に楽しんでもらえてうれしかったのを覚えています。
イベント関連としては高専カンファレンスin西京の運営をやりました。
事務部門の責任者をさせていただきました。準備は普通に大変でした。
イベント自体は楽しかったですが、運営はもうやりたくないなと思いました。
あとは自動車学校に行き始めました。
5.4年生
インターン、就活、地域の方々とのつながりを作るなどなど様々な活動を進めていきました。
順番に振り返ってみましょう。
5月にはCoderDojo光にメンターとして初めて参加させていただきました。
CoderDojoは子供向けのプログラミング道場です。
チャンピオンの方に勉強会でお会いし、ご縁があって参加しました。
私たちが教えるでもなく子供たちが主体的にプログラミングに取り組む姿には非常に感銘を受けました。
それから卒業するまで色々な形で関わらせていただき、様々な出会いがありました。
本当にCoderDojoに関わらせていただいてよかったなと非常に感謝しています。
coderdojo-hikari.com
3年生の時と引き続き高専祭のメイン部署にも関わらせていただきました。
4年生の時は部署長として企画の責任者として運営を行っていきました。
クイズとかARとかVRとかレーザートラップとか色んなアトラクションを用意しました。
事務的な作業や指示に追われて、3年生の時のようにあまりクリエイティブなことができなかったのは心残りですが、楽しかったです。
色々なことがあってストレスフルな毎日でしたが、皆で企画を作り上げていくのは非常に達成感のあるものでした。
18人ぐらいのグループのリーダーとして活動しましたが、不器用で色々とリーダーとしての指示を間違えた場面が多かったかなと思います。
自分がリーダーとしてはっきり指示できない部分も多くメンバーには多大な迷惑をかけたと思います。
あとは無意味な事務仕事とかミーティングほど意味のないものはなかったなと反省したりもしています。
企画的には成功できたのかなと思いますが、当日の運営も含めて反省点が非常に多かったなと思います。
本当にチームメンバーの方々には僕なんかに付いてきてくれて非常に感謝しています。
僕にリーダーは向いてないのかなと思ったりもしました。
インターンにも何社か行きました。
学校に来た企業は賃金も出ないし、「就業」というより「体験」インターンが多かったので自分で探したいなと思いました。
逆求人に行くなど活動しましたが、まだまだ実力不足で何度面接を受けても落ちるというのを繰り返していました。
インターンがやっと決まった時は非常に嬉しかったのを覚えています。
結局実際のプロダクトに関わるというより体験型のインターンに行ってしまったのは少し後悔している点です。
また、もし面接受けた企業と日程が被るからという理由で受けなかった企業も多くありました。
なりふり構わず色々な企業を受けておくべきだったなと思っています。
そして、興味がないから申し込みしなかったというのももったいなかったなと思います。
インターンなので少しぐらい興味が持てれば応募したら良かったなと思っています。
今は興味がなくても新たな視点を得ることができたのになと思います。あと実力不足だなと改めて実感しました。
そんな反省を活かして就職活動は10月からスタートしました。
そして、少しでも興味がある企業は積極的に面接を受けてみるということを心がけました。
就活していく中で様々な企業について知れて自分のやりたいことが見えてくるので、1社だけを見るのではなく複数の会社を見るということは大切なことだと思います。
書面やHPだけでなく、実際に様々な企業の方にお話を聞いて納得のいく就活がしたかったので、学校推薦ではなく自由応募で挑戦することを決めました。
10月のサポーターズの1on1を皮切りに就活をスタートさせました。
そして高専祭が終わると同時に平均して1週間に1回は面接か面談が4月ぐらいまで生活が始まりました。
やはり実力不足で最初の方は落ちまくります。
お祈りメールを見ると、人格否定をされた気分になりますが、めげずに面接を受け続けました。
入社した会社に出会ったのは1月に参加したジースタイラスの逆求人です。
今までは何となくこの会社に入社してみたいなという気持ちで選考を受けていましたが、
自分の考えややりたいことに合致する企業に出会い、逆求人でお話した後は明確に入社したいと思い興奮したのを覚えています。
それが私の入社を決めた企業です。
20社ぐらいの選考を受け、4社に内定をいただきました。
4社どこにも魅力があり、非常に非常に悩みましたが、考えに考えて入社する会社を決めました。
私の恒久的な「ITを利用して社会をよりよく便利にする」目標をより大きな範囲で実現できるかなと思ったのが理由かなと思います。
また、Web×プログラミング勉強会やクリエイティブハントなど地域で開催されている勉強会にも積極的に参加しました。
今まで知らなかった多くの方に出会うことができ、たくさんのつながりを得ることができました。
また、コワーキングスペースカラムとの出会いも様々な面でよい影響を与えてくださいました。
ちょくちょく勉強しに行ったり勉強会に行ったりすると、色々な方を紹介してくださったりとつながりも増えました。
5年生のときは、お仕事を紹介してくださったり、勉強会の会場を提供してくださったりと非常に親切にしていただきました。
卒業直前まで様々お世話になりました。本当にありがとうございます。
その他に参加したイベントは、OSC広島(CoderDojoがらみで登壇)高専カンファレンスに2回、DojoCon、石巻ハッカソン、石巻ハッカソンin周南などです。
あと大きな出来事としては免許を取得しました。また家庭教師をバイトとして始めました。
6.5年生
5年間の集大成、そして学生最後の年として様々な活動を行ってきました。
卒業研究では、「秘密分散法を利用したアンケート集計システムに関する研究」という題目で研究を行いました。
情報処理学会の学会誌で秘密計算について知り素晴らしい技術だと思い研究を進めました。
しかし、学内に秘密計算ができる先生はおらず、サポートはしていただきましたが、右も左も分からないまま1人で研究をしたので、
右往左往してしまい良い研究ができたかどうかは微妙なところですが、不完全なところは多くありますが無事に終えることができたので良かったです。
学科でも最終的な順位が6位だったので一定の評価はしていただいていたのかなと思っています。
セキュリティキャンプにも参加しました。
バラエティトラックに参加し、様々な講義を受講させていただきました。
貴重な講義を受講させていただき、非常に勉強になりました。また、多くの人に出会えたので良かったです。
詳しくもブログを是非読んでください。
セキュリティキャンプのほかにも、レッドハッカソンHIROSIMA、セキュリティミニキャンプ名古屋、クリエイティブハント、CODEBLUE(学生スタッフ)、LINE DEVELOPER DAY、DojoCon、高専カンファレンス(登壇)など色々なイベントや勉強会に参加させていただきました。
5年生のときには、地元で勉強会の立ち上げ、主催も行いました。
地元では、IT系のコミュニティが非常に少なく、エンジニアはいても交流の場がないといった課題があります。(現在進行形で)
少しでも多くの地元の人にITに興味を持ってもらったり、エンジニアの交流の場を作りたい、
そして自高専のくすぶっている学生の方に外に出て来てもらいたいという思いから
やまぐちITパーティーやChallenge!スマホアプリ開発勉強会(全5回)の主催を行いました。
様々な方にご協力いただき、僕自身も新たな発見や出会いがあったのでやってよかったなと思っています。
そして大きな出来事としては、先生に誘われて中国大連に短期留学に行ったことです。
中国に行く前は、中国に対してよい印象は持っていませんでした。少し不安な中でスタートした生活ですが、多くのカルチャーショックを受けましたが、最終的には非常に楽しく行ってよかったと思いました。
大連や旅順の観光、中国語学習、中国文化の体験など充実した日々を送りました。
初めて海外に行き、異文化を学び、自分の価値観を大きく変える機会になりました。
海外や中国に対する漠然とした不安が大きかったですが、実際に行ってみて意外と何とかなるものだと思いました。もっと早く留学プログラムなどに参加しておけばよかったと少し後悔しました。
7.部活動
僕は、散々迷った末、卓球部に入部しました。
本当はプロコンなどに出る部活に入ろうと思っていましたが、見学に行ったとき展示されているのがゲームやCGばかりで僕が想像していたものと何か違うなと思い入部するのをやめました。
運動部に入ると決めても、やったことのないアーチェリーや剣道に挑戦しようかとも思いましたが、中学校から続けている卓球を続けることにしました。
1年生のうちからプロコンなど、プログラミング関連に多く挑戦しておけばよかったなと思ったことも何度もあるのは事実です。
1年生のうちから実力をつけていきたいと思う人は、プログラミング関連をする部活に入るべきだと思います。
学生時代ぐらい運動を続けたいという人には運動部に入ることも一つの手段だと思います。
実際に運動部の練習は忙しいですが、並行して様々な活動をしていくことは十分にできます。
(私は卓球の実力がなく僕がいなくてもチームが回っていたというのも事実ですが)
県体にも出たことがない弱小校からいきなり強豪校へ入部したので、ついていけるかどうか不安しかありませんでした。
しかし、そんな僕にも分け隔てなく接してくださる優しく尊敬できる先輩方ばかりで、楽しく部活動を続けることができました。
素晴らしい先輩方に出会えたので、本当に卓球部に入ってよかったなと今でも思っています。
また、5年間で、カットマンという新しい道にも進むことができました。
振り返ってみるとあまり卓球は試合でチームに貢献できるほど上達することはできませんでしたが、中学校の頃よりはましになったかなと思います。
卓球の能力はあまりありませんでしたが、先輩や同級生、後輩たちのおかげで、様々な場所に試合などで行くことができ、主にマネージャー的なことしかできませんでしたが、よい経験となりました。
僕という人間を受け入れてくれて、本当に卓球部には感謝しています。
また、部活動を通して人間関係というのは難しいなと強く思った5年間でした。(嫌な思いをすることもたくさんありました。)
正直に言えば高専生活で嫌だったことの半分以上は部活関連だったような気もします。
ここまで5年続けてきたという話をしましたが、途中でやめていった人も何人もみてきました。
当初、同級生の部員は9人いたはずですが、色々あっていつの間にか卒業時には4人になっていました。
学生という時間は有限です。やりたいことがあったら自分の気持ちを優先することも大事なのかなと色々な人を見て思いました。
嫌なことや嫌いなことをやっていても時間が無駄になるだけだと思います。
8.五年間心がけてほしいこと
ここからは5年間全体で心がけてほしいことを書いていきます。
1年生の頃は、ホームルーム開始の40分前ぐらいには教室にいて、課題などをしていた真面目な学生でした。
しかし、それは2年生の後半から10分前、5分前、1分前、0分前、1分後、2分後、5分後というように段々崩れていくのであった...
授業で遅刻をつけられたのは、5年生のときの1度しかありませんでしたが、常にギリギリな行動をしていたのは5年間の反省点です。
3年生の頃には、とうとう「もう少し早く来ましょう」と担任の先生に言われる始末でした。
もっと余裕を持って最低でもHRの10分前ぐらいには教室につく生活を心がけるべきだと思います。
振り返ってみれば課題などもギリギリに提出することが多かったなと思います。
いつも締め切り日の夜中にヤバいやばいと言いながらやることが多かったと思います。
計画的に物事を進める能力を身に着け、早め早めに課題をこなすことが大切だと思います。
また、自ら主体的に色々なことに挑戦していってほしいなと思います。
9割の高専生が、自分の高専の中だけで閉じこもっているような気がします。(僕の感覚ですが)
プロコンでもデザコンでもロボコンでもいいし、何でもいいので色々なことに挑戦していってほしいなと思います。
その一歩として、勇気をもって、積極的に様々なイベントに参加して、多くの人とつながりを作っていくことが大事だと思います。(今、コロナ禍で中々厳しいですが...)
イベントや勉強会では、自分の知らない技術や知識を身に着けることができるだけでなく、色々な方とのつながりを持つことができます。
多くの人とつながりを持つことは後々財産になると思います。
私もイベントや勉強会で出会った方から、貴重な機会やお仕事を頂いたりすることができたりすることもありました。
都会のイベントなどでも学生には交通費を出すみたいなイベントもあるので行きたいイベントはTwiterなどでアンテナを張っておくといいと思います。
また、懇親会にも積極的に参加して、色々な人に話してほしいなと思います。(今、コロナ禍で中々厳しいですが...)
私も緊張して中々できないのですが、話しかけたり、人の輪に入るのはとても緊張するが案外誰も気にしないので積極的に話していくとよいと思います。
(イベントや勉強会は懇親会が本番まであるので...)
あと、名刺を作って色々な人に配り覚えてもらいましょう。
また、僕はあまり出場できませんでしたが、ハッカソンとかコンテストに参加するのも良い経験となると思います。
9.まとめ
振り返ってみるとなんだかんだ楽しく好きなことができた5年間でした。
本当に恵まれた環境だったなと思います。
5年間ただ過ごしているだけではもったいないので、校内、校外問わず有意義な高専生活にするためにも色々なことに挑戦してほしいなと思います。
やり直せたら、もっと早いうちから色々なIT技術の勉強をして作品をたくさん作り、コンテストに出たり、色々なところに行ったりしたかったなという反省点はいくらでも出てきますが、やはり僕には高専という環境は好き勝手色々なことができたのでとても良かったように思います。
あくまで僕が過ごした5年間を書いてみたので人それぞれだとは思うし、僕なんかはまだまだ凄い人に比べれば技術的にも活動的にも劣っていますが、もし、この記事が何か皆さんの参考になれば幸いです。
docker-composeでVue.js環境を作った時に詰まった話
docker-composeを使ってVue環境を構築したとき、vueプロジェクトができないというエラーが生じたので解決方法を書いておきます。
環境
Windows Home
Docker version 19.03.1, build 74b1e89e8a
docker-compose version 1.24.1, build 4667896b
※ Windows Homeなのでdocker toolBoxを使っています。
DockerFileとdocker-compose file
DockerFile
FROM node:latest WORKDIR /app RUN yarn global add @vue/cli
docker-compose.yml
version: '3' services: web: build: . ports: - 8080:8080 volumes: - ./app:/app stdin_open: true tty: true command: npm run serve
起こったこと
docker-compose build
して、イメージを作成したところまでは良かったのですが、
docker-compose run web vue create .
と実行してVueプロジェクトを作成すると、以下のようなエラーが生じました。
Vue CLI v4.3.1 ? Generate project in current directory? Yes Vue CLI v4.3.1 ? Please pick a preset: Manually select features ? Check the features needed for your project: Babel, TS, Router, Vuex, Linter ? Use class-style component syntax? Yes ? Use Babel alongside TypeScript (required for modern mode, auto-detected polyfills, transpiling JSX)? Yes ? Use history mode for router? (Requires proper server setup for index fallback in production) Yes ? Pick a linter / formatter config: Basic ? Pick additional lint features: Lint on save ? Where do you prefer placing config for Babel, ESLint, etc.? In dedicated config files ? Save this as a preset for future projects? No ? Pick the package manager to use when installing dependencies: NPM Vue CLI v4.3.1 ✨ Creating project in /app. ⚙️ Installing CLI plugins. This might take a while... npm ERR! code EPROTO npm ERR! syscall symlink npm ERR! path ../@babel/parser/bin/babel-parser.js npm ERR! dest /app/node_modules/.bin/parser npm ERR! errno -71 npm ERR! EPROTO: protocol error, symlink '../@babel/parser/bin/babel-parser.js' -> '/app/node_modules/.bin/parser' npm ERR! A complete log of this run can be found in: npm ERR! /root/.npm/_logs/2020-05-04T10_23_38_694Z-debug.log ERROR command failed: npm install --loglevel error
npm ERR! syscall symlink
と言われています。
これはWindows環境ではdocker-composeのvolumesで指定したローカルの/appにシンボリックリンクを貼れないということだと予想されます。
ちなみに、
volumes: - ./app:/app
というdocker-compose.ymlの記述はローカルの/appというディレクトリにDockerコンテナの/appの中身をマウントしてねというイメージです。
(正確には違うかもしれないです。違っていたらごめんなさい)
解決方法
Docker Quickstart Terminalを起動するときに管理者権限で起動しましょう。
管理者権限で起動し、先ほどと同じコマンドを入力して実行するとVueプロジェクトの作成が正しく実行されます。
管理者権限で起動して、Docker Quickstart Terminalでエラーが出る場合は、
再起動を行うか、Virtual Boxで動いているdefaltという名前の仮想マシンを終了すれば管理者権限で起動できます。
結論
Docker toolboxは管理者権限で起動しましょう。
他にもnpm installやyarn installができないという報告もあり、特に問題がなければ管理者権限で起動するべきだと思いました。
Latexでciteを使って文献参照するときに上付きにする方法
Latexを使っていた時に少しつまづいたので記載しておきます。
通常、citeを使った際は、以下のように文章と同じサイズで文献参照が行われます。
しかし、文献参照を上付き文字にしたいときも出てきます。
そのような際は、パッケージを追加するときに「super」というオプションを指定します。
\usepackage[super]{cite}
以下のように上付きの文献参照ができます。
しかし、上付きの文献参照に[ ]をつけたいことがあります。
そのような際は、以下のようにrenewcommandを使ってciteコマンドを修正します。
\renewcommand\citeform[1]{[#1]}
以下のように[ ]の上付き文献参照ができます。
\documentclass[12pt,a4j]{jarticle} \usepackage[super]{cite} \renewcommand\citeform[1]{[#1]} \begin{document} 本文章は、夏目漱石の吾輩は猫である\cite{ref1}を記載している。 吾輩は猫である。名前はまだ無い。\\ どこで生まれたか頓と見當がつかぬ。何ても暗薄いじめじめした所でニャー/\泣いて居た事丈は記憶して居る。吾輩はこゝで始めて人間といふものを見た。\dots \begin{thebibliography}{99} \bibitem{ref1} 夏目漱石, ``吾輩ハ猫デアル,'' https://www.aozora.gr.jp/cards/000148/files/790.html. \end{thebibliography} \end{document}
FlutterでQRコードやバーコードを読み取る方法
このブログは、「Challenge! スマホアプリ勉強会Vol.3」で作成予定のアプリについての解説ページです。
QRコードやバーコードの読み取りを行うアプリをFlutterで作る方法について解説します。
今回利用するパッケージ
今回は、barcode_scan 1.0.0というパッケージを使ってQRコードの読み取りを実現します。
pub.dev
QRコード以外にもバーコードの読み取りも可能にしているようです。
準備
まず、Androidおよびiphoneのアプリ内でカメラのパーミッションを許可するコードを書きます。
Android側
android/app/src/main/AndroidMainifest.xmlを以下のように編集します。2つの記述を追加するだけです。
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.example.third_app"> <!-- 次の記述を追加する --> <uses-permission android:name="android.permission.CAMERA" /> <!-- 英語のコメント --> <application android:name="io.flutter.app.FlutterApplication" android:label="third_app" android:icon="@mipmap/ic_launcher"> <activity android:name=".MainActivity" android:launchMode="singleTop" android:theme="@style/LaunchTheme" android:configChanges="orientation|keyboardHidden|keyboard|screenSize|locale|layoutDirection|fontScale|screenLayout|density|uiMode" android:hardwareAccelerated="true" android:windowSoftInputMode="adjustResize"> <!-- 英語のコメント --> <meta-data android:name="io.flutter.app.android.SplashScreenUntilFirstFrame" android:value="true" /> <intent-filter> <action android:name="android.intent.action.MAIN"/> <category android:name="android.intent.category.LAUNCHER"/> </intent-filter> </activity> <!-- 次の記述を追加する --> <activity android:name="com.apptreesoftware.barcodescan.BarcodeScannerActivity"/> </application> </manifest>
android/build.gradleを以下のように編集します。自動的に生成されている場合もあります。その際は編集の必要はありません。
Kotlinで書かれているパッケージなのでこのような処理が必要となります。
buildscript { // 1.2.31以前だったら次を変更 ext.kotlin_version = '1.2.71' repositories { google() jcenter() } dependencies { classpath 'com.android.tools.build:gradle:3.2.1' // 記述がなければ次を追加 classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version" } } allprojects { repositories { google() jcenter() } } rootProject.buildDir = '../build' subprojects { project.buildDir = "${rootProject.buildDir}/${project.name}" } subprojects { project.evaluationDependsOn(':app') } task clean(type: Delete) { delete rootProject.buildDir }
android/app/build.gradleを以下のように編集します。自動的に生成されていることもあります。その際は編集の必要はありません。
/* 省略 */ apply plugin: 'com.android.application' // 次の記述がなければ追加 apply plugin: 'kotlin-android' apply from: "$flutterRoot/packages/flutter_tools/gradle/flutter.gradle" android { compileSdkVersion 28 sourceSets { main.java.srcDirs += 'src/main/kotlin' } lintOptions { disable 'InvalidPackage' } defaultConfig { // TODO: Specify your own unique Application ID (https://developer.android.com/studio/build/application-id.html). applicationId "com.example.third_app" minSdkVersion 16 targetSdkVersion 28 versionCode flutterVersionCode.toInteger() versionName flutterVersionName testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner" } buildTypes { release { // TODO: Add your own signing config for the release build. // Signing with the debug keys for now, so `flutter run --release` works. signingConfig signingConfigs.debug } } } flutter { source '../..' } dependencies { // 次の記述がなければ追加 implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version" testImplementation 'junit:junit:4.12' androidTestImplementation 'com.android.support.test:runner:1.0.2' androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
AndroidMainifest.xml、android/build.gradle、android/app/build.gradleは以下のような位置にあります。
ios側
ios/Runner/info.plistにカメラの説明を以下のように追加します。
<key>NSCameraUsageDescription</key> <string>Camera permission is required for barcode scanning.</string>
pubsec.ymlの編集
pubsec.ymlを以下のように編集します。
name: third_app description: A new Flutter application. # 英語の文章 version: 1.0.0+1 environment: sdk: ">=2.1.0 <3.0.0" dependencies: flutter: sdk: flutter # The following adds the Cupertino Icons font to your application. # Use with the CupertinoIcons class for iOS style icons. cupertino_icons: ^0.1.2 # 以下を追加する barcode_scan: ^0.0.3 dev_dependencies: flutter_test: sdk: flutter # 以下省略
編集後は、packages getボタンを必ず押してください。
QRアプリのプログラミング
いよいよアプリのプログラミングをしていきます。
lib/main.dartを以下のように編集します。
重要な点には、コメントを付けていますので合わせてお読みください。
import 'package:flutter/material.dart'; // 必要なQRコードを読み取る際に必要なpackageをインポート import 'package:flutter/material.dart'; import 'package:barcode_scan/barcode_scan.dart'; import 'package:flutter/services.dart'; void main() => runApp(MyApp()); class MyApp extends StatelessWidget { @override Widget build(BuildContext context) { return MaterialApp( title: 'QR scaner And QR Maker', theme: ThemeData( primarySwatch: Colors.blue, ), home: MyHomePage(title: 'QR scaner And QR Maker'), ); } } class MyHomePage extends StatefulWidget { MyHomePage({Key key, this.title}) : super(key: key); final String title; @override _MyHomePageState createState() => _MyHomePageState(); } class _MyHomePageState extends State<MyHomePage> { // 読み取り結果を格納するString型の変数readData String readData = ""; /// QR及びバーコードスキャンを行うメソッドscan() /// Future:非同期処理を実現する Future scan() async { try { // String型のcodeにBarcodeScanner.scan()の結果を代入 // await:非同期対応の要素のキーワード String code = await BarcodeScanner.scan(); // readDataに読み取ったデータを格納する setState(() => this.readData = code); } // 例外処理:プラグインが何らかのエラーを出したとき on PlatformException catch (e) { // エラーコードがBarcodeScanner.CameraAccessDeniedであるときは、 // このアプリにカメラ機能のパーミッションを許可していない状態であることを示す if (e.code == BarcodeScanner.CameraAccessDenied) { setState(() { // readDataにエラー内容を代入 this.readData = 'カメラのパーミッションが有効になっていません。'; }); } // その他の場合は不明のエラー else { setState(() => this.readData = '原因不明のエラー: $e'); } } // 意図しない入力、操作を受けたとき on FormatException{ setState(() => this.readData = '読み取れませんでした (スキャンを開始する前に戻るボタンを使用しました)'); } catch (e) { setState(() => this.readData = '不明なエラー: $e'); } } @override Widget build(BuildContext context) { return Scaffold( appBar: AppBar( title: Text(widget.title), ), body: Center( child: Column( mainAxisAlignment: MainAxisAlignment.center, children: <Widget>[ Text( 'QRボタンを押すと読み取りを開始します', ), Text( // 読み取り結果readDataを表示 '$readData', style: Theme.of(context).textTheme.display1, ), ], ), ), // ボタンを用意する floatingActionButton: FloatingActionButton( // onPressed:ボタンを押すことでscan()という関数が実行される onPressed: scan, tooltip: 'QR SCAN', child: Icon(Icons.add), ), // This trailing comma makes auto-formatting nicer for build methods. ); } }
実行結果
プログラムを実行すると、以下のような画面が現れます。
下側のボタンを押すと、以下のようにカメラ画面が表示されます。
QRコードを読み取ると、トップの画面に戻り読み取った結果が表示されます。
バーコードの読み取りもできます。