「行って帰ってくる話」ってきれいだよね
このブログは、「すごくない」kintone その２ Advent Calendar 2025 12/11(金)の記事です。
昨日はお茶漬けのＰさんの「kintoneで日付を計算してみよう（4/4） 文字列フィールドの日付を日付フィールドに入力するには？」でした。１記事だと思っていたら４記事になっていたそうです。ボリュームがすごい…✨️
先に断っておくと、この記事はほぼポエムです。
「行って帰ってくる話」にはどうやら普遍性がありそうだ
個人的に、物語として「行って帰ってくる話」という話の構造には、普遍性があるような気がしています。
たとえばこれは、むかしばなしの筆頭であろうももたろうもそう（産まれる→鬼退治に出る→仲間が増える→鬼をこらしめる→帰ってくる）ですし、ファンタジーの古典である指輪物語(ロード・オブ・ザ・リング)も、基本的には行って帰ってくる話だったりします。また、漫画や映画などでも伏線が回収されるところが一番盛り上がるポイントだったりするのではないでしょうか。
ITにおける「行って帰ってくる話」
これはkintoneには限らないのですが、ソフトウェア開発においては「Vモデル」という開発モデルが古くからあります。
これは、元々ウォーターフォールモデルでは設計とテストは対応せず、順々に処理するものだったのを、設計とテストを対応させて確認するようにしたものです。
※「みんなのアジャイル」第1章から引用
現代のソフトウェア開発には、それそのものはそぐわないケースも多いのですが、これを小さい粒度で何度も繰り返す といった事は今でも行われており、「設計」した粒度にあわせて「テスト」をしよう というのは今でも一般的に受け入れられている概念であると言えるでしょう。
実は去年の8月頃に、とある本の執筆で大変困っていた
今年(2025年)の1月に出た、とある本(みんなのアジャイル)なのですが、この執筆はおおむね昨年の8月頃におこなっており、丁度私が第1章を書いていました。
この本はもともと、ぼくのアジャイル100本ノックという技術同人誌(合同誌)の底本があり、アジャイルに関する100本の記事をオムニバスで読めるもので、オムニバス本としては非常に多種多様な内容が読めて楽しい内容なのですが、逆にいうとオムニバス本なのでまとまりがなくて、今回の企画が出た時に「最初に導入となり、全体を束ねるような内容の第一章が必要だね……」という話になり、私がアジャイル開発についての基本的なポイント（歴史的な経緯など）を解きほぐすような章を書く事になりました。
まずは、最初の興りみたいな話を調べた
第1章を書くにあたって、「最初どうやってそれが発生したか？」について書くのは、実はあまり難しくありません。
というのも、基本的に手法やアプローチというのは自然発生するものもありますが、誰かが体系的にまとめて公表することで一般化するもので、当然それを「まとめた人」「まとまったタイミング」があります。
それを調べて書けばよい といってしまえばそれまでなのです（ただし、アジャイルソフトウェア開発としてはスクラムやXPなど複数のやりかたが存在しそれぞれのルーツを追う必要性はありましたが）。
実は、あまりアジャイルソフトウェア開発になじみのない人には知られていない気もするのですが、アジャイルソフトウェア開発の元々の源流は実は日本にあります。
(みんなのアジャイル)の第1章の記載箇所から引用すると
これは、1986年に野中郁次郎博士と竹内弘高博士が、当時の日本の製造業における革新的な開発手法を分析し、「スクラム」と名付けて論文発表したものを、
https://hbr.org/1986/01/the-new-new-product-development-game
という事で、元々は日本由来の手法なのです。
これが海外に伝播し、海外でソフトウェア開発に適用された(結果としてスクラムやXPが出てきた)後、これらが国内に再輸入され、日本でも一般的なソフトウェア開発手法として使われるようになった という経緯があるのですが、
読みやすさを担保するために話として普遍性をもたせるならば、やはり「（日本から海外に）行って（海外から日本に）帰ってくる話」にしたほうが良さそうだなぁ というのが頭をよぎったのでした。
ここでのアジャイルにおける「帰ってくる」is 何？
まあそういった検討の結果、最後は国内の話に回帰したいわけです。
ですので国産のアジャイル的な手法とよべ、また特徴的なものを２つ挙げ、時系列で並べる事にしました。
その１つ目がSPINA3CH（スピナッチキューブ）です。
詳細はこのPDFに詳しいのですが、IPA（情報処理推進機構）が開発した、ソフトウェア開発およびその方法を自己改善するためのツールになります。
なおこのSPINA3CH（スピナッチキューブ）、マイナーに見えますが実は国際的に知られているものだったりします。というのもこの内容を元にしたものが、現在はISO/IEC TR 29110-3-4(ソフトウェア開発における自律改善手法) として国際規格になっていたりするからです。
そして、２つ目はkintone SIGNPOSTです。
こちらの概要については、ページからそのまま引用します。
「kintone SIGNPOST(キントーンサインポスト)」は「kintoneで継続的な業務改善をするための道しるべ」として、kintone経験者の考え方やコツを体系的・網羅的にまとめたコンテンツです。
https://kintone.cybozu.co.jp/kintone-signpost/about.html
kintone SIGNPOSTについて(個人的に)思っていること
kintone SIGNPOSTはアジャイルソフトウェア開発の各種書籍と読み比べるとよくわかるのですが、実はアジャイルソフトウェア開発の影響を色濃く受けつつ、それをkintone向けにチューニングした内容になっています。
kintoneを使う上で、kintone SIGNPOSTを活用されている方も多いと思うのですが、国内でのITの利活用にkintoneやkintone SIGNPOSTがうまく刺さっている理由の一つとして、源流をめちゃくちゃたどると実は国内で産まれた手法が大きなルーツの１つであるという点は結構大きいのかもしれないな…… という事を感じています。
また、時系列に並べるとkintone SIGNPOSTが一番最新のアジャイルソフトウェア開発手法と言えそうで、じつはkintoneでの継続的な業務システム改善を使っているという事は、世界でも最先端な部類に入る、ソフトウェア開発手法を取り入れている事になるのでは？ と個人的には感じています。
おわりに
このブログもちゃんとkintoneの話に着地し、伏線（「すごくない」kintone その２ Advent Calendar 2025 ）も無事回収する事ができたのでした。
めでたしめでたし。