こんにちは
システムチーム / プログラマーのNです。
今回のブログは、仕様作成時や作業時において、作業に落とし込まずに考えることの重要性を書きたいと思います。
先日、上司がデキテルのサーバー増強を行いましたので、そのことについても書こうと思います。
考えを作業に落とし込みすぎるとどうなるか
仕様作成の段階において作業レベルで考えると、仕様がコードに引っ張られてしまい、コードレベルで「できる」「できない」を判断してしまいます。
「ここのコードはこうなっているから、こう変更するのは難しい」
や
「機能を追加する場合、この部分が難しい」
であるなどの情報が先にきてしまい、
サービスにとって必要なものが明確にならないということが発生してしまいます。
プログラマーとして毎日コードを見て、書いていますので、仕様作成段階においても無意識にコードから入ってしまうことがあります。
もちろんコードを見ての判断は大事なのですが、順番として上位に持ってきてはいけません。
「なぜ作るのか」
「なにを作るのか」
「誰に対して作るのか」
など
これらを明確にして初めて細部を詰めていく必要があります。
明確にしないままコードレベルから詰めてしまうと、自分の都合のいいような仕様しか考えられなくなります。
コードレベルから考えていないつもりでも、無意識に「できる」「できない」を判断してしまいます。
プログラム的に可能かどうかの判断は仕様作成の最後の段階で良い。
その段階でまた「なぜできないのか？」というところから考え、解決するためにはどうすればよいかを詰めていけば良いのです。
デキテルサーバー増強の開発手記を読んで
なぜ今回、作業に落とし込まないというブログを書いたかというと
上司が行ったデキテルサーバー増強の開発手記を読んで改めて重要性を感じたからです。
まず4カ月に及ぶ大規模開発でありながら、最初に立てた見積もり通りに作業が完了したということに驚きを感じました。
私自身、今年は新規システム案件を経験したということもあり、途中までは見積もり通り進んでも、詰まる部分が発生し遅延になったということがあったので余計に驚きを感じました。
なぜ見積もり通りに完了できているのだろうと考えたときに、ブログ内で共通しているのは
自分本位の開発ではなく、サービス全体のこと、現在サービスを使っているお客さまのこと、また未来に使う誰かのことを考え開発している
ということです。
「デキテルにとって正解は何なのだろう」
「お客さまのことを考えダウンタイムなしでリリースするにはどうすればいいのだろう」
「パフォーマンスを上げるといっても比較対象によって上がってる・下がってるの感じ方が違う」
など
考えていることが、１つ２つ高いところにあると感じました。
そういった経緯もあり今回のブログのテーマにしました。
不定期ではありますが、社内でも勉強会の開催がありますので積極的に質問をしていきたいと思います。
最後までお読みいただき、ありがとうございました。
