もう大丈夫。私が来た。

最近ヒロアカ読んでる。タイトルはオールマイトのセリフ。かっこいいなぁ。

僕は、技術的にサポートしてほしいって依頼があると、開発チームの中に入って、内側から手を動かしながらサポートをするって活動をやってる。

サポートするときは難しいことはあんまり考えずに、このチームにはこうやったらいいかなと思うことを勘でやってるんだけど、ふと最近思ったのが、自分は技術的なサポートの前にやってることがあるなぁってこと。

それは「不安を取り除く」こと。

不安だから細かく管理しようとしてしまうし、不安だから何でもかんでも優先度が高くなっちゃうし、不安だから自分の居場所を守ろうとしてしまう。そういう流れが自然と生まれてくる。

だから「細かく管理しなくてもうまくいくよ。1ヶ月見てて」とか「それは今作らなくても大丈夫だよ。本当に必要なものをまず作ってから考えても大丈夫だよ」とか「タスクの進捗が遅くても大丈夫。みんなで助け合えるチームだよ」とか「技術的な部分は、なんとかするから目の前のことに集中してていいよ」とか。

そんな風にして、安心してもらうと、いい方向に流れ始めて、いい感じにみんなが持ち味をだして、チームが良い空気の中で成長していくように思う。

オールマイトみたいになりたいなー!

Java の CLI アプリケーション用フレームワーク picocli はミスタイプ時にサジェスチョンを出してくれる

長くなっちゃったから最初にまとめ

まとめ

picocli は便利。

デフォルトでサジェスチョンの機能がついている。なので、オプションやサブコマンドの定義だけしておけば、ミスタイプしたときにサジェスチョンを出してくれる。

  • オプションの場合は、先頭2文字が一致するオプション一覧
  • サブコマンドの場合は、先頭2文字じゃなくて、似たものを出してくれる

こんなつぶやきを見かけて

がくぞさんのこんなつぶやきを見かけて

あぁ、たしかにそういうのフレームワークに含まれてたら便利だなー、picocli だったらありそうだけどどうなんだろうなぁ?って興味本位で見てみたら、デフォルトでその機能が入ってたのでメモを残しとく。

picocli?

Javaコマンドラインアプリケーションを作る用のフレームワーク

https://picocli.info/

最初ピコリかー名前かわいいなと思ってたけどよく見てみるとピコシーエルアイだった。いろいろと気が利いていて便利そうだなぁって思って眺めてる。ちゃんと使って何かを作ったことはまだない。GraalVM の NativeImage に対応してるのも良いね。

サンプルアプリ

↓に書いてある例をそのままコピペして作った

https://picocli.info/#_example_application

まるっとそのままってのもなぁと思って bufferings ってオプションを足しておいた。何の役割もない。

@Command(name = "checksum", mixinStandardHelpOptions = true, version = "checksum 4.0",
    description = "Prints the checksum (MD5 by default) of a file to STDOUT.")
public class CheckSum implements Callable<Integer> {

  @Parameters(index = "0", description = "The file whose checksum to calculate.")
  private File file;

  @Option(names = {"-a", "--algorithm"}, description = "MD5, SHA-1, SHA-256, ...")
  private String algorithm = "MD5";

  @Option(names = {"-b", "--bufferings"}, description = "Sample.")
  private String bufferings = "MD5";

  @Override
  public Integer call() throws Exception { // your business logic goes here...
    byte[] fileContents = Files.readAllBytes(file.toPath());
    byte[] digest = MessageDigest.getInstance(algorithm).digest(fileContents);
    System.out.printf("%0" + (digest.length * 2) + "x%n", new BigInteger(1, digest));
    return 0;
  }

  // this example implements Callable, so parsing, error handling and handling user
  // requests for usage help or version help can be done with one line of code.
  public static void main(String... args) {
    int exitCode = new CommandLine(new CheckSum()).execute(args);
    System.exit(exitCode);
  }
}

ここに置いといた:

github.com

試してみると

↑のようにオプションを定義しておくだけで、ミスタイプしたときは picocli が勝手に「これじゃない?」って教えてくれる。

気が利くなぁ

公式ドキュメント

https://picocli.info/#_invalid_user_input

The default parameter exception handler prints an error message describing the problem, followed by either suggested alternatives for mistyped options, or the full usage help message of the problematic command. Finally, the handler returns an exit code. This is sufficient for most applications.

