読者です 読者をやめる 読者になる 読者になる

Appresso Engineer Blog

アプレッソのエンジニアが書く技術ブログです。

Agile Japan 2016、そしてアジャイルについてガヤガヤ話しました! 

開発部の土岐です。 今年4月に育休から社会人復帰後3ヶ月経過し、ようやく社会というものに慣れてきた社会人再一年生です。

ということで、弊社アプレッソの開発部10名がワイワイ参加し、先日レポート記事をアップしたAgile Japan 2016。

AgileJapan2016

あなたと作るアジャイル」というテーマを真摯に受け止め、「参加することはスタート地点。その後にどんなアジャイルを作るのかが問題なのだ!」という気概で、参加者と参加できなかった者も含めて、「我々の開発プロセスをどのように作っていくか?」という主旨の元、ガヤガヤと座談会をしました。 今回は、この座談会で話した内容の概要を紹介しようと思います。 なお、今回の記事は以前の参加感想記事を前提としておりますので、未読の方はご一読いただくことをオススメします。

appresso.hatenablog.com

appresso.hatenablog.com

「スクラム」で何ができるか? 「スクラムマスター」は何をやるか?

印象深かった講演として真っ先に挙げられたのが、Joe Justice氏による基調講演の「スクラムがイノベーションを加速する 〜ソフトウェア以外にも適用されはじめたアジャイル〜」。スクラムと言えばソフトウェア開発プロセスの手法というイメージが強いですが、火星移住計画や農業などさまざまな分野でスクラムの手法を適用し、プロジェクトを成功に納めている事実に驚いた人が多かったようです。

「スクラムの"良いものをより素早く提供しよう"というイノベーションが広がっていっていることを実感して感動した」

という感想がありました。

その中で話題となったのが「スクラムマスター」という役割の重要さです。

「生産性を上げるための障害を取り除くスクラムマスターが居てこそのスクラムだと思った」

「従来の我々のプロジェクトだとマネージャーがチームリーダーをやることが多かったが、まったく違う立ち位置だと思う」

「生産性を上げるためにあらゆることをやるというのがスクラムマスター。開発者のモチベーションを上げることもそれに含まれると思う」

「アプレッソの中で取り入れるためには、これまでに組織や部署に捕われず考える必要がある」

など、「スクラム」・「スクラムマスター」を実際に自分たちでやるためにどのようなことが必要か、ということを具体的に検討しました。

「見える化」によって達成されるものとは何か?

アジャイルは本当に日本のソフトウェア開発を変えることができるか?」についての感想では、「見える化はどのようにやるべきか?」ということが話題になりました。

「"見える化"の例として野球のスコアボードの例がとても分かりやすかった。現在の状況や全体の流れなど、これに正しい情報が集約されている。見える化の典型的な例だと思う」

 「ソフトウェア開発ではカンバン、バーンダウンチャート、ニコニコカレンダーなどが"見える化"のやり方として採用されることが多い」

「見える化」はよく話題になりますが、どのような方法でやるのが良いのか、どこまでやるのが良いのか、ということは悩ましい問題です。

アプレッソのチームでもこれまで取り組んできましたが、ツールやグラフなどデジタルでやることが殆どで、アナログで常に見える場所に置いておく、ということはそれほど積極的ではありませんでした。

そういう中で

「どこまでアナログ化するか? どこまでデジタルで管理するか? その線引きはどうするか?」

ということを議論となりました。

「すべてをアナログで書くと管理が大変だし、情報が多すぎる。かといってデジタルだと"ここにあるからね"と言っても見ないことが多い」

という課題があり、そもそも「何のための見える化なのか?」ということについてについて話しました。

具体的な実践として、現在アプレッソではプロジェクトのインセプションデッキを開発部の皆が通る場所の壁に貼っています。

「インセプションデッキを貼ることによって、プロジェクト外の人から"あれはどうなってる?""これは重要だよね"といった会話が発生している。見える化の良いところはそういうところだと思う」

といった具体的な成果についての意見がありました。これから、

「重要なのは"他人事にしない"ということではないか? プロジェクトの状況を見えるようにすることで、プロジェクト内外の人へ情報が開かれる。それによって"我々のプロジェクト""我々のプロダクト"という意識で関係者全員が取り組むことができる、ということがあると思う。」

「以前だとプロジェクトの中でも各担当者で情報が閉じていた。見える化することによってその連携が自発的にやれるようになると思う」

など議論が行われ、

「どこまでが良いかは恐らく実践しながら考えていくしかないと思う。今回のプロジェクトでは可能な限りアナログで見える化していってみよう」

という結論になりました。

開発とQAの幸せな関係とは?

