Skip to main content

「顧客が本当に必要だったもの」を実現するための制約条件

はじめに​

ソフトウェアに開発に関する者のすべてにおいて、有限なものしかない。 その中で最善のアプローチを取るしかないので、のしかかる制約についてきちんと言語化しておこう。

開発に関係する人々が感じる制約は大きく次の 7 つの制約が存在する。

理想的な状態を考えた上で、それぞれの条件の理想状態を考えてみる。 本当は泥臭いことをたくさんしなければならないが、それを言い始めると理想はいつまでも語れないので、最後にまとめて書く。

時間​

一日に作業できる時間は限られている。仕事をしている時間はざっくり次の 4 つに分類される。

  1. 思考
  2. 開発
  3. コミュニケーション
  4. 諸業務

時間を短縮するためには​

時間最適化の方法
思考開発の仕様を理解しやすい環境・状態にする。
開発開発スキルを磨く
業務コミュニケーションプロトコルを決める
諸業務必要業務はフローチャートに落とし込み、迷わないようにする

予算​

サラリーマンからすればほとんどの場合なかなか抑えづらい部分ではあるが、手段はゼロではない。

予算を獲得するには​

工事中

実装難易度​

  • スキルレベル
  • 仕様の複雑度

実装難易度が高くならないようにするためには​

難易度最適化の方法
スキルレベル学習し、自己のレベルを上げる。学習するための時間を設ける。
仕様の複雑度大前提として複雑にしない。アンチパターンを知る。
他に頼る類似の SaaS を利用するなどする

保守コスト​

保守項目内容
状態管理ステートレスではない場合、CRUD + Migration、廃止までを考える必要がある
連携サービス利用されている場合は連絡が必要
ヘルプ機能説明
CRMサポートに対する問い合わせ。ヘルプが正しく機能していれば促すだけになる。
複雑度線形か非線形で変わる

保守コストを下げるには​

施策内容
ステートレス化状態を持たないようにする
ドキュメント化ドメインロジックについて明確に記述する。開発関係者以外のドキュメントは要求定義に基づく。
簡素化複雑な処理を一箇所にまとめない。規模を大きくしない。

運用コスト​

運用項目内容
不具合対応重要度に応じて待機体制などが敷かれる

運用コストを下げるためには​

運用項目内容
廃棄容易性不具合箇所だけ切り離すことが可能にする
Blue/Green投入前後で切り替えが直ぐにできる状態にする
カナリアリリース大きな投入前に試験運用を行う

心理負荷​

心理負荷項目内容
負債化顧客に対して負の印象を与える場合や、実装の将来を見据えたときに負の遺産になる場合。
運用時緊急時などで運用者に緊張などの負荷がかかる
長いレビュー実施した内容に対するレビューが長い場合、ストレスがかかる。
無茶なスケジュール相手のスケジュールが見えていないような場合に仕事を依頼する

心理的負荷を下げるためには​

対策内容
事前共有RFC のように、少し時間がかかりそうな内容は前もって共有し関係者が腰を据えられるようにする。
意図を伝える予期しない指摘や理解できない内容をコメントされた場合、レスポンスに困る可能性があるので、明確に意図を伝える
自動化人のせいにしないで済むようにする。
可視化すべてを把握するのは難しいので、一般に広く知れ渡った把握しやすい図を用いる。

物理負荷​

物理負荷項目内容
電気代ランニングコストがかかる
損耗ハードウェアの損耗
故障・障害ハードウェアが再起不能に陥るような致命的な不具合。それによって生じる損害。

物理負荷を下げるためには​

対策内容
フェイルセーフ万が一が起きても安全な方に倒すようにする
再発防止二度発生しないように対策する