読者です 読者をやめる 読者になる 読者になる

futoase

よろしくお願いします。

ソフトウェア開発からひとしきりの終わりまで

雑記 人生

以下の様な流れかなぁ。妄想だけど。

発生から終わりまで

  1. 事業計画をまとめるにあたり、四半期及び中間決算、通期などの期間目標を定めるとき
  2. 企画段階における、市場投入に対する配慮をする時点
  3. 企画が立ち上がり、キックオフが行われた時
  4. 企画がとあるストリームを通じて末端の開発者に流れてきた時
  5. 設計段階
  6. 実装前段階
  7. 実装及び設計作業中のイテレーション
  8. 完成前の企画判断
  9. 市場投入前判断
  10. 市場投入
  11. 市場投入後の経過観察

事業計画をまとめるにあたり、四半期及び中間決算、通期などの期間目標を定めるとき

これはIRやら、社内の偉い人の会議とかだから会社の空気を読み取れるぐらいかな。
力をさらに注ぐべき事業とか、伸びている事業がわかる程度か。
そして伸びている事業に自分が属しているか、か。

企画段階における、市場投入に対する配慮をする時点

パズドラみたいなゲームを作ればおこぼれが、みたいな感じで
企画が発生し、パズドラが流行ってる今なら開発工数短め、できるだけ早く
リリースさせたいとかそんな意識がどっかから生まれるのかなぁ。

企画が立ち上がり、キックオフが行われた時

お偉いさんにも話が通り、メインの企画者、
アプリの規模によるけど本当のメインは一人か二人かなぁ。
そしてキックオフ、つまり企画がスタートする

企画がとあるストリームを通じて末端の開発者に流れてきた時

なんか端折ってるけど、開発の枠組みが見えるのってこの段階な気がする。
妄想だけど。末端の開発者は当日の会議でいきなり知るか、
人付き合いがよければ酒の席や個人間のチャット、喫煙室などで
情報をもらえるかもしれない。

設計段階

ミーティングも終え、設計段階に入る。
小さいところじゃなく大きいところだと、設計に異議を唱えるのは
結構きつい気がする。大きい流れにそう、長いものに巻かれるのが楽という。
納得いかないかもしれないが、飲むしか無い。

実装前段階

ここが一番難しい。未知のことをやるんだったら
技術調査をしつつコードを書き捨てるということを
繰り返していかなければならない。
設計に誤りがあるかもしれないし。
でも、設計に誤りがあっても突き進むしかない風潮があったりするから悩みモノ。

実装及び設計作業中のイテレーション毎の振り返り

これができないチーム・部署は終わると思う。
デスマにならない場合でも、モノが永遠にリリースされない。
出来上がってるけど出来上がってない状態が出来上がる。
動作して社内の人間には提供できるものができているけど、
社会には出せない。出せない理由は色々あるけど、そんな状態になる。

イテレーションを決めて現状のステータスを把握する
ハードな作業が続く。実装もハードだけど、会話というプロトコルが一番ハードだ。。。

完成前の企画判断

要求者側に提出する。ここでどんでん返しが発生する。
大抵の場合すんなりと通らない。実装前段階か、ヘタすると設計まで戻る。
戻る場合の理由についてしっかりとした意思があれば良いが、
「なんとなくダメっぽいから」ということだけ言い残して
ダメっぽい点が出てこないまま作り直しでは意味が無い。
金が減っていくだけだ。。。

市場投入前判断

もうリリースは万全だ。問題ない。
バグがでた。一週間延期。

市場投入

ティザーサイトからサービスへの切り替えを実施した。
これで良い。が、投入した後サービスが使えないことが判明、
徹夜の日々。目の前の問題を解消することに追われているので精一杯

市場投入後の経過観察

サービスはうまくいっているのか、想定している数値は伸びているのか
確認が行われる。うまくいっているのであれば、数名の保守要員を残し、
他のエンジニアは他の開発部署へ旅立っていく。

最小限のエネルギーで実装し最小限のリリースで済ませた場合は
機能追加、強化及びピボット(全部じゃない場合があるが)のため、
チーム人員の減少はないのかもなぁ。

問題点

以上一連の流れを踏まえていても、
じゃあどこがうまく言ったのか、とか
ライブストリーム的な話になっても
じゃあ今現在どこがうまく言っているのか、などの
共有が行われないとだめだ。
理由は自分が作ったものであり責任があるから、という感情が生れないからだ。

以上は全部妄想である。

Copyright (c) 2013-2017 Keiji Matsuzaki