TerraformCloud + GithubActionsを使ってPRのコメントにplan結果を出してみる
TerraformCloud
個人で検証がてらtryしてみた話
- TerraformCloudは簡単にいうと以下です
今回やってみたこと
- Github Actionsを使用してPlan結果をPRのコメントに表示させるということをします。
- またコメントは必ず最新のcommitに対してのplan結果のみを表示するようにします。
完成形
準備すること
Terraform Cloud
- Workspaceというものを作成します。
- こちらの作成方法ですがTerraformを使用して作成します。
- 他にやり方を見つけられなかったので知っている方いたら教えて欲しいです
terraform { cloud { organization = "hironeko" workspaces { name = "tf-cloud-sample" } } }
こちらをmain.tf
などに書いてもらい、 以下のコマンドを実行します
terraform login
ブラウザを開くのでAPIのtokenを作成し作成されたらコピーしておきます。
再び、ターミナルを開きコピーしたAPI tokenを貼ります。ターミナル上は表示されませんがエンターを押してもらい完了です。
最後に下記コマンドを実行してください
terraform init
これで下準備は完了です。
実装
- main.tfを下記のようにひとまず書いておきます
terraform { cloud { organization = "hironeko" workspaces { name = "tf-cloud-sample" } } } provider "aws" { region = "ap-northeast-1" } variable "sample_instance_type" { default = "t2.micro" } resource "aws_instance" "sample" { ami = "ami-05ffd9ad4ddd0d6e2" instance_type = var.sample_instance_type tags = { Name = "sample" } }
Terraform Cloudでplanを実行可能にする
- Terraform Cloudでplanを可能にするには、IAMユーザーのクレデンシャル情報が必要になります。なので発行しましょう
今回はAPI経由でplanを行うのでこの設定を行なっています
Github Actionsを書く
name: "Terraform" on: push: branches: - main pull_request: jobs: terraform: name: "Terraform" runs-on: ubuntu-latest env: tf_version: "1.5.3" steps: - name: Checkout uses: actions/checkout@v3 - name: Setup Terraform uses: hashicorp/setup-terraform@v2 with: terraform_version: ${{ env.tf_version }} cli_config_credentials_token: ${{ secrets.TF_API_TOKEN }} - name: Terraform Format id: fmt run: terraform fmt -check -recursive - name: Terraform Init id: init run: terraform init - name: Terraform Validate id: validate run: terraform validate -no-color - name: Terraform Plan id: plan if: github.event_name == 'pull_request' run: terraform plan -no-color -input=false continue-on-error: true - name: Remove old comment id: remove_old_comment uses: actions/github-script@0.9.0 if: github.event_name == 'pull_request' with: github-token: ${{ secrets.GITHUB_TOKEN }} script: | opts = github.issues.listComments.endpoint.merge({ owner: context.repo.owner, repo: context.repo.repo, issue_number: context.issue.number, per_page: 100, }) const comments = await github.paginate(opts) for(const comment of comments) { if (comment.user.login === "github-actions[bot]") { github.issues.deleteComment({ owner: context.repo.owner, repo: context.repo.repo, comment_id: comment.id, }) } } - name: Update Pull Request uses: actions/github-script@v6 if: github.event_name == 'pull_request' env: PLAN: "terraform\n${{ steps.plan.outputs.stdout }}" with: github-token: ${{ secrets.GITHUB_TOKEN }} script: | const output = `#### Terraform Format and Style 🖌\`${{ steps.fmt.outcome }}\` #### Terraform Initialization ⚙️\`${{ steps.init.outcome }}\` #### Terraform Plan 📖\`${{ steps.plan.outcome }}\` #### Terraform Validation 🤖\`${{ steps.validate.outcome }}\` <details><summary>Show Plan</summary> \`\`\`\n ${process.env.PLAN} \`\`\` </details> *Pushed by: @${{ github.actor }}, Action: \`${{ github.event_name }}\`*`; github.rest.issues.createComment({ issue_number: context.issue.number, owner: context.repo.owner, repo: context.repo.repo, body: output }) - name: Terraform Plan Status if: steps.plan.outcome == 'failure' run: exit 1
PushしてPR作成すれば終わりです
参考にした記事
とても助かりました。ありがとうございます。
また記載しているコードのほとんどを上記記事の内容を流用しています。
大量の漫画を断捨離した結果
総冊数
- 途中まで数えていたけど途中からわからなくなったw
- 多分売った分だけで1000冊前後あると思う
- 今回ラノベや小説なども数十冊売りました
小学生の頃から集めに集めた漫画コレクション
売ったタイトル
- ARMS
- SAMURAI DEEPER KYO
- あひるの空
- 猿ロック
- 21世紀少年
- 島根の弁護士
- シャーマンキング
- クロスゲーム
- Rose Hip Rose
- 伝説の頭 ~翔~
- いちご100%
- あねどき
- 初恋限定。
- メル
- 烈火の炎
- Q&A
- ホイッスル
- アライブ
- キャプテン翼~ワールドユース編~
- シュート
- 全シリーズ
- グラップラー刃牙
- テニスの王子様
- 銀の匙
- バクマン
- デスノート
- 孤高の人
- 忍空
- フェアリーテイル
- RAVE
- 坊や哲
- Stay Gold
- ヒカルの碁
- ブラックキャット
- ボルト
- 医龍
- アカギ(バラバラ)
- ジパング
- クロサギ
- ブリーチ
- 幽遊白書
- クローズ
- ワースト
- クローバー
- KATSU!
- いつも美空
- クロスゲーム
- 鋼の錬金術師
- テラフォーマーズ
- あひるの空
- etc
残したタイトル
思い出はたくさんあるが・・・
大体の内容は覚えている。売却する漫画は、4~7回は読み直しており、一番読み直しているのだと10回前後は読んでいる気がする
引っ越し等のたびに連れ回したりしていたのだが本棚を買い増したり色々することに疲れてしまい、かつ漫画はどんなに綺麗に保持しても紙なので匂い等がどうしても気になってしまう。
また中古で買ったものもいくつか存在してそれらの日焼け具合とかが気になったりしてた。
今回売ったタイトル以外に過去今までに保持していたが既に売却したものを以下に列挙してみる
覚えている範囲は以上だが多分まだある。
読んだことある漫画を一部列挙
- 五等分の花嫁
- 彼女借ります
- ジョジョ(第5部まで)
- 外道の歌
- 死役所
- 食戟のソーマ
- ゴールデンカムイ
- キングダム
- スラムダンク
- 鬼滅の刃
- 流浪人剣心
- 呪術廻戦
- 東京リベンジャーズ
- 新宿スワン
- ガンツ
- 七つの大罪
- SPY×FAMILY
- ブルーロック
- ブルーピリオド
- 薬屋のひとりごと
- ウシジマくん
- ゲットバッカーズ
- ブラッククローバー
- ブルージャイアント
- 終わりのセラフ
- 終末のワルキューレ
- Dr.STONE
- ぬらりひょんの孫
- ダンまち
- 僕等がいた
- ギャングキング
- オーバーロード
- からかい上手の高木さん
- 咲
- 無職転生
- 銀魂
- 僕のヒーローアカデミア
- 約束のネバーランド
- ワンパンマン
- SAKAMOTO DAYS
- 地獄楽
- ラノベ原作
- etc….
こう思い返すとかなりの物量の漫画を所持したり読んだりしてきたんだなって思います。また一部だけ読んだってのは抜いているのでおそらくまだまだ量があります。
全部振り返って感想を言いたいくらいですね。
大切なことは漫画から学んだ
と言うMixi(今のご時世わかる人減った?)のコミュニティに入ってたことがありますが多くのことを漫画から学びました。コンテンツとしてもですが歴史、言い回し、神話系などなど多くの雑学が入っている。こち亀なんかは最たる例なのではないかな?
それらに限らずとても学びは多く、現実世界の人間関係以外で学ぶことはたくさんあって閉じた世界以外を見るという点でも漫画は素晴らしい文化だと思います。
一体いくらで売れたのか?
今回2社に自宅集荷で依頼を行いました。理由は、片付けるなら一気にというスタンスで後腐れなく綺麗に処分!という気持ちと1社で集荷できる量と段ボールをもらえる量に上限があったため2社になったという感じです。
- A社
- コミック463冊:1816円
- 書籍(ラノベ・小説)83冊:376円
- B社
- コミック637冊:5850円
- book off
- こちらで売ったのは書籍も含めての漫画100冊程度
- トータルで1700円くらいになった
売った感想
- 集めるのにかかった費用に比べてあまりにも理不尽な額しかならずなんともいえない気持ちになりました。メルカリとかで全巻セットで販売すればいくらか値段は上がったかもしれないけど小分けにして出品して対応してとか考えると時間と労力に合うのかという問題に直面するのでメルカリで売れば良かったなーという後悔は今のところないです
全て買取してもらうためにやったこと
- 古い書籍に課しては、カバーが汚れてたりするから全て綺麗に掃除した
全体的な感想
- 気持ち的な問題だがかなりスッキリした。
- お金的な問題としては、んーかなり買い叩かれたなーって印象を持った。後悔はないけど商売ってそういうものだよなーって気持ちになった
- 誰かに勧めるか?
- これはかなり悩むけど速攻売り払いたいなどの理由がない限りあまりおすすめはできないかなと思う
- 自分が愛読して愛でてきた漫画を二束三文で買取と言われる虚しさは正直あるので時間と労力がある人は、メルカリやブックオフとかそれなりの場所で売る方がいいかなと思う
- オンラインの会社だと送ったが最後、大抵は、返却して欲しいとは言いづらいというのと今は送料がばり高いので返却時の送料とかかかるかはわからないですが、一旦送ったが最後という気持ちが必要ですね
AWSの知識地図の書評
読んだ感想
- ざっくりとしたオーソドックスな使い方や基本的な知識を学ぶことができる書籍
- 対象読者は、初学者から中級に達する前の人の復習という位置付けにもなっている気がする
- これを読んだからすぐにガリガリと実践に入れるかというとそうではない
- AWSを始めたばかりの人には辞書的な使い方も少なからずできそう
学べること
- 基本的なAWSのリソースについてどんな役割をしててどんな使い方をするのかがわかる
- また基本的なネットワークやサーバー構成(構築)についても学べる
学べることの例
IAMとは?
- AWSにおける認証認可のサービス
- IAMを構成する要素は4つ存在している
- IAMユーザー
- IAMロール
- IAMポリシー
- IAMユーザーグループ
- これらを駆使して適切なアカウント管理を行いましょうということが書かれている
- またMFAの設定などについても言及されている
ネットワーク関連
- 通信の種類(インバウンド / アウトバウンド)
- CIDR
- サブネットマスク
- サブネット(private / public)
- インターネットゲートウェイ
- NATゲートウェイ
- これらについても最低限の知識の説明がわかりやすく書かれている
まとめ
全体通して基本的なことを学べる。これをきっかけに深掘りしてさらに体系的に学べる書籍やAWSのドキュメントなどを読んで知識を深めるのが良さそうと感じました。
AWSのWebConsoleのUIはよく変わるのでこの書籍に書かれているUIと異なっている可能性が読むタイミングで変わっている可能性もありそうだけどそこは適宜ググれば解決しそうだし、基本さえわかっていればUIが変わってても対応できそう
ざっくりと理解してた部分の穴埋めができたのでとてもよかった
さらに知識を深めて市場価値を上げていきたい
社内輪読会を1年開催して
輪読会が第3回目まで継続されるようになった
自分が入社した時は、社内で勉強会的なものは一切なく個が孤立しているような雰囲気がありちょうどスクラムチームが発足したり体制変更があったタイミングでした。
スクラムチームが発足したのはいいのですが、ガッツリスクラムを経験した人がいないという状態でまさに混乱期(というよりそれ以前の問題?状態?)でした。
そんな中スクラムイベントを行なう日に中途半端に時間が余ってしまい仕事するには微妙な時間の余り方をしてました。
なのでスクラムについて勉強するというお題目のもと第1回目の輪読会を提案しました。
第1回輪読会
SCRUM BOOT CAMPを対象書籍にしました。
手法としては、順番をランダムに決めて回し読みをしていき最後にその日に読んだ範囲でのディスカッションを行うという流れを組んでおりました。(最初は5-10分のディスカッションタイムでしたがのちに参加者の提案で15-20分に拡大)
参加者は開発部署の人のみで行っておりました。スクラムについての勉強がメインの部分もあったのでそれはそうという流れでした。
ここでの良かった点は、実際に普段の業務で生まれたスクラムについての疑問点等についてチームの垣根を越えて意見交換やアドバイスがお互いにできた点かなと思います。
第2回目輪読会
カイゼンジャーニーを対象書籍にしました。
今回からBiz側の方も参加してもらえました。参加の回数は少なかったですが開発だけでなく全社的にアジャイルへのマインドセットを考えるきっかけになったのかなとも思います。
第3回輪読会
正しいものを正しくつるを対象書籍にしました。
この会から手法を変更しました。手法を変更した理由は以下の狙いがありました。
- もっとBizの方の参加を期待
- 回し読みが輪読会への参加のハードルになってたかもしれないという仮説をもとに手法を変更し参加者を増やす
- 何か結論を出すのではなく参加者同士でディスカッションをして社内でのコミュニケーションを活性化させる内容にしたい
以上の狙いがありました。
その結果開催以来のBiz側の参加人数になりました。Bizのが多いかも?という比重になっています。
まだ一回しか開催していないですが初回の感想として、発言数がかなり増えディスカッション等が増え、部署を越えたコミュニケーションが生まれた。
締めの際にとてもポジティブな反応が参加者からもらえた。
という具合で手法を変える試みを行って良かったなと思いました。
さて気になるのはその手法です。
回し読みではない輪読会
自分の経験的にもやったことの手法で正直うまくファシリテートできるか不安がありました。
具体的な手法を公開したいと思います。
- 使用したツール
- Google meet
- Miro
まず最初に主催者である僕の方でMiroのボードを用意しました。用意したボードのイメージを以下にテキストと画像で紹介します。
アジェンダ
## 時間外 質問付箋をあらかじめ投稿してください 発見・理解できたことをあらかじめ投稿してくだい アイスブレイク・チェックイン雑談です(2 - 5m) - 上段 (20m) - 質問 - 投稿(2m) - 発表(2m) - 発見・理解できたこと - 投稿(2m) - 発表(2m) - ディスカッション(10m) - 長引くようなら最後に時間をとります - 下段 (20m) - 質問 - 投稿(2m) - 発表(2m) - 発見・理解できたこと - 投稿(2m) - 発表(2m) - ディスカッション(10m) - 長引くようなら最後に時間をとります まとめ・締め ディスカッションで後回しにしたものの深掘り等 本日の感想・良かった点など(1.5m)
簡単に補足説明したいと思います。基本的には、記載内容のままですが雑多に目安となるtime boxをちゃんと決めて進行させる感じです。
進行するのも参加するのも人間なので時間通りに進むわけがないです。
なので事前に記入等を行うようにしてもらいます。これも初めてだとなかなか書いてくれないという問題も起きそうですがその際は、まずは主催者が書くことだと思います。例を明示することでハードルを下げます。あとはリマインドです。
それでも一応当日に記入する時間を設けているんで大きな障害にはならないと思います。
- ディスカッション
この項目だけはハンドリングがとても難しいです。なのでファシリテートの腕が試されます。どうにか乗り切りましょう!
- 締め
最後に本日の感想や良かった点など参加した人への感謝などいう時間を設けてます。意図は単純に誰しもが誉められたら嬉しいじゃないですか?また輪読会は、何かを合意形成する場ではなく、ディスカッションしてコミュニケーションをとり、書籍の理解を深めて普段の業務に活かすという目的で開催しているのでそのきっかけになった人へ感謝をいったり言語化して良かったことを口にすることで楽しい場であってほしいなという思惑があります。
Miroのボードのイメージ
1つのフレームにこのような付箋の塊を2個用意します。アジェンダの上段・下段がさしているものになります。
ディスカッションメモは、ファシリテーターが書くでも参加者が書くでも問題ありません。全員参加でというイメージです。
基本的に付箋に関しては、書いた人が誰かわかるように記入者のラベルを表示するようにしています。
まとめ
社内で何かしらのアクションをして他部署の人がくる場を取り仕切るというのはとてもパワーがいることですが結果的には、参加者が参加して良かったと思ってもらえる場を開催できているようでとても良かったなと思います。
開催手法も提案はしましたが参加予定者での多数決で決めました。結果初の試みになりましたがそこそこうまく回せたのかなと思える内容になり、他社の事例で見かけない輪読会への挑戦をして良かったと思います。
ちなみに開催頻度も毎週から2週に1度へ変更しました。
これからも引き続き新たな挑戦をしていきたいなと思いました。
突然php -vがエラーになった
前提
表題の通りだけどなぜかphp -vがいきなりエラーになった
エラー内容は下記
dyld[30484]: Library not loaded: /opt/homebrew/opt/icu4c/lib/libicuio.70.dylib Referenced from: /Users/user_name/.anyenv/envs/phpenv/versions/8.0.18/bin/php Reason: tried: '/opt/homebrew/opt/icu4c/lib/libicuio.70.dylib' (no such file), '/usr/local/lib/libicuio.70.dylib' (no such file), '/usr/lib/libicuio.70.dylib' (no such file), '/opt/homebrew/Cellar/icu4c/72.1/lib/libicuio.70.dylib' (no such file), '/usr/local/lib/libicuio.70.dylib' (no such file), '/usr/lib/libicuio.70.dylib' (no such file) [1] 30484 abort php -v
解決方法
- ひとまずググってみました。検索結果は、以下の記事が参考になりそうでした
記載してある内容の通り brew update
の影響のようですね。phpに限らず、Node(brewで管理している人)でのエラーを起こしている人もいました。
実際に行った解決方法
- phpenvでinstallしてたversionを全部消してから新たにphpをinstall & buildし直した
結果
あれこれとコマンドを頑張って指定のversionを入れたりとかしなくても結果少ないコマンドの数で問題なくphpを動かすことができる状態になった
この方法が一番手っ取り早い気がします。
転職して半年経ったので振り返ってみる
自分が今の会社に入って半年くらい経ったので社内でおこなってきた活動を列挙し今後どのようなアクションを実行していくのかを書きたいと思います。
雑多なポエム的なものになっちゃいますがお付き合いください。
やったこと
- 輪読会
- スクラムマスターのみでの振返り(2週に一回)
- YWTのフレームワークを使用して簡易的に情報共有の場
- PHPUnitの勉強会
- フロントエンドのLint設定モブプロ
- フロントエンドの共通化促進
- チームのPMと日々1on1
- その他
- 提案等
振り返ってみて色々やったなーという感がありますね。かいつまんでそれぞれどんなことを行い、社内にてどんな影響があったかなどを主観を元に書いていきたいと思います。
実際の活動内容
輪読会
前職での経験も踏まえて提案を行い実際に開催
開催目的
- チーム(事業部)の垣根を超えたコミュニケーション
- 自分達が作業をする上でプラスになる知識がつけれる
輪読会の流れ
- 最初の45分前後を使って対象書籍を回し読み
- 最後の15分前後を使用して当日読んだ箇所に関連する文脈を話題にした議論タイム
当初は議論の時間を設けておらず読み進めていく途中で議論できそうなことを拾っていましたが、参加している方から枠を設けての議論をする時間が欲しいとのことで上記のような流れになりました。
影響
- 参加者が違うチームにいたり、専門領域が異なっていたりしている中でそれぞれの視点から意見や考えが出てきた
- 第二回目からBizサイドも巻き込んだ輪読会になる
今後
- 事前に資料を作成したりして発表をするような輪読会ではないので、輪読会の場で発散や出たアイディアが蓄積されていない点の改善
- 二冊目の輪読会のメンバーも集まり、開発メンバーだけでなくBizからも参加者が生まれたのはとてもいい傾向です
スクラムマスター振返り
前提
開催目的
振返りの流れ
今後
- よりいい方向にチーム(組織全体)が進むための活動と捉えて引き続き定期開催していくつもりです
PHPUnitの勉強会
開催目的
- テストがないことによりコードが何をしているのか仕様的に正しいのかちゃんと動いているのだろうかなどが不明になっていた
- テストを書く文化が根付いておらず、テストがないPRが常態化していた
基礎編と応用編を行う
- 基礎編は、単純なFeatureテストの実装について
- 応用編は、Unitテストの作成でdataProviderやReflectionについて
影響
- 少しづつだがテストを書こうという意識が芽生えてきた気がする
今後
- テストを書くというのが実装とセットになっているという文化にする
- テスト書けない人がいない世界にする
フロントエンドのLint設定モブプロ
開催目的
- Lintがメンテされていない
- ルールが古い
- ディレクトリによって違う
- Lintに対して意識が低い
- Lintがメンテされていない
若手のフロントエンジニアをドライバーとして実際にモブプロを行う
- シニアエンジニアの方の力も借り、形にすることができ、ドライバーになったエンジニアにとってもいい経験になったのではないかなと思います
その後
- 歴史的経緯から即座に反映させることが困難状態であることが判明したため、いまだに反映までは至っておらず自分が部署移動したら順次着手するタスクになってそうです
フロントエンドの共通化促進
目的
影響
やったこと
- 自分が担当した機能のフルリニューアルで既存のBlade(Laravelで使うテンプレートエンジン)からVueへの移行を行うタイミングで共通化(簡略的なAtomicデザイン)をおこなっていきました
やったことの結果
- 影響にも書きましたが共通化は、このフルリニューアルでベースとなる構成を他チームに示せたこと
- また事前に他チームに対しても設計の面に関して共有していました
チームのPMと日々1on1
目的
- チームをより良い状態にするため
- PMとしての自分が理解している範囲、経験からの提案など
どうして日々の1on1なのか
- 週一、月一でもよかったかもしれませんがチームとして前進するため毎日の業務で躓いていることなどを言語化してもらいどこに課題があり、解決したいのか
- 右も左もわからない状態で教えてくれる人もいない中で進むくらいなら自分と伴走して一緒にチームの開発や設計に関して円滑に進めるように日々解決していくのがベストかと思ったため
結果
- 他チームのPMと比べてもしょーもないですが、間違えなく成長してくれていると思います。これは、俺のアドバイスがあったからではなく、彼自身の真摯な姿勢や理解し実行し検証し着実に一歩一歩進んで行こうとする足を止めなかったからだと思います
- 最近の1on1は、課題解決云々よりも雑談のが増えていますが開発のスピードが落ちているわけでもないのでポジティブに捉えてます
その他
- あげたらキリがなさそうですが列挙します
最後に
入社して約半年ですがまぁー色々やっている気がするなーと振り返って思いました。ただこれらは、やりたくてやったという色もあるので今後は、メンバーや部署内から同じように提案が出てきて皆で挑戦していけるような文化になることがいいと思っています。
また新入社員であれこれと口うるさい人間が社内でこういった行動ができる環境は、ベンチャーならではと感じてます。
会社として、組織として改善は、まだまだ山積みで人からすれば遠ざけたくなるようなことや触れたくないようなこともたくさんありますが今後の自分のキャリアを考えるとこういった経験は、なかなか出会えることはないとも思っています。
長くなりましたが、最後までポエムに付き合っていただきありがとうございます
スクラム開発の立ち上げに携わる
はじめに
- 気づいたら一年振りのブログです
- 職場も新しくなり右往左往しています
この記事の概要
- スクラム開発立ち上げの時期に入社したのでその際に感じたことなどを書きます
- 厳密には、すでに移行の準備は始まっており、自分が入社した段階ではチーム開発を始める手前の状態でした
- ポエムっぽい側面もあります。
スクラム開発スタート
前提
見積もりは時間ではなく相対的なポイントで見積もる
個人的な観点ではなしますと時間で見積もれるならそれはもう不確実性がなく、何をどう実装しどれくらいで終わるか明瞭であるため、スクラムで開発する必要性はないと思いますので、まぁスクラムでやらなくていいんじゃないんですか?と思っています
不確実性とは?
- ふたしかなこと と定義されています。
システム開発においての不確実性とはどんなことがあるのでしょうか?
- 例えば
- 影響範囲、結合度が高い実装がされている場合至る所に影響が発生します。これは予め予測が可能なものではないです。
- 外部サービスを使用している場合、社内に知見がなかったらドキュメントを読み解きながらの実装になりますので想定より時間がかかってしまうことが多いですね。
- また途中で考慮漏れに気付いてのタスクの追加、設計の見直しなども起こりうることですね
他にも様々なことが起因になり、想定外のことが発生し、時間を使うこともしばしばあると思います。
時間で見積もりを出すとどうなる?
時間という概念は、皆が平等に共通認識を持っています。15分は15分以上でもなく以下もなく15分です。なのでその時間内に終わらせないといけないという縛りがメンタル的に発生します。そうなると心理的ハードルがあがります。また焦りも生まれ、その時間内に終わらせるために気づかないうちにバグを生み出しているかもしれません。そうなると本末転倒ですね。なので時間で見積もる必要性がないです。また不確実なことに対して時間を見積もれるわけがないです。
また時間というのは、あればあるだけ使えばいいという発想になりがちです。締め切りがm月d日だったとしてぎりぎりその日までに終わればいいやとなります。実際は、もっと早く終えられるかもしれないのにです。
- ただしポイントにしたからといってここが完全に解決されるわけでもありません
結果正しい見積もりって可能なの?
結論は完璧には、無理です。
- なので不確実性に対して学習をしていき、スクラムイベントのスプリントプランニングで決める計画がスプリント内で完走できる計画になるように確度を上げていく姿勢(学習だったり、のうはうの蓄積)が大事になります。
もし社内で正しい見積もりが必要であるなら概算を出すことは可能だが前後するという共通認識は必要ですね。
- スクラムを続けていくことにより確度の高いリリース予定日は想定可能になっていくと思いますが
守破離を意識しましょう
スクラムに限ったことじゃないですが、未経験の未知なことに対して分からないことがわからないままカスタマイズするのは、かなり悪いミス(悪手)です。
- わからないことが悪いことではないですが、経験した上でオリジナルに昇華させるのが大事です。
- また経験も自らが学んだこと出なければいけないと思います。事実に基づいてがとても大事ですね
またルールがあるということは、そのルールに従うことを想定したフレームワークになっているので原則は、従うのがベストだと思います。
守破離の守を守らずに始めるとどうなるか?
- スクラムをやっている気になることです。
チームでの動きが始まってから
やったこと
スクラムの文脈とは異なることもありますがどれも不足していると感じたため行動しました。
今後の課題
- 責任の所在など
- ここは、個人の領域から離れてしまうため事業部全体でどうしていくかの共通認識を取る必要がありそう
- 肩書き上は、明確には分かれているように外から見えなくもないがひどく曖昧な状態と感じている
- 開発者のスキルの底上げ(現状webとmobileのエンジニアが混在している)
- スクラムイベントの目的の再共有
- 複数のスクラムチームが存在しているためLeSSへ昇華させるよう働きかけ
他にもたくさんの課題が潜在的にも表面的にありそうです。が課題等は、積極的にみつけて改善していきたいですね。
まとめ
スクラムは、経験者がいればどうにかなるってこともなく、大事なのは、アジャイルやスクラムに対してのマインドセットな部分も強いんだろうなと感じてます。個人的には、スクラムでの開発は、スプリント内のやることが明確だったり目指すゴールが何かなどが知れたり、ウォーターフォール開発よりは好きです(対極の開発スタイルと言っているわけではないです比較対象として)
今後は、開発者のロールは剥がされ、スクラムマスターとして接していく立場になる予定です。この半年でスクラムマスター兼開発者→SRE所属のスクラムマスターとなりそうです。本来ならスクラムマスターとしてだけの立ち回りがいいのでしょうが今のチームの自己組織化がまだまだ未達の状態なので(自分の至らなさですね)そのような状態になりそうです。