俺には無い物なんだけど書いて行きたい。随時書き足して行く。
PM 的な物は書いてない。要員管理とか用地管理とか資材管理とかスケジュール管理とか予算管理とか見積もりとか交渉・折衝とか会議体とか開発体制とかホットラインとか社内環境( 物理的( 机、椅子、パソコン、ディスプレイ、マウス、キーボード、カードキー、カードリーダー、LAN、電源、ホワイトボード、ホワイトボードのペン( 常に書ける奴を置く )、ダブルクリップ、紙、トナー、キングファイル )な物や電子的な物( グループウェア、共有ディレクトリ、メーラー、定期バックアップ、各種アカウント、その他 )の両方 )の整備とか承認管理( 上長、法務、総務、経理、経営者、営業、顧客、要員 )・権限委譲( 事前報告・事後報告・報告不要 )とかイベント開催とか部外者連携とか案件管理とか契約管理( 秘密保持契約、受託開発、派遣 )とか品質管理とか情報管理・セキュリティ管理とか作業分担・作業内容の明確化とか納品物の明確化とか納品とか勤務状況管理( 残業、休日出勤、シフト出勤、深夜残業、全休、半休 )とか周知とか緊急事態対策とか育成とか人事とか査定とか。
営業的な物は書いてない。顧客管理とかアポイント獲得とか交渉とか受注とか。
顧客的な物は書いてない。RFI, RFP を書くとか企業を募るとか競売にかけるとか開発企業の提示内容の精査とか発注とか。
法務とか総務とか経理とか経営者みたいな物は書いてない。
そういうのは別の話って事で書かないよ。SE 的な物を書いて行く。
- 体制
- ステークホルダーやキーパーソンを洗い出す。体制図を書く。開発者、運用者、経営者、ユーザ企業、エンドユーザ。
- ヒアリング
- 考える時、ドキュメントを読む時、ドキュメントを書く時、人の話を聞く時、人に話をする時、システムエンジニアとして考えながら動くようにしたい。人が「ｘｘｘの場合はｙｙｙです」という事を言った場合は基本的に曖昧である事が多い。逆のケースとか否定のケースとかを必ず考える様にしたい。間違った事を言ってるかも知れないので鵜呑みにはしない。
- 顧客と開発者の双方が御互いに力を出し合わないと殆どの場合で上手く行かない事( システム開発に失敗する )を納得して貰う。
- 顧客はシステムに疎いので開発者が歩み寄って根気強く聞き出す事。顧客の現場に何日間も居座って分析する事も必要になる事もある。その際には顧客にちゃんと OK を貰う事。
- ユーザがシステム化に望んでいる物を明確にして行く。何が重要な事なのかを明確にして行く。「コストを削減したい」「既存システムとの連携を深めたい」「この機能を使い易くして欲しい」「作業効率を高めたい」。提案型営業の場合はウリを明確にする。
- 分析
- 業務分析や既存システム分析を行う。システム化前の業務フローや既存システムの業務フローやシステム化後の業務フローを作成し分析する。
- 理由を考える。なぜなぜ分析。
- 5W1H を考える。
- ユーザを考える。ある機能を使うユーザはこれこれで、権限はこれこれで、ある画面にアクセス出来る権限はこれこれだけれども、更にユーザの所属によって表示される機能が絞り込まれる、とか。運用管理者の事を考える。ログやレポートや特別なオペレーションに就いて考慮する。経営者の事を考える。経営者向けのレポートに就いて考慮する。経理を考慮する。経理システムとの連携を考慮する。ターゲットユーザを考える。年齢や性別や言語や知識水準や職場環境。移動しながら使う仕事とかセキュリティの厳しい職場で使うとか考える。
- サーバ日時や運用日や営業日を考える。運用日時を考える。オンライン稼働時間とか。24 時間運用とか。バッチ稼働時間とか。足掛け年数、満年数。
- 経営者的に考える。イニシャルコスト、ランニングコスト、システム寿命、費用対効果、次期システム移行コスト。
- 政治的に考える。エネルギー消費節減。資源消費節減。国防( 戦時、天災、情報防衛 )。地産地消。現地採用。
- 全体最適と個別最適。
- 設計
- あると便利な一般的な事柄を考える。一時保存、既存データを流用して新規作成、キャンセル処理、緊急処理、リマインド。ユーザの誤入力を減らしたり拾ったりする工夫。何らかの事故への対処。準正常系( 誤入力等々 )や異常系( メモリ不足やネットワーク切断や予期せぬバグ等々 )を考慮する。逆に異常系を考慮する際に「ここは考慮しないで良い」という範囲を明確にする( そういうのは一律システムエラーで良いという事にするという事 )。システムで対処するか運用で対処するか考慮する。
- ワークフローを考える。承認依頼( 重要度、期限付き )、承認依頼取り消し、承認、承認取り消し、否認、否認取り消し、差し戻し、差し戻し取り消し、中抜き差し戻し。承認要、事前通知要、事後通知要、通知不要。周知( 対象ページへのハイパーリンク付き )。開封済み、未開封。着手( 予定終了日時付き )、着手取り消し。関与、関与取り消し、排他的関与、排他的関与取り消し、関与許可、関与禁止、排他的関与許可、排他的関与禁止。個々人の権限の管理。上位権限を持つ人は下位権限を持つ人のデータを書き換えたり、下位権限の人の権限を設定出来たり、色々なリソースに対して下位権限の人々がどの様なアクセスが可能かを設定出来たりする。ワークフローの並列化( And, Or )。平時ワークフロー、代替ワークフロー、緊急ワークフロー。履歴を持つ。更新差分を保持して差分を画面表示する。コメントを付けられる。要処理プッシュメッセージ。ワークフロー外の人達の存在認知権限、参照権限、更新権限。ワークフロー内の人達の参照権限、更新権限、削除権限。他ユーザのオンライン履歴( ログイン履歴 )の参照。他ユーザの行動予定の参照。見込みによる効率化( 予測在庫数、予測受注数 )。待ち時間( バッチ処理時間、荷物輸送時間、来客待ち時間 )。ワークフローと行動予定の統合。CMS のワークフローなんかの場合は、表示されている物を修正する場合に、表示されている物は表示されたままで、裏で修正後の物がワークフローに乗る感じにしたりする事もある。
- 他システムとの連携を考慮する。
- 代替案を提示する時は筋悪な物も忘れずに提示する。メリットデメリットを全て書く。
- 上限と下限を考える。数値化出来るあらゆる物で考慮する。メモリ容量、プロセス数、同時実行数、印刷レイアウトや画面レイアウトでの文字列の縦横、文字列の長さ、バイト数、数値、同時接続数、データ件数、行数、ページ当たり行数、ページ数、ファイル数、ディレクトリ数、ファイルサイズ、カラム数、一括実行数、処理時間、応答時間、CPU 時間、日時、スタックサイズ、ネットワーク回線速度、実世界の様々な物…、トラック台数、トラック容量、トラック航続距離、倉庫容量、人員数、在庫数、金額。
- 全ての入力と全ての出力を常に考える。
- 同期処理と非同期処理を考える。
- 運用管理者が欲しい機能を考える。起動、終了、強制終了、再起動、バックアップ、リストア( バックアップを用いて元に戻す )、ロールバック( 処理を始める前の状態に戻す )、リラン( やり直し、繰り返し )、ログ、フェイルオーバー、リジューム( 途中から再開する )。
- データ
- カーディナリティを考える。ER 図で表現出来る。
- 最も多様である 0 ... n : 0 ... n の関係から考えて行く事。
- 人と組織の関係を例に考えると、人は複数の組織に所属するし、組織は複数の人を抱えるので、n : n である( 最小値が 0 か 1 かは場合によるし、場合によっては n : n ではなくて 1 : n かも知れない )。
- ある項目が取り得る値を列挙する。取り得る値の範囲を決定する。一覧の作成。初期値。NULL や空文字や 0 等々の特別な値の考慮。特別な値の決定。型や文字コードや比較方法の決定。外部から入って来るデータのフォーマットは yyyy/MM/dd, #,##0 であるけど格納する時は yyyyMMdd, 数値型 に変換する等々のルールの決定。順序。生成処理( シーケンス的な )。
- 事象の重なりを考える。以下の 5 パターン。2 つの円で表現すると良い。マトリクスでも表現出来る。
- A は B の部分集合である。
- B は A の部分集合である。
- A と B は部分的に重なる。
- A と B は完全に重なる。
- A と B は部分的にすら重ならない。
- 論理学みたいに考えてみる。マトリクスでも表現出来る。
- 数式を考える。A + B = C といった法則を考える。
- 状態遷移を考える。因果を考える。状態遷移図で表現出来る。
- A -> B, B -> C, B -> D, C -> A, D -> B。
- データの公開範囲とか参照権限とか更新権限を考える。
- データの発生、利用、変化、消滅を考える。CRUD 図で大まかに表現出来る。
- データの寿命を考える。履歴を残すデータと残さないデータを考慮する。マスタは一般的に履歴が残らないので、名称の変更があった時に過去データの参照がおかしくなったりする事がある。テンプレートとなるデータからインスタンスのデータを作る様なパターンにすると履歴が残る。
- データ項目を集めてレコードやテーブルを作ったならば、ユニークになる項目の組み合わせを全て列挙する。
- 一括して更新や参照を行うべきデータの塊を定義する。
- 一括して処理されるデータの塊を考える。一括処理対象となる範囲を考える。処理の順序を考える。処理を中止すべき事項を考える。
- トランザクションがどうあるべきかを考える。ロールバックされるべき単位を考える。一括処理が複数トランザクションで構成されるのか単一トランザクションで構成されるのか考える。
- 排他ロックがどうあるべきかを考える。
- トランザクションやロックの関係を考える。ロックが複数のトランザクションを内包する。逆にトランザクションが複数のロックを内包する。ロックとトランザクションは 1:1 の関係である。
- 良くあるパターンに状態を表すフラグを用いるというのがあるが、そのフラグとトランザクションやロックや一括処理との関係を明確化する。
- 先勝ちと後勝ち。
- データの利用のされ方や環境の制約を考慮してデータの物理的な構造を決定する。インデックスを考慮する。要求される応答時間。要求される同時アクセス数。要求されるデータ量。検索キーとなる項目。ハードウェアやネットワーク。ハードコーディング、定数、設定ファイル( クラスパス )、設定ファイル( ファイルシステム )、ISAM、DB、ネットワーク、コマンドライン引数、ユーザ手打ち…。
- データの在り方が将来的に変化する事を考慮する。予算や顧客要望に応じて考慮する範囲を決める。
- 1 ... 1 : 1 ... 1 でテーブル分割するのは、処理速度の改善とか、更新日時を細かく制御したいとか、テーブルスペースを分けるとか、フレームワークの制約を守るとか、そういうのを目的にしている。
- テーブル定義が変更になった場合、ソースへの反映、SQL への反映、DB 定義書への反映、ER 図への反映、それらを上手く連携させて漏れなく行う方法を考える。特にカラム名変更のインパクトは大きい。日本語コメントの修正は漏れ易い。
- カーディナリティを考える。ER 図で表現出来る。
- リリース
- ハードウェア、OS、ミドルウェア
- クライアントマシンのスペックやソフトを考慮する。CPU、メモリ、ハードディスク、モニタ解像度、プリンタ能力( 速さ、dpi、カラー、フォント )、OS、ブラウザ等のミドルウェア、インターフェイス( キーボード、マウス、タッチスクリーン )。
- サーバマシンのスペックやソフトを考慮する。CPU、メモリ、ハードディスク、OS、DBMS、WEB サーバ、アプリサーバ、プロトコルスタック、ライブラリスタック、仮想化、ストレージ。
- ネットワーク構成を考慮する。インターネット、イントラネット、VPN、SSL、SSH、プロキシ、ロードバランサ、各種接続機器( レイヤー 2, 3, 4, ... )、SNMP。データセンター、クラウド、社内サーバー、IP アドレス、ドメイン、Verisign。
- サーバの台数や構成を考慮する。
- クライアントマシンの台数を考慮する。
- 参照
- 行動
- 作業範囲や責任の所在を明確にする。その上で一緒にやるべき作業は一緒にやる。そして当たり前の事だけど二人で一つの作業をしたら分業のメリットが無くなるのも考慮する。遠慮し過ぎない。踏み込み過ぎない。
- 一人で仕事を抱え込まない。
- 人に訊くべき事とそうでは無い事の境界線を体得する。自分の時間は金に換算出来るのであり、相手の時間も金に換算出来るのであり、遠慮し過ぎも訊き過ぎも良く無い事を理解する。訊きに行く相手が嫌がったとしても、プロジェクトの遂行が最重要なのであって、それに抵触しなければ大義はこちらにあるので遠慮し過ぎない事。そして問題が起こる様なら営業や上長に相談する事。以下の様な事を考慮する。
- 自分で考えると時間が掛かるけど、その人に訊けば一発で解決する。
- 一般的な事柄であってインターネットやマニュアルで調べられる。職場独特の事柄であって探し出したりするのに非常に苦労する。
- 質問をされる人が忙しくて、しかもクリティカルな仕事をしている。
- 自分が抱え込んでいる仕事がクリティカルな仕事である。
- 自分がその問題にぶち当たっている事で作業が止まってしまう。やる事が無くなってしまう。
- 同じ会社の人間である。
- その事柄に就いて既に現場ノウハウ集に書かれている。似たレベルの人達が既に質問済みである。質問される人が主管である。主管では無いが関係者である。
- 口頭でのやり取りはなるべく記録に残す。
- 業務あってのシステムである事を忘れない。運用に於いても開発に於いても。
- 会議、電話会議、テレビ会議、電話、メール、自分から歩いて話す、向こうから歩いて来て話す、情報伝達手段は適切に使い分ける。無駄な会議はしない。会議をするならスムーズに進める。全体に及ぶ事は周知する。
- 作業はメモに書き出すと良い。
- 作業の優先順位を考える。重要な作業の優先順位は関係者全員の合意を必ず取る。
- 作業を細分化する。自分なりの見積もりを考えてみる。
- 必要なツール、ソース、ドキュメントの在り処を把握する。
- 基本的に何らかの資産を作成する場合はコピー元を探す又は頂く事。
- 現場に入って直ぐの場合は、元から現場に居る人間が「超便利技」を知っている場合があるので、割と頻度を高めに訊いてみる。
- 常に先の事を考える。スケジュールやワークフロー。自分が居なくなるまで。自分が居なくなった後。再び自分が入る時。次に誰がどう動いた時に自分が何をするのだろう。手が空いたり回らなくなったりするかも。これをこの様にして置けば後が楽になる。詳細設計書は新規作成の時には多少は有用だけど保守段階ではゴミになるかも。テストデータや環境を残して置けば改修時に楽が出来る。テスト仕様書も流用出来る。ドキュメントはこういう作りにして置けば後で見易いし直し易い。ソースはこういう風に書けば作り易く見易くデバッグし易く解析し易くテストし易い。後に入って来た人の為にこういう情報を纏めて置くとスムーズに導入出来る。
- テスト( 結合テストやシステムテスト )
- 業務フローに則ってテストを行ってみる。業務フローに則って細かな仕様に対してテストを行う。テストパターンは倍々にするのでは無く要所に絞り込む事。結合バグを発見する為。
- ログインユーザが同じ画面との連携が上手く行く事。
- ログインユーザが別の画面との連携が上手く行く事。
- バッチ処理との連携が上手く行く事。
- 他システムとの連携が上手く行く事。
- 運用で対処する事になったオペレーションをシステム的にどういった手順で行うのかをテストする。
- システム構成や設定ファイル等々を本番に限り無く近くしてテストを行う。設定ファイルの移行ミス等々を無くす為。
- 運用時間も限り無く本番運用に近い形でテストを行う。
- ユーザにテストして貰う。ユーザの認識と合っているか確認する。
- リグレッションテスト。モンキーテスト。
- テストの実施。
- 色々と考慮して割り振りや詳細スケジュールを作る。
- テスト環境を作る。DBMS、アプリサーバ、WEB サーバ、リポジトリ。
- 共有知を周知する。ログ参照方法、データ参照方法、ログイン方法、エビデンス取得方法。
- 可能ならテストで各自が使うデータの範囲を事前に決めて置く。若しくは規約を設ける。
- 事前に粗方のデータは有識者が作り込む。
- 類似バグの起票に就いて対策を考える。管理者を置く。
- ワークフローを考える。以下の流れの中で関係者への通知を必要に応じて行う事。バグ票は各段階で必要に応じて更新する事。必要に応じて繰り返す事。
- バグを発見してバグ票を起票する。
- 分析をする。横展開が必要ならする。
- 修正者を決定する。管理者が決定する。個々人が決定する。
- 修正資産を調査する。
- 修正資産が確定したら他の仕事( 他のバグの修正、テスト工程と並行して進んでいる別の修正 )と被らないか確認する。
- 修正を実施する。
- 修正した資産のレビュー依頼をする。
- 依頼された人はレビューを実施する。
- ローカル環境で動作確認をした方が良い場合はローカル環境で動作確認をする。
- テスト環境への資産反映を行う。又は管理者に依頼する。
- テスト環境の再起動等々が必要な場合は行う。又は管理者に依頼する。
- 修正された事をテスト環境で確認する。
- 管理者の承認を貰う。
- リポジトリに修正した資産をコミットする。コミットログに就いてはテンプレートを事前に配布して置く事。
- 業務フローに則ってテストを行ってみる。業務フローに則って細かな仕様に対してテストを行う。テストパターンは倍々にするのでは無く要所に絞り込む事。結合バグを発見する為。
