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

累計閲覧数 30 PV

はじめに

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

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

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

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

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

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

工事中

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

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

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

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

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

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

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

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