スケジュールのない開発はエンジニアの天国か？

Saleshubでエンジニアをしております安田と申します。
Saleshubに入社して4か月以上が経ちました。
色々なことに慣れた一方で、慣れないこともあります。

今日はその一つであるスケジュールというお話をしてみたいと思います。

スケジュールって嫌だよねー

エンジニアの皆さんは「スケジュール」という言葉を聞いたときに、どんなイメージを持つでしょうか？

• 納期に間に合わずビズサイドと険悪になった

• 上司から納期を死守せよ、と言われて激しいストレスを感じた

など、いやな思い出をたくさん持っている方が多いのではないかと思います。僕もその一人でスケジュールなどできるだけ無縁でありたい、なんの時間的な制約もなく開発をしていたい、そう思っていました。

ただ、今のSaleshubに入って、その自分の認識はとても一面的なものだということに気付きました。

どういうことか？

じゃあ、ふわっとしたスケジュールしかない世界は？

実は現状のSaleshubの開発はとてもふわっとしたスケジュールしかありません。
大きなプロジェクトがxxごろまでに完了している予定。
こんな感じです。

なので、そのプロジェクトを細分化した個々のタスクにどれくらい時間をかけてよいのか？どれくらい時間をかけるのが理想的か？といったことはどこにも示されていません。

なので、個々のタスクをどれくらいのスケジュールで終わらせるべきか、というのはその作業をしている人の「感覚」に委ねられています。

一見このことはスケジュールが個々人に委ねられていて、自由でよい。
制約を受けることなく、理想の開発ができる。
そう思われるかもしれません。

僕もそう思っていました。
ただ、やってみるとそんな単純な話ではありませんでした。

スコープ、フェーズ、プライオリティの共通認識が作れない

まず自分が驚いたのは、組織とプロダクトのコンテキストから想定されるスコープ、フェーズ、プライオリティといった自分の認識が、他のメンバーと合わない。

これは別に他のメンバーを批判したいわけではありません。
もちろん、自分は自分が正しいと思いがちなので、気持ち的にそういう部分もなかったわけではないですが、それよりもそれがあまりに合わないので「なぜ？？？」という疑問のほうが僕の中で強く生じました。

プロジェクトの大枠については、その必要性や緊急性が十分説明されており違和感はないです。そこはふわっとしたスケジュールから読み取ることもできます。ただそれをブレークダウンした個々の作業レベルになると、僕の中で「今のフェーズのスコープはこの辺で、プライオリティの低いこの作業は別フェーズでやればいいだろう」とぼんやり考えていたことが、どうも通じない。

これは正直驚きました。
そして最初なぜこのようなことが起きているのか、原因を認識できませんでした。

スケジュールの本質について考える

それはひとえに僕が「スケジュール」というものの本質を理解していなかったからだと思います。

逆に僕はこの非常にスケジュールのあいまいな世界ではじめてスケジュールというものの本質に気付きました。

スケジュールはエンジニアを縛って、制約して苦しめるものでもなんでもなくて、「時間」という情報を「構造化し可視化」したもの、ということに気付いたのです。

ビジネスの世界はスピードを求められます。
もしくはビジネスの世界でなくても人がもつ時間は有限で非常に限られています。

その有限な時間を、いかに濃密に費やすか？いかに有効化するか？
ここでは、ある意味プログラミングよりもずっと高度なエンジニアリングが求められます。ベストプラクティスも、テストも、Lintもありませんから。

スケジュールがエンジニアリングを苦しめる。
これはよく起こるし、不可避なことでもありますが、スケジュールの本質とは全く関係ありません。どちらかというと「まずいスケジュール」によって引き起こされる、本質とは関係のない事象といってもよいのではないかと思います。

スケジュールの本質は、

• 求められているタスクがビジネスのタイムラインの中でどう位置付けられているか？

• 求められているタスクがどのタイミングにおいて最も有効で、どのタイミングになると効果が薄れていくのか？

• 求められているタスクが適切なタイミングで実行されないとどのようなビジネスインパクトがあるのか？

• 求められているタスクの中で必要不可欠な要素は何で、後回しにできるものは何か？

• そのことを後回しにしたことのリスクは何か？

こうした価値観や状況のような情報が、細分化されたタスクとして、かつそれが時間軸の中で「表現」され、組織のメンバーに共通認識として「共有」される、ということがスケジュールの本質なのではないかと思います。

もちろん、この意見には以下のような反論もあると思います。
スケジュールはそんな甘っちょろい話ではなくて、顧客に対する約束、コミットメントだ、と。

これに対しては僕も反論の余地はありませんw
顧客に対して約束したのではあれば、その場合のスケジュールの本質的価値は、価値観やら状況やらの共有といった「ぬるい」ものではなくなると思います。

ただ、顧客との関係で必要不可欠でない場合でも、価値を共有したり、チーム間でスムーズにコミュニケーションをするためにも、スケジュールというツールはとても有効である、ということにいまさらながら気づかされました。

やや会社批判的な内容にもなってしまいましたが、Saleshubがだめだとかそういう話ではありません。先だってnoteに書いた通り、基本は素晴らしい会社でありながらも、まだまだ未成熟な部分がたくさんあり、ひいては改善の余地がたくさんあるので、もっともっと強くなれる組織だと考えています。そして僕自身も今回の経験を通して一つ賢くなり、強くなった気がしており、それはSaleshubという素晴らしい場のおかげだと感じています。

スケジュールの考え方をSaleshubの開発に有効に導入し、開発をより有効で楽しいものに、サービスを一層素晴らしいものに変えていきたいと考えています。