WHAT HAPPENED
話が進んでいても、
そのまま作るとは限らない。
案件では、 必要な機能について話が進み、 開発の内容も見えてきていました。
でも、 途中でその機能自体が なくなることがありました。
技術的にできなかったわけではありません。
別の事情で、 作らないという判断になった。
開発側にいると、 どうしても 「どう作るか」を考えます。
でも実際には、
そもそも作るかどうか
という判断もあります。
CHANGE
仕様は、
途中で変わることもある。
最初に決まった内容が、 最後までそのままとは限りません。
話を詰める中で、
「このケースはどうするのか」
「この条件では動かない」
「やっぱり別の方法にしたい」
といったことが出てきます。
開発途中で変われば、 設計や実装への影響もあります。
だからこそ、
何が変わったのか。
なぜ変わったのか。
そこを理解しておくことが 大事だと感じました。
TECHNICAL ANSWER
技術的にできても、
作るとは限らない。
開発者としては、
Javaで実装できる。
標準機能で対応できる。
追加開発すれば実現できる。
ということは考えられます。
でも、 それだけで決まるわけではありません。
本当に必要なのか。
優先度は高いのか。
追加開発するほどの価値があるのか。
こうした判断も入ってきます。
この辺りは、 パッケージ製品のカスタマイズでも 同じように感じたところです。
AGREEMENT
大事なのは、
何を合意しているか。
開発側では、
「この仕様で決まった」
と思っていても、
利用する側では まだ検討中だった。
ということもあり得ます。
だから、
何を作るのか。
どう動くのか。
どこまで決まっているのか。
そこを合わせておく必要があります。
実装に入ってから 認識が違っていたと分かると、 手戻りも大きくなります。
SUMMARY
開発は、
技術だけで動いているわけではない。
Windchillの案件では、 技術的にできることでも 作らないことがありました。
進んでいた話が 途中でなくなることもありました。
仕様が変わることもありました。
その経験から、
「どう作るか」だけではなく、 「何を作ることで合意しているのか」 を見る必要がある
と感じるようになりました。
技術を理解することと同じくらい、 その背景を見ることも 開発では大事だと思っています。