内閣官房情報通信技術（IT）総合戦略室 発行「アジャイル開発実践ガイドブック」の感想
2021 年（令和３年）3 月 30 日に日本政府の内閣官房情報通信技術（IT）総合戦略室というところから「アジャイル開発実践ガイドブック」なるものが公開されました。内容的には日本政府の各省庁におけるIT調達のアジャイル適用がどーのこーのといった文書になっています。社内のTeamsでこの情報が流れ、中身を見て「すげー」とか思ったのですが、それがまたあの市谷さんが関わっていると知って、これは「レポートしなくては！」と思ったのでエールとして何か書きます。
ガイドブック原文はこちらです
政府機関がこういうものを刊行する意味
基本的にこの文書は政府機関内でIT関係の調達に関わる官僚の皆さんに向けた文書です。ですから別に外部に公表する必要はないのかもしれません。確かに応札するベンダーとかに見せるという意味もあるのでしょうが、こういったオープンな姿勢というだけでもすごく共感が出来ました。それ以上に、こういった政府側の文書がオープンになることで数多くの「堅い会社」の中で新しい息吹を生み出そうとしているたくさんの人達にとって、非常にありがたい文書だと思います。なぜならアジャイルに否定的な人たちにとって一番影響があるのは「権威」であり、その頂点は「政府」だからです。だいたいの抵抗勢力・・・・単にアジャイルが嫌だと言っている人達だけでなく「アジャイルって日進月歩の業界だけに合致するもんだろ」と知ったようなことを言うような人たちに取って「内閣府だってこう言っていますよ」という言葉は必殺技としか言いようがありません。
ホント ありがとうございます
「１ はじめに 」
現実的には開発期間を潤沢に確保することは難しく、要求とその仕
様の詳細をすべて記述するのに費やせるほどの時間をあてられないことも少なくありません。
ここでは従来のスタイルのIT開発、IT調達において何が問題なのか、アジャイルで何を解決するのかが完結に書かれています。けっこうここがいい加減な事が多いですね・・・反省。でもそのなかで注目したのは1Pの最期の「アジャイル開発への理解」のところ。アジャイル開発の書籍のほとんどは開発チーム向けが多いので、どうしても主眼はそちらになりがちなのですが、経験者に聞けば聞くほど・・・しかも堅い組織で苦労した話はほぼすべて「プロダクトオーナー」です。
職員はアジャイル開発の役割の１つである「プロダクトオーナー」としての
振る舞いを理解する必要があります。
職員はアジャイル開発の役割の１つである「プロダクトオーナー」としての
振る舞いを理解する必要があります。システム開発全般にわたって、主体的に関与しなければなりません。
「職員は」
ココ大事ですよね。アジャイルは受託企業のやることで自分たちは関係ない・・・そういう態度の発注元が多いですよね。そうですよこれこれ！は中側（ビジネス目標を達成したい側）が自分ゴトでないと成り立たないですね。
このひっさいつわざの余韻に浸りながら、その後の一般的なアジャイルの用語の説明に入ります。
「２ 政府情報システムにおけるアジャイル開発」
元来は特定の開発プロセスを指すものではなく、より良い開発のあり方を追求する態度のことを指しています。
そうでうよね、自分的には「思想」とか「考え方」と説明していましたが「態度」・・・・これもしっくりきます。アジャイル開発という言葉からアジャイルって手法みたいに考えられがちですが、態度ですよね。正しくはウォーターフォールという手法を否定するものでもないですし、その裏の態度・・・・「ドキュメントに何も疑問を持たずに投入工数ぶん何も考えず働け！」・・・は否定したいですが。
そしてコラム「混ぜるな危険」
異なる文化を無意識に「混ぜて」しまうことには注意を払いたいところで
す。
文化、態度ですからね・・・・ここは見えにくいのでついついまぜちゃいます。偉い人めんどうだし・・・。事情はわかりますわかります。でも注意は払わないと「態度」に致命的な事態が・・・・
そこからフィードバックの話、そしてコラム「モニタリング改善におけるアジャイル開発の有用性」・・・BIツールの活用によってアジャイルな態度になっているお話です。ＢＩツールも、クラウドもアジャイルにつながるツールです。不思議な事にこの周辺の人は「アジャイル」を連呼しないですが、（自分的には基本的にこちらの住民）態度は確実にアジャイルな方々が多いです。・・・ここをつなげてくれたのもチョットうれしいです。
協働を育み、チームの機能性を高める
「アジャイル開発の９つの意義」としてひとつづつ丁寧に紹介されていましたが、自分が注目したのはここです。ひちつのITシステムに向かって利害が推す反する場合など（社内システムはこれが多い）は、この協働って大事ですよね。話し合いながら・・・そして実際に動くものを見ながら「落としどころ」をお互い確認する。・・・机上の空論では利害関係者のどちらかの意見が押し通されるか。逆に何も決まらないか・・・最近のウォーターフォール案件が「要件定義が終わらないシンドローム」に陥るのはこの「協働」になっていないからですね。
そこから「９つの意義を十分に発揮するための前提」です。
全部大事なのですが、注目するのはコレ「対話コミュニケーションの重視」ですね。一つの実物を囲んで、相対する利害の人・・・別に対立していなくても予算やスケジュールという敵がいます。・・・・が課題の解決という共通の目的、顧客という向かうべき相手に正面から向かって話し合う・・・・嗚呼これ。
そこからアジャイルの適用方針です。
ア 向いている領域
開発対象についてある程度の方向性はあるものの、全容が明らかになって
おらず、開発を進めながら詳細化していく必要があるケース。あらかじめ詳
細を決めることができない、あるいは決めにくい領域（例えば、利用者の体
験デザインから検討が必要な情報システム）。
よく、アジャイルなんてWebサービスとかやっている一部の事業向けの手法と思い込んでいる人たちがいますが、そんなことはないです。詳細を決められない領域ってもっとたくさんありますよね。たとえ経理領域でも「キャッシュフローの改善」だったら確実な答えはないわけです。しかも今はＶＵＣＡの時代です。完全にアジャイルに関係ない領域はないですよね。
「３ アジャイル開発の運営」
ここは役割とスクラムイベントと作成物についてです。役割の最初は当然のごとく「プロダクトオーナー」ですね。そうですよね職員に向けた内容ですし・・・・でもスクラムの中心はスクラムマスターと思われがちですが、大事なのは（全員大事ですが・・・）プロダクトオーナーですよね。しかもここにトドメのコラム「プロダクトオーナーが果たす役割」・・・「プロダクトオーナー」と「プロダクトオーナー支援」を分けるのはいいですね。いただきです。
そこからはイベントや運営とかの説明になります。
アジャイル開発の本質は、経験したことに基づいて、その次の活動を最適化
していくところ（適応）にあります。
このへんが手法ではなく態度というところのメインどころですね。IT人材使い捨ての従来の態度ではなく成長していく（させていく）事ですよね。
「４ 各種留意事項」「５ 参考情報一覧」
ここから全般的に陥りやすい落とし穴・・・・ドキュメント、要件定義、品質管理、・・・そこから第三者チェックの話、体制の話・・・ここから網羅的にカバーできなかったところを説明しています。
勝手に感想
たった33Pの内容ですが、アジャイルに挑むために必要な事はだいたい載っていますよね。（そんな凄い判断できる身ではないですが）
・・・「せめて、これだけは読んでくれ」という状況・・・堅い組織ではほぼすべてこの状況になると思いますが・・・・スクラムガイドはもっと完結ですが、あれは志のある人にしか刺さらない・・・には最適な文書です。ありがたくいただきます。
自分の会社ではアジャイル無理かな・・・・
と思っている人はこの一冊です。
JIS規格で刊行してほしいくらいのレベルです
」
この記事が気に入ったらサポートをしてみませんか？