「パラメーターに対するデフォルトの例外ハンドラーは、問題の内容をプリントしたあとに、ミスタイプしたオプションの候補かヘルプを表示する」ってちゃんと書いてある。

最初にこれを読んで、これっぽいよなぁと思って。これが僕が思ってるのと同じことなのかなぁ?って確かめてみることにしたのだった。合ってた。

でもどこで?

ソースを見てみたら CommandLine.java のこの部分でサジェスチョンを取得してる。この戻り値のリストが空じゃなかったら、それが候補として表示されて、空だったら、ヘルプが表示される。

/** Returns suggested solutions if such solutions exist, otherwise returns an empty list.
    * @since 3.3.0 */
public List<String> getSuggestions() {
    if (unmatched.isEmpty()) { return Collections.emptyList(); }
    String arg = unmatched.get(0);
    String stripped = CommandSpec.stripPrefix(arg);
    CommandSpec spec = getCommandLine().getCommandSpec();
    if (spec.resemblesOption(arg, null)) {
        return spec.findVisibleOptionNamesWithPrefix(stripped.substring(0, Math.min(2, stripped.length())));
    } else if (!spec.subcommands().isEmpty()) {
        List<String> visibleSubs = new ArrayList<String>();
        for (Map.Entry<String, CommandLine> entry : spec.subcommands().entrySet()) {
            if (!entry.getValue().getCommandSpec().usageMessage().hidden()) { visibleSubs.add(entry.getKey()); }
        }
        List<String> mostSimilar = CosineSimilarity.mostSimilar(arg, visibleSubs);
        return mostSimilar.subList(0, Math.min(3, mostSimilar.size()));
    }
    return Collections.emptyList();
}

L.18029 にある (picocli:4.6.1)。CommandLine.java はファイルが大きすぎてGithub で表示できないみたい↓w

https://github.com/remkop/picocli/blob/master/src/main/java/picocli/CommandLine.java#18029

ざっと読んでみよう

まずは resemblesOption で「オプションっぽいかどうか」をチェックしてる。Possible solutions: が表示されるためには、これが true になる必要がある。

boolean resemblesOption(String arg, Tracer tracer) {
    if (arg == null) { return false; }
    if (arg.length() == 1) {
        if (tracer != null && tracer.isDebug()) {tracer.debug("Single-character arguments that don't match known options are considered positional parameters%n", arg);}
        return false;
    }
    try { Long.decode(arg);        return false; } catch (NumberFormatException nan) {} // negative numbers are not unknown options
    try { Double.parseDouble(arg); return false; } catch (NumberFormatException nan) {} // negative numbers are not unknown options

    if (options().isEmpty()) {
        boolean result = arg.startsWith("-");
        if (tracer != null && tracer.isDebug()) {tracer.debug("'%s' %s an option%n", arg, (result ? "resembles" : "doesn't resemble"));}
        return result;
    }
    int count = 0;
    for (String optionName : optionsMap().keySet()) {
        for (int i = 0; i < arg.length(); i++) {
            if (optionName.length() > i && arg.charAt(i) == optionName.charAt(i)) { count++; } else { break; }
        }
    }
    boolean result = count > 0 && count * 10 >= optionsMap().size() * 9; // at least one prefix char in common with 9 out of 10 options
    if (tracer != null && tracer.isDebug()) {tracer.debug("'%s' %s an option: %d matching prefix chars out of %d option names%n", arg, (result ? "resembles" : "doesn't resemble"), count, optionsMap().size());}
    return result;
}

↓ここがいまいち分かんないんだけど、対象の文字列と、このコマンドのオプション全部に対して前方一致する文字数を取得して、一致する文字数がオプションの数の9割を超えてたらOKになるみたい。大体のオプションは --- で始まると思うから、それで始まってたら true になりそう。ダッシュで始まってないものは「オプションっぽくない!」って判別されるってことなのかな。

boolean result = count > 0 && count * 10 >= optionsMap().size() * 9; // at least one prefix char in common with 9 out of 10 options

その次は?

resemblesOptiontrue だったら、次は、この処理に入る。ここで返されたリストが空じゃなければ Possible solutions: として表示されて、空だったら usage が表示される。

  return spec.findVisibleOptionNamesWithPrefix(stripped.substring(0, Math.min(2, stripped.length())));

おや?ダッシュを取り除いて、最初の2文字だけが渡されるっぽいぞ?

