HOW TO GO

〜昨日の今日とは一味二味違うBlog〜

2023年のふりかえりと2024年の目標的なもの

ふりかえり&来年のこと。

去年の今頃はまだまだ収まっていなかったコロナウイルス感染症(COVID-19)は落ち着いたと言える状況になりました。まだ油断はできませんが「日常が戻ってきた」といえる1年だったと思います。

2023年の記録

ライフスタイル・ワークスタイル

仕事では公共の世界に足を踏み入れて1年2カ月が経ちました。リモートワークの割合は10~20%ほどでしょうか。民間企業にいた頃からずいぶんと働き方や生活が変わりました。

9月からは公務員からほぼ公の財団法人に移籍し、新たな組織の立ち上げの真っただ中です。

運動(カッコは前年比)

  • フットサル:20回(-13)
  • ジム:16回(+6)
  • ランニング:26回(-50)
  • ゴルフ:3回(-32)
    • 練習:2回(-21)
    • ラウンド:2回(-9)
  • 登山:6回

去年たくさん行ったゴルフにあまり行かなくなりました。一緒に行く友人が離れてしまったことが原因。今年はもう少し行きたい。 そして運動の数が全体的に減りました。リモートワークが減り時間が取れないのと疲れてる中だとどうも怪我が怖くてサボりがちです。

学びの活動

登壇が増えました。外に発信できる仕事ができ、声を頂けるのは幸せなことです。

読書は毎年20冊くらいの水準に戻りました。やはり通勤電車生活が戻ったことが大きいのでしょう。

資格取得も意識しました。技術知識を意識してインプットしないと。

その他の活動

出張で地域のデジタル化の課題(またはデジタル化じゃない課題)を聞く機会に恵まれました。課題をしっかり認識した上での課題解決です。今後とも足を運んでいきたい。

2023年のトピックス

転職(移籍)

広域自治体(地方公務員)から財団法人に転職しました。転職と言っても仕事を変えたわけではなく籍をおく組織が変わっただけです。引き続き行政のDXに取り組みます。

コミュニティが広がった

行政関係のお仕事をする方々と繋がりが作れた1年でした。1年前にデッカイギ(行政デジタル改革共創会議)に参加し、全国の自治体職員の方々のパワーと真摯さに感銘を受けたのが昨年で1番大きな出来事でした。

昨年はほぼボッチ参加でしたが1年経った今年は同じ職場の同僚もたくさん参加してくれる予定です。 (スタッフとしても微力ながらお手伝いさせていただきます)

またクラウドのコミュニティにも積極的に参加しました。クラスメソッド社に在籍していた頃よりクラウドの資格も増え仲間も増えました(笑)

2024年どうするか

根気よくやるべきことをやる

行政のDXに引き続き関わっていきます。この1年、様々な都合でやるべきことができないことも経験してきました。物事には良きタイミングというものがあるのだろうなと思いながら腐らず根気よくやり続けます。

すぐに実現できない状況でも「やるべきこと」に間違いはありません。諦めることのほうが損失です。必ずやる。

広がりを意識する

場を広げることで貢献できることがあると感じた1年でもありました。機会があれば様々な場所でお手伝いをできれば嬉しく思います。

フィジカル、インテリジェンス

「読書増やす」「資格取得」を意識してインプットを増やしつつ、運動量をもう少し増やしつつフィジカルをキープし良いパフォーマンスを出せるように。

今年も頑張ろう。

ガバメントクラウド 共同利用におけるコスト構造の課題について(2023.10.6)

本記事では2023年10月6日時点で私が感じているガバメントクラウドのコスト構造の課題について記載します。

今後、制度やスキームが改善され課題が解消することを願いつつ現時点はこのような課題があったことの記録として。 この記事が課題解決の一助になれば幸いです。

※本記事は個人的な見解であり、所属する団体・組織の見解ではありません。念のため。

この記事で扱う課題は「ガバメントクラウドのコスト」

