４月２４日　伴走開発のための業務の可視化について

４月２４日ですね。

昨日、要件定義フェーズでお客様のもとに行ってました。
フェーズも大詰めなので、フロー図を打ち合わせながら修正し、その場で修正しながら進めました。

終わった後、今のようにヒアリング結果をすぐその場でフロー図に反映させながら進めることに感心されました。

これ、私がフローチャートの書き方を知ってるからです。
私のことはどうでもよくて、ここでお話ししておきたいことは、そもそもお客様との間に共通言語がないと話が始まらないことです。

例えば、条件によって判断する処理を表すには、横の菱形を入れます
これは、フローチャートでは基本です。が、この条件判断処理を星型に表してしまうと、途端にお客様は混乱します。
なぜなら条件判断処理が菱形というのは、ITの世界では共通認識だからです。

もう、何十年も前から条件分岐は菱形であると伝承され、共通認識になっています。そのため、いまさら私が条件判断処理は星形と言い募ったところで誰も同意してくれません。

フローチャートの仕様は、相当昔に作られたものなので、テープデバイスやパンチカードが図案に採用されています。そればかりか処理もそうした前時代の装置が想定されています。
なので、今の私たちがフローチャートの仕様に忠実に準拠する必要はないと思います。実際、私もいい加減な理解です。そもそも独学なので、誰かに書き方を習った事がありません。

それでも、処理とビジネスフローの時間軸を図で表すにあたっては、お客様との間に処理の共通認識を持つ必要があります。
テキストでつらつらと書くと冗長になってしまう処理フローも、フローチャートを使えば簡単に表せます。

何度もここで書いている通り、これからはプログラミングそのものはAIがやってくれます。
これからの技術者のスキルで求められるのはプログラミングてはなく、お客様のビジネスフローをシステムに落とし込む能力です。
つまり、フローチャートのように、お客様と認識を合わせられるための記述ルールを知っていなくてはなりません。

正直、フローチャートなど時代遅れなのだと思いたいです。
今は作ったプログラムからフローチャートに落とせるツールもあります。
が、お客様とその場で認識を合わせつつ、処理の流れの相互認識を深めるには、フローチャートにまだ一日の長がある気がします。

その場で対面しながら進められるkintoneも、巨大な組織や多くの関係者がいるような今回のような案件だと初期導入の共通認識が大切です。つまり、最初のビジネスフロー上での相互理解が必要なので、フローチャートが役立ちます。

ということで、どこかで軽く皆さんに説明する機会を作っておいた方がよさそうです。