幡ヶ谷亭直吉ブログ

娘のここねと格闘するエンジニア。

SHIFT Agile FES に参加しました

SHIFT Agile FES に参加しました。

イベントの概要

SHIFT Agile FES (Agile Japan Satellite)
SHIFT Agile FESは、アジャイルをテーマとしたSHIFT主催のカンファレンス。
国内最大級のアジャイルカンファレンスである「Agile Japan」のサテライトイベントとして開催します。


People-Centric Agile : Crafting Quality
アジャイルだからこそ実現できる品質がある。
品質にプライドをもつSHIFTが、エンジニア組織のあり方も含め、人間中心のアジャイルをともに考え、議論する場を創ります。

▼公式サイト
https://contents.shiftinc.jp/shift-agile-fes/

▼プレスリリース
https://prtimes.jp/main/html/rd/p/000000090.000018724.html

引用:

shiftevolve.connpass.com

イベント参加の背景

  • 及川さんと吉羽さんの本にいつも多くの学びと刺激を頂いている。
  • 先日のデブサミでもおふたりの講演が最高でした。
  • まさかその2人のお話を1日でお聞きできるだなんて!と参加!

セッション

  1. KEYNOTE 1】生成AI時代における人間の情熱とプロダクト志向

    speakerdeck.com

    ■メモ
    プロダクトが誰の何のためのものか説明できるか?
    生成AIの活用が不可欠となる中でいかに人が意思を持ってものごとを進めていくか。
    今まで:AIは副操縦士。今後:パートナー。操縦を任せられる存在に。
    AIの操作感が人間と相対するのと変わらなくなってきている。

    そもそもプログラミングとは?
    ・抽象化
    コンピューターからの距離が遠くなってきている。機械語高級言語
    ・ビジネス用途の最適化
    コンピューターは計算機で、プログラミングも計算だった。
    ビジネス用途のプログラミングの進化。
    ビジネス用途、ビジネス要件をいかにコンピューターに実現させるか。

    生成AIによるプログラミングは今までの経路の延長線上にある。
    プログラミングは手段である。
    本質はプロダクトであり、プロダクトが価値をもたらすこと。

    コードを書くことではなく、ソフトウェアからの体験がプログラミングのゴール。

    今後、抽象化の流れが続いていくと。
    要件定義は必要。機能+非機能。コンピューター領域に対する知見は必要。
    ただ、分からなくてもAIからのサポートで実現できるかも知れない。
    なので、要求定義ができればソフトウェアは作れるかも知れない。

    ただ、自分が作りたいものをはっきり伝えられることが重要となる。
    ビジネスとして何を実現したいかが重要となる。
    どんなに手段が変わっても、実現したいものは変わらない。

    進化を否定するものではない。
    AIは柔軟性が高い。ただ、曖昧性が残る。
    開発は型に重きをもった取り組み。なので、AIだけでは実現ができない。

    ソフトウェアエンジニアの苦悩。
    生成AIに代替されると危惧されるスキルの再定義が必要。
    進化は2極化する。
    高度専門エンジニア。AIに任せられない領域のエンジニア。
    AI活用型エンジニア。ジュニアが不要になる。中間層がリスクを抱える。
    ただ、残るエンジニアが居なくなった後にリスクが生まれる。

    価値創造を目指すものの、現場としては手段に拘って価値を目指せていない。
    価値創造の本質:事業継続のための収益、世界を変えるビジョン、顧客。
    アジャイル、生成AIを目的化しない。

    美しい鰭。

    takoratta.hatenablog.com


    創造性とは逸脱すること。ズレは発散的要素を入れているだけ。
    価値創造への執着心とビジネスに対する戦略。仲間との共創。
    他者に認められること。ロゴス(論理)、パトス(共感)、エトス(信頼)。
    アマビールの創造性の定義。創造的思考、専門知識、動機付け。
    動機付けには、内発的、外発的がある。
    内発的動機付けがモチベーション理論で一番重要とされている。
    ただ、すべてを結びつけることができない。
    外発的動機付けから着手したものを内部的動機付けに持っていくことが重要。

    情熱駆動開発。
    スタートアップに大企業が勝てないのは情熱。
    価値の創造に向き合う。顧客価値・事業価値。
    そのために、技術を磨く。

    AIを使うが使われてはいけない。
    AIに模範されるぐらいの創造性を発揮する。

    ■感想
    及川さんのお話にいつも熱を頂いています。今回はエンジニアの今後についての話でした。
    ソフトウェアファーストでの手の内化と同じ文脈のまま、むしろエンジニアがプロダクトに求められる意思に同期できないと手段のひとつのままであれば代替されてしまうという話として聞いていました。
    AskTheSpeakerではエンジニアが事業領域に食い込む以外のあり方について質問をさせて頂きました。恐らくは我々が行っていることを構造化して把握することで、AIに対してオーナーシップを発揮して活躍できる領域はあるのではとイメージできました。

  2. 幸せに働ける組織を目指すリーダーの葛藤と挑戦

    speakerdeck.com

    ■メモ
    □クリエーションライン
    1回目の落ち込み。
    理念・ビジョンいらないと思っていた。
    欲で取った案件で炎上し、メンバーが離散した。
    その時読んだのが『TeamGeak』。
    どん底の時にはなんでもやる。そうした時に理念・ビジョンは遠い存在。
    ただ、『TeamGeak』を通してHRTを学んだ。

    www.oreilly.co.jp


    2回目の落ち込み。
    共創をテーマにかかげていたが、作ることが目的化してしまい、ビジネスパートナー含め人をどんどん増やしていた。
    ただ、管理できなくなっていたし、できていないことに気付けていなかった。
    事業方針に対するオーナーシップを持てずにいた。
    やらないことを決め、事業方針の一貫性を取り戻した。

    職場に重視していること。
    ・HRT
    ・知的コンバットができる
    ・透明性、検査、適応のサイクルが回っている

    今後のとりくみ。
    ITエンジニアの社会的地位向上。
    価値創出にコミット。Co-Creation Startup事業。

    □SHIFT
    価値観の分断。
    オペレーションエクセレンス。効率・型化の追求。
    ただ、生産性の高いクリエイティブなチームには悩みが必要。

    葛藤。
    単価評価が誘発する個人主義成果主義の誤解。
    挑戦。
    評価タイプの拡大。単価を支えるスキルの分解。プロセスを賞賛する仕掛け。

    事業成長、事業拡大は目的を見えにくくさせる。

    職場に重視していること。
    ・やりがいのあるミッションと成功体験
    ・一緒に成長できる仲間
    ・評価と報酬に結びつく仕組み

    今後のとりくみ。
    エンジニアリングだけでは達成できない規模の経済による業界構造変革。

    ■感想
    クリエーションラインさんのお話がとても興味深かったです。
    共創のための新しい事業をはじめたというお話は、受託側のエンジニアとしてとても心強く感じました。
    先日のこちらのお話も考えるところが大きかったです。

    youtu.be

  3. KEYNOTE 2】Kent Beckの思想と学びの道筋

    speakerdeck.com

    ■メモ
    ケント・ベックのキャリア。
    1961年生まれ。87年までオレゴン大学。
    要件定義の重要性を学ぶ。
    84年Smalltalkに傾倒。87年オブジェクト指向言語に関する論文を執筆。
    96年のクライスラー社のC3プロジェクトがXP誕生のきっかけとなった。
    97年にJUnit開発。
    2001年アジャイルマニフェスト起草参加。
    2005年XP第二版。
    2011年Facebook入社(18年迄)スケールの複雑性、意思決定の可逆性を学ぶ。
    3Xモデル。Explore、Expand、Extract。探索、拡大、抽出。
    2022年。Help Geeks Feel Safe In The World。

    吉羽さんが初めて出会ったケント・ベックはXP第一版。
    当時開発リーダーだったため、実践を推し進めることができた。

    ケントベックが影響を受けた『パターン・ランゲージ』。

    kajima-publishing.co.jp

    今に至る岐路が当時から見えていた訳ではないと思うが、ケント・ベックの代表的な書籍にはアレクサンダーの名前が登場する。
    吉羽さんの翻訳書籍には、持ち込み企画。提案の両方がある。
    連続したシリーズを意図した出版ではないが、必ず吉羽さんの判断が入るため、似た領域のテーマとなる。

    自分たちのプロセスは自分たちのものにする。
    与えられたプロセスをこなすだけでなく、実践していることが重要。

    パーセンテージでの報告は意味がない。
    動くものにこそ価値はあるため、実物を見せて信頼を醸成する。

    ケント・ベックも優しくなった。
    チームの外側にも優しくなった。いろいろな価値観を尊重できるようになった。

    ■感想
    秋葉さんの吉羽さん愛あふれる時間でした。
    翻訳書籍についてのお話とても興味深かったです。
    私は『EffectiveDevOps』、『チームトポロジー』に強く影響を受け、『ダイナミック・リチーミング』に今改めて考えさせられています。
    AskTheSpeakerでもチーム形成についてお話お聞きしました。
    誰でもチームに対する刺激は与えられるかもしれないしできないかもしれない。
    コンテキストにも状況にも依存する。けど、やってみないと分からない。
    そうしたお話をお聞きできてうれしかったです。
    TidyTogetherもチームでの開発の話だと思っています。
    今から翻訳書を楽しみにしています。
    Findyさんの開発生産性カンファレンスも楽しみです。

    dev-productivity-con.findy-code.io

  4. 若手中心の内製アジャイル開発で研究開発に挑戦
    ■メモ
    アジャイルでの研究開発の実践からの学び。
    スクラム・オブ・スクラム。チームの悩みを話合う場ができた。
    メトリクスをDevチームに価値ある情報として提供。

    ■感想
    実践の共有の貴重さ。
    メトリクスを単純な数字ではなく価値あるものとして提供することや、
    コミュニティで自分たちの学びや体験を共有することの重要性を学びました。

  5. やめシフ大集合!!~SHIFT卒業生座談会~
    ■感想
    SHIFTから他の企業様に転職した方たちのお話。
    とても魅力的な方たちが在籍していたことを実感しました。

  6. トップエンジニアが語るDX最前線
    ■メモ
    内製化を進めていくうえでベンダーとの共存していくことを考えている。
    HOWの部分まで手の内化できるように進めている。
    SoEは内製化しやすい。SoRは内製化しづらい。
    一つの失敗が大きな影響を生む。
    内製化は良いことだけじゃなく、責任を背負う/覚悟することでもある。

    JTCはネガティブな印象がある。そうじゃない事例を作りたい。
    ウォーターフォール駄目は雑。
    アジャイルでもアウトカムでてないと意味がない。
    属性やラベルで判断できない。JTCでは何も判断できない。

    個人依存からの脱却。
    DXからすぐに始めることではない。まずは成果を出してから。
    金太郎あめのような再現性ばかりを追求しても、イノベーションは生まれない。   
    個人の力をいかんなく発揮できる方がエンタープライズも変わる気がする。
    承認行為はオーナーシップを無くす行為。
    不確実性を解消していく取り組みのうえでも支障となる。

    Connecting the Dotsを考えずに成功を目指していくことはできない。
    過去を知らない人が否定しても始まらない。
    対象を理解して上で、自分でできることをアドオンしていく必要がある。
    複雑性の高い対象を扱えるようになることが大事。
    予期しないことで個々人が繋がっていくこともある。

    従来の価値観mode1、スタートアップがmode2とした場合、相手のmodeが自分たちにとって重要になるタイミングがある。
    どちらの状態でも成果を出していくことが重要。

    enterprisezine.jp


    社会インフラの開発というキャッチコピーでそこまでエンジニアは集まらない。
    もっと情緒的な理由で人が集まる。
    AIに開発が代替されていく中で、開発には今後ますますヒューマンスキルが求められるかもしれない。
    内製開発はベンダーを介さずシステム利用に伴う痛みを直接実感できることでシステムの改善が進む。

    ■感想
    クレディセゾンさんもイオンさんもいつも大きな刺激を頂いています。
    今回、特に「内製化はキラキラした部分だけではなく、開発の責任を引き受けることでもある」という話が刺さりました。    
    ただ、受託側がその責任を引き受けたうえで開発に向き合えるかというと、微妙だとも感じています。
    実際のユーザーがシステムを利用する姿を見て、痛みの共感ができるか。
    自分事として感じられない限り、本質的な改善は後ずさりしていく気がしています。
    そうした上でも、クリエーションラインさんのように成果の実現を目指して共創していくことが、将来のあるべき姿なのかもしれないと感じました。

ブース

今度の技術書典に出展するきっかけとなった親方Projectさんに感謝をお伝え出来たのが嬉しかったです。
この本に背中を押してもらいました。

techbookfest.org

この本に製作のサポートをして頂きました。
nextpublishing.jp

前回の技書博後にDMでのやり取りさせて頂いた時にもアウトプットについて後押し頂いたことの感謝お伝え出来ました。嬉しい。

Findyさんブースでもいつもの感謝を。
Findyさん経由でのアウトプットにいつも多くの学びと刺激を頂いています。

アンカンファレンス

お昼休みに『Be Agile』についてのセッションに参加しました。
「スプリントは2週間、レトロスペクティブは1週間という考え方もありではないか」という意見があり、興味深く感じました。
スクラムを「インクリメント」と「チーム」のための仕組みと捉えたとき、そのようなリズムが適したチームもあると思います。
また、スプリントレビューという行為も、単なるインクリメントの成果確認にとどまらず、ステークホルダーとの意思疎通を深めるための重要なアクションとして捉えるべきだと思いました。
『Be Agile』とはインクリメントやチームだけが担うものではなく、関係する人々がプロセスや状況を整えていくこと全体を指す言葉なのだと、改めてイメージすることができました。
濃厚な時間となりました。皆さまありがとうございました。

まとめ

朝から現地で参加し、途中で自宅に戻る必要があったため、途中からはオンラインで参加しました。
ハイブリッド開催、本当にありがたかったです。

一日を通して、あらためて「エンジニアが意図をもって開発に取り組むこと」の重要性を実感しました。
各キーノートはもちろん、すべてのセッションからそのような流れ伝わってきて引き締まる思いでした。

受け渡された作業をただこなすことは、近い未来かなりの確度でAIに代替されていくと思います。
そのうえで、アジャイルの文脈でも、エンジニアだけでなくプロダクト開発に関わるすべての人が、オーナーシップを持ってプロダクトの成功を目指していくことが今後ますます重要になっていくと感じました。

学びの多い1日をありがとうございました。