本記事では「ガバメントクラウド 共同利用時のコスト」にフォーカスします。

標準仕様書のFit&Gap問題(実運用との乖離)、クラウドの運用管理補助者の担い手問題(自治体の情報システム部門の過負荷問題)、移行困難団体とそれに関連する補助金の額および期限、などなど多くの課題があると思いますが本記事ではガバメントクラウド共同利用におけるコスト問題を扱います。

ガバメントクラウドの契約スキーム

まずは前提条件としてガバメントクラウドの契約スキームをおさらいします。

地方公共団体情報システムのガバメントクラウドの利用に関する基準 【第1.0版】

この契約スキームのポイントは

という点にあります。

ガバメントクラウド「単独利用」「共同利用」

こちらもおさらいです。

デジタル庁は大きく「単独利用」と「共同利用」の2つの利用方法を提示しています。単独利用は民間企業と同じように1つの自治体がCSPのアカウントを専用につかう方法です。大きな規模の自治体は単独利用のほうがよいとされています。共同利用は複数の自治体で共同で管理する方法です。AWSでいうと1つのアカウントの中に複数の自治体のシステムを構築するようなイメージです。同一のシステム開発ベンダーのパッケージを利用している場合はベンダーにとって管理が容易になることからほとんどのベンダーは「共同利用」で進めたいと考えています。

共同利用における3つの方式

多くのシステム開発ベンダーが共同利用を推してるのですがその中に3つの方式があります。アカウント分離、ネットワーク分離、アプリケーション分離の3つです。AWSを例に概念を記載します。

  • アカウント分離:自治体ごとにAWSアカウントを別のものにし、それぞれに業務システムを構築する方式。監視、運用管理用のサーバーは共用アカウント上に構築する。
  • ネットワーク分離:1つのアカウント内の別VPC自治体ごとの業務システムを構築する方式。ストレージ、監視、運用管理用のサーバーは共用のVPC内に構築する。
  • アプリケーション分離:1つのAWSアカウントに複数の自治体が共用で利用する業務システムを構築する方式。いわゆるマルチテナントのシステム。

多くのシステム開発ベンダーは「アカウント分離」「ネットワーク分離」を採用する想定となると言われています。つまり「共同利用」と言いつつ実態は自治体ごとにサーバーとDBが構築されてしまう状態で2025年度末を迎えることになります。デジタル庁の言葉を借りれば「リソース効率の低い」方式です。もちろんコストは高くなります。

課題は「ランニングコスト」「コストガバナンス」の2つ

上記2つの課題があると考えています。詳細を以下に記載していきます。

ランニングコストの増加

1つめはランニングコストの懸念です。

上述したようにほとんどのシステム開発ベンダーは「アカウント分離」または「ネットワーク分離」方式でシステムを構築します。

純化すると以下の構造となります

  • ガバメントクラウドに移行する2025年度末時点では、現状の構成(オンプレやデータセンターで自治体ごとに個別にサーバーとDB構築されている構成)とほぼ変わらない構成となることが想定される
  • 2025年度末の期限もあり大きなアーキテクチャ変更を実施しないシステムが多い(モダン化、マネージドサービス利用は最小限)
  • 当然オンプレに比べるとサーバーの単価は高い
  • ネットワーク接続(専用線)の費用など純増する費用もある
  • よってランニングコストは増えることが想定される

もちろん2026年度以降にモダン化などでコスト効率化は可能だと思います。ただ私個人の経験からモダン化によるコスト削減でそこまで大きな効果が期待できるのか...という懸念があります(あくまで個人の推測です)

この課題に対してはモダン化での最適化とは別に「アプリケーション分離」への変換を模索すべきだと考えています。

2026年度からがランニングコスト削減のスタート

クラウドは従量課金モデルですので実運用が始まってからが本番です。コンピュートリソースなどの利用状況とコストのモニタリングを行い実測値からコスト削減施策を継続的に行っていく必要があります。

