ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話（前編） アジャイル開発の代表的な方法論であるスクラムをテーマに、都内で1月に開催されたイベント「Regional Scrum Gathering Tokyo 2024」で、経験豊富なアジャイル開発のエキスパートとしてウクライナを拠点にアジャイルコンサルタントをしていたドミトロ・ヤーマク（Dmytro Yarmak）氏が、ロシア軍の侵攻後にウクライナ軍に入隊し、中隊長としてリーダーシップを発揮するためにさまざまなメソッドを駆使して軍隊の組織を変革していった経験を語ったセッション「A True Story of Agile Coaching in Ukrainian Armed Forces」が行われました。 軍隊という、企業とは異なる構造や目的を備えた組織で、しかも多くの民間人が入
こんにちは！ ソフトウェアエンジニアの福間（fkm_y）です！ アンドパッドでは業務時間中にいくつか勉強会をしているのですが、そのなかの「アジャイルな見積もりと計画づくり」の輪読会が終わったのでどんなふうに輪読会をやっていたのか紹介したいと思います！ 輪読会について はじめに やってみて どんな意見が出た？ ある回のディスカッションで使用したボード 滞りなく運営できた？ 感想 さいごに 輪読会について はじめに はじめに「アジャイルな見積もりと計画づくり」の輪読会に参加したい人をSlackで募り、見積もりや計画作りに興味、課題感を持っている有志のメンバーを集めました。その後、どんな形式で進めるかディスカッションしてルールを決めてからやっていきました。 いつ 毎週月曜の12:30~13:00 ルール 毎週1章づつ予め読んでおき、気になったことをメモに残しておく 会当日 気になった点を一人ずつ
また、この図の説明においては理想的なケースにおいても1つ前の工程に戻る事が述べられています。 " Hopefully, the iterative interaction between the various phases is confined to successive steps. " (投稿者訳) 理想的には、各段階において工程が前後する範囲は直近の工程に限られる。 理想的でない場合はどうかというと、テストから設計まで工程が戻りうると示唆しています。 "The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as dist
2020年11月5日から7日に開催されたスクラムフェス札幌2020で、招待講演を勤めました。 スクラムフェス札幌2020 運営の根本さんから最初に招待講演の打診があったのは、2020年の1月のことでした。うれしくはあったものの、正直最初は乗り気ではありませんでした。スクラムの集まりで招待講演をする資格があるとは自分に思えなかったし、なによりアジャイル札幌として今も活動している人たちの前で、ぼくが何を話せるだろうと考えたからです。 ぼく自身は2017年でアジャイル札幌の運営からは身を引かせてもらっていたし、フォーカスすべきものを絞った結果、アジャイル札幌の集まりに積極的に関わるということもなくなってしまっていました。彼らは活動を続け、積極的に外に出ていき、新しい人たちを迎え、アジャイル札幌として活動しているというのに。そんなぼくが、どの面を下げてみんなに何を話すのか、みんなの方がよっぽどその
新たな課題は、開発組織のあり方 前回のインタビューでは「エンジニア人員数」が課題でしたが、今回はどのような背景で角谷さんにお仕事を手伝っていただくことになったのでしょうか？ ビビッドガーデン平野俊輔氏（以下、平野氏）：一言で言うと、会社の成長フェーズが変わったことです。前回は正社員エンジニアが3人のまま売上が一気に10倍になった背景があり、開発リソース確保のために多くのエンジニアに声をかけさせていただきました。おかげで現在はエンジニアが複業・業務委託の方を含めて10人を超える規模になっています。 ビビッドガーデン平野氏 ここからさらに開発のスピードを上げていくためには、開発組織自体を強くしていく必要があります。今後どれだけエンジニアが増えても円滑に開発を進めることができ、かつ開発スピードも上げられる「開発組織のあり方」を考えた上で採用を進めていくことにしました。 そして今回、角谷さんにはビ
アジャイル界隈では割と知られているのですが、見積もりが何故ずれるかという説明の1つに不確実性コーンというものがあります。ざっくり説明するとプロジェクトの初期段階では不確定要素が多いので見積もりには4倍くらいの誤差があり、プロジェクトの進行とともに不確実な部分が少なくなってきて誤差は収束に向かうという話です。 引用：プロジェクトマネジャーのための「プロセス設計術」 - プロジェクトの本質とはなにか：ITpro この不確実性コーンですが、個人的には次のように解釈しています。 プロジェクト開始時には、全ての情報が揃うことはないので見積もりには誤差が生じる 全ての情報を集めてからプロジェクトを始めるのは現実的ではない。 ブレを小さくするには、出来るだけ対象となる範囲を小さくする。（タスクを細かい単位に分解する） 個々の仕事の処理能力が高いのに、何故か仕事が遅い人というのがたまにいます。そんな人を見
これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。 前提となるプロジェクト 今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。 細かい仕様は決まっていないが、作るものの要件はある程度明確である アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど) 数ヶ月以上のプロジェクトである 短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。 プロジェクト初期にやっておきたいことは何か 上記のようなプロジェクトの
いつの間にか、社内ですっかりインセプションデッキおじさんと化している中村です、こんにちは。 今日は、ヌーラボでのインセプションデッキの使われ方と、インセプションデッキを作る際に私が気をつけていることを紹介します。 インセプションデッキとは インセプションデッキとは、プロジェクトの目的や背景といった全体像を捉え、プロジェクトの向かう先を表すためのドキュメントです。お偉いさんから一方的に降ってくるものではなく、メンバーみんなで考えて共通認識を合わせるのが特徴です。詳しくは、書籍「アジャイルサムライ」などを参照ください。 私とインセプションデッキの馴れ初めは、およそ1年前の2016年末のことです。外部アジャイルコーチとして入ってもらっているギルドワークス様からこういうものがあるよと教えてもらい、その当時走ろうとしていたプロジェクトに適用してみました。 それ以来、事あるごとに社内で展開していき、1
書いた人 : たなべすなお 達人プログラマ Dave Thomas が Asakusa.rb で話するというので聞いてきた これは発言のまとめではなく感想レポートです Asakusa.rb は毎週火曜日に開催されている地域 Ruby コミュニティです。2012 年 2 月 21 日、その Asakusa.rb へ Dave Thomas がやってきて話をするという機会がありました。これはその場で話を聞いて受け取った内容をまとめたレポートです。当日は Ustream によるストリーミング中継はされていたのですが、残念ながらアーカイブにはなっていません。そのため、その場にいた著者が何を受け取ったか1という主観に大きく依存するものなため、Dave の発言の抄録ではなく内容の正確さはまったく保証できない感想レポートです。 今でも見られる唯一の間違いのない情報は Dave 本人が後に公開してくれたス
こんにちは、Forkwell事業部の中の人です。 本日は、つい最近 Forkwell Jobs の開発現場で起きたエピソードについてご紹介します。 きっかけはあるメンバーの一言でした。 「複数メンバーの加入から1ヶ月以上がたった、ベロシティもかなり安定してきた。よし、ここらでおれたちのベロシティをあげて、ビジネスサイドの連中をあっと言わせてやろうぜ！」 この一言で息巻いた我々は、ベロシティをあげることを目標に設定し、ビジネスサイドのホワイトボードに ◯pt / 10pt のような数字を書き加えました。 しかし、すぐに色々な現場を経験してきた他事業部のエンジニアの面々から、ベロシティをあげることを目標にすることには弊害があることを教わることになりました… ベロシティを目標にする弊害 目先のポイントを増やすためにとりあえずリリースして残タスクを先に積む事案が発生、後々の作業が滞る 目先のポイン
日本のアジャイル１０年、人々とコミュニティの私的物語 平鍋健児 （※）この記事は、2011年に書籍『Ultimate Agile Stories』に寄稿したものを転載しています。執筆時点で、『Ultimate Agile Stories - Iteration 2』が刊行されています。(2012/8/15) ぼくが初めてアジャイル、というか、XP、そうエクストリームプログラミングについて知ったのは、2000年の初めだった。ふと目について注文した洋書『Extreme Programming: Explained』がamazon.comから届き、それを週末に読んだのだ。このときに、どんな電流が走ったかは、多くの人の前で語ってきたが、Kent Beck という人物がとんでもなく明快に、そして極端に、人に喜ばれるソフトウェア開発、という視点でプログラミング活動を中心おいて4つの価値と12個のプラ
EC事業部チーフテクニカルリードのけんちゃんくんさんです。 GMOペパボでは、新しいプロジェクトが始まるときや何かの節目に、チームビルディングの手法としてドラッカー風エクササイズや、それをカスタマイズしたワークショップを実施しています。今回は、そのワークショップの中身と、ファシリテーターとして気をつけていることをお伝えします。 ドラッカー風エクササイズとは ドラッカー風エクササイズは、アジャイルサムライの著者であるJonathan Rasmusson氏が書籍やブログで紹介しているチームビルディングの手法です。4つの質問に全員が答えることで、相互理解の促進と期待のすりあわせという効果があり、特にプロジェクトの開始時や新メンバーを迎えるときに効果的であると言われています。 4つの質問 「4つの質問に答えるだけ」と書きましたが、質問の内容はなかなかハードです。 自分は何が得意なのか？ どういうふ
キムタクが表紙の『anan』 No.1914の特集は「人はチームで強くなる！」でした。コンビニで見かけて気になっていたので、早速購入して読んでみました。そのなかでも特に気になったのは、「ココッパ」というアプリを開発されているユナイテッド株式会社さんの紹介記事です。 IT業界でよく使われる”アジャイル開発法”でタスクと時間を把握しながら進行（p.34） まさか『anan』に「アジャイル」という言葉が登場するとは思いませんでした。実際、カンバンを使ってアプリケーションを作られているようです。あまりにも興味深かったので「ananにアジャイルが載ってる！」とFacebookに投稿したところ、「mjd？」とか「創作だろ？」とかいろいろ言われてましたが、本当に載っているので是非読んでみてください。 他にも女性誌が「チーム」を扱うとこういう感じになるんだなあという意味で、とても勉強になりました。「ローラ
アジャイルのプラクティスを、もう一度解説して行きたいと思います。できるだけ、日本の文脈にあった内容を加えて、実践できるように。また、野中先生に後でコメントを頂く予定。 ペア・プログラミング 文字通り、2人一組になってペアでプログラミングを行う。XPでの１つのプラクティスに挙げられており、１台のPCを交互に使って行うのが基本形。昨今ではデュアルディスプレーを使ったり、ネットワークと画面共有を使ったりして遠隔地で実践しているチームもある。 コーディングは単純作業ではない。１つ１つの変数や操作の名前を決めることや、その構造、アルゴリズムにいたるまで、多くの設計判断が入り込む、クリエイティブな活動である。また、ミスが起こりやすい作業でもある。刑事やパイロット、スキューバダイビングなど、リスクが高い作業はペアで行うことは現実の世界にはたくさんある。二人でプログラミングを行うことで、リアルタイムにレビ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