List<String> findVisibleOptionNamesWithPrefix(String prefix) {
    List<String> result = new ArrayList<String>();
    for (OptionSpec option : options()) {
        for (String name : option.names()) {
            if (!option.hidden() && stripPrefix(name).startsWith(prefix)) { result.add(name); }
        }
    }
    return result;
}

ふむ。最初の2文字の前方一致するオプションを表示してるってことか。想像してたよりシンプルだな。

ところで

こんな Issue を見つけた

Add help for mistyped commands · Issue #298 · remkop/picocli · GitHub

あれ?最初の2文字よりももっとリッチな感じがするぞ。

ので

もうちょっとコードを眺めてみる。あー。getSuggestions のオプションじゃなくてサブコマンドの方か

        List<String> visibleSubs = new ArrayList<String>();
        for (Map.Entry<String, CommandLine> entry : spec.subcommands().entrySet()) {
            if (!entry.getValue().getCommandSpec().usageMessage().hidden()) { visibleSubs.add(entry.getKey()); }
        }
        List<String> mostSimilar = CosineSimilarity.mostSimilar(arg, visibleSubs);
        return mostSimilar.subList(0, Math.min(3, mostSimilar.size()));

resemblesOption でオプションっぽくないって判断されたときにこっちに入ってきて、似てるサブコマンドの上位3つを返してる。ほほー。

CosineSimilarity.mostSimilar

CosineSimilarity というクラスでスコアを計算してるみたいで、このクラスは ↑の Github Issue にコメントにある通り Grails のコードを参考にしたみたいね

Grails のコード:

grails-core/CosineSimilarity.groovy at master · grails/grails-core · GitHub

ふむふむ。picocli の CommandLine は、これを参考にして内部に private な CosineSimilarity クラスを定義してて、その中で bigram を使って似てるかどうかを判断してるみたい。

だから、サブコマンドの場合は前方一致じゃなくてもサジェスチョンを出してくれる:

Unmatched arguments from index 0: 'mmit', '--bufferings=abcde'
Did you mean: commit?

へー。なんでオプションは前方一致で、サブコマンドはそうじゃないんだろう?

ためしに

オプションも CosineSimilarity を使うように強引にごにょごにょしてみると

Unknown options: '--uff', 'abcde'
Possible solutions: --bufferings

ってできた。うーん。でも結構めんどくさかったし、別にオプションは先頭2文字で十分な気がする。

まとめ

picocli は便利。

デフォルトでサジェスチョンの機能がついている。なので、オプションやサブコマンドの定義だけしておけば、ミスタイプしたときにサジェスチョンを出してくれる。

  • オプションの場合は、先頭2文字が一致するオプション一覧
  • サブコマンドの場合は、最初の2文字じゃなくて、似たものを出してくれる

おまけ

この記事を書くのに、動作を確認しながら書いたので、push しといた。

面白かった

昨日の夕方にスクラムフェス大阪で基調講演をしました #scrumosaka

bufferings.hatenablog.com

ということで、基調講演をしました。

楽しかった

聞いてくれた人が前を向いて一歩踏み出してみようって思ってくれるといいなって考えながら、お話しました。

みんなが Discord や Twitter で盛り上げてくれて、終わった後も「届いたよ」って声が聞こえてきて、ほっとしました。

今日のセッションの中で触れてくれてる方もいて、今日を楽しむ入り口になったなら良かったなって思います。

楽しかった

お話をいただいてから、どんな話にしよう?ってずっと考えて。スクラムフェス大阪だから、やっぱり自分の内側の話をしたいなと思って。

そこからは、自分が何を考えながら過ごしてるかなぁって、考えて。考えが発散して。ノート何冊かになって。

その中から、自分がお話したいことってなんだろう?って絞っていって。そんなこんなで、最後まで内容に手を入れながら、あーでもないこーでもないってやって。

自分の今を全部のせることができたと思います。ぐったりしたけど楽しかった。

ありがとうございました

もし、何か聞きたいこととか気になることとかあったら、気軽に Twitter ででも話かけてください。喜びます。

スクラムフェス大阪。最高でした。みなさんありがとうございましたー!

明日の夕方にスクラムフェス大阪で基調講演をします #scrumosaka

www.scrumosaka.org

17時過ぎからー

Scrum Fest Osaka 2021 - 誰も嫌な思いをしない変化 | ConfEngine - Conference Platform

完全オンラインで日本中がおまつりだー

Scrum Fest Osaka 2021 - Program Schedule | ConfEngine - Conference Platform

楽しみ