コスト削減施策はもちろんシステム改修が伴います。その費用は誰が出すのかというのも論点の1つにすべきでしょう。

コストガバナンスの難しさ

2つめはコストガバナンスの問題です。

いくつかの論点がありますので整理します。

共同利用ならではの費用の透明性の低さ

クラウド費用は自治体がデジタル庁を通してCSPに支払うことになりますが、共同利用方式となると費用の透明性が危うくなります。そもそもストレージや監視用の共用サーバーなどは厳密に費用を複数の自治体の利用実績で分割することは困難です。

平常運用時には「費用は人口比率で案分」のような取り決めがあれば問題ないと思いますが、例えば以下のようなトラブル時には単純な費用の案分とはならないでしょう。

  • どこかの自治体の利用が適切ではなく特定の処理でコンピュートリソースやストレージを使ってしまい費用が上がった
  • 問い合わせ(または障害)調査のために、調査用のサーバーとDBを作って調査・検証したため費用が上がった

契約スキーム

上述の契約スキームに記載した通り「クラウド費用はシステム開発ベンダーのビジネススキームの外」です。つまりインフラコストの削減はシステム開発ベンダーにとってインセンティブは小さいものになります。

※もちろんインフラ費用が安いほうが選ばれやすくなるので関係ないわけではありませんがベンダーを入れ替えるほどのインパクトにはならないのでは、という想定です

コストの正当性(適切さ)を見るのは誰か

コストの正当を見るのは誰?という問いの答えはもちろん自治体になります。ここでも課題があります。

  • クラウドインフラのコスト構造を理解する必要がある
    • クラウドのコスト構造がわかる職員が必要となる
    • 小規模な自治体ではこのような職員を配置できない懸念がある
    • 多くの自治体でマルチクラウド構成になることが想定される。1つのCSPだけでも把握しておくべき知識量は多いがマルチクラウドとなった場合はさらに難易度が増す
  • ベンダーごとのシステム構成はオープンにしてもらえるのか?という懸念
    • システム開発ベンダーにとってアーキテクチャはビジネスの種でありオープンにすることを敬遠する懸念がある
    • とはいえクラウドインフラの費用の正当性を確認するにはシステム構成を見る必要がある

ガバメントクラウドの契約スキームの都合上、「見せたくないシステム開発ベンダー」「見る必要があるが見ることが難しい自治体職員」という構図になってしまいます。

コスト削減を主導するのは誰か

コスト削減が可能な箇所がある場合、システム改修を行う必要があります。

  • そのシステム改修費用は誰が出すのか
    • 自治体?システム開発ベンダー?
    • システム開発を委託しているのであれば自治体が支払うべきだが、パッケージのようにサービス提供のような形式で導入しているシステムが多いので改修費用をすべて自治体が持つのかというと...?
  • 共同利用の場合の意思決定の難しさ
    • 仮に自治体が出す、となった場合に共同利用の場合は複数の自治体の意思決定が必要になる
    • 財政の状況や政策の優先順位によって支出できる額にバラつきが出てしまう可能性がある
    • このような調整は労力を使うことから自治体職員およびシステム開発ベンダーにとっては消極的になってしまう可能性がある

このように「誰が主導してどのように意思決定するのか」が複雑で調整や意思決定に多大な労力がかることが懸念されます。

まとめ

ガバメントクラウド共同利用時のランニングコストの問題とコストガバナンスの問題について記載しました。

移行期限やその他の制約によるコスト効率の低いシステム構成となってしまう現状の契約スキームではコストガバナンスを担う立場の不在という問題についてまとめました。

すぐにすべての問題が解消されることは困難かもしれませんが契約スキームの見直しは重要なことなのかなと感じています。

議論の広がり、深まりを願って

名古屋の高橋さんのnote、中島さんのPostに触発され、今の自分の考えを文章にしてみました。本記事で扱った課題はとても困難で大きなものです。もっとたくさんの人で議論を広げ、深めていきたいと思います。

