tokoroten: I’ve been thinking a lot about DX, and I’ve tried to put it into a network structure, and this is what I came up with: the root of agility has shifted from personnel change to double-loop learning using digital. In short, the root of agility has shifted from personnel change to double-loop learning using digital technology. DX is a shift from personnel change to double-loop learning utilizing digital technology.
nishio: why not leave the root of agility at the root of personnel changes? Has it stopped working? Why is that?
tokoroten: software development is a large wave of operations and highly specialized, so we cannot hire software personnel in-house IT personnel cannot be reassigned because they are specialists (which is now a lie). As a result, the trend is toward IT Externalization. In the non-software area, agility can be ensured through personnel transfers.
tokoroten: Nevertheless, the non-software domain has narrowed over the years, and computers are now taken for granted in almost every sector. As a result, agility through software modification has become more efficient than agility through rearrangement.
nishio: “Agility is gained through reassignments,” “Software is now used in almost every department,” and “Agility through software retrofits more efficient”? So you started reassigning and firing Tayupinko (people) instead of people.
nishio: On the other hand, companies that outsourced software development fell into the trap of change inhibition, saying that they could not modify software without clarifying the specifications in advance, and thus could not gain “agility through software I understand that the company that outsourced software development could not gain “agility through software modification” because they fell into the trap of “cannot modify software without clarifying the specifications in advance”. I am convinced.
tokoroten: y, it’s around the right side of the diagram. It’s around V-shaped model dysfunction or something like that. To accept the “modifiability” of the ordered software, there must be at least one person who can write the code. If it is not evaluated at the acceptance inspection, there is no benefit to pay for the “changeability” in the SI’s business model.
nishio: Unless the party specifying and placing the order includes Software Modifiability in the requirements, the contractor is not obligated to make it. When changes are needed, it is an additional billing opportunity for the contractor. Rather, there is an incentive to make it difficult to change without information that has not been given to the ordering party to prevent other vendors from taking it.
nishio: this whole argument is convenient for Cybozu. The reason why Cybozu kintone is selling so well is because it is “software intended to be highly changeable”. And it solves the development resource problem by allowing business applications to be created to some extent without specialized engineers. - System development by non-engineers
nishio: In the days when “highly specialized and difficult to relocate personnel” were needed to make business applications, the operation was based on the idea that “people are needed only when making applications and not later”. The two assumptions are now changing.
tokoroten: y, software has become something that is constantly being modified and the bar for expertise has been lowered. Software has gone from mainframes, to Linux-based, to regular web applications. Then things like Kintone, Google App Script, and RPA are getting into the mix. It has become much more organized.
relevance
This page is auto-translated from /nishio/DX=デジタルを活用したダブルループ学習への移行 using DeepL. If you looks something interesting but the auto-translated English is not good enough to understand it, feel free to let me know at @nishio_en. I’m very happy to spread my thought to non-Japanese readers.