今日も研修。今日からは方式設計について。
今まで基盤系の業務をやったこと無いので、
方式設計は未知の領域。
現場から、基盤の方式設計をバリバリ書いているエンジニアが
講義に来てくれたが、時間切れで要点をうまく説明いただけなかった。
要件定義をコミットして次フェイズに行き、後戻りしないようにすること、
後戻りしたら、プロジェクト全体に影響あることを力説されていた。
その後、WEBアプリケーション／ファット／リッチクライアントの
どれが良いかを検討。個人的にはリッチがベストかと思っていたが、
チーム内で検討した結果、WEBに。
WEBの場合、アプリケーション配布の必要が無い(セキュリティパッチとかは考えない)
というのが、決め手となった。運用・導入コスト重視。
個人的には、WEBアプリの開発って、ブラウザ単位のテストがめんどうとか、
レスポンス遅いとかHTMLでの作りこみがめんどいとかいう印象があり、
内部に閉じたシステムにはリッチがベストかと思っていたが。
とはいえ、リッチについてあんまり良く知らないし、妥協することに。
その後、有識者の指摘で、評価ポイントをブレイクダウンして、
それ毎に、○×評価(△使わない。あいまいなので)、
でもユーザの一番重要視する項目を聞いといて、それが充分満たせる
ものを導入するというのが良いと言われた。たとえ○が一番多くても、
最重要ポイントが×なら、それは論外だと。なるほど。
松竹梅の3案作って、ユーザヒアリングするのも、有効なんだろう。
その後、方式設計の目次作って、またまたレビュー。
障害対策について、項目から抜けていたんだが、有識者指摘だと、
方式設計で最も苦心するのが、障害関連についてだそうだ。
障害パタン洗い出しとか、その場合の運用方針とか、色々考えるそう。
明日は早くに出社して、方式設計書くことに。
自分の担当は、セキュリティ。書けるかな。。