note.com

また、2024年1月開催の「デッカイギ」でも議論の続きができると嬉しく思います。

www.dekaigi.org

最後に

この記事が同じような課題感を持ち、火中の栗をなんとかすべく奮闘している全国の仲間の課題解決の一助になれば幸いです。

CAPM®(Certified Associate in Project Management)を取得してきました

先日たまたまCertified Associate in Project Management(CAPM®)のことを知り、興味があったので実際に取得してきました。

みかけたのはかわたつさんのnoteです。
CAPM®とった話|かわたつ|note

受験の条件、学習の仕方などは上記noteに詳しく書いてありますのでこちらをご参照ください。
ここではなぜCAPM®を取得しようと思ったのか、受験しての感想などを記載します。

プロジェクトマネジメント知識の学習の難しさ

常々プロジェクトマネジメントについての体系的な知識の習得は難しいなと思っています。
そりゃPMBOKにまとまっているのですが、PMBOKを読もうと思うタイミングって普通に仕事している中であまりありません(個人の感想)。
私自身、プロジェクトマネジメントのことは実際にプロジェクトを一緒に進めつつWBSの書き方、品質管理のノウハウ、会議体設定の考え方などを先輩から教えて頂いた記憶があります。
実践的な知識は身につくものの、体系的な知識としては触れる機会は少なかったと思います。

資格取得の難しさ

プロジェクトマネージャーの資格といえばPMI(Project Management Institute)のPMPIPA情報処理技術者試験 プロジェクトマネージャ試験(PM)」があります。

PMP:「4,500時間以上の実務経験/3年のPM経験」が必要。経歴などの提出も必要。
IPA PM:経歴は不問だが、記述式の試験が含まれている
2つともプロジェクトマネージャーの経験を前提とした資格となっているため、経験を積まないと受験しようと思わない構造となっています。

体系的な知識 ⇔ 現場の経験のサイクルが重要

何事も「体系的な知識を得る」→「現場でやってみる」→「うまくできなかった部分を学びなおす」というサイクルを経て知識・スキルの定着・積み上げをしていきます。

プロジェクトマネジメントにおいては資格の難易度、条件が厳しいため体系的な知識を学ぶ機会が少ないのでは?と感じてました。
つまり知識⇔実践のサイクルがない状況です。
PjMが育つ・スキルアップする土壌としては心細いなと思っていました。

CAPM®は知識習得の入口として最適

そこでCAPM®は良い資格だなと思いました。
プロジェクト・チームメンバー、新人のプロジェクト・マネジャー、大学生、大学院を対象としており、受験資格としては23PDUがあればOKです。
資格取得をモチベーションに体系的な知識を学べるかと思います。

「プロジェクトマネジメントを学びたい人に勧められそう」と思ったのでまずは自分で取得してみたのでした。

【余談】CAPM®の知名度の低さ

周囲のPjMの方々、PMP保持者の方々数名に聞いてみたのですが、CAPM®のことを知っている人はいませんでした(笑)
ベテランPjMがこの試験のことを知り、若手PjMに学習の一環としてCAPM®を勧めるような状況にしていきたいですね。

「実践的データ基盤への処方箋」の読書メモ

仕事でデータ基盤のことを知る必要がでてきそうなのでこの本を手に取りました。
タイトルにもある通り著者の経験をもとにした実践的なシステム構成や勘所などが記載されています。よい本でした。

気になったところをメモ。

業務レイヤー(p.17)

https://gihyo.jp/assets/images/news/report/2022/06/0601/image11.png

データを生成または扱う人やシステムという業務とロール/オペレーション/アプリケーション/ストレージのレイヤーのマトリックスを作ります。 書籍にもあるように業務とレイヤーに分析・分割することでどの場所に対する改善案を行うのかが明確になります。

なんとなく全体を漠然とみて偶発的・思いつきの施策をやることを防げそうです。いい図。

履歴データ(p.24)

商品価格や商品説明などの変更を履歴として保存していないシステムの多々ありそうですが、「データ分析」という目線でみると非常に重要なのはその通りだなと思いました。

1か月前、1年前の価格がわからない(今の価格しかわからない)ようでは分析のしようがありません。言われるとその通りなのですがどの項目の変更をどこまで履歴として持つのかという要件はしっかり議論をすべきかと思います。

3層 データレイク層 / データウェアハウス層 / データマート層(p.26~)

言わずと知れた3層です。ぞれぞれの層での目的、注意点や勘所などが記載されています。基本として押さえておきたい知識です。

データマートはユースケースを想定して作る(p.38)

「データマートはユースケースを想定して作る」という視点はなかったので良いインプットとなりました。

これも言われてみるとその通りです。データマートを作るにはデータ活用をするユースケース(誰が何の目的でどのデータを見たいのか)を定義する必要があります。ユースケースが定義されていないとそのデータはいずれ活用されなくなるはずです。

メタデータ(p.48)

メタデータ」はあまり意識していませんでした。これも非常に重要な要素ですね。

データの作成された日や属性(個人情報の有無、文字列or数値、単位、etc...)などはデータがどのように加工されたのかによってわからなくなってくるので定義しておくことは重要です。

また「そのデータは誰がどのくらい見ているのか」のようなメタデータはデータ基盤の運用や改善に必須だと感じました。

データスチュワード(p.58)

データ基盤の整備を推進し、利用者からの相談窓口する役割を「データスチュワード」と言うそうです。

聞きなれない役割名ですが思えばこれも重要な役割であり、過去に名前は違えどこういう人がいるデータ基盤はうまくいっていたと思い起こされます。

データ基盤に関する要件を聞き出し、システム構成やコストなどを考慮しつつ仕様を策定し利用者に提供するようなイメージでしょうか。プロダクトマネージャーのような存在だと理解しました。

データソースから収集方法(p.71)

書籍ではデータソースごとに収集の方法は異なるよ、と記載されています。CSVや画像などのファイル、API、ログ、端末データ(IoTなど)によって収集方法が異なるため多くの知識やノウハウがあるとのこと。(このあたりは経験上よく知っていました)

データソースの正しさはデータ分析の命です。そこを担保するためにデータフォーマットを定義する「AVRO(Apache AVRO)」のような存在は重要かもしれません。意図しない誤りを防ぐにはこうした型の定義を担保する仕組みを導入するのは検討に値すると思いました。

同様に「Apache Perquet」のようなデータ圧縮の仕組みも視野に入れるべきかと思いました。

列指向型圧縮(p.137)

分析用DBは更新処理に向いていない、というのはなんとなく知っていましたが列指向型圧縮や列の統計情報を使っていることが学べました。なるほど、と。

分析に最適化されたDBの中で何をしているのかを少し理解できました。ありがたや。

データ活用組織の文化・土壌(p.158)

組織の偉い人、クライアントの大きな声に惑わされることなくデータを活用した意思決定ができる組織の文化・土壌についても書かれています。

・データに関する文化:データを使った意思決定、データを使った業務改善を行う文化があるかどうか 
・業務の実行と組織構造:データ活用を推進する部門と業務遂行する部門に乖離がないか 
・必要なスキルと人材:意思決定を行うCDO、仕組みを作るデータエンジニア、業務部門との橋渡し役のデータスチュワード、分析を意思決定に生かすデータアナリストの存在

集権型、分権型、ハイブリット型(p.160)

データ活用組織のありかたが提言されています。

・初期は「集権型」:データ活用を一気に推進するために集権型の組織を作る。人数も少ないので分散させるより集中的な組織とする。 
・中期は「分権型」:人数が増えると本当に必要な業務部門に人材を分散させる。業務部門への展開を狙う。 
・成熟期は「ハイブリット型」:各業務部門に展開しつつ、横串的に実施する施策もある。両面で活用が推進できるようにする。 

理想的な展開とは思いますが、業務部門への展開、人材の採用では課題が多くありそうです。頑張りどころなのでしょう。

データ組織の成功要因(p.162)

「データマネジメント知識体系ガイド 第二版」(日経BP, 2018)の10要素(の中の9要素)を解説してます。どれも重要な要素です。

  1. 幹部からの支援
  2. 明確なビジョン
  3. 前向きに取り組むべきチェンジマネジメント
  4. リーダーシップ統制
  5. コミュニケーション
  6. ステークホルダーの関与
  7. オリエンテーションとトレーニン
  8. 導入状況の評価
  9. 基本理念の遵守
  10. 革命ではなく進化

データ活用とセキュリティ(p.176)、セキュリティポリシー(p.181)

技術的な話ではなく、組織としての運用の話です。エンジニア寄りの仕事をしているとこのあたりは「降りてくる」ものという意識ですが、データ組織としてはセキュリティなどの各種ポリシーを制定することはとても重要な仕事です。

まとめ

以上、気になったところのメモでした。
データ基盤、データ組織と簡単に言っても、業務の分析、システム構成や技術・勘所やノウハウ、メタデータなどの考え方、組織作り、セキュリティポリシーなど検討すべきポイントは多岐にわたることがよくわかりました。

皆さまもデータ基盤に関わる際にはご一読を。

2022年のふりかえりと2023年の目標的なもの

ふりかえり&来年のこと。

まだまだコロナウイルス感染症(COVID-19)は収まっていません。ただ世の中はいちいち大騒ぎせずイベントも旅行も元に戻りつつあります。 このことが良いことなのか良くないことなのかは今は判断できません。様子を見つつ生活や仕事を柔軟に変えていく必要があるのかなと思います。

2022年の記録

ライフスタイル・ワークスタイル

仕事の環境が変わりリモート中心から出勤するスタイルに変わりました。 朝の運動、夜の勉強会の参加などに影響がありそうです。 環境に適応しパフォーマンス出せるようにしなくては。

運動(カッコは前年比)

  • フットサル:33回(+5)
  • ジム:10回(-9)
  • ランニング:76回(-48)
  • ゴルフ:35回(+26)
    • 練習:22回(+13)
    • ショートコース:2回(±0)
    • ラウンド:11回(+3)

昨年からコンスタントにゴルフに行くようになりました。そこそこ上達して100を切ることを多くなりました。嬉しい。

朝ランを意識的に少し減らしました。疲れがあると脚が張ってしまいケガにつながることを懸念して。 朝ランのついで筋トレやHIITをするようになりジムに行くことが減りました。 懸垂10回×2、中山きんに君のHIIT動画をやるようにしてます。

学びの活動

  • セミナー登壇・コミュニティへの参加

    • XP祭り2022(ちょこっと出演したのみ)
    • DAコミュニティ(Disciplined Agile Japan)への参加
  • 勉強会・セミナーへの参加

    • Regional Scrum Gathering Tokyo 2022
    • Agile Lounge #1「大規模アジャイル開発を神話にしない戦略会議」
    • 星野リゾートアジャイル開発の実際 〜独自の経営戦略の実現を支えるチーム運営〜
    • 平鍋健児 ☓ 市谷聡啓 〜組織を芯からアジャイルにする対談〜
    • 選んだ場所でリーダーになる~CreationlineとClassmethodの場合
    • JSTQB カンファレンス in 2022 Autumn
  • 読書:8冊(+2)
  • 資格:1つ(±0)
    • DASA DevOpsファンダメンタル
  • メンター業:4名
    • 仕事の傍ら、以前交友があった方々との壁打ちの時間を作った
    • エンジニア、スタートアップのCTO、WEB制作/デザイン組織の事業部長の3名。社内でも1名の指導を行いました。(その他2名ほどは途中で終わりました)

読書は去年に引き続き少なかったです。毎年20冊くらいなのに今年は8冊。やはりもう少し増やさねば。 コミュニティ活動ではDAコミュニティに飛び込んでみました。定期的に体系的な知識を得てディスカッションする場はとても気に入っています。今後も楽しみな活動になりそう。

メンター業は経営目線のアクション、組織作り、評価制度など様々な悩みを一緒に考えたのはよい経験になりました。無償での活動ですが学びがありすぎるので今後も継続したいと思います。ありがたい。

その他の活動

  • サウナ・温泉・銭湯:19回(+1)
  • サッカー観戦(スタジアム):7回(+4)

コロナの収まりとともにサッカー観戦が増えました。声出し応援も一部試合で復活してスタジアムに感動が戻ってきたのが嬉しかったです。

2022年のトピックス

転職した

クラスメソッド株式会社にを退職し、11月から自治体のDXを進める職につきました。 不満があっての退職ではなく単純に自治体DXに興味があり、今後の自分の糧になると思ったからです。 自分の中では大いなるチャレンジです。楽しもうと思います。

メンター業の明と暗

メンター業は非常に有意義な時間となりました。 様々な立場での考えを聞きながら自分から何を伝えられるのかを考える場はとても緊張感があり良い場となりました。 また自然と傾聴を心掛けることにもつながり良い経験となっています。

一方で成果が得られなかった人もいました(その方々とのメンターは辞めました) その人の特性によっては成長の手助けはできないことを改めて認識させられました。コーチング・メンタリングに適していない人に対してはお互い徒労となることを学びました。誠実に成長を求める人と一緒に進みたいと思えました。

コーチング・メンタリングは難しいなと改めて感じた出来事でした(あまりポジティブな話ではないのですが自身としては大きなトピックなので記録として記しておきます)

2023年どうするか

深堀り

コミュニティ、仕事を深堀りしていきたいと思っています。

深い知識や経験・知見を得なければ価値が出せないと感じています。 特に仕事では公共分野のデジタル化という自身にとって新しいチャレンジです。分野としてフィールドは広く・深いことは2か月でよくわかったので、よく学び価値を出せるような行動をしていくのみです。

読書量の向上、運動をキープ

  • 読書増やす
  • 運動量をキープ、体調をキープ

を意識的に行っていきます。インテリジェンスとフィジカルが揃い、良いメンタルを保つことでパフォーマンスがでるはずです。

頑張ろう。

大谷 真史選手の引退に寄せて

大谷 真史 さんがサッカー選手を引退することを決断されました。
個人的に応援しているクリアソン新宿の選手でした。
一方的にお世話になったので引退によせて感謝を記したいと思います。

criacao.co.jp




大谷さんの動画に助けてもらった

大谷さんといえばこの動画です。
youtu.be

ユースチームのヨーロッパ遠征を記録した動画ですが、僕はこの動画に何度も助けられてきました。
おそらく10年近く前にチームビルディングやチェンジマネジメントを学ぶ際に「組織に変化を起こす」「ムーブメントを作る」の参考動画として拝見したのだと思います。
・ムーブメントを起こすには
・誰かが最初の1人となる
・2人目がとても重要
・3人目以降で大きな波になる
といった趣旨の学びだったと思います。

f:id:sugiim:20220110081437p:plain
最初は大谷さんが1人で踊り始めます

f:id:sugiim:20220110081640p:plain
大谷さんのチームメイトが2人目として踊りに加わります

f:id:sugiim:20220110081829p:plain
さらに他チームの方が3人目して参加

f:id:sugiim:20220110084724p:plain
すぐに大勢が参加してムーブメントとなりました



この動画に感銘を受けた僕はリーダーとして何か変化を進める時には必ず2人でやることを徹底してきたのでした。
その意味で僕がソフトウェア開発のチームでリーダーや部門長、コーチを務めてこれたのはこの動画・大谷さんのおかげなのだと思います。

直接お礼が言えた&活躍を見れた

3年前、クリアソン新宿の新加入選手として大谷さんを知りました。そしてあの動画の主人公だったことも知ります。
まさか本人と会えるとは思ってもみませんでしたのでとてもビックリしたのでした。

一言・二言の短い会話でしたがこの動画に何度も助けてもらったことのお礼をいう事ができ、その後3シーズン、クリアソン新宿でプレーする大谷さんを見ることができたのは幸せでした。
フォワードとして泥臭く、決して諦めず、熱いプレーを見るのが大好きでした。
(もっと試合を見に行っておけばよかったなぁ、と後悔してます)

引退に寄せて

ありがとうございました。お疲れ様でした。
次の場所でも熱く躍動する、魂で走る大谷さんを期待して。

2021年のふりかえりと2022年の目標的なもの

今更ながら2021年のふりかえりと今年の目標を。

f:id:sugiim:20220102184512j:plain

2021年、2022年になっても新型コロナウイルス感染症(COVID-19)は収まらず、仕事はリモートワーク中心のまま。 秋ごろから感染者数は激減し皆で会ってコミュニケーションをとれるようになったが油断はできない状況が続いています。

2021年の記録

ライフスタイル・ワークスタイル

  • 仕事はリモートワーク中心となった
  • 実際に会って仕事をしましょう、ということはなくなった
  • 転職後、同僚とあまり会えないので名前と顔を覚えらえれない
  • リモートワーク、運動、リラックスする時間のバランスがよくなってきた
  • 身体に無理をかけずに生活することを心掛けるようになった
    • 睡眠時間が増えた
    • 風呂に長く入る、ストレッチするなど身体のケアに時間をかけるようなった

運動

  • フットサル:28回
  • ジム:19回
  • ランニング:124回
  • ゴルフ:19回
    • 練習:9回
    • ショートコース:2回
    • ラウンド:8回

ジムを再開しつつ朝ランも継続したが足の痛みもあり回数は減らした。 ゴルフ仲間が増えたので回数が増えた。少し上手くなって楽しくなってきた。7月に初めて100を切った。 運動は定期的にできているが右足もも裏の張りがとれず痛みと付き合いながら。歳をとるとはこういうことだ。

学びの活動

  • 勉強会・セミナー・研修:10回
  • セミナー登壇:1回(少しだけだけど)
  • 資格:1つ(AWS-CLF)
  • 読書:6冊
  • blog:5本

読書が少なかった。毎年20冊くらいなのに今年は6冊。 リモートの弊害なのだが何か改善策を考えないと良くない。

その他の活動

  • サウナ・温泉・銭湯:18回
  • サッカー観戦(スタジアム):3回

サッカー観戦はまだまだ足が遠のいている状態。スタジアムで声を出せないのがなぁ・・・。

2021年のトピックス

始めたこと

  • 英語の勉強を始めた
    • 英会話レッスンを会社負担で受講できるので15年ぶりに英語の勉強を始めた
    • 思ったよりできなくなっていて苦しい
    • 継続して頑張る
  • 平日の飲酒を減らした
    • 何もない平日は飲酒をしないようにした
    • だましだましきたけど健康診断の数値が怪しくなりつつあったから
    • それほど抵抗なくできているので継続する

転職した

  • 2021年8月に株式会社アイリッジ → クラスメソッド株式会社に転職した
  • なぜ辞めたのかはあまり語るまい
    • 組織・プロダクトを一緒に作ってきたチームのみんなと離れるのは寂しいし申し訳ない気持ちだった
  • 8月からは「内製化支援コーチ」という肩書になり様々な開発現場の支援をする仕事をする
  • 新しい仕事を楽しめそう

2022年どうするか

  • 支援者(コーチ)としての知識・経験を得る
  • 「内製化支援」という仕事のよい事例を構築する
  • 可能性を感じる分野にも手を出す

新しい仕事、新しい仲間、新しいクライアント。 多く学び、多くチャレンジし、開発現場を少しでも良くする仕事を目指して頑張る。