概要
プログラミングは物事を自動化することが目的で上達すればするほど物事が自動化すると思っていた。
しかし実際は全く自動化できないことに最近気付いた。
プログラミングの原則にDRYという原則がある。
DRYとは
DRYとはDon’t Repeat YourSelf の略称で要するに、
「同じことを2回もするな」
という原則である。
これはプログラミングを一度でも学習した者なら誰でも知っているぐらい有名な原則である。
これは大変素晴らしくプログラマなら誰でも模範にする原則であるが、
こと仕事に関しては皆DRYができていない風である。
もちろん、僕も同様だ。
アプリの設計方針は現場によってバラバラであるという事実
今でも現場によってアプリの設計方法が違っていて新しいアプリのソースコードを見るたびにゲンナリする。
だいたい優秀なプログラマが実装するなら設計は同じようなモノになりそうだが、
現実は似たような設計方針のソースコードがなかったのだから皮肉な者である。
つまり、携わるアプリが変わるごとにそれまでの知見がリセットされてしまうのだ。
僕はこれまで4年ぐらいフリーで色々なアプリを見てきた。
4年も色々なアプリを見てきたならどこかしらで設計は被りそうなはずなのだが全く逆でバラバラなのである。
因みにこれまでの経験上ですが、
「もし仮に別のアプリを従来と同じ設計方針で作れないのか」
と言われたら僕はNOと答えます。
同じ設計でAアプリだったりBアプリだったりを開発できるはずである。
ここがiOSアプリの摩訶不思議な現象だったりします。
つまり、最初に携わる人(プログラマ)によって設計方針が決まってしまう
ということ。
機能の施策やメンバーによってさらにバラバラであるという事実
企画で炎上する流れ
昔は新機能を追加するときは良いプロジェクトの進め方が分からなかったのでよく炎上したものだった。
とりあえずやりたい機能をヒアリングしてその通りに実装して企画立案者(プランナーやディレクター)に確認してもらう。
すると企画立案者は「思っていたものと違う」と思ってさらにそこから修正を加えていく。
そして、修正したものを見せてフィードバックを貰うのを繰り返すと今度は機能でバグが起きてアプリが落ちてしまったり(機能の矛盾)
元々の機能ができなくなったり違う結果が起きてしまったりしてそれを改修して行くのである。
この流れが3回ほど繰り返されたら経験則だが8割ほどの確率で「炎上」に発展します。
炎上を回避する方法
上記の流れが多かったため、とあるタイミングからやり方を変えて見る試みをし始めるようにしました。
最初の企画立案者から新機能を追加する要件を言われた時にその機能についてヒアリングする量を増やしました。
それまでは試しにそのデザインになるように実装するのではなく、
その機能を企画立案者といろんな角度でヒアリングして機能の内容を徹底的に洗い出すようにしました。
機能の目的(現場では正常系と言われる)は勿論のこと、エラーや例外(現場では異常系と言われる)についてもその時点で尋ねるように変えてみました。
次にアプリのソースコードで修正箇所に該当する場所を探してその周辺のソースコードや設計方針を5~6割を目処に調査します。
(モバイルアプリの場合はだいたいにおいてアプリのドキュメントが無いことが多い)
あらかた調査が終わってからちょっと時間を空けて設計を考えてから本実装に移すように変えました。
機能の実装で分からなくなったらできる限り早く企画立案者かサーバーサイドに質問をして疑問を解消させることは優先させます。
この方針に変えてからはある程度安定して新機能やバグ修正が行えるようになりました。
あと工数について最初の段階で見積もり工数の2倍ぐらいを貰うこと。(本当は3倍)
気持ちの工数としては「本実装」分の工数と「リスク」分の工数という感じです。
つまり、
- 新機能の話しが来ればその機能の仕様を最初にできるだけ多く理解して企画立案
- その時点でどうすればいいのかわからない部分を解消させる
- 工数をあらかじめ余裕が持てるぐらいのスケジュールにしておく
この3点を抑えるようにすれば炎上の確率を下げられるのではないかという気づきがあります。
結論
他人の想定している挙動が口頭ベースではわからないことと既存のソースコードの設計が見えにくいので
仕事のプロセスはなかなか自動化できませんよね。という話でした。
