一問一答:SI事業者が陥りがちなアジャイル開発がうまくいかないことへの解決策
私が主宰するITソリューション塾では、アジャイル開発の実践をテーマに、戦略スタッフサービス・代表 戸田孝一郎さんに、毎期一枠の講義をお願いしています。戸田さんは、長年、アジャイル開発の現場を指導し、ITベンダー/SI事業者の事業変革にも関わり、これまでも数多くの成果をあげられています。
そんな彼を講師に招いているのは、実践に裏打ちされたノウハウあるいは、「実践の勘所」を教えていただくためです。実践経験があるからこその話しは、実に生々しく、実際の開発の現場に携わるエンジニアにも響くようです。
そんな戸田さんの講義について、受講者から質問のメールを頂きました。これに対して、戸田さんからは、実に丁寧な回答を頂いたのですが、そのやり取りは、多くのSI事業者が持つ企業文化に根ざした率直な疑問であり、たぶん多くの皆さんが、「常識」だと感じる内容だと思います。それについての戸田さんの回答が、見事にその常識を打ち砕き、アジャイル開発の本質を解き明かしてくれます。
そこで、質問者のお名前を伏して、このやり取りを紹介させていただきます。
このやり取りの最後に、戸田さんから、「プログラミング能力を向上させる方法」についての、実践的アドバイスもあります。
アジャイル開発について、疑問を持っている人、ご苦労されている人には、特に、役に立つ内容だと思います。
*[注釈]は、私が追記しています。
===
受講者からの質問
先日の講義[テーマは、「アジャイル開発の実践」]、ありがとうございました。
戸田さんの事例を交えた講演、いろいろ気づきがありました。
一点、クラシック受託開発脳から脱却しきれていない私にしっくりこない件があり、質問させていただきたい点がございます。
大規模開発でもアジャイル形式での開発が適合するという事例があったかと思います。
大規模開発ですと、システムが出来上がったあとでも不具合対応、追加開発などが発生することはよくある話かと思います。
クラシック系開発だと、そのまま開発チームの一部が維持されて保守チームだの、追加開発チームだのが設定されることが多いかと思います。
アジャイルの場合は、チームは別の開発にすぐに移ってしまうかと思いますが、この場合の保守や追加開発はどのようにスムースに対応するのでしょうか?
追加の場合は、いつからならできますよ、という猶予はあろうかと思いますが、保守の場合はいますぐ対応して、ということがあってこの場合、チームが解散しているから、すぐにはできない、ということかと。
アジャイルチームとは別に、保守チームを立上げと組成して、そこに引き継ぐようなイメージになるのでしょうか?
作った人が保守しないというのは一般的につらいとは思いますが、このあたりの意識ギャップがクラシック脳なのでしょうか...
すいませんが、このあたりモヤモヤしておりますので、ご教示くだされば幸いです。
戸田さんからの回答
ご質問ありがとうございます。
ご質問の内容はWF[ウオーターフォール]で開発すると移行後に追加変更要求や保守対応で開発チームを残して、お客様への対応に当たると言うのは、半ば常識化しておりますね。
まずこの考え方の根本原因は、二つの原因があります。まず一つ目は、WFの開発の仕組み上、プロジェクト途中での変更要求に対応ができない為に、移行後まで待ってもらう事が常識化しています。なので、移行後も開発チームが残らないと対応できないと言う事ですね。
アジャイルではリリース直前まで変更要求を受け付けて即対応しますので、このような移行後の追加変更要求は、ほとんど出ません。
二つ目は、プログラムがシッカリとかけていない質の悪いプログラミングだと言う技術的な問題です。保守をするために開発した人が居なければできないと言う事は、プログラムが俗人化されて書かれており、大変質の悪いプログラミングです。
良いプログラミンとは、オープンソースの様なコードです。ドキュメントが無くてもプログラミング言語を知っている人であれば、誰でもソースコードを見ただけでメンテナンスできる程の可読性の高いプログラミングがされておれば、開発チームを解散しても全く困りません。
大変失礼ながら、〇〇様がご懸念せれる事態は、開発エンジニアのプログラミングスキルが低いと言う技術力の無さと、個人のサイロ化した開発方法(WFの最大の欠点)でチーム開発できないと言う事が原因です。
アジャイルを正しくやれば懸念される事象は全く起こりません。
回答になりましたでしょうか?
質問者の返答
戸田さん、ご回答誠にありがとうございます。
誠に耳の痛い話でして、頭の切り替えができていないことがよーくわかりました。
後半はその通りかと思いますし、前半においてもビジネス環境の変化により構築時点では想定しえない変更があったとて、可読性の高いコードによって別のメンバーでも改造可能、という理解をしました。
引き続き自身、組織の意識や仕事の改革を進めていこうと思います。
今後ともよろしくお願いいたします。
戸田さんの返答
ご理解いただきありがとうございます。
個々のエンジニアのプログラミング技術品質を高く向上させるには、アジャイルのプログラミング技法であるXP(エクストリーム・プログラミング)をエンジニアの皆さんに習得していただくことが早道です。
XPはアジャイル向けの技術ですが、ことプログラミングをするということではWFでも活用できます。
XPを習得されれば、自ずとプログラミングに対すると品質を意識できるように成長します。誰でも成長します。ぜひ頑張って御社の半ば常識化しているソフトウエア作成の基本を見直して、技術力を高めてください。
システム設計の技術力を高めるよりも、プログラミングの技術力を高めるほうがシステム開発では数段有益です。システム開発の基本はプログラミング技術力の向上です。設計やアーキテクチャもプログラミングの技術力がなければ、絵にかいた餅です。
ぜひともソフトウエア生産技術を向上させてください。世界に冠たる日本の製造業にて開発された生産技術力はソフトの世界でも有益です。
製造現場に学ぶ姿勢が大切です。期待しております。
また何か相談事ができれば、いつでも気楽に連絡ください。
===
いかがでしたか?目からうろこの方も多かったのではないでしょうか。
私たちは、どうしても「常識」に囚われがちです。しかし、アジャイル開発は、そういうSIの常識から見れば、「非常識」の極みかも知れません。この常識のギャップが、"本物の"アジャイル開発の実践を妨げているのでしょう。
SI事業者の方からは、「アジャイル開発には取り組んでいるが成果をあげられない」や「納期やコストが守れない」、だから、「アジャイル開発を辞めようと思っている」といった、話しを聞くことがあります。
そのことについて、戸田さんは、講義のなかで、次のような話をされていました。
「それは、アジャイル開発ではないからです。アジャイル開発には、しっかりとした原理原則があり、それを活かすためのマインドセットがなくてはうまくいきません。」
ご紹介したやり取りが、皆様の気付きになることを願っています。
ITビジネス・プレゼンテーション・ライブラリー
【12月度のコンテンツを更新しました】
======
目的の資料にいち早くアクセスできるよう、以下の二点を変更しました。
・タイトルと資料の構成を大幅に変更しました
・研修資料を作るベースとなる「最新のITトレンドとこれからのビジネス戦略(総集編)」の内容改訂
ITソリューション塾について
・教材を最新版(第38期)に改訂しました
・講義の動画を新しい内容に差し替えました
======
DXとビジネス戦略
【改訂】デジタル化がもたらすレイヤ構造化と抽象化 p.14
【改訂】デジタル化とDXの違い 改訂版 p.27
【改訂】DXの定義 1/3 p.39
【新規】DXの定義 2/3 p.40
【改訂】DXの定義 3/3 p.50
【改訂】DXのメカニズム p.45
【新規】「デジタル前提」とは何か p.46
【改訂】DXの公式 p.47
【新規】なぜ「内製」なのか 1/3 p.178
【新規】なぜ「内製」なのか 2/3 p.179
【新規】なぜ「内製」なのか 3/3 p.180
【新規】ITベンダーがDXを実践するとはどういうことかp.174
ITインフラとプラットフォーム
【新規】サーバー仮想化とコンテナ 1/2 p.76
【新規】サーバー仮想化とコンテナ 2/2 p.77
【新規】コンテナで期待される効果 p.78
【改訂】コンテナとハイブリッド・クラウド/マルチ・クラウド p.81
開発と運用
【新規】アジャイル開発が目指すこと p.37
【新規】SI事業者がアジャイル開発で失敗する3つの理由 p.74
IoT
【新規】Connected p.139
ビジネス戦略・その他
【新規】個人情報とプライバシーの違い p.146
【新規】「個人を特定できる情報」の範囲の拡大 p.147
【新規】Privacy保護の強化がビジネスに与える影響 p.148
【新規】影響を受けるデバイスやサービス p.149
【新規】スマホAIの必要性 p.150
AIとデータ
【新規】データサイエンティストに求められるマインドセット p.146
改訂【ITソリューション塾】最新教材ライブラリ 第38期
・ITソリューション塾の教材を最新版に改訂しました
- DXと共創
- ソフトウエア化されるインフラとクラウド
- IoT
- AI
下記コンテンツを新規に追加しました
- RPAとローコード開発
- 量子コンピュータ
- ブロックチェーン
下記につきましては、変更はありません。
ERP
クラウド・コンピューティング