何をやりたいのかをすぐに見失ってしまう

最近、プログラミングのことよりも、頭の中のメモが多い理由は分かってる。たぶん6月末までこんな感じ。今日もそんな感じ。

宿題やりなよ

娘たちに「宿題やっときなよ」って言ってもあんまりやらない。気分が乗らないから。

でも、宿題をやる気にさせる方法なら分かってる。僕がリビングの机で勉強を始めるか、一緒に宿題をやろうとすればいいのだ。そうすると、娘たちも宿題をやろうという気分になってくれる。

なのに実際は「宿題やっときなよ」とだけ言ってツイッターを眺めてる。なので娘たちは宿題をやらなくて、僕はまた「やりなよー」って言うのを何回も繰り返してたりする。

どうしてだろう?

近道?

言ったらやってくれるのが一番はやい。だからそれで済ませたい、かな?だけど、よく考えるとそれは「僕にとって」一番はやいのであって。娘にとってはそうじゃない。

はて?僕がやりたかったことって何だっけ?って考えると、それは「娘が宿題を終わらせること」

あぁ、最初は「娘が宿題を終わらせること」を目的にして「やりなよ」って伝えるんだけど、そのすぐ後には「娘たちが自分の期待通りに動くこと」という目的に変わってしまってるっぽい。

遠回り?

自分の行動に対して、何か反応があって、結果が出てくる。絵にするとこんな感じか?

f:id:bufferings:20210508095631p:plain:w300

  • 「宿題やりなよ」を入れると「お絵描きする」が出てくる。
  • 「一緒に宿題やろう!」を入れると「宿題やる」が出てくる。

それが分かってるのに、僕は自分にとって最小の労力ですむ「宿題やりなよ」を選んで、娘たちの「反応」の部分が変わることで、「宿題やる」が出てくることを期待してる。ということか。

自分ではなく、娘たちが変わってよ、って思ってるってことか。

なるほど。

仕事でも見かける

これって、仕事でも見かけるなぁ。例は省くけど。

自分で変えられるのは自分の「行動」だけで、相手の「反応」は直接は変えられない。相手の「反応」は、自分の「行動」を通して変わる。

だから、望む「結果」を本当に手にいれたかったら、自分の「行動」を変えればいい。

宿題やりなよ

実際に僕が「宿題やりなよ」って言ってるときは「別にやらなくてもいいけど」くらいの気持ちだし、「いつか自分でやるようになるといいな」くらいの気持ちなんだろうな。

まぁ、たまには一緒に勉強しようかな。

後輩が自走できるようにサポートするぞー

この記事を読んで、自分が後輩をサポートするときはどうするっけなぁって考えてみた。例によってあんまり深く考えずに勢いで書く。誰にでもどこにでも当てはまるもんじゃないと思う。僕のいる環境の話ね。

note.com

信頼する

まずは、信頼する。頑張ろうとしてるとか、良いものを作ろうとしてるとか、自走したいと思ってるとか。そういうの。例えばもし「頑張ろうとしてないように見える」場合、「頑張ろうとしている」という部分を信じてるから、その気持ちが行動につながるまでの間のどこかに妨げとなる何かがあるはずって考えて、それを見つけて取り除いていく。

対話

自分の期待を共有する

「自走できるようになってね?」ってだけ言って待ってるのってめんどくさい。僕はめんどくさいことが嫌い。楽をしたい。てか、言うだけでできるならもうなってる。それよりも、今何ができているか、次の一歩は何か、目指したいのはこういうところだよ、ということを伝える方が手っ取り早いので好き。

いいなと思ったことをフィードバックする

いいなと思ったところは、みんなの前でいいね・ありがとうって伝える。そういうのが好きじゃない人の場合は、ダイレクトメッセージで伝えたりする。

それとは別に、本人が気づいていない良いところを1on1で細かく伝えたりもする。リモート会議でみんながシーンとしてるときに意見出してくれてその後に他の人にも聞いてくれたのありがとうとか、コードの名前に気をつけてくれてるのいいと思うとか、ドキュメントを分かりやすく書いてくれてありがとうとか。

自分の行動の中で何が良かったのか、って言ってもらわないと分からない場合は多いよね。だからそういうのは言葉にして伝える。自信と道標になるかなと思って。

良くなるといいなと思ったことをフィードバックする

