はじめに
東京オリンピックを2年後に控え、日本のIT業界に突然降って湧いた「日本でもサマータイムを導入するかも？」という問題。
この話、数日経てば「そんなのうそぴょーん」とか「すいません、前言撤回します」みたいなオチで終わるだろうと思ってたのですが、このブログを書いている時点ではそういう気配はなく、むしろ前向きに検討しているような雰囲気で「おいおいおい！」と思っております。
こんな「ピカーン💡いいこと思いついちゃった！」的なノリで突然サマータイムを導入するのが、技術的にどんなに無茶な話なのかは、他の専門家のみなさんが論じてくれているのでここでは書きません。
そのかわりに、もしこんな話が僕が勤めている株式会社ソニックガーデンの「納品のない受託開発」で巻き起こったら僕はどんな対応をするか、という思考実験をしてみようと思います。
前提知識：「納品のない受託開発」の開発スタイルについて
「納品のない受託開発」ではその名の通り、お客様の要望に応じて専用のシステムを開発する「受託開発」でありながら、システムを全部最後まで作ってお客様にお渡しする「納品」がありません。
「納品のない受託開発」の特徴を簡単にまとめると以下のようになります。
- プログラマとお客様が毎週定例のミーティングを開き（通常はビデオ会議）、その週に開発するシステムの仕様を決める
- プログラマは次回のミーティングまでに、お客様に成果が見えるプログラムを実装する
- 翌週のミーティングで開発したプログラムをお客様とレビューする。そして、また次の週に開発するタスク決める
- レビューが済んだプログラムは随時本番環境にリリースされる
- ソニックガーデンは毎月定額の開発費をお客様からいただく
- プログラマは毎週、一定量のタスクを実装する。納期についてはあくまで「ベストエフォート」でしか約束できないので、「xx月xx日までのリリースを死守してほしい」というようなご要望には原則として応じない
上の流れを見てもらえばわかるとおり、「納品のない受託開発」ではプログラマが直接お客様と対話し、話をした本人がプログラムを書きます。
SEとプログラマが分かれていたり、間に別の会社が入ったりすることはありません。
「納品のない受託開発」の詳細についてはソニックガーデンのホームページ、もしくは弊社代表の倉貫が書いた以下の著書をご覧ください。
もしお客様から「日本にサマータイムを導入したいんだけど」と言われたら
さて、ここからが本題です。
現実にはあり得ませんが、もしお客様から「日本にサマータイムを導入したいんだけど」と言われたら、僕はどう返事をすればいいでしょうか？
「それは無理です。絶対にできません」？
「仕様を教えてください。それから見積もりいたします」？
「サマータイムを導入するのがどんなに大変なことか、ちょっと説明させてください」？
いいえ、どれも違います。
最初に返す言葉は、
「なぜサマータイムを導入する必要があるんですか？その理由や背景を教えてください」
です。
「やりましょう」でも「無理です」でもなく、「そもそもなぜサマータイムの導入が必要なのか」を確認します。
報道などで伝え聞くところでは、「マラソンの開始時刻を2時間早めたいから」という理由があるようですが、もしお客様がそのように回答してきたら、「では、そのまま素直に開始時刻を2時間早めればいいんじゃないでしょうか」と提案します。
そこから「いいえ、それは無理なんです。なぜなら・・・」と、お客様から納得のいく理由が返ってくれば議論をさらに進めることができます。
ですが、そうでなければ「サマータイムの導入」というタスクは永遠に実行に移されません。
受託開発と言えど、ソニックガーデンのプログラマはお客様の要望を全部そのまま受け入れるわけではないのです。
「IT投資に対するソフトウェアの価値を最⼤化すること」というビジョンと、「判断に理解と納得を持ち思考停止しないこと」という価値観
ソニックガーデンのビジョンの一つに「IT投資に対するソフトウェアの価値を最⼤化すること」があります。
IT投資に対するソフトウェアの価値を最⼤化すること
SonicGardenはソフトウェアの可能性を信じています。物理的な制約を受けることのないソフトウェアは、ユーザや企業が必要とする要求に対し、最も効率よく価値を提供することができるはずです。しかし、今のソフトウェア開発には無駄が多く、投資に対する価値が提供しきれていないように思います。私たちは、業界にはびこる無駄を見直し、IT投資に対するソフトウェアの価値を最大化することを目指します。
https://www.sonicgarden.jp/company
さらに「判断に理解と納得を持ち思考停止しないこと」という価値観もあります。
「判断に理解と納得を持ち思考停止しないこと」
SonicGardenでは、言われた通りに仕事をするということを嫌います。お客様からの要望による機能を実装するにも、自社サービスの機能を設計するにも「本当に必要なのか？」という観点から考えて納得をした上で取り組むようにします。
https://www.sonicgarden.jp/company
これらを組み合わせると、プログラマは「サマータイムを導入することは本当に必要なのか？サマータイムを導入する以外に、お客様の問題を解決できる、もっとスマートで低コストな解決策はないか」ということを考えます。
その解決策を検討するために、「本当に困っていることは何か」「本質的な問題はどこにあるのか」ということを、ミーティングの中でお客様と議論しながら深掘りします。
議論の末に出てくる結論
議論ではお客様とプログラマの双方が心の底から納得がいく結論を出す必要があります。
先ほど述べたとおり、「お客様が本当に困っていること」を探り出すのも重要ですし、我々プログラマもお客様に対して「もしサマータイムを導入しようとしたら、どれくらい大変なのか、実際にどれくらいの工数がかかるのか」を説明し、お客様にその大変さやサマータイム導入によるメリット・デメリットを理解してもらわなくてはなりません。
このようにお客様とプログラマが、お客様のビジネスを成功させるために本音で意見をぶつけ合い、最終的な結論を導き出します。
「サマータイムを導入するか否か」というテーマであれば、大きく分けて「導入しない」もしくは「導入する」という2種類の結論が出てくると思います。
「サマータイムを導入しない」という結論の場合
お客様が「本当に困っていること」を理解し、それを解決するもっと良い方法が「サマータイムの導入」以外にもあるなら、我々プログラマはその方法を提案し、お客様に納得してもらいます。
場合によっては「全くコードを書かない（つまり、何もしない）のがベスト」という結論に至ることもあります。
普通の受託開発では「コードを書かない＝儲からない」ということになりますが、「納品のない受託開発」は毎月定額で料金をいただくことになっているので関係ありません。
むしろ、「サマータイムを導入しない代わりに、お客様にとって、もっと価値の高い別のタスクに取り組む」という、お客様とプログラマの双方にとって有意義な選択肢を採ることができます。
「サマータイムを導入する」という結論の場合
一方、議論の結果「なるほど、そんな事情があるのなら、サマータイムを導入することもやむを得ない。いや、むしろサマータイムを導入することには十分な理由と価値がある！」という結論に至る可能性もゼロではありません。
しかし、その場合でもソニックガーデンでは「毎週、一定量の成果を出す」というルールを変えることはありません（つまり、プログラマは体を壊すようなハードワークをしません）。
なので、あまりにも無茶な内容だと、「見積もりした結果、お客様が希望する納期に間に合わない」という問題が発生します。
その場合は「無駄な要件を可能な限りそぎ落とし、本質的な問題を解決できる要件だけを残して、納期に間に合うように努力する」という選択肢を採ります。
とはいえ、「日本にサマータイムを導入する」というレベルになると、何を削ったら納期に間に合うようなボリュームに落とし込めるのかイメージが沸きませんが・・・。
ですが、実際の「納品のない受託開発」では「要件のスコープ」を調整することで、お客様の希望する納期に間に合わせることがよくあります。
まとめ：で、結局「サマータイムを導入して本当に解決したい問題」は何？
というわけで、このエントリでは「納品のない受託開発」でお客様から「日本にサマータイムを導入したいんだけど」と言われたらプログラマとしてどうするか？という思考実験をしてみました。
実際に「日本にサマータイムを導入したい」なんていう話をし始めるお客様はいませんが、そこまでいかなくても「それ、本当にやろうとしたら大変な工数になりますよ」というようなご要望をいただくことはよくあります。
そういう場合は上に述べたような議論を通して、我々プログラマはお客様にとって最も費用対効果の高い形にタスクを落とし込むようにしています。
ところで最初の話に戻りますが、僕らは普段こんなふうに仕事をしているので、「マラソンの開始時刻を2時間早めたい。だから日本にサマータイムを導入したい」という話がいまいちピンと来ないんですよね。
僕はどう考えても「マラソンの開始時刻を早めたい」なんていうのは表面的な理由で、「本当は何かもっと本質的な理由や目的が背後に隠れているはず」と思ってしまいます。
ですが、報道ではそのあたりの情報がハッキリ明示されないので、サマータイム導入に関する昨今の議論を見てても非常にモヤモヤしてしまいます（「そもそも」の話がしたいのに、それができなくてモヤモヤする）。
少なくとも僕個人としては「うーん、今見えている理由だけだと、ちょっとサマータイムを導入するのは無理（＝プログラマとして受け入れられない）ですね」というのが、現時点での答えになると思います。
あわせて読みたい
このサマータイム導入問題は、以前読んだ「失敗の本質」にどこか通じる話があるんじゃないか、という気もしています。
結局、戦争が終わってから70年経った今でも「声の大きい人の意見が通る」とか「非合理的な精神主義で、現場が無茶を強いられる」といった行動パターンから抜け出せないのだとしたら、非常に残念です。
