SE/ITコンサル向け思考のフレームシリーズ 「Input/Output」
よくあるお悩み
自分自身への言い聞かせも兼ねて、頭の中を整理してみるシリーズ。
よろしければお付き合いください。
複雑なシステムを設計しないといけない、または設計書のないぐちゃぐちゃな既存システムの解析をしないといけない、そんな局面はよくある。
ついつい複雑な処理のことばかりに目が行って、だんだんよくわからなくなって設計が進まない、解析が進まないなんてことも。
そういう時はこれでもかというくらい、まずはシンプルに
Input
Output
だけを考えてみるとよい。
プログラムの場合
分かりやすいように小さいプログラムで考えてみる。
例えば関数には引数と返値がある。
引数:Input
返値:Output
である。Javadocなどのクラス仕様書にも必ず書いてある。
また、Web APIの場合
Input:リクエストパラメータ
Output:JSONやXMLでのレスポンス
となる。
何かを渡すと(何かしらの処理の結果)何かが返ってくる。
その返ってくる何かがプログラムやWeb APIの目的である。
ジョブの場合
バッチプログラムを順番に実行するジョブの場合はどうか。
最初のバッチでファイルを作成し、そのファイルを次のバッチで読み込むという場合があるだろう。この場合は最初のバッチのOutputが、次のバッチのInputになる。I/Oのリレーのようなものだ。
また、最初のバッチであるテーブルを更新し、次のバッチでその更新結果を踏まえて処理を回す場合があるだろう。
この場合は最初のバッチでのテーブルへのINSERT・UPDATEがOutput、そしてその更新されたテーブルのレコードが次のバッチでのInputになる。これもI/Oのリレーと言える。
そしてこれを続けていった最後のOutputが、ジョブの目的と言えるだろう。
迷子になったとき
色々考えていて思考が迷子になった時は、
・どんなOutputを作るのか?
・なぜそのOutputが必要なのか
また、そのために
・どんなInputが必要なのか?
・本当にそのInputで十分か、または本当に必要か?(不要ではないか)
を問い直してみるとよい。
そしてInputとOutputを、フローチャートやデータフローダイアグラムで繋いだら(この中でもI/Oのリレーが行われている)、ほぼ設計完了である。
終わりに
これを明確に意識し出したのは、前職の先輩が、
「システムなんてさ、要はInと処理とOutだけなんだよ」
って話をしてくれた時。
乱暴なようで本質をついている。
そんな私もプロジェクトメンバのシステム設計をレビューすることがあるが、この思考のフレームが染みついているので、パッと見ただけで大体の問題を指摘できている気がする。
普段どうやって考えているかを言語化するのはなかなか難しいが、この思考のフレームシリーズは今後も続けられればと思う。
この記事が気に入ったらサポートをしてみませんか?