エンジニアでも出来るAdobeXDでプロトタイピング
なぜプロトタイピングが必要なのか？
スクラムを導入した際にプロダクトオーナーとエンジニア間で機能の必要性に関して揉めることが多々あるのではないでしょうか。 なぜそのような状況になるのか見てみると、「その機能が必要とされているという確証を得ていない」ことが多いと思います。
「自分はこれが必要だと思う」「いや自分はこっちのほうがいいと思う」といった発言は主観的な判断になりやすく、「客観的に見てユーザーが必要としているか」という判断が漏れてしまいます。 では、どうすれば「客観的に見てユーザーが必要としているか確証を得る」ことが出来るのでしょうか？
１つの方法として「仮説を検証する」があるのではないでしょうか？ 「ユーザーがXXXをしたいと考えているはずだ」という仮設を立て、何かしらの手段で「ユーザーはXXXをしたいと考えていた」という情報を得ることができれば、 「客観的に見てユーザーが必要としているか確証を得る」ことが出来るはずです。
「仮説を検証する」方法としてまず考えられるのは、「実装した機能を使ってもらう」があるでしょう。 この場合、スクラムなどのイテレーションで実装していくスタイルの手法を取り入れることで実現できるはずです。 しかし、実装するのにそれなりのコストがかかりますし、実装した後に変更するコストも決して低くはなく、現実的には厳しいものがあると思います。。。
どうすれば、コスパよく「仮説を検証する」ことが出来るのか考えてみると、「プロトタイプを作る」という考えがあります。 最近ではいくつかのプロトタイピングツールがあり、それらを使うことによって「低コスト」で「仮説を検証する」ことが出来るはずです。
そこで、今回はプロトタイピングツールの１つである「AdobeXD」を使ってみたいと思います。
AdobeXD
Adobe XDは、共同作業を促進するパワフルで使いやすいプラットフォーム。 webサイトやモバイルアプリ、音声インターフェイス、ゲームなどのデザイン制作をチーム全体でスムーズにおこなうことができます。
プロトタイプを作ってみた
自分用に作っているアプリのプロトタイプをAdobeXDを使って作ってみました。
特別なスキルは必要なく、チュートリアルの動画を幾つか見ただけで作ることが出来る使いやすさです。
デザイン画面
プロトタイプ画面
また、デザインレビュー機能があったり、実装する際に必要なスタイル詳細を共有できたり、svgなどのアセットも自動で共有できたりと プロダクト開発チームで使うための機能が一通りそろっています。
良かった点・悪かった点
良かった点
- 簡単に使える
- 動作が軽い
- コンポーネント機能で管理が楽にできる
- 実機でプロトタイプを動かせる
- リアルタイムに変更内容をプロトタイプに反映できる
- チーム開発用の機能が揃っている
- 履歴機能がある
悪かった点
まとめ
- 「客観的に見てユーザーが必要としているか確証を得る」手段として「仮説を検証する」がある
- 「仮説を検証する」ために「実装した機能を使ってもらう」にはコストが高すぎる
- コスパよく「仮説を検証する」ために「プロトタイプを作る」ことが出来る
- 「プロトタイプを作る」ためのツールとして「AdobeXD」を使ってみた
- 「AdobeXD」は「特別なスキルは不要で誰でも簡単に使える」し「チーム開発に必要な機能が揃っている」
感想
- チームの共通言語として「AdobeXD」を使うと良さそう
- 「Prott」「Figma」などとも比較してみたい
参考資料
インプット大全 - 読書メモ
インプットとアウトプット
| インプット | アウトプット |
|---|---|
| 読む | 話す |
| 聞く | 書く |
| 見る | 行動する |
インプットの基本法則
- 「量」より「質」を重視する
- 「量」だけ増やしても自己成長にはつながらない
- 「質」を高めた後に「量」を増やす
- 「質」を高めるには？
科学的に記憶に残る本の読み方
- 「電子」より「紙」で読む
- 「紙」の方が「記憶力」「理解力」の点において有利
すべてを自己成長に変えるものの見方
- 「観察力」を磨くことで、６つのメリットが得られる
- コミュニケーション力がアップする
- 人間関係が良好になる
- 情報収集力が上がる
- 自己成長のスピードがアップする
- 変化に敏感になる
- ビジネスで成功する
- 「OODAループ」（ウーダループ）
- 見るインプット源
- テレビ
- 映画
- ライブ
- アート
最短で最大効率のインターネット活用術
- 「DIKWモデル」
- Wisdom：知恵
- 行動できる
- Knowledge：知識
- 使える
- Information：情報
- 理解できる
- Data：データ
- 見える
- Wisdom：知恵
- ネットから得られるもの →「情報」
- 本や人から得られるもの →「知識」
- インプットする「情報」と「知識」の割合は３：７以下にする
- 「情報をたくさん集める」行為 → 時間が取られる → 「知識」と「知恵」が減ってしまう
インプット力を飛躍させる方法
- 「マンダラチャート」
- 脳内図書館を構築する
- 一度にインプットする情報を「３つ」までにする
- 脳が一度に処理できる情報は３つまで
- ３つの情報を処理した後に、次の３つの情報を処理していく
感想
- ゴール設定とアウトプット前提のインプットを毎回行えるようにしたい
- 観察力は地道な積み重ねが必要そうだが、行動するハードルは低いので意識してやってみたい
会議ファシリテーションでスクラムの価値を引き出す
最近ではソフトウェア開発手法として、スクラムを採用している方々も多いのではないでしょうか。
さて、「スクラムガイド」では4つのイベントが定義されていて、 スプリント期間が1週間であれば、だいたい以下のような時間配分になるのではないでしょうか？
- 120分：スプリントプランニング
- 75分：デイリースクラム（15分/1日）
- 60分：スプリントレビュー
- 60分：スプリントレトロスペクティブ
この場合、「毎週315分」をイベントという名の会議に使っていて、 「労働時間の13％」に相当することになるのです。（週40時間労働の場合）
これらはスクラムで重要な要素となっている「透明性」「検査」「適応」を実現するために用意された必要最低限のイベントとなっていて、 基本的にはイベントを省略することは推奨されていないと思います。
つまり、スクラムでは「労働時間の13％」をイベント（会議）に使い「透明性」「検査」「適応」を実現する仕組みを提供しているのです。 スクラムの価値を引き出すためにはこれらのイベントの効果を高めることが必要なのではないでしょうか？
そこで今回は、スクラムの価値を引き出すために、誰でもできる「会議ファシリテーション」に関する情報を整理したいと思います。
会議ファシリテーションとは？
「ファシリテーション」の意味を辞書で調べてみると、以下となっています。
グループによる活動が円滑に行われるように支援すること。 特に、組織が目標を達成するために、問題解決・合意形成・学習などを支援し促進すること。 また、そのための方法。
つまり、「会議ファシリテーション」とは「会議が円滑に行われるように支援すること」となるでしょう。
会議とは？
「会議」の意味を辞書で調べてみると、以下となっています。
① 関係者が集まり、討論・相談や決議をすること。また、その会合。 「編集－」 「対策－」 「 －室」 ② 一定の事柄を相談し決定するための機関。 「日本学術－」
砕けた言い回しをすると「みんなで話し合ってゴールに到達する」ことではないでしょうか？
スキル不要で始める会議ファシリテーション
「会議ファシリテーション」は特別なスキルを持っていなくても実践することができます。
今回は以下の5つの項目を紹介したいと思います。
- 終了条件を確認する
- 時間配分を確認する
- 決まったこと・やるべきことを確認する
- 事前に確認する
- 発散と収束を区別する
終了条件を確認する
会議とは「みんなで話し合ってゴールに到達する」ですので、会議の一番最初に「ゴールに到達したと判断できる条件」の認識をあわせましょう。 これにより、会議は終了したけど何も決まっていない状態になるリスクを低減できます。
e.g.
- 次のスプリントで対応するチケットに見積もりがついている状態
- 次のスプリントで対応するチケットに受け入れ条件が記載されている状態
- 次のスプリントで対応するチケットの優先順位が決まっている
tips
- 終了条件はできる限り明確に判断できるものにすると、認識の齟齬が少なくなるでしょう
- 常に終了条件が見えるようにホワイトボードに書いておくと意識しやすいでしょう
時間配分を確認する
「ゴールに到達する」方法は1つだけでは無いはずです、今回の会議ではどのような時間配分・アジェンダで勧めていくのか会議の一番最初に認識合わせをしましょう。 これにより、議論がそれてしまうリスクを低減できます。
e.g.
- 5分：現在のベロシティを確認
- 30分：次のスプリントで着手できそうなチケットに見積もり・受け入れ条件を記載する
- 10分：次のスプリントで着手できそうなチケットの優先順位を更新する
tips
- 常に時間配分が見えるようにホワイトボードに書いておくと意識しやすいでしょう
決まったこと・やるべきことを確認する
多くの場合、会議を行ったことで「決まったこと」や「やるべきこと」が出てくると思います。必ず会議の最後に改めて認識合わせをしましょう。 これにより、「決まったことが」が守られなかったり、「やるべきこと」が実施されないリスクを低減できます。
e.g.
- 決まったこと
- ○○○のチケットは△△△なので次のスプリントでは対応しない
- やるべきこと
- ○○○のチケットが△△△である理由を□□□さんに確認しチームに共有する
- 担当：Aさん
- 期限：XX月YY日
- ○○○のチケットが△△△である理由を□□□さんに確認しチームに共有する
tips
- 実行可能なアクションである場合は、「誰が」・「いつまでに」行うのか確認すると良いでしょう
事前に確認する
時間は有限ですし、会議の進め方によっては準備が必要となる場合もあるでしょう。「終了条件」や「時間配分」を事前に確認し会議の準備をしましょう。 これにより、議論以外のことに時間を費やしてしまったり、情報が足りなくて決められないといったリスクを低減できます。
e.g.
- 終了条件
- 次のスプリントで対応するチケットに見積もりがついている状態
- 次のスプリントで対応するチケットに受け入れ条件が記載されている状態
- 次のスプリントで対応するチケットの優先順位が決まっている
- 時間配分
- 5分：現在のベロシティを確認
- 30分：次のスプリントで着手できそうなチケットに見積もり・受け入れ条件を記載する
- 10分：次のスプリントで着手できそうなチケットの優先順位を更新する
- 事前準備
- ○○○のチケットが△△△である理由を□□□さんに確認しておく
- 担当：Aさん
- ○○○のチケットが△△△である理由を□□□さんに確認しておく
発散と収束を区別する
「現状」や「課題」に対して「方針」や「解決策」を決める場合、それぞれに対して「発散」し「収束」する流れを経る必要があります。 「発散」と「収束」を区別し順番に議論を進めていきましょう。 これにより、論点が行ったり来たりしてしまうリスクを低減できます。
e.g.
- 「発散：現状の課題を確認」→「収束：議論する課題を選択」→「発散：課題に対する解決案を議論」→「収束：実行する解決案を選択」
tips
- 時間配分を決める際に発散と収束を区別すると良いでしょう
まとめ
スクラムでは「労働時間の13％」をイベント（会議）に使い「透明性」「検査」「適応」を実現する仕組みを提供しています。 それらのイベント（会議）の効果を高めるには「会議ファシリテーション」が有効です。
「会議ファシリテーション」は決して難しいものではなく、スキル不要で始められるものも多くあります。 なので、スクラムを採用している方々には「会議ファシリテーション」を使って、スクラムの価値を最大限引き出してほしいなと思います。
参考資料
3ヶ月でTOEIC500点から800点にスコアを上げる
はじめに
Webエンジニアとして仕事をしているが、英語が出来ないだけで様々なチャンスを逃したり、情報を得られる範囲が限られてしまうため、唐突に恐怖心をいだき英語の勉強をはじめました。
その時の忘備録としてどの様な取り組みを行ったのかまとめておこうと思います。
勉強を始めるときにやったこと
英語の勉強を始める際に以下のようなことをやりました。
ゴールを決める：TOEIC800点期限を決める：3ヶ月誰かに宣言する：上司に宣言勉強方法を決める：https://37toeic.com/
大切なのは、いつまでに・どこに到達するのかを決めモチベーションを作ることだと思いました。
あまり良い方法ではないかもしれないですが、他人に宣言をすることで多少なりとも言ったからには実行しないとなという気持ちは得られたかなと思います。
その上で、やり方に関してはとりあえず何か決めてやってみて、ダメそうだったら直ぐに軌道修正すればよいのかなと思います。
勉強方法
こちらのサイトを参考に勉強を行いました。
37歳からのTOEIC勉強法というタイトルになっていますが、特に年齢に依存せず100日程度で800点を目標とした勉強法だったため採用することにしました。
紹介されている勉強方法を厳密に守ることはできませんでしたが、電車の中や帰宅後の時間を使って1日に1~3時間ぐらいは勉強する時間に当てていました。
結果
TOEIC IP を社内で受験し、結果としては795点を取ることができました。
一応、ゴールは達成できたので良かったかなと思います。（厳密には5点足りてないですが、そこはOKとしました）
ただし、これで英語のリスニングやリーディングが凄くできるようになったかと言われると、そうでもないなという感じがあります。確かにTOEICの点数は取れるようになりましたが、一般的な英語に関してはまだまだスキルが足りないなと感じることが多々あります。
TOEICで800点取れてるからといって英語が凄くできる訳ではないんだなと思いました。
エクストリームプログラミング
エクストリームプログラミング
エクストリームプログラミング（XP）はアジャイルソフトウェア開発手法の1つである。
- XPとは、効果のない技術的・社会的な古い習慣を捨て、効果のある新しい習慣を選ぶことである
- XPとは、自分が今日やるべきことを十分に理解することである
- XPとは、明日をよりよくしようとすることである
- XPとは、チームのゴールに貢献した自分を評価することである
- XPとは、ソフトウェア開発で人間としての欲求を満たすことである
価値・原則・プラクティス
価値というものはとても抽象的なものである。なので、「この1000ページのドキュメントを書いたのは、コミュニケーションに価値をおいているからです」という意見は、正しいかもしれないし、間違っているかもしれない。
逆に、プラクティスといものはとても具体的である。「毎朝10時にスタンドアップミーティングに参加する」というプラクティスは、参加出来ているかどうかを簡単に判断できる。
この価値とプラクティスの間には大きな隔たりがある。価値は普遍的なものであるが、プラクティスは状況によって大きく異なる。この2つの間のギャップを埋めるのが原則である。
価値
コミュニケーション：Communication
チームによるソフトウェア開発で最も重要なのはコミュニケーションであり、チーム感覚や効果的な協力関係を生み出すために重要なものである。
シンプリシティ：Simplicity
問題を解決するための最もシンプルな方法を選択する。無駄に複雑な方法を選択する必要性はない。ただし、シンプルであるかどうかは状況によって異なるものである。
フィードバック：Feedback
最初に決めた方向性が、ずっと有効であることは無い。それが、ソフトウェアの要件・システムのアーキテクチャなどであっても同じである。経験をする前に何かを決めてしまうとすぐに駄目になってしまう。変化は避けられないものであり、対応するためにはフィードバックが必要となる。
勇気：Courage
勇気とは恐怖に直面したときの効果的な行動である。勇気を持って真実を語れば、コミュニケーションや信頼が強化される。勇気を持って新しい解決策を見つければ、シンプリシティが促進される。
リスペクト：Respect
チームメンバーはお互いに人として等しく重要である。ソフトウェア開発において人間性と生産性を同時に高めるには、チームに対する個人の貢献をリスペクトする必要がある。
原則
人間性：Humanity
ソフトウェアを開発するのは人間であり、人間性を保つために個人の欲求を満たすことが重要である。しかし、チームによるソフトウェア開発で難しいのは、個人の欲求とチームのニーズの両方のバランスを取り、みんなが自分らしくいられるようにすることである。
経済性：Economics
ソフトウェア開発における経済性には2つの側面があり、貨幣のタイムバリューとシステムやチームのオプションバリューである。貨幣のタイムバリューでは、今日のお金は明日のお金よりもバリューがあるとされる。将来のオプションバリューでは、ある機能を再利用できたとすると本来の目的だけに使うよりもバリューが高いということになる。
相互利益：Mutual Benefit
相互利益とは現在の自分・将来の自分・顧客に対する利益を求めることである。誰かにとって不利益となる解決策をとってしまうと、そこから敵意が生まれ、人間関係を引き裂くことになってしまう。
自己相似性：Self-Similarity
ソフトウェア開発においても、異なる規模の問題に対して、解決策の構造を新しい文脈にコピーしようとする。
改善：Improvement
「完璧な」プロセス・設計・ストーリーは存在しない。だが、「完璧に」プロセス・設計・ストーリーをやることはできる。改善によってソフトウェア開発の高みを目指し、今日できる最高のことをやるのである。
多様性：Diversity
お互いがよく似ているチームは、居心地は良いかもしれないが、機能的ではない。解決策を導き出すには多様性が必要である。
ふりかえり：Reflection
優れたチームは、どうやって仕事をしているのか・なぜ仕事をしているのかを考えている。なぜ失敗したのか・なぜ成功したのかを分析している。ミスを明らかにしそこから学ぼうとするのである。偶然に優秀になれる人などいないのである。
流れ：Flow
流れとは、すべての開発作業を同時に行い、バリューあるソフトウェアの安定した流れを生み出すことである。ソフトウェアのデプロイやインテグレーションの頻度を下げると、フィードバックの頻度が減り状況が悪化してしまう。
機会：Opportunity
問題を変化の機会と考えよう。その場を切り抜けるための問題解決しかしないサバイバルな姿勢では不十分である。より高みを目指すには問題を学習や改善の機会へと変換すべきである。
冗長性：Redundancy
重要で困難な問題は、複数の方法で解決すべきである。ひとつの解決策が失敗しても、その他の解決策で惨事を食い止めることができる。冗長性にコストが掛かるとしても、大惨事を回避できるならそのコストは支払うべきである。
失敗：Failure
失敗することにより解決策を導き出すのに必要な知識を得ることができる。その知識が得られたのであれば決して無駄ではない。ただし、よりよい方法を知っていながら失敗することを正当化するものではない。
品質：Quality
低品質を受け入れることでプロジェクトが早くなることはない。高品質を要求することでプロジェクトが遅くなることもない。むしろ、品質を高めることでデリバリーが高速になることが多い。品質基準を下げてしまうと、デリバリーが遅くなり予測できなくなってしまう。
ベイビーステップ：Baby Step
大きな変更は、大きなステップでやりたくなるものである。しかし、重大な変更を一気に行うのは危険であり不安を伴う。大きな変更が失敗してチームが無駄に後退するよりも、小さなステップで進むオーバーヘッドのほうが小さい。
責任の引受：Accepted Responsibility
責任とは割り当てるものではなく引き受けるものである。責任には権限が伴わなければいけない。このバランスが取れていないと、チームのコミュニケーションが破綻してしまう。
プラクティス
全員同席：Sit Together
チーム全体が入れる十分な広さのオープンスペースで開発すること。物理的に近くにいれば、コミュニケーションが促進される。ただし、近くにプライベート空間を用意するなどして、メンバーのプライバシーや自分だけの空間といった欲求を満たせるようにすること。
チーム全体：Whole Team
プロジェクトの成功に必要なスキルや視点を持った人たちをチームに集めること。1日に無理なくやり取りできる人数は12人までである。また、小数点以下の人間を入れてしまうと、情報の共有に時間を割く必要がでてきたり、チーム感が失われたりと、非生産的である。
情報満載のワークスペース：Informative Workspace
仕事の内容が分かるようなワークスペースを作ること。プロジェクトに関しがある人が近づいて見たときにが、抱えている問題などの情報が得られるようにしておこう。また、お菓子を用意したり、仕切りのある机を用意したりと人間のその他の欲求も満たす必要がある。
いきいきとした仕事：Energized Work
生産的になれる時間だけ働くこと。無理なく続けられる時間だけ働くこと。意味もなく燃え尽きてしまい、次の2日間の作業が台無しになれば、自分にとってもチームにとってもよろしくない。
ペアプログラミング：Pair Programming
同じマシンを前にした2人で、本番用の全てのプログラムを書くこと。これにより、お互いにタスクに集中したり、意見を出し合ったりすることができる。ただし、ペアプログラミングは疲れるプラクティスであるので、適度な休憩をはさみつつ進めると良いだろう。
ストーリー：Stories
「これまでのレスポンスタイムで5倍のトラフィックを処理する」といった、顧客に見える機能の単位を使って計画すること。そして、開発工数を見積もること。これにより、ビジネスと技術の観点からお互いにやり取りができる。
週次サイクル：Weekly Cycle
1週間分の仕事の計画をまとめて立てること。そして週の初めに、進捗の確認・着手するストーリーの選択・必要なタスクの見積もりを行うこと。週の終わりまでにデプロイ可能なソフトウェアを作ることが目的である。また、週次サイクルは、実験を行うための手軽で頻繁で予測可能なプラクティスでもある。
四半期サイクル：Quarterly Cycle
四半期分の計画をまとめて立てること。四半期に一度はチーム・プロジェクト・進捗・ゴールについて振り返ること。四半期は自然で広く受け入れられている時間の尺度であり、ビジネス活動ともうまく同期できる。
ゆとり：Slack
どのような計画にも、遅れたときに外せるような重要度の低いタスクを含めること。あとからストーリーを追加したり、多くのストーリーをデリバリーしたりするのは後からでもできる。
10分ビルド：Ten-Minute Build
自動的にシステム全体をビルドして、全てのテストを10分以内に実行させること。時間がかかると使用頻度が減り、フィードバックの機会が失われてしまう。
継続的インテグレーション：Continuous Integration
数時間以内に変更箇所のインテグレーションとテストをすること。インテグレーションのステップはプログラミングよりも時間のかかることが多い。インテグレーションに時間がかかれば、その分だけコストが上がり、予期しないコストも増えてしまう。
テストファーストプログラミング：Test-First Programming
コードを変更する前に、失敗する自動テストを書くこと。これにより、不要なコードの追加を防いだり、疎結合で凝集度の高いコードを書いたり、自然で効率的な開発のリズムを得ることができる。
インクリメンタルな設計：Incrementel Design
システムの設計に毎日手を入れること。システムの設計は、その日のシステムのニーズにうまく合致させること。小さくて安全なステップで稼働中のシステムを変更する経験を積み重ねていくと、設計にかける労力を遅延させることができるようになる。そうすれば、システムはシンプルになり、進捗は早くなり、テストが書きやすくなる。
まとめ
XPの目的は、圧倒的なソフトウェア開発の実現である。ソフトウェアはもっと安いコストで、もっと少ない欠陥数で、もっと高い生産性で、もっと高い投資効率で、開発することができる。
ソフトウェア開発において、良いチームの間には、異なるところよりも似ているところが多い。そのようなチームに共通していることを「エクストリーム」な形で抽出したのがXPである。
XPは、今日よりも素晴らしい明日を作り出す手助けをしてくれるだろう。
参考
- https://ja.wikipedia.org/wiki/エクストリーム・プログラミング
- エクストリームプログラミング Extreme Programming Explained 2nd Edition
アジャイルプラクティス
アジャイルプラクティス
効果的なプラクティス無しにプロジェクトを進めてしまうと、問題が多発し品質の悪いソフトウェアを作り続ける羽目になってしまうことだろう。
そのような苦い経験をすると、同じ過ちを繰り返さないよう過去の経験を元に成功したプロセスを採用してしまいがちである。気づいたときにはプロセスが大きくなりすぎて身動きが取れなくなってしまう。そのような状況でさえチームはプロセスが足りないのが良くないのだと思いこんでしまい悪循環に陥ってしまう。
この状況を改善しようと業界のエキスパートが集まり、開発チームが迅速に作業し変化に対応できるよう「価値と原則」をまとめたのである。
アジャイルソフトウェア開発宣言 - 価値
プロセスやツールよりも、人と人同士の交流を重視する包括的なドキュメントよりも、動作するソフトウェアを重視する契約上の交渉よりも、顧客との強調を重視する計画に従うことよりも、変化に対応することを重視する
プロセスやツールよりも、人と人同士の交流を重視する
良いプロセスを使っていても、優秀な人材がいなければプロジェクトはうまくいかない。また、優秀な人材が揃っていたとしても、協調して仕事を行うことができなければ失敗する。協調性のないスーパースター集団よりも、うまくコミュニケーションを取れる平均的な人材を集めたほうがうまくいきやすい。
仕事を進める上で適切なツールを使うことはとても大切である。しかし、ツールに頼りすぎたり、大きくて複雑なツールを過度に導入することは状況を悪化させる。まずはホワイトボードや紙などのシンプルな道具を使ってみて、どうしてもうまくいかないのであれば他のツールを導入してみよう。
大切なのは、開発環境を整えるよりも開発チームを形成することのほうが重要だということである。
包括的なドキュメントよりも、動作するソフトウェアを重視する
ドキュメントを用意することは人間に情報を伝える手段としては適切であり、重要なものである。しかし、ドキュメントがたくさん作られてしまうことは不足するよりもタチが悪い。必要なのは、シンプルで重要な事柄のみを記載したドキュメントである。
新メンバーへ仕事の内容を教えるときに重要となるドキュメントは「コード」と「チーム」である。コードの処理内容に嘘はなく確実な情報源である。また、常に変化するロードマップなどは「チーム」の頭の中にある。これらを伝える最も良い方法は、人間同士で直接伝えることである。
契約上の交渉よりも、顧客との強調を重視する
ソフトウェアを開発する上で前もってプロジェクトの納期や条件を契約書で定めること自体が、そもそも無茶である。契約書で定めた内容の大半は途中で意味をなさなくなってしまう。
プロジェクトを成功させるためには、顧客からのフィードバックが欠かせない。顧客は契約書にすべてを任せず、開発チームに対して頻繁にフィードバックを行い密接にプロジェクトに関わるべきである。
計画に従うことよりも、変化に対応することを重視する
ソフトウェア開発において、遠い未来の予定を立ててもあまり意味がない。理由としては以下の3つであり、変化に対応する能力があるか否かが、プロジェクトの成否を分けるのである。 - ビジネスの状況が変わりやすい - 顧客は動いているシステムを見ると、要求を変更してくる - 開発時間を正確に見積もることは難しい
詳細な予定を2週間程度、おおまかな予定を3ヶ月程度作り、その先に関しては大雑把にしておくのが上手な計画の建て方である。こうすれば、綿密な計画を練っている時間は小さくなり、変化に対応しやすくなる。
アジャイルソフトウェアの12の原則 - 原則
- 再優先事項は顧客を満足させることであり、価値あるソフトウェアを早い段階から継続的に届けることでこれを実現する
- 要求変更を歓迎し、たとえ開発過程の後半であってもそれを受け入れる。アジャイルプロセスは、変化に対応することで顧客の競争上の優位性を確保する。
- 実動可能なソフトウェアの納品を頻繁に行う。できるだけ短い期間で納品することを旨とし、数週間から数ヶ月間隔で納品する。
- 顧客と開発者はプロジェクト全般を通じて日々ともに働かなければならない。
- やる気のある開発者をプロジェクトの中心に据え、彼らが必要とする環境とサポートを与え、信頼して仕事の完遂を任せる。
- 開発チームで情報を伝達する最も効果的な方法は、直接話し合うことである。
- 実動するソフトウェアこそが進歩状況の尺度である。
- 持続できるペースで開発する。そうすれば、スポンサーも開発者もユーザーもずっと一定のペースを確保できる。
- 高度な技術と優れた設計への配慮は、アジャイル性を高める。
- シンプルさが肝心 - やらなくていいことはしない。
- 最高のアーキテクチャ、仕様要求、設計は自己管理能力のあるチームから生まれる。
- チームは定期的にプロジェクトを見直し、より効果的な方法を考え、対応方法の変更や調整を行う。
再優先事項は顧客を満足させることであり、価値あるソフトウェアを早い段階から継続的に届けることでこれを実現する
ソフトウェア開発プラクティスに関する調査により、以下の調査結果が出ている。 - 最初に納品される機能が少なくて乏しいほど、最後の納品での品質はより高いものになる。 - 頻繁に納品すればするほど、最終的な品質はより高いものになる。
要求変更を歓迎し、たとえ開発過程の後半であってもそれを受け入れる。アジャイルプロセスは、変化に対応することで顧客の競争上の優位性を確保する。
開発チームは変化を恐れない。変化によって市場が求めているものをより深く学ぶのである。そして、変化に柔軟に対応できるようソフトウェア構造を柔軟に保つ努力を怠らない。
実動可能なソフトウェアの納品を頻繁に行う。できるだけ短い期間で納品することを旨とし、数週間から数ヶ月間隔で納品する。
最初の段階から実動可能なソフトウェアを頻繁に納品する。ドキュメントやプランを提示するだけでは不十分であり、実質的に意味はない。
顧客と開発者はプロジェクト全般を通じて日々ともに働かなければならない。
アジャイルな状態を保つために、顧客と開発チームやステークホルダーは密接かつ頻繁にやり取りを行うべきである。
やる気のある開発者をプロジェクトの中心に据え、彼らが必要とする環境とサポートを与え、信頼して仕事の完遂を任せる。
プロジェクトで重要なのは「人」である。プロセス、環境、管理などは二次的なものであり、それらが「人」に悪影響を及ぼすのであれば変更を必要とする。
開発チームで情報を伝達する最も効果的な方法は、直接話し合うことである。
プロジェクトの主要なコミュニケーションは「会話」である。仕様、計画、設計をドキュメントにすることを求めない。ドキュメントを作るのは重要かつ緊急な場合である。
実動するソフトウェアこそが進歩状況の尺度である。
進捗状況は実働可能なソフトウェアの量で判断する。ロードマップ上でのフェーズやドキュメントの枚数などで判断はしない。
持続できるペースで開発する。そうすれば、スポンサーも開発者もユーザーもずっと一定のペースを確保できる。
ペースを上げすぎると途中で燃え尽きたり手を抜いて大失敗することになる。明日できることは無理して今日中にやらない、常に最高の品質が保てるペースで仕事を進める。
高度な技術と優れた設計への配慮は、アジャイル性を高める。
プロジェクトの進行を早くさせたければ、ソフトウェアを常に健全な状態に保っておく必要がある。そのために、乱雑なコードを書いてしまったら、後回しにはせずその日のうちに書き直すのである。
シンプルさが肝心 - やらなくていいことはしない。
いきなりシステム全体を作ろうとせず、目的を達成するために必要なシンプルな方法を段階的に導入していく。予め必要となりそうなことを予想してもあまり意味はない。必要な作業だけシンプルに行えば、問題が発生しても柔軟に対処できるのである。
最高のアーキテクチャ、仕様要求、設計は自己管理能力のあるチームから生まれる。
チームは自己管理能力があり、一丸となって課題に取り組む。各個人がアーキテクチャ、仕様要求、設計に意見することはあるが、各個人が責任を負うことはない。責任はチーム全体にあるのである。
チームは定期的にプロジェクトを見直し、より効果的な方法を考え、対応方法の変更や調整を行う。
チームは、ルールや習慣などを常に見直す。環境は常に変化しそれに合わせて自分たちも変化しないとアジャイル性を保てないからである。
参考文献
- https://agilemanifesto.org/
- アジャイルソフトウェア開発の奥義 第2版
アジャイル設計
アジャイル設計
アジャイル設計とはプロセスやイベント等の事ではない。ソフトウェアの構造や読みやすさを向上させるため、原則・パターン・プラクティスを継続的に適用する行為である。
ソフトウェアは時間が経つにつれ腐敗していく。汚いコードが溜まっていき、どんどんメンテナンスしづらくなってしまう。そうなると、ちょっとした変更でさえも大変な労力を必要としてしまう。
アジャイル開発者は可能な限りソフトウェアをきれいな状態に保ち、変更しやすい状態にしておく必要がある。だから、毎日、毎時間、毎分、ソフトウェアをリファクタリングする努力を怠ってはいけない。
設計の悪臭 - 腐敗するソフトウェアの兆候
次に示す傾向が1つでも現れたら、ソフトウェアが腐敗し始めた兆候である。
- 硬さ
- もろさ
- 移植性のなさ
- 扱いにくさ
- 不必要な複雑さ
- 不必要な繰り返し
- 不透明さ
硬さ
変更によって他の部分にまで影響が出てしまい、他の部分も変更を必要とする状態。
1つの変更で、依存しているモジュールを芋づる式に次々と変更しなければならないような場合を、設計が「硬い」という。
もろさ
変更によって他の部分が壊れてしまう状態。
モジュールのもろさが増すと、1つの変更でさえも予期せぬ自体を招くようになる。
もろいモジュールは、常にリファクタリングが必要とされるモジュールを探すと良い。
移植性のなさ
他のシステムでも役に立つ部分があった場合に、その部分を切り出すことが困難な状態。
扱いにくさ
ソフトウェアの扱いにくさと開発環境の扱いにくさの2種類がある。
変更をするときに、設計構造を維持しないやり方を選んだほうがやりやすいソフトウェアは「扱いにくい」。
設計構造を維持できるかどうかではなく、開発環境の非効率差を増やさないような変更をしたくなるソフトウェアは「扱いにくい」。
不必要な複雑さ
設計している時点で必要のない要素が含まれている設計は「不必要な複雑さ」である。
あとで必要になると思い、予め処理しやすい仕組みを取り入れておいた場合などに発生する。
不必要な繰り返し
同じようなコードが何度も現れるような状態。
システム内に重複しているコードがあると変更が大変になる。重複している箇所からバグが見つかった場合に同じような箇所を全て修正しなくてはならないのである。
不透明さ
わかりにくいモジュールは「不透明」である。
時間が経つにつれ、コードはどんどんと不透明になっていく。そういった不透明さを最小限に抑えるために常にリファクタリングする努力を怠ってはいけない。
設計を行う
参考文献
- アジャイルソフトウェア開発の奥義 第2版