もうひとつは、ネガティブフィードバック。「あの行動は、話を聞いていないように見えたよ」とか「今回のタスク、ちょっと手戻りが多かったね。次同じようなのが来たらどうしようか?」みたいなの。「あなたは話を聞いていませんよね?」みたいな主観的な決めつけじゃなくて「どう見えたか」とか、「手戻りが多かったよね」っていう事実とかを中心にする。

信頼が前提にあるから「もっと話をちゃんと聞くように!」じゃなくて「どうしたらそう見えない行動を取れるか」とか「どういう仕組みにしたら手戻りを減らせるか」みたいな話ができる。

フィードバックはあったかいうちにする

どちらもできるだけはやく伝えたい。特に、ネガティブフィードバックは評価時期に伝えるのだと遅すぎる。そこまでの間に良くなってて評価も上がるのが一番いい。だって、後輩をサポートするときって「後輩の評価があがること」が僕のゴールだから「評価時期だから言うけどここ良くないよ」みたいなの意味ない。

迷ってることはそのまま伝える

サポートしてるときは結構悩むことがある。先輩だからある程度しっかりしてるほうがいいのはそうだけど、完璧じゃなきゃいけない、みたいなのはちょっと邪魔。

例えば「話を聞いてるよって伝えるにはどうしたらいいんだろう?分からん。これ質問で引き出そうとしてるとかじゃなくて、本当にどうしたらいいかよく分かってないんだよね」みたいに相談したりする。「じゃあ、こういう風にやってみるのはどうでしょうか?」って教えてもらえたりして「おーいいね。それやってみよう!」ってなったりする。

話を聞く

自分の意見を伝えたら、次は相手の気持ちを知りたい。これ、順番が逆だとあんまり話したい気持ちにならないかなと思うので、先に自分の気持ちを伝えるようにしてる。

相手の考えが自分と違ったとしても「相手がそう考えている」ということは否定することじゃないので「そう思ってるんだね。教えてくれてありがとう」って言う。「そっかー」ってよく言う。その次に使う接続詞は順接にする。「そう思ったんですね。でも・・・」じゃなくて「そう思ったんですね、じゃあ・・・」にする。

イメージとしては、横に並んで一緒に目的地を見てる感じ。「今こっちに向かってるよね、じゃあ、あのゴールに向かうには次にどうしたらいいと思う?一緒に考えよう」みたいなの。

だいたいここまでが、お互いの考えを共有するためにやってること。実際は、これを「行動」の中でやってる。

行動

やって見せる

最初は、やって見せる。何が正解かも分からない状態で「自分で考えてやって(でも、僕の期待には応えてね)」みたいなの、さっきも言ったけどめんどくさい。「最初は僕がやるから、次は自分でもできるようになるつもりで見ててね」

タスクに対して「こういう場合は、こんな風に考えるよ」って考えを伝えて「だからこんな風にコードを書いて、でドキュメントにはこういうことを書くよ、その理由は・・・」みたいに。

「この仕様だと何種類かに読み取れるよね?そういうときは『Aさんの時間をいただくのもったいないから、たぶんこれだろうしこれで実装しよう』じゃなくて『Aさんーこれ教えてくれー』って教えてもらう方が結局良いものができるんだよ」みたいに。

んで「ふむ。時間をいただくのが申し訳ない?それわかる。じゃ、申し訳なくならないような仕組みをチームで考えてみようかー」とかも。

一緒にやる

次は、一緒にやる。ペアプロのナビゲーターみたいな感じ。「そうそう、そこは仕様書確認してみようか」「おーその名前付けいいね!」「そこは、こういう風にやったほうが良いと思うー」「ちょっと興味があるだけなんだけど、そこどう考えてそれにしたの?・・・なるほど」「お、悩む?そういう場合はAとBがあるよ。試してみる?」とか。

やったのを見る

その次は、やったのを見せてもらう。ここでまた気づくことが出てくるので、そしたらその部分はまたやって見せたり、一緒にやったりして、徐々に一人でできるようになっていく。

任せる

そういうことを繰り返して、どんどんできることを増やしていきつつ、もう安心だなと思う部分は完全に任せていく。とはいっても、チームのレビューとかがあるから、まぁその後輩とチームに任せるって感じではあるか。

心持ち

失敗の機会を与える

失敗しながらが一番成長できると思うので、小さくいっぱい失敗してもらえるような仕組みにする。プルリクエストのレビューよりもペアプロで拾う。週次の30分の共有よりも日次の5分の共有で伝えるとか。