セッション「新米スクラムマスタとQAおじさんのアジャイル珍道中」についての話では、プロジェクトの中でのQAと開発の関係について議論となりました。

「従来のウォーターフォールを小さいイテレーションで回す、ということとアジャイルなやり方との最大の違いは何か?」

という疑問については、セッションに参加した者から

「大切なのは"フィードバック・ループ"だと思う。設計ありきで開発、テストがあるのではなく、詳細設計・テスト設計が並行で進み常にレビューし合って作っていく。またプロダクトオーナーによる仕様設計にもフィードバックを 返していく」

「このフィードバックのループをプロセスの中で常に繰り返していくことによって、品質を上げていきつつ早いサイクルでプロダクトを作ることが可能になるのではないか」

という意見が出ました。

アプレッソでもかつては「開発→QA」というフェーズを完全に分けてプロジェクトをやっていたのですが、段々と「QAが開発初期から参画する」という方向へシフトしていっています。

しかしそのやり方については悩みどころも多いところです。その中で「QAと開発、そしてプロダクトオーナーのフィードバックのループを作っていく」というのは方向性として大変参考になしました。

結局テスト期間って必要なの?

続いてQAと開発の関係の話は、セッション「まだテスト期間とかつくっているの?  ~アジャイルな開発におけるテストとの付き合い方~」についても議論となりました。

「セッションではQAが居ないチームでどのように品質を高めるか、という話だったが、QAを置いている我々のチームでも真似したいところが多くあった」

「特に開発からテスト期間までが長いプロジェクトでは、テスト期間に問題が発生すると対応が大変になる。ユーザーストーリーの完了をテストも完了した"リリース可能"な状態にする、というのは実践的なプラクティスとして有効だと思った」

それでは結局のところ、我々のプロダクトで「テスト期間は不要!」と言えるか? という議論になりました。その中では、

「品質を担保するためにテスト期間は必要だと思う。しかし、品質を守りながら素早いリリースを行うために、イテレーションの中でテストを組み込んでいくことはぜひチャレンジしたい」

「そうすることで品質を保ちながらテスト期間を短くすることができるかもしれない」

などの意見が出ました。またQAとは別の視点で、

「バグは"関心の低い"作業から生まれる、という話が印象深かった。プロダクトの品質に関心を高く持つ、ということによってバグを出しにくくすることができるかも」

など品質についてどう取り組むか、という話をしました。

どこまでBe lazyでいける?

セッション「文化の壁をぶち壊せ!日本でも出来る本物の DevOps ジャーニー!」で話された「Be lazy」という考え方については、賛同と疑問が両方ありました。

「アメリカは仕事に対するの考え方が違う。やらなくていいものはやらない、本質的な問題だけに注力する=Be lazyという意識がある。それによって生産性を上げている」

「日本はやらなくていいことに労力を注力し過ぎだと思う。例えばアメリカの製品について本国にサポート問い合わせをすると、1行"try this!"みたいなメールでモジュールが返ってきて終了、みたいなことがあった」

「Be lazy」で仕事をやっていくのはすごく魅力的な話ですが、実際問題としてそれが可能なのか? という意見がありました。

「エンドユーザーやパートナー企業に対しては、それが可能な土壌はまだ無いと思う。適用箇所は考えなければいけない」

「アジャイルも含めそれは外国の文化。そのまま取り入れるのではなく"考え方をインストール"していく、取捨選択して取り入れることが大切だという話があった」

などという意見が出ました。我々の仕事という範囲で考えたところ、全部は無理でも「Be lazy」になれるとこはあるのではないか? という話になりました。

「例えば社内のコミュニケーションでも必要以上に気を使って時間を浪費しているところがあるのかもしれない。もっと端的でもいいのかも」

「開発やQAでもエビデンスを残すために使っている無駄なプロセスがあるのかもしれない。品質は落とさずに省ける無駄を省くという意識は持っていいのかも」

などの議論が行われました。

終わりに

ということでガヤガヤといろんなことを議論しました。(実際はここでは書けないような生々しい話もしながら!)

Agile japan 2016とそれに対する議論を経て、我々で作る「アジャイル」の具体的なイメージがかなり具体的になってきました(なってきたような気がします)。

ということでバトンは受け取った、後は走るのみ! ということでアジャイルの取り組みがアプレッソでは始まっています。

次回以降の記事では、実際にアジャイルへどのように取り組んでいるか、それに対する良いところ、悪いところなど気づいたことを紹介していきたいと思います。

お楽しみに!

最後に宣伝ですが、ぜひこの取り組みに参画してみたい! という方、アプレッソではエンジニアを募集しています。ぜひご検討ください! カモンジョイナス!

appresso 採用情報2016

www.wantedly.com