冴えた頭で、楽しくスクラム開発するための食事法

ここ数年、加齢と共に増える体重、仕事中の強い空腹感、食後を襲う不自然な眠気に問題を感じていた。眠い時間と、空腹の時間が、1日のうちの多くを占めているようでは、いくらScrumを実践していても、生産性を高めることは難しい。


1年ほど前から、「シリコンバレー式 自分を変える最強の食事」を読んだことをきっかけに、食事の内容を大きく変えた。
主には、パンから、シリアル、オートミールを変えても、会社に着く頃には空腹になっていた朝食をバターコーヒーに変えたところ、空腹感が劇的に緩和された。
昼食から炭水化物(ご飯、麺類)を無くすことによって、昼食後の眠気が大幅に改善された。

結果として、1日に実際に生産的に仕事に取り組める時間が大幅に増加した。

そもそもソフトウエア開発は、人の古来からの自然な状態に比べると、運動不足になりがちだ。知的労働者には、それに向いた食事が必要である。
Googleでは、GoodなエンジニアとGreateなエンジニアの違いを解析し、血糖値の安定をKPIにとして、エンジニアに料理を教えているらしい。
ブドウ糖は、食べ過ぎるとインスリンを生成して脂肪が蓄積され、食事から3、4時間経つと、血糖値は低下してしまう。ことため、少量づつ、3、4時間おきに食事をする事が、血糖値の安定には望ましいが、なかなかそもいかないだろう。

ここで紹介する食事法では、血糖値よりも、安定して脳にエネルギーを供給するケトン体に着目している。
脳は、ブドウ糖しかエネルギー源にできないと言われる事もあるが、それは誤りで脂肪を分解して、生成されるケトン体も脳のエネルギーとして利用可能であることがわかっている。
ケトン体は、ブドウ糖よりも長時間、安定してエネルギーを供給できる事がわかっており、朝のバターコーヒーにに含まれるMCTオイルが、分解される事によって生成される。

食事を変えた現在、体重は20歳のころに戻り、空腹感は半減し、食後の眠気はほぼ解消している。

過去には様々なパラダイムシフトがあった。

「すべての物体はお互いに引き合っている」
「地球は回っている」
「人類は進化した生物の1つの種である」

WFからアジャイルに移行した皆さん!常識を疑い、真の原則をみつける事には敏感ですよね。 現在は以下の進行中のパラダイムシフトの真っ只中。

「WF開発にはメリットは無い」
「傷口を消毒してはいけない」
「痩せたければ、脂肪を摂ろう」

パラダイムシフトを見極めて、より良い道を選ぼう!

 
 

Outline/Structure of the Experience Report

  1. 自分の動機と実施結果
  2. これまでの、ダイエット法
  3. 人類の進化の歴史
  4. シリコンバレー式ダイエットとバターコーヒー 
  5. 糖質(炭水化物)制限ダイエットについて
  6. パラダイムシフトについて

Learning Outcome

糖質制限ダイエットについての理解

パラダイムシフトについて知る

Target Audience

体重が気になる方、空腹、食後の眠気などを感じる方

schedule Submitted 4 years ago

Public Feedback


    • 武市 大志
      keyboard_arrow_down

      武市 大志 - 日経電子版 穴のあいたバケツ開発

      60 Mins
      Keynote
      Intermediate

      日経電子版は2015年に日経電子版アプリを全面リニューアルし、その後の継続的な改善リリースによってアクティブユーザー数を1年で2倍に押し上げ、AppStoreのおすすめベストニュースAppにも選ばれました。

      これらを実現したのはレガシーな開発体制からの脱却、社員がメインエンジニアとしてプログラムを書く内製開発、そして部局の壁を越えて理想を実現するためのチーム力でした。アジャイル開発を進める上で遭遇した課題・解決策、そしてこれからの展望をお話しします。

    • Hiroyuki Ito/伊藤 宏幸
      keyboard_arrow_down

      Hiroyuki Ito/伊藤 宏幸 - アジャイル・メトリクス実践ガイド

      45 Mins
      Talk
      Intermediate
      アジャイルの文脈において、メトリクスの取得・活用は、もはや一般的なこととなりつつあります。
      メトリクスには、仮説検証に基づく経験主義的な行動を促し、結果として自律的成長や協働につながるという側面があります。
      一方でプロダクト開発の現場からは、「メトリクスの取り方がよく分からない」・「どう活用すれば良いのか分からない」といった意見も耳にします。
       
      当セッションでは、プロダクト開発の現場の「メトリクス難民」を救うため、メトリクスの学術的裏付け、具体的な取得・活用方法および事例を、
      Agile2016・SQiP2016の最新の知見を踏まえながらご紹介させていただきます。
       
      さぁ、皆さんも爆ぜましょう!
    • Harada Kiro
      Harada Kiro
      CEO and Agile Coach
      Attractor Inc.
      schedule 4 years ago
      Sold Out!
      45 Mins
      Talk
      Beginner

      Kaizen is a Japanese word that means continuous improvements.

      However, people usually find that make one improvement is easy but having improvements continuously is not that easy and rarely could keep them continue.

      In this session, we present Kaizen patterns where teams can use to help themselves to achieve continuous improvements.

    • Toshiyuki Ohtomo
      keyboard_arrow_down

      Toshiyuki Ohtomo - 缶詰屋さんの課題解決にスクラムを使ってみた

      20 Mins
      Experience Report
      Intermediate

      〜スクラムマスターが求められているのは、ソフトウェアの世界に限ったことじゃないを実践したみた結果を共有します〜

       

      自然派オリジナル缶詰の制作、販売を行う会社とお店を立ち上げたばかりの元エンジニアの社長さん。

      やりたいことが沢山ある中、お店をオープンしました。
      まずは店舗運営の初期メンバーを3人雇ったけれど、その人達の日々の仕事を考えること(指示出し)で手一杯になって、本当にやりたかったことになかなか手を付けられない日々。

       

      ストレスがたまる中、そういえばエンジニア時代にも同じことがあったような。

      あのときは、スクラムを取り入れることに挑戦したな。

       

      ただ、どうすればスクラムを缶詰屋さんに適応することができるのか。

       

      手探りで缶詰屋さんにスクラムを適応した、社長さんとスクラムマスターのお話をします。

       

    • Takahiro Kaihara
      keyboard_arrow_down

      Takahiro Kaihara - つらい問題に出会ったら

      Takahiro Kaihara
      Takahiro Kaihara
      Jester
      Tao of Scrum Kansai
      schedule 4 years ago
      Sold Out!
      20 Mins
      Talk
      Intermediate

      スクラムに取り組むと、とても解決が難しい問題を掘り当ててしまうことがあります。
       
      ロジカルには解決できないような問題 --- 例えば、

      マネジメント層に不信感をもっていたり

      何かが原因で孤立してしまった人、

      原因を誰のせいにもできない問題でつまづいてしまった人…


      組織で働いていると、矛盾、葛藤、理不尽な問題はたくさんあります。
       
      そのような体験をしたり発見した方は多いのではないでしょうか?
       
      私もスクラムチームを支援する立場として、そのようなつらく難しい問題に直面し悩みました。
       
      そんな時にふとしたきっかけで、私はコーチングのプロのコーチに

      『つらい問題に出会ったときの向き合い方』が存在することを教えてもらいました。

       

      それは、ある「対話」のやり方でした。
       
      そこで得た知識と経験を、Regional Scrum Gathering Tokyo 2017 に参加される皆さんにも共有したいと思います。

    • Ryutaro YOSHIBA (Ryuzee)
      keyboard_arrow_down

      Ryutaro YOSHIBA (Ryuzee) - Pitfalls of Scrum -- My findings from coaching / スクラムの落とし穴 〜アジャイルコーチが遭遇するよくある問題とその解決方法

      45 Mins
      Talk
      Intermediate

      As an agile coach, I've been finding and watching lots of failure or mistake or misunderstanding related to Scrum. This session will introduce common pitfalls that many team encounter and will provide the way how to avoid those pitfalls.

      アジャイルコーチとしてスクラムに関する多くの失敗や間違い、誤解を見てきました。本セッションではよくある落とし穴や問題、間違いと、それをどう避けるかについて解説します。

    • Takao Oyobe
      keyboard_arrow_down

      Takao Oyobe - シン・未来会議 - スクラムチームを支える組織づくり -

      20 Mins
      Talk
      Intermediate

      自分たちの組織をどうやって改善するのか

      特にエンジニアは組織の話となると嫌厭しがちです。
      わかります、自分もそうでした。

      でも、身近な改善を続けると必ず組織の問題にぶつかります(ました)。
      昨今話題のDevOpsやMicroserviceの話をとりあげてみても、組織とは切っても切り離せません。

      そんな時にもちろん今とは違ういい組織を探すことも一つの選択肢です。
      しかし、そんな都合がいい組織は果たしてあるのでしょうか。
      仮にあったとして自分がそこに都合よく入れるのでしょうか。

       

      そんなことを考えた1エンジニアが、組織を変えることを考えて「未来会議」というものをやってみた話をします。

      自分たちのどうやって組織と向き合えばいいのか、どういう組織を目指すべきなのか一緒に考えませんか?

       

    • Yosuke Matsuura
      keyboard_arrow_down

      Yosuke Matsuura - 最短で成果を上げる!強いスクラムチームの作り方

      45 Mins
      Case Study
      Beginner

      頑張ったのに成果として認められないから脱却し、「最短で成果を上げる」ためのノウハウをご紹介します。
      私は、2011年にスクラムと出会ってから、ほぼ毎期で社内賞または社外賞を14件受賞することができるように成長できました。
      (補足:スクラム実践前は、ウォーターフォール開発のエンジニアでしたが、社内賞・社外賞からは無縁でした。。)
      最短で成果を上げるためには、「強いスクラムチームを作る」ことが大切だと実感しております。

      なぜ、スクラムチームをつくる必要があるのか?、どのようにしたら、強いスクラムチームを作ることができるのか?を成功・失敗事例を交えながらご紹介いたします。
      また、現場では、スクラムによるアジャイルな開発を導入していない方にも、明日からすぐ実践できる秘訣をご紹介いたします。

    • Mitsuyuki Shiiba
      keyboard_arrow_down

      Mitsuyuki Shiiba - 結果的にスクラムになってる!なのがいいと思う!

      20 Mins
      Experience Report
      Intermediate

      この5年間くらい、いくつかのチームをスクラムな開発チームにしてきたんだけど。「スクラムをやろう!」ってしてると、あんまりうまくいかないなぁって感じある。じゃあどうすんの?って「結果的にスクラムになってる!」ってのが良さそうだなって思う。

      今、僕のサポートしているチームは全員がペアで仕事をしていて、スプリントの期間は1週間。開発チームと運用チームがあって、そのメンバーが2スプリント毎に入れ替わって知識を共有していってるから、全員がお互いにカバーできる状況になってるの。ペア作業をやるなんて余裕があっていいなって言われたりするんだけど全然そんなことなくて、めちゃめちゃ忙しいチームだからこそ、こういう形にしてしまったんだよね。スクラムをやろうとしてやってたら、できなかっただろうなーって思う。ほんと、結果的にスクラムになったって感じ。

      僕の所属してる楽天の大阪支社の開発部は、ほとんど全部のチームがスクラムを取り入れた開発スタイルなんだけど、そのそれぞれが自分たちの担当しているサービスの特性や、ビジネスメンバーの考え方、開発チームの成熟度や、メンバーのスキルなどに合わせて、色んな形のスクラムになってるのも、そういうことなのかなって。

      スクラムをやろうとするとどういうところが良くないのか、結果的にスクラムになってるっていうのは具体的にどういうことなのか、で結局どうやって進めていくと良さそうなのかを、僕のこれまでの体験を交えながらお話ししたいなって思います。

    • 45 Mins
      Experience Report
      Intermediate

      あるチームがScrum、XPなどアジャイル手法を用いての開発、またアジャイルな姿勢、ふるまいができるようになってきたとします。
      その次のステップの1つとしてアジャイルなカルチャーを他のチームや組織に広げていくことがあります。
      それにより、学び続け、変化に対応できる組織となり、不確実な状況を生き残ることができます。

      しかしここに至るにはいくつもの壁や難しさがあります。
      ギルドワークスの現場コーチでは、様々なクライアントの現場にいる開発チームの改善から始まり、その後、プロダクト、サービスの事業、そして組織の改善まで行っています。

      このセッションではそのぶつかってきた壁、壁のアプローチ、その失敗談、また乗り越えることができたお話をします。

    • kyon _mm
      keyboard_arrow_down

      kyon _mm - Scrumありがとう、そしてさようなら-Scrum 破-

      kyon _mm
      kyon _mm
      Test Architect
      オンザロード
      schedule 4 years ago
      Sold Out!
      45 Mins
      Experience Report
      Intermediate

      ScrumをScrum Guideに従ってやることから、次のステップに進んだ私がいるチームの事例発表になります。私達は2015年にテストやメトリクスを活用して、プロダクトにもプロジェクトにも透明性、検査、適応の3本柱を強化してきました。

      私達はいまやスクラムに別れを告げつつあります。スプリントは1日以下で、ロール(PO, SM, Member)はスプリント毎にクジで決定し、スプリントレビューはPO以外が全員個別にデモします。テストやメトリクスも更に洗練され、いまや私達は自分達のタスクを最小6分単位でスケジュール、追跡し、改善に役立てています。

      このチームが取り組んでいること、そしてどうしてこのようなことをやっているのかをみなさんにご紹介します。

    • Masahiro Taguchi
      keyboard_arrow_down

      Masahiro Taguchi - ゲーム開発を盛り上げる技術とチームを支え続ける原動力

      20 Mins
      Talk
      Beginner

      みなさんの開発現場は盛り上がっていますか? 開発現場では、チームが協力しあって取りかかることは重要だと思いますが、その場の空気が盛り上がっていないと、チームが協働的に取り組むことが難しくなってきます。

      また近年のゲーム開発では、開発規模がますます巨大化していく上に、市場やお客様のニーズも日々変化してきているため、開発の複雑さも増してきており、そうした中でライバルよりも良いプロダクトをお客様に早く届けることがビジネスとして重要であり、そのために開発プロセスや考え方もそれに合わせて変化させていくことが重要になっています。

      本セッションでは、ゲーム業界でのソフトウェア開発の特徴をお話した上で、私が開発現場をもっと良くしていくためにどのような取り組みを行ったのか、またどのような想いを持ってチームを支え続けてきたのかをお話したいと思います。

      関西人なので面白おかしく話すことを保証します!

    • Daisuke Watanabe
      keyboard_arrow_down

      Daisuke Watanabe - スケールアップする組織におけるLeSS実践と継続的改善手法

      20 Mins
      Talk
      Beginner

      「最高の開発チームをビルドしたい、開発現場をよりよくしたい!」

      日々そう考えている皆さんと同じく、Gunosyの開発チームでも様々な課題を解決しながら組織をスケールアップし、現在はLeSSの導入実践を試みています。このセッションではフラットで10名規模の開発メンバーから50名規模のクロスファンクショナルなLeSS開発組織へスケールアップを行うときにでてきた課題と、それを乗り越える際に重視したポイントをリアルにお伝えしたいと思います。

      私達の経験のご紹介と、厳しくも楽しみながらいかに開発をよりよくしていけばよいのか、皆様の開発現場での改善の一助になるようなセッションになれば幸いです。

    • Yudai Moriya
      keyboard_arrow_down

      Yudai Moriya / Akihisa Kodera / Hiroshi Muto / Jun Obata - 学生がチーム開発のメンタリングを改善したひと夏の話

      20 Mins
      Talk
      Beginner

      筑波大学大学院 M2 4人による発表です.

      筑波大学では,毎年8月に2週間のenPiT開発合宿を開催しています.全国の大学から100名近くのM1の受講生が参加し,10数チームに分かれて,プロジェクトを通してチーム開発を学んでいます.

      そこには,前回の受講生であるM2の学生が,教員や社会人とともにメンターとして参加しています.

      合宿中は,受講生チームの朝会を必要に応じてファシリテーションし,Scrum of Scrumsを実施して情報共有を行っていました.

      これまでメンターは,受講生をサポートする仕組みを作り,毎年改善してきました.
      昨年の受講生だった僕たちの経験から,メンターをもっと有効活用する方法はないかと考え,"enPiT Go"というメンター呼び出しシステムを作成し導入しました.

      本セッションでは,このメンタ―呼び出しシステムと,Scrum of Scrumsを使ったメンタリングの仕組みについてお話します.
      Scrumの実践とメンタリングを経験した学生の体験談や,そこから得られた知見を共有します.

    • Stefan Nüsperling
      keyboard_arrow_down

      Stefan Nüsperling - Scale an Organization the Agile Way | 会社組織のスケールアップ

      45 Mins
      Workshop
      Intermediate

      In this workshop you will learn how to grow business in an agile way, with a simple card game called „Meddlers“, developed by Jurgen Appelo, the founder of Management 3.0.
      Management 3.0 is a pioneering approach to help creative organizations survive and thrive in the twenty-first century.

      The exercise allows players to visualize and discuss organizational structure, in a way that matches the concept of value networks.

    • Takao Oyobe
      keyboard_arrow_down

      Takao Oyobe / Naoto Nishimura - Agile ガチンコ Fight on 1.12

      45 Mins
      Panel
      Advanced

      誰が一番アジャイルなのか?

      アジャイル、スクラム、名前はなんだっていい。

      俺達の目的を叶えるために、現場で日々繰り広げられる闘いの日々。
      そこで培ったものこそがホンモノの証だ!!

      教科書は読むのはもうやめだ。
      俺たちには現場で鍛え上げた経験がある。

      誰が一番アジャイルなのか、今こそ決めようじゃないか。

       

      (セッションの詳しい内容は詳細を御覧ください)

    • Kenji Morita
      keyboard_arrow_down

      Kenji Morita - 20分でスクラム入門 ステップ・バイ・ステップ

      Kenji Morita
      Kenji Morita
      Sr. Engineer
      Canon Inc.
      schedule 4 years ago
      Sold Out!
      20 Mins
      Talk
      Beginner

      スクラムについて、大きな重要な概念から順に説明し、何段階かに分けて少しずつ詳細化しながら解説をして、最後にはスクラムガイドに載っている用語の説明まで辿り着きます。

      スクラムの有用性を説明する必要がない相手への説明、用語から入ると嫌がられそうな相手への説明用に作りました。

      聴衆の方には、当たり前の内容だと思いますが、新米スクラムマスターが開発チームに説明をする場合、事務部門などでスクラムを採用したい場合の説明などに使えるとおもいます。

      資料は、皆さんがカスタマイズして使えるようにpptxでお配りしたいと考えています。

    • Kenji Morita
      keyboard_arrow_down

      Kenji Morita - LeSSにおけるチーム連携のパターン

      Kenji Morita
      Kenji Morita
      Sr. Engineer
      Canon Inc.
      schedule 4 years ago
      Sold Out!
      20 Mins
      Talk
      Advanced

      最近は日本でも、Scrumの実践者は増えてきており、1チームでの開発で成功をおさめ、2チーム、3チームと規模を拡大している事例も増えてきていると思います。Scrumのスケール手法としては、SAFeがメジャーですが、フレームワークとして非常に大きく、数チームのためのフレームワークとしては、取り組みにくいのが現実です。

      そこで、昨年は「Nexus と LeSS 概要と説明」と題して、それらの概要や共通点を紹介しました。どちらの手法も、元になっているスクラムと同じで、必要最低限の必須のフレームワークのみを定義しており、少しずつ開発規模を拡大していくチームが、必要最小限のプラクテスを実践し、不足部分に関しては、開発チームが改善していくスタートラインとするのに、適した手法になっています。

      Nexusでは、依存関係が最小になるように、LeSSでは、フィーチャーチームによるチーム分割を基本とし、ドメイン知識や実装する機能について、チーム内で完結し、できる限りチーム内でのコミュニケーションで、開発が進められるように考えられています。

      しかしその場合、異なるチームが同じコンポーネントの変更をする必要があり、専門性の高い技術を全てのチームが持たなければならないことを意味します。
      このような問題を解決するため、LeSSには以下のようなチーム間連携の仕組みがあります。
      * マルチチーム・バックログリファインメント
      * No Branch
      * コミュニティー
      * オープンスペース
      * トラベラー
      * コンポーネントメンター
      * スカウト

      本セッションでは、Scrumのスケールアップの時に、チーム間連携を改善するこれらのプラクティスについて、紹介します。

      LeSS Study コニュミュニティーで学び、日本での第一回の「認定LeSS実践者コース」の受講からの学びを少しでもお伝えできればと考えて居ります。

    • Miho Nagase
      keyboard_arrow_down

      Miho Nagase - Manga Drawing Programming Workshop

      Miho Nagase
      Miho Nagase
      Agile Coach
      Attractor Inc.
      schedule 4 years ago
      Sold Out!
      45 Mins
      Workshop
      Beginner

      This workshop is a simulation of traditional software development process.
      Participants will experience the whole software development process including requirements, specification, designing, coding and testing with handoffs.

    • Tomoyasu Ishii
      keyboard_arrow_down

      Tomoyasu Ishii / Atsushi Harada - 小さいコミュニティの始め方

      20 Mins
      Talk
      Beginner

      アジャイルを学ぶコミュニティ「アジャイルひよこクラブ」を立ち上げて3年目となります。

      おかげ様で毎回様々な著名人にご支援いただき、色んなバックグラウンドの方に参加いただけるコミュニティとなりました。今年のデブサミにもコミュニティとして参加させていただきました。

      もちろん最初からスムーズにコミュニティ運営が進んだ訳ではありません。
      参加者が全く集まらなかったり、業務におわれイベント準備が全く進まないこともありました。

      無名で、経験も少ない僕らがコミュニティを立ち上げた時どんな課題が起こって、どう試行錯誤をしてきたかという経験をお伝えできればと思います。

      一つだけ言えるのは、コミュニティはただ参加するより運営する方がずっと学びは大きいということ。

      これから勉強会やコミュニティを始めてみたいと思う人の参考になれば幸いです。
      きっと一人で学んで達人になる人はいない。なのでカテゴリはあえて「達人スクラムマスターへの道」にさせていただきました。

    help