失敗、というか、自分の期待と違う場所に向かった場合は「何がそうさせてるのか」を知る良い機会。怒られるかもしれない、という気持ちだったり、知らないということが恥ずかしくて聞けないとか、目的を勘違いしてたとか。それが分かれば、次はそうならないような仕掛けを一緒に考える。

ちなみに、失敗は、自己申告しなくても勝手に見つかるような仕組みにしておく。自分から「これ失敗かもしれません・・・」って言いづらいから。

最短距離を求めない

質問の仕方とか、確認の方法とか、目的地にたどり着くのに最短の道を選んでなくていい。「自分だったらこの道をいくから君もここを通るべきだ」みたいなの。それよりも自分で考えてやってみることに価値がある。「その道行くの?いいね。行ってみよう!」「わー!目的地についてよかった!」でいいかなと。その後で「こういう道もあったよ」くらい。

最後は拾っとく

任せるし、失敗から学んだらいい、とはいえ、プロジェクトとかを失敗させてしまうとめんどくさいことになる。なので、その辺りは拾っておく。今のスキルではこぼれ落ちてしまう部分がどうしてもあるからね。

もし、その拾ったものを伝えて理解できるんだったら伝えるし、まだ伝えてもわかんないかなと思うのは別に伝えない。そのときがきたら伝えればいいかなと思って。

目的を共有する

これ最初に書けばよかった。「何をするか」っていうタスクじゃなくて「何を達成したいか」っていう目的を共有する。「そのためにチームのみんなでベストを尽くしてほしいんだよね。どうする?」みたいなの。

タスクよりもプロジェクト、プロジェクトよりもサービス、サービスのためにチーム、その視点を全部見せておく。と言っても、プロジェクトぐらいまでしか見えてない人もいるかもだけど別にいい。いつか、どっかで言ってたことが役に立てばいいかなくらいで。

どこまでやるの?

こんな話をしてたら「そんなことしてる時間ない」みたいに言われるときあるけど「僕は、それをやらない方がめんどくさいってだけだよ」という気持ち。

こんなとこかな。こういう風にしてたら、勝手に自走してくれる。

僕の中でのスクラムの定義は広い

スクラムで開発をしているか?」

 と聞かれると「うーん」ってなる。それは、あなたの中のスクラムの定義による。

そして、スクラムの定義に厳しい人だけでなく、多くの人にとって、僕のやっている開発はスクラムではないだろう。

Doneの定義が明確ではなくてもスプリントを始めるし、スプリントバックログアイテムは全部は完了しないのが普通だし、スプリント中の差し込みも当然あるものとして開発をしている。

プロダクトマネージャー(POに近い役割)は2人いるし、プロジェクトマネージャー(SMに近い役割)も2人いるし、エンジニアのリーダーとしての開発マネージャーもいる。

 

全然スクラムじゃないよね。

 

でも、僕の中では、もうこれでスクラムと呼んでいいことになっている。

僕の中のスクラムの定義

 じゃあ、僕の中のスクラムの定義ってなんだろう?

 

それは、何をやっているかではなくて、どう反応していけるか。

Commitment, Courage, Focus, Openness, Respect、そこに謙虚と信頼。これを持ったチームで、透明性を持って検査と適応をしていれば良い。

そんなチームで、プロダクトだけじゃなくて、プロダクト化されていないところまで含めた「サービス」全体を見て。

自分たちの今持っているをスキルを、期待ではなく、過去の実績をもとに把握して、ベストな道を選ぶ。

そういうチーム。今何ができるか、じゃなくて、今できることを持って、どこに踏み出そうとしているか。

チームもプロダクト

現状維持をしたいとは思っていない。やりたいことはたくさんある。もっとチカラをつけて、もっと良いサービスづくりをしたい。

そう考えると、サービスに対するスクラムチームであると同時に、チームそれ自身も自分たちのプロダクトだなと思う。そちらも育てていく。

スクラムマスターはチームというプロダクトのプロダクトオーナーだなぁって感じがする。そして、自分が何もすることがなくなるようになんてならない。

フレームワークとしてのスクラム

とはいえ、フレームワークとしてのスクラムを否定しているわけではない。

分かりやすいガイド、入口、1つの形として存在してくれているおかげで踏み出すことができるし、自分が違うやり方をしているなぁって認識できる。

アジャイルな開発をしているか?」

と聞かれたら「そうだね」とは言えそう。

ということで、僕の中のスクラムの定義は広い。

今日もぼーっと思うことをメモしておいた。