近40年来，我利用各种硬件、操作系统和开发语言等进行软件开发，现在个人回想起来，能按照标准化的相同步骤如期推进开发的时段，实际上都很短暂啊。

2001年发布了敏捷软件开发宣言，但当然在此之前，就有许多软件开发者不断探索和实践各种方法，比如面向对象、UML、XP（极限编程）等，努力寻找更好的开发方式。
即使项目是以计划驱动的，也会将高变更风险的部分进行抽象，或者将高技术风险的部分提高优先级并进行实施验证，不是吗？
今后当然要感谢并活用前人的智慧，也会以自己的方式不断进行自由的创新吧。

如果不仅包括开发者，还加上运维人员就变成了 DevOps，如果再包括业务部门就变成 BizDevOps……
当然要遵循“对客户而言不被识别为价值的就是浪费”的精益理念，不仅要重视 CX（客户体验），也要将 DX（开发者体验）作为 QoEL（工程生活质量）看待，对吧？
我认为，不仅限于敏捷，追求更好的方法以便更好地生存本身就是一种自然行为，在这方面的平衡非常重要。

人类在睡眠时会整理记忆，将不必要的内容遗忘。
让人挂念的事情会在梦中多次模拟，以提高明天存活的概率。
深度睡眠（Non-REM）让大脑和身体休息，REM 睡眠则进行记忆再处理和生存所需行为程序的脑内模拟，两者交替进行，这可以说是一次次的回顾时间。
我觉得这和我们几个人合作狩猎猛犸象（群体工作 Mob Work）的时代并没有本质区别。

据说断眠的吉尼斯纪录是 264 小时 12 分（现已删除），但通常从醒来到下一次醒来的24 小时就是一个时间盒
（人体生物钟大约是 24 小时 10 分左右，所以需要每天重置以调整节奏）。
今天必须做的事你今天做了吗？（可以等到明天的就留到明天）

有人说人每天要做 35000 次决定，但这些决定有轻重缓急之分，从关乎生死的重要决策到无论选哪个都差不多的琐碎抉择都有。
为了不在优先级低的事情上浪费时间和精力，史蒂夫·乔布斯据说每天早上都穿同样的搭配出门，这也让人感到合理。人类本质上会优先关注对自己至关重要的事情，对吧？

大家是更喜欢把最喜欢的食物留到最后才吃，还是一开始就先吃掉？
不过这也要看具体情况，对吧？
那么在两小时自助吃到只剩 30 秒时，最后那个放着“最爱草莓”的小蛋糕，你会先吃草莓，还是先吃蛋糕胚或奶油？

小时候，即便只有短短 20 分的课间休息，也会跑到操场去玩躲避球吧？
当然铃声一响（时间盒），就得回到教室，但下个课间休息时，又从之前的地方接着玩。～

下雨天在高速公路上调节雨刷速度，或者在外汇（FX）交易中刷新股价走势图……为了持续观察现实，速度越快越好，对吧？

想到这些，不禁觉得自己要得上“凡事都看成敏捷”的毛病了……

• 100 件想在死前完成的清单（人生的产品待办事项列表）
• 旅行（在已定的预算和时间内，对目的地进行优先级排序，放弃优先级低的）
• 手术（专家团队对患者进行持续治疗的群体工作，优先流程效率而非资源效率）
• co-Working（群体工作下的团队作曲） Jazz 会话（群体工作即兴演奏，重于实际发出的声音而非乐谱♪）
• Teal 组织／Holacracy 组织
• U 理论
• In-basket 思维
• シャトレーゼ的新产品开发
• 老字号旅馆陣屋的复兴、本田F1专业知识
• 東京都世田谷区立桜丘中学校（废除校规和定期考试）
  ……等等，都让人不知为何感受到类似的思维方式。

自从新冠疫情趋于平稳已久，远程工作的敏捷实践也变得司空见惯，生成式 AI 的应用也在推进，工作方式也发生了巨大变化（最近发布的 Scrum Guide 扩展包允许部分产品开发人员使用 AI）。
在真实的会议室里，白板最多只能容纳 3～4 人共同书写；而使用在线看板，则可以支持 100 人同时书写。在现实会议室里，佩戴口罩会使面部表情难以分辨，且在大型会议室中距离较远也不易看清；但在线会议无需口罩，面部表情也更清晰。

按需提供。也就是“按优先级单件流转”更合适？
尽管有人说“固定开发团队更好”，但感觉就像为本地部署服务器按照峰值需求进行容量规划一样。当然从接单方来看，增减人手都很痛苦，但如果像云服务那样灵活地“在需要时以所需量高效使用所需资源”，或许才是真正更优。
如果重视持续为产品增值，那么进行多团队扩展也行——可在全球范围内组建 3～4 支有时差约 6～8 小时的团队轮班开发。当然在日本国内也可像医院那样采用三班倒……（不过我在 2000 年左右曾进行过两班倒开发，长时间坚持下来相当艰难）。

PMI 的 PMBOK DA（Disciplined Agile）也提出 “Choose Your WoW! Way of Working!” ，强调“选择自己的工作方式”十分重要。
在 DA 中，不仅可以选择“XP”、“Scrum”、“UP”等，还可以选择在 2001 年敏捷宣言中未包含的“SAFe”或“Spotify 模型”，甚至包括传统方法，堪称“全家桶”。
面向对象与 UML 大师 Ivar Jacobson 的《现代软件工程》中，通过抽象化来兼顾各敏捷方法的优点。
今后“逆康威定律”、“Teal 组织/Holacracy”以及 Web3 的 DAO（分布式自治组织）等，组织与软件结构的优化应会持续推进。

目前 Scrum 的使用份额最大，但给人一种更多是管理者支持，而非开发者支持的印象。当然作为组织需要有选择标准，但不应阻碍各团队的创新吧。
在回应市场、客户及最终用户期望的同时，为了更好、更愉快地、有意义地进行开发，我们要一方面尊重前人的智慧，另一方面也要拥有抛弃以往常识（偏见集合）的自由，今后也要持续追求“更好的方法”。

“赋予自由就能更好地演化以实现更顺畅流动”的构造法则，似乎也能为快速而持续地传递价值的敏捷实践提供启发。
为了生存，我们将不断寻找更好的方法。
我认为，如果有自由（没有过度的多余管理），就能朝着更好的方向进化。

27 亿年前的地球完全是自由状态，当最早进行光合作用的细菌开始向地球释放剧毒“氧气”时的生存策略

• 在几乎没有氧气的环境中生存 → 海底或动物肠道等
• 探索与氧气共存的策略 → 将能以氧气为能源的线粒体纳入细胞内
  在没有高级医疗研究设施的 27 亿年前的地球上……
  没问题♪感觉无论发生什么都能想办法应对。