暗黙知は帳簿と運用に眠る - 業務理解に向けて - #benkyoenkai
年忘れLT宴会<第60回IT勉強宴会>に参加しました。最も刺激を受けたのは杉本さんのLTでした。
暗黙知
同じお客様の開発を何度かすると「なるほど」と過去のことが理解できることがあります。与えられた仕様(要件)を満たすソフトウェアを開発する中で、その背景にある暗黙知が得られた瞬間です。
もちろん、最初の開発でもある程度は暗黙知を得ることはできます。仕様についてそれはなぜかを質問することです。納得できる詳しい説明や、これまでそうしてきたからなど、色々な回答が得られます。
しかし、暗黙知の全体像に関しては、開発を一通り終えて、実際の運用がうまく回り出して一通りの業務を近いするまで、なかなか得られません。
帳簿は暗黙知の中心
杉本さんのLTで紹介された開発では、帳簿(DB)が業務システムの中心で、運用で対応する部分も含めて業務システム開発します。そのような開発に於いては、業務分析やデータモデリングを追求することで、業務を明確にして暗黙知をシステムに取り込んでいくのでしょう。
それはソフトウェアのプログラミングだけでなく、帳簿(DB)はもちろんのこと、運用を含めた暗黙知を明確にしないと教務システムはうまく開発できないという示唆だと思いました。
おわりに
SRA Advent Calendar 2017に「効率的なモデリングをマネージメントする」(ここにも転載:その1、その2、その3)という記事を書きました。これに運用はほとんど考慮されていません。
これまで、いわゆる業務系とは異なる開発をしていながらも、IT勉強宴会で色々勉強をさせていただいてきましたが、どこかモヤモヤするものがありました。それが運用であったことに気付くことができたのは、今回の大きな収穫でした。
IoT関係で運用と言うと、UIがらみを除くとクラウドのアーキテクチャ設計とその運用設計がそれに当たります。クラウドでは新しいサービスが続々と出てきますので、それが開発を一通り経験しないとわからない理由だったのかと腑落ちした次第です
LT中のアジャイルとウォーターフォールに関しては、主語が大きくて気になりますが、それを上回る刺激を受けました。ありがとうございました。
« 効率的なモデリングをマネージメントする その3 - 開発標準を素直に実施しない - | トップページ | [#Node-RED]インジェクトノードで定期処理 - ポーリングとバッチのヒント - »
「私のアジャイル」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 「任せて、任せず」「魚を与えるのではなく"釣り"を教えよ」(2021.08.16)
« 効率的なモデリングをマネージメントする その3 - 開発標準を素直に実施しない - | トップページ | [#Node-RED]インジェクトノードで定期処理 - ポーリングとバッチのヒント - »
コメント