はじめに

こんにちは！KINTOテクノロジーズの開発支援部に所属する「きんちゃん」です。

普段はコーポレートエンジニアとして「全社利用するITシステムの維持管理」を行っています。

先日、「KINTOテクノロジーズ MeetUp！～情シスによる情シスのための事例シェア4選～」というタイトルで「コーポレートIT領域に特化した、事例発表＋座談会形式の勉強会」を開催しました。

今回は、その勉強会で事例発表した内容について、補足を交えながらテックブログ上で紹介します。

発表資料

当日の発表資料全体については、以下を参照ください。
【アジャイルなSaaS導入】最小工数で素早く最大の成果を生む秘訣

ここから先は、実際に発表で利用したスライドと共に、資料だけでは分かりづらい部分の補足や、会場ではお話できなかった部分について、色々と補足していきます。

タイトルの選定

さっそくですが、このタイトルです。

「アジャイル」というキーワードについては、多くの方が色々な解釈を持たれており、発表のタイトルとして利用するのは、なかなか悩むところです。

ただ、僕の発表を聴いてくださった/見てくださった誰かが「あ、こういうのもアジャイルなんだ」「そんなに難しい話じゃないな」といった気づきを得て、それがその人の新たな行動の後押しになれば、と考えて「アジャイル」を利用しました。

※もちろんキーワードとして「惹きがある」という点もポイントでした。

話すこと/話さないこと

タイトルで「アジャイル」のキーワードを使ったからには、やはりメインで伝える内容は「アジャイルソフトウェア開発における価値」にリンクできると良いなと思ったので、このような内容にフォーカスしています。

もし「もっと詳しい導入プロセスや、プロジェクトの途中で起きた地味な話を聴いてみたいよ！」という方がいらっしゃれば、ぜひKINTOテクノロジーズへのJoinをご検討ください。

背景

まずはITチームから導入を開始したITSM（IT Service Management≒問合せ/依頼管理）ツールですが、それなりにスムーズな導入ができた背景もあり、IT以外の管理部門にも導入しましょう！という流れができました。

その流れができるまでは、社内であまり「IT以外の管理部門」に接する機会はありませんでした。

僕自身、前職以前を含めて過去に多くの非IT部門の方々とのプロジェクト経験があったため、このプロジェクト推進の指名をもらった時は、過去の経験が活かせると感じたため、嬉しかった記憶です。

「ある程度のゴールイメージはあるものの、具体的な要件や機能については定まっておらず、とは言えなるべく工数はかけずに勝ちを得たい」という背景から、「カッチリと要件を決めてフェーズを切った導入（≒ウォーターフォール）」よりも、「最小限の価値を作り込みながら、対話と軌道修正を繰り返す導入（≒アジャイル）」の方が適している、と判断したものになります。

このスライドでは「アジャイルに進めると良いんじゃなーい！？」と、あたかもプロジェクト開始時点から考えていたように見られますが、実際には「どういうふうに進めようかなー。とりあえず関係者の人たちに話を聴くところからだなー」くらいの感覚でした。

実際には、管理部門の方々とのヒアリングを経た上で、「この人たちとなら、このスタイルで進められそう！」という感覚を得たため、後述の「アジャイルな進め方」に踏み切った形です。

アジャイルについて

僕は、社内で「アジャイルってなんですか？」って聞かれた時に「短い期間でカイゼンを繰り返しながら、価値にフォーカスした仕事を進められている状態です」みたいな回答をしています。

ソフトウェア開発に触れている方であれば「アジャイルソフトウェア開発宣言の価値と原則」は分かりやすいですが、そこにピンと来ない人もいます。

最近では「アジャイルのカタ」という文書も公開されたり、非IT向けのアジャイル書籍も発売されたり、色々と説明しやすくなってきたな、という感覚があります。

プロジェクトの進行について

ここからのスライドについては、できるだけ「アジャイルソフトウェア開発宣言における価値」にリンクする形で「どこがアジャイルなのか？」を説明できるように心がけました。

このスライドで伝えたかった事は、「なるべく無駄なコミュニケーションを減らし、本質的な会話にすぐ入れるようにするための仕掛けづくり」です。

良くあるソフトウェア開発の場合は、「今どのような業務をおこなっているのか？」を探索する工程や、「何をやりたいか？」を明らかにしていく工程があります。

今回は「ある程度のカタが決まったSaaSの導入」であるため、「今の業務を元に要件を定めていく」よりも、「カタを前提にした、良い使い方」を模索していく方が適切と考えました。

また、ローコードツールの強みとして、初期段階での「作って壊して作り直す」のコストが圧倒的に低い事もあり、「初回の打ち合わせ前に、最小限の価値が提供できるプロトタイプを作る」事も容易に進められました。

結果として、初回の打ち合わせで「さぁ、どんなものを作りたいですか？」という会話を始めるのではなく、「こういう使い方のシステムだとどうでしょう？何かおかしなところはありますか？」といった、具体的な動くものを対象にした議論からスタートできるようになりました。

これらは、アジャイルソフトウェア開発宣言でいうところの以下の価値にフォーカスした点となります。

• プロセスやツールよりも個人と対話を
• 包括的なドキュメントよりも動くソフトウェアを

このスライドで伝えたかった事は、「短い間隔で価値を作り込み、フィードバックを得て、納得の行くシステムを提供するための仕掛けづくり」です。

打ち合わせで良くあるものとして「持ち帰り検討」があります。例えば「どういうメニュー構成が良いか検討してくる」「どういう処理フローが良いか検討してくる」といったものです。

今回は、そのような「持ち帰り検討」を「相手にお任せ」するのではなく、「持ち帰り検討の場に、自分がゲストとして参加させてもらう」方法を取りました。

そうする事で、会話の中で出た質問や懸念・違和感といったものを即座に受け止め、素早く回答したり、その場でシステムの改修に手をつける事もできるようになります。

結果として、「持ち帰り検討の場」であるにも関わらず、「検討を踏まえた仕様変更と、実際の機能改修」までも進めてしまえるようになりました。

また「ここで大きな仕様変更が出た」とありますが、ある意味「作り直し」をした方が良い状況になりました。もちろん、これまで作ったものを捨てる事になりますが、議論の場に僕も参加していた事で「作り変える事の必要性と価値」について十分に納得した上で、その選択を取る事ができました。

これらは、アジャイルソフトウェア開発宣言でいうところの以下の価値にフォーカスした点となります。

• 契約交渉よりも顧客との協調を
• 計画に従うことよりも変化への対応を

プロジェクトを終えてみて

今回のプロジェクトを通じて、僕が大きく得られたと感じるものは「信頼関係」です。

あくまでも僕からの一方的な意見ではありますが、「この人たちと一緒に仕事をすると、良い結果が得られる」「次も何かあったら相談してみたい」と思ってもらえるようなきっかけづくりに貢献できたのではないか、と感じています。

今回の例にあるような「アジャイルな取り組み方」でなくても、もちろん良い結果を産めるような進め方は多くあると考えています。

ただ、何か進め方に困った場合は、「アジャイル」が持つ価値を参考に、自分の行動をちょっとだけ変えてみる事をオススメします。

• ありたい姿を描き、そこに向かってちょっとだけ行動を変えてみる
• ちょっとだけ変えてみた行動の結果を観察し、そこから更にありたい姿を描く
• またちょっとだけ行動を変えてみる

この繰り返しができてしまえば、それはもう「アジャイル」な状態と言えるでしょう。

最後に

冒頭にも書きましたが、今回の事例を見てくださった誰かが「あ、こういうのもアジャイルなんだ」「そんなに難しい話じゃないな」といった気づきを得て、それが次の新たな行動の後押しになれば、幸いです。