このすみ技術ろぐ

とあるWebエンジニアが、技術や趣味について書くブログです。

受託開発のメリットを活かせ!失敗しないプロジェクト運営のコツを受託開発の極意で学

「受託開発の極意」という、岡島幸男さんの本を読みました。私はたまたま図書館で見かけたのですが、200ページに届かない文量で、ページ数こそ少ないものの、ノウハウがギュッと凝縮されている本です。

極意は言い過ぎだと思いますが、ページ数も控え目で、サクッと読める良い本でした。

・・・というわけで、個人的な備忘録に加えて、自分の意見も織り交ぜつつ、受託開発について書いていきます。

目次

なぜ受託開発は嫌われるのか?

本書では、以下のような理由が挙げられています。

  • やらされている感
  • 顧客に振り回されている感
  • 自分の仕事が何の役に立っているのかわからない感

これらの原因は、受託開発が「受け身」という側面を持っていることが問題です。受託開発だから、下請けだから、お客様の言うことだから。こういった受け身の姿勢が、受託開発の失敗や、モチベーションの低下を招くのです。

受託開発を楽しむには

まず、受け身の姿勢を変える必要があります。人に振り回されて失敗するくらいであれば、こちらから攻めるのです。

  • 積極的に顧客からヒアリングをして、要件を引き出す
  • 顧客がITの専門知識に詳しいことは稀なので、要件定義を上手くサポートする
  • プロジェクトに積極的に関わることで、顧客からの信頼や満足を勝ち取る

顧客は受注者と発注者の関係ではなく、一緒にサービスを作り上げていくためのパートナーなのです。サービスを中心に物事を考えれば、開発しているプロジェクトに対しても愛着が湧いてきませんか?

受託開発では、既に顧客がいるというメリットを活かして、顧客を振り回すくらいの勢いで行きましょう。

なぜお客様に関心が持てないのか?

受託開発において、メンバーがやらされている感を抱くの理由の一つに、お客様の顔が見えないということが挙げられます。会議の議事録や、送られてきた仕様だけを見ても、そこに人はいないのです。

一番の解決方法は、やはりフェイス・トゥ・フェイスです。議事録役として、顧客との会議にメンバーを参加させる。もしくは、○○機能の開発担当として同席させる。手段は何でも構いません。

とにかく、使っている相手の顔が見えることが重要です。そうすることによって、どうしてもシステム目線で見がちなエンジニアに、顧客目線という視点が生まれてきます。

本来、システムを使うのは顧客なわけですから、顧客目線で見つめる事は当然なわけですが。受託開発だと、これがなかなか難しいのです。

f:id:konosumi:20180731030432j:plain

顧客が納得するための見積もり

見積もりにおいて、以下のようなことが重要点として挙げられます。

  • 見積もるための十分な情報を引き出す(もらえる)こと
  • 見積もりの根拠に納得感を与えること
  • ただ見積もるだけでなく、工数を抑えたり、価格を抑えるためのプラスアルファの提案(代替え案)が提示できること

見積もるための情報を引き出す

見積もりの正確性を高めるためのコツは、何と言っても情報量です。シャーロック・ホームズは、作中において「情報量が足りない間は推理しない」のような旨を語っていたと記憶していますが、私もそう思います。

そのためには、お客様からヒアリングをし、システムで実現したいことの要件を固めていきます。これの繰り返しです。

見積もりに向けたヒアリングのゴールは、例えば一般的なWebシステムであれば、必要な画面や帳票といった「モノ」を集めていくことです。見積もりには、対象物となるモノが必要です。

モノが出揃えば、後は画面毎に機能を検討しながら、見積もりへと進むことができます。

見積もりの根拠を高める

見積もりの根拠を高めるコツは、数値で計算できることです。なんとなくで弾き出した数値ではいけません。ユースケースポイント法、ファンクションポイント法、タスク分解法・・・といった方法論が、本書では列挙されています。

一定の方針に沿って算出された見積もりであれば、そこに自然と根拠が生まれます。

また、過去のプロジェクト実績があれば、大いに活用しましょう。見積もりの妥当性を検討する場合、やはり過去の実績は大きな基準となります。

要件定義

本書に、以下の興味深い一文が書いてありました。大きな要因は「要件の分析不足」と「ヒアリング不足」です。

要件は変わったのではなく、間違って定義されてしまっていることが多いのです

プログラマの仕事は問題解決である

開発者は、ただプログラミングの能力が高いだけでは不十分です。ここでは、お客様と一緒に(お客様視点で)物事を考えながら、整理していく問題解決能力が重要になってきます。

Ruby開発者で有名なMatz氏も、同様のことを述べているわけですから、意識しておいて損はありません。

プログラマの仕事は問題解決

引用:Matz氏講演会「学生エンジニアの生存戦略」 - Qiita

要件の変更は、後の工程になるほど影響が大きくなります。問題に気づくタイミングは、早ければ早いほど良いです。

目に見えない要件にも気をつける

システムの要件は、画面や帳票のような、何も目に見えるものだけとは限りません。

  • 信頼性要件: 復旧に要する時間や、システムの稼働率、など
  • 効率性要件: 3秒以内に応答は返す必要がある、などの性能面
  • 使用性要件: デザインの決まり事や方針、ガイドライン、など
  • 保守性要件: ソフトウェアの今後の変更や、修正のしやすさ、など
  • 移植性要件: 他のOSでも動作する必要がある、など

私は初めて知りましたが、これらの品質要件は「JIS X0129・ISO/IEC 926」として、国際規格にまとめられているらしいです。

f:id:konosumi:20180731031445j:plain

設計・実装・テスト

変更に強い設計を重視する

設計とは、定義された要件を満たすための実現手段を検討し、品質を作り込む作業です。

ここで、重要なことは、後の変更に強い設計(=保守性が高い)にすることです。なぜ変更に強いことが重要かといいますと、簡単に言ってしまえば、後々の修正や仕様変更に強くなるからです。

例えば、モジュール同士が疎結合になっている設計であれば、他の変更が他に影響する、いわゆるデグレのような問題は少なくなります。

テストコードを活用した実装

変更に強くなるためには、変更によって生じるバグ(デグレ)を、早期に検知できる仕組みづくりが必要になります。そこで登場するのが、「テスト駆動」や「テストコード」といった考え方です。

本書には、ほとんどの問題は単体テストで発見できると書いてあります。個々のモジュールの段階で、潰せるバグは潰しておきましょう。

テスト計画による品質の画一化

テストを実施するにしても、統一した基準がなければ、メンバーによって品質はバラバラになってしまいます。品質を保証するためには、予め「どういうポイントで、どこま細かくテストするのか」を策定しておきましょう。

出来れば、テスト基準はお客様とも合意しておくことが望ましいです。

ドキュメントは運用のためにある

ドキュメントはメンテナンスされないとはよく言いますが、ドキュメントは何のためにあるかって、納品するためではなく、運用するためにあるのです。

たとえ、ドキュメントが納品物ではなかったとしても、運用フェーズにおいてドキュメントがあるとないでは、大きく変わってきます。何せ、人は読んだ本の内容を、1週間後には90%も忘れてしまうような生き物なのです。

ソースコードのコメントでも良いので、とにかくドキュメントは積極的に残しましょう。また、適切にメンテナンスされるドキュメントを維持するための、仕組みづくりも重要になってきます。

進捗は細かくブレークダウンする

進捗管理は、全体進捗のような大枠ではなく、細かいタスクレベルで管理するようにしましょう。

私見では、最近はタスクは長くても1日以内に終わるように細分化するといった取り組みが、流行っているように見受けられます。細かくすればするほど、進捗は正確性を増していくのです。

タスクの粒度が大きいと「このタスク、進捗がずっと90%だけど?」といった事態が発生します。あるあるです。私も経験があります。

プロジェクトの成功を掴むためには、まずは自分から変わろう

多くの人が、自分は変わりたいと思っています。特に、IT業界は優れたエンジニアが際立って目立つような世界です。「私もああなりたい」と思うことは、往々にしてあります。

KIML(Know,Imagine,Move,Love)サイクル

これは著者が考案した用語だと思うのですが、KIMLが興味深かったので紹介します。

  • Know: 今の自分を知る
  • Imagine: 変わったあとの姿を思い描く
  • Move: 行動する
  • Love: 変われた自分を好きになる

私なりに要約するならば、まずは現状を分析し、改善後の理想形を思い描きます。次に現状と理想のギャップを埋めるために行動します。行動した自分は、素直に褒めてあげましょう。

これは、確か7つの習慣にも書いてあったと記憶していますが、人はすぐには変わりません。まずは、自分から変わるしかないのです。自分が変われば、それに影響を受けた周りにも変化が生まれてきます。

仲間を増やそう

プログラミングは、結局は個々の作業にまで落とし込まれることが多いです。プログラマーが孤独を感じやすい理由はそこにあるのですが、何も一人で全てを頑張る必要はありません。

開発を楽しむには、仲間を作りましょう。社内で勉強会を開催しても良いですし、試しにペアプログラミングをやってみるのも面白いです。

さいごに

本書を読んだ感想として、受託開発を成功に導くコツは「顧客やメンバーをはじめとして、プロジェクトに関わる人たちを、如何に巻き込むかが重要である」と感じました。

こうやって考えてみると、受託開発も自社開発も、求められる素養はそこまで変わりないのです。もちろん、ビジネス上のメリットで言えば、受託開発では自社開発と違って、入金額の見通しが立ちやすいなどの違いがあります。

かのアジャイルサムライに「アジャイルな顧客」という一文がありますが、本書が求めていることは、それと似ています。主体的に顧客(や元請け)が関わってくれるような関係を築き上げることこそ、受託開発の極意なのではないでしょうか?

補足

本記事に書いてある内容には、私見が大いに含まれています。そのため、興味を持たれた方は、ぜひとも原著を読まれることをオススメします。

少ないページ数ではありますが、ノウハウが凝縮された良書です。

Habiticaによるゲーム感覚のTODO管理と習慣化の維持

「Habitica - Gamify Your Life」は、RPGの主人公を育てるようなゲーム感覚で、TODO管理と習慣化の維持を目指すサービスです。

habitica.com

さらにOSSなので、GitHubにソースコードも公開されてます。気になったので試してみました。

まず最初にキャラクターを作る

Habiticaではじめにやることは、キャラクター制作です。RPGでいう主人公のキャラクターメイキングです。

なお、最初の段階ではパーツも少ないのですが、ゲームを進めていくと増えていくみたいです。そして、キャラクターに名前を付けたらゲームスタートです。

初期画面

Habiticaの初期画面です。大きく分けて「習慣」「日課」「To-Do」「ごほうび」があります。

f:id:konosumi:20190122233448p:plain

習慣

習慣として定着させたいことを入力します。

f:id:konosumi:20190122234111p:plain

良い行ないをしたら「+」をクリックします。ゴールドや経験を獲得します。

f:id:konosumi:20190122234055p:plain

悪い行ないをしなら「-」をクリックします。体力が減ります。

f:id:konosumi:20190122234215p:plain

たとえば飲み会であれば、飲みすぎなければ良い習慣となり、飲みすぎたら悪い習慣になります。自分の分身であるキャラクターがダメージを受けるので、悪い行ないは控えましょう。

日課

表題は日課となっていますが、曜日や繰り返し頻度が選べます。使い勝手の感覚は、Googleカレンダーの定期スケジュールと似ていました。

f:id:konosumi:20190122234503p:plain

日課をチェックすると灰色に変わり、プレイヤーは経験値・ゴールド・マナ、落とし物のチャンスを得ます。つまり、日課をこなすほど主人公が成長します。

To-Do

To-Doは「タイトル」「メモ」「チェックリスト」「難易度」「期限」「タグ」が設定できます。高機能ではないですが、及第点の内容です。

f:id:konosumi:20190122234923p:plain

To-Doも他と同じく、達成すると経験やゴールドを得られます。

ごほうび

ゴールドを消費して、ごほうびを得ることができます。主人公の装備品であったり、自分でごほうびを作成することも可能です。

f:id:konosumi:20190122235258p:plain

習慣やTo-Doをこなすことでゴールドを得て、それを消費することでごほうびを得るというライフサイクルです。

ソーシャル機能

パーティーを組んだり、ギルドに所属するなどといった、Habiticaユーザーが連携するソーシャル機能があります。

ただし、ギルドやキャンプ上でのやりとりはほとんど英語なので、私はまだ所属できておりません。

ペットを飼う

私はまだ始めたばかりでレベルが低いため、アンロックできてないのですが。レベル3を超えるとペットが飼えるようになります。

たまごを手に入れて、ペットをたまごがえしの薬でかえして、えさを与えて・・・という流れです。

クラス・システム

初期状態では戦士ですが、レベルが10を超えると、ジョブチェンジのシステムが解放されます。「戦士」「魔道士」「治療師」「盗賊」になれます。

f:id:konosumi:20190123001217p:plain

習慣化の維持とは?

色々と検索をして調べてみたのですが、Habiticaは人生をRPGのようにタスク管理することで、レベルアップするためのツールみたいです。

たとえば習慣であれば、普通に習慣を達成しても何も反応がなければ、モチベーションが保ちづらいです。そこで、Habiticaは主人公の成長やごほうびといった要素を加えることで、習慣の継続を目指してします。

習慣の例は色々あるみたいですが、一例を上げると以下のような習慣です。

  • 健康:早起きする
  • 家事:食後は必ず皿を洗う
  • 勉強:宿題を1つやる

Habiticaユーザー

人生fmのきりみんさんは、Habiticaユーザーです。普通に生活しているだけで達成感を得る事ができるという感想は、確かにその通りかもしれません。

自然に習慣をこなしているだけで、経験やゴールドが貯まっていきキャラクターが豊かになっていくので、ポジティブな反応が得られます。

kirimin.hatenablog.com

HabiticaはOSS

ITエンジニア的におもしろい点で言えば、HabiticaはOSSとしてソースコードが公開されています。Web版に加えて、iOSとAndroidのモバイルアプリ版もあります。

github.com

さいごに

自分で難易度が調整できてしまう側面があるので、最終的には自分自身の継続力に委ねられる点があります。ただ、ゲーム要素を取り入れるというアイデアは、とてもおもしろいです。

習慣を根付かせたいと考えている人であれば、試してみてはいかがでしょうか?

habitica.com

ワンストップ見積もり本で、プロジェクト見積もりの勉強を始めよう - おやかた.amに寄せて

昨日徹夜をしまして、ワンストップ見積もり本の原稿を書き上げました。

note.mu

ワンストップ見積もり本は、C95(2018冬コミ)の親方Projectにて頒布される予定の技術同人誌です。「おやかた.am」という技術同人誌を紹介するポッドキャストと、私が技術書典で頒布した、エンジニアアンチパターンのコラボによって誕生しました。

anchor.fm

誕生のきっかけは、ぜひともポッドキャストを聞いていただければと思います。ワンストップ見積もり本は、見積もりについてひたすら言及する、稀有な本です。10名以上の著者によって執筆される予定です。

宣伝も兼ねまして、見積もりについて少し語っていきたいと思います。

見積もりの難しさ

エンジニアアンチパターンには、「過小見積もりで炎上するプロジェクト」という、見積もりに失敗した話があります。

booth.pm

「おやかた.am」を聞いていて感じたことは、やはり見積もりは難しいということです。IT業界には、徹夜や帰れないといったイメージが、どうしても付きまといます。それらは大抵、無茶な見積もりや仕様変更、想定外の作業による工数の膨らみなどによって、引き起こされます。

  • 予算が足りないので、増員できません。残業でカバーしましょう
  • 納期はずらせませんが、機能は削れませんし、品質も妥協できません
  • ...etc

炎上しうるプロジェクトでは、さまざまな悲劇が起こります。兎にも角にも、プロジェクトは炎上すると辛い目に合います。見積もりは、慎重にやる必要があります。

そこで、見積もりに関する経験、知恵や知識を結集しようという想いで誕生したのが、「ワンストップ見積もり本」です。

SHIROBAKOで感じる、見積もったスケジュールを守ることの難しさ

プロジェクトの炎上はどのようなものかと申しますと、アニメのSHIROBAKOを見てもらうと分かりやすいです。

f:id:konosumi:20181124141034j:plain

「SHIROBAKO」で描かれるのは、アニメ制作の現場です。主人公である宮森あおい(みゃーもり)は、制作進行というポジションのため、スケジュールを管理しています。

アニメ制作には「監督」「原画」「アニメーター」「CGクリエイター」「サウンド」をはじめ、さまざまな役割の人たちが関わっています。そこで、それぞれのスケジュールを調整するために制作進行というポジションが必要です。

しかしながら、このスケジュール管理はとても難儀です。さまざまな要因によって、オンスケから少しずつスケジュールが遅延します。

  • 監督がいつまでも絵コンテに迷っている
  • 制作陣の仲違いが発生して、チームがバラバラになってしまった
  • 少しずつスケジュールが遅れていき、ついには当日ギリギリ納品になってしまう

アニメの制作が間に合わなくても、アニメは枠がありますので放映されます。その場合、すでにできあがっている話を結集した、総集編などが放映されます。実際に、そのような事態に陥ってしまったアニメも、世の中にはいくつもあるそうです。

見積もりを守るためのチームワークとチームビルディング

ワンストップ見積もり本は、主に見積もりを対象とした本です。但し実際には、アニメの「SHIROBAKO」で描かれているように、見積もりその後の制作進行もとても重要です。

見積もった内容をオンスケで進めていくためには「プロジェクトをリードする技術」も大事になってきます。

kakakakakku.hatenablog.com

せっかく見積もりが上手くできたとしても、守れなければ意味がありません。そこで、プロジェクトを開始する段階での見積もり力と、その後のプロジェクトリードの技術が両方とも必要になってくるのです。

さいごに

C95(2018冬コミ)の親方Projectで頒布されるワンストップ見積もり本は、ひたすら見積もりについて語る稀有な技術同人誌です。

どんなにプロジェクトリードが上手かったとしても、最初の見積もりに失敗してしまっては、プロジェクトは炎上します。プロジェクト運営で重要なことは「適正な見積もり」と「プロジェクト進行(リード)」です。

見積もりは大変な作業ですが、その後のプロジェクト進行を左右する重要な工程です。ぜひとも、ワンストップ見積もり本で見積もりの勉強を始めてみませんか?

私も執筆に参加しまして「過⼩⾒積もりで炎上するプロジェクトから得られた学びと実践」という章を執筆させていただきました!

note.mu

MicroSoft To-Doによるプライベートのタスク管理

こんにちは。私のプライベートのタスク管理は、Trello、Todoistと試してきたのですが、「MicroSoft To-Do」についても試してみました。

プライベートをTrelloでタスク管理する - このすみろぐ

Todoistによるプライベート(個人)のタスク管理を始めてみた - このすみろぐ

利用イメージは以下のような感じでして、タスクが完了したらチェックを付けるという、いわゆるスタンダードなTo-Do管理になっています。

f:id:konosumi:20180503142019p:plain

それでは、個々の機能について詳しく書いていきます。

MicroSoft To-Doとは?

「MicroSoft To-Do」は、Wunderlistというタスク管理ツールが元になっています。それをMicroSoftが買収したことで「MicroSoft To-Do」として生まれ変わりました。

Wunderlistのここがすごい!山ほどあるタスク管理アプリの中からWunderlistをオススメしたい6つの理由 – OTTAN.XYZ

Wunderlistにかわるマイクロソフト「To Do」が提供開始 | Lifehacking.jp

位置付けとしては、MicroSoftオフィスシリーズの中の一つであると言っても過言ではありません(注釈:厳密に言うと違います)。

To Do リスト アプリ - Microsoft To-Do

利用料金は無料で、MicroSoftアカウントがあれば、すぐに利用を開始することができます。私は既にMciroSoftアカウントを持っていたので、アカウント登録が不要なのはとても楽でした。

MicroSoft To-Doの使用感

「MicroSoft To-Do」を使ってみた感想としては、とにかくシンプルで、動作がサクサクで、操作は直感的です。

f:id:konosumi:20180503110422p:plain

ここからは、細かい解説をしていきます。

リスト

左ナビに表示されているのは「リスト」です。リストは、タスク(To-Do)をカテゴリ分けするための機能です。

私の場合は「プライベート用のタスク一覧」「ブログ用のタスク一覧」「同人サークル用のタスク一覧」といった具合にリスト分けをしています。

f:id:konosumi:20180503110745p:plain

先にリストを作ってしまい、リストページでタスクを追加しても良いですし、各タスクはドラッグアンドドロップで、リスト間を移動させる事も可能です。

タスクの追加

タスクの追加は「+ To Do の追加」をクリックして、タスク名を入れてEnterを押すだけです。

細かく編集したい場合は、タスクをダブルクリックします。

f:id:konosumi:20180503111121p:plain

私の1日

「MicroSoft To-Do」は、溜まったタスクの中から、今日やるタスクを選んで私の1日に追加するというUIになっています。

f:id:konosumi:20180503111301p:plain

「私の1日」に追加すると、今日の予定リストにタスクが追加されます。

通知

通知によって「To Do」をやり忘れないようにリマインダを送信する事ができます。アプリ版を利用していれば、プッシュ通知として届きます。

ブラウザ通知でも使えますが、アプリ版での利用がメインとなるでしょう。

f:id:konosumi:20180503111713p:plain

期限と繰り返し

タスクには、期限と繰り返しを設定することができます。

f:id:konosumi:20180503112012p:plain

繰り返しを設定した場合は、タスクを完了すると、例えば「毎日」であれば「翌日」のタスクが自動的に作成されます。

メモ

メモは、いわゆるタスクの概要を入れます。Trelloなどと違い、コメントを何件も残すといったことは出来ません。あくまで、タスクの備考欄という位置付けになります。

ステップ

タスクには、ステップを追加することができます。いわゆるチェックリストのようなものです。

f:id:konosumi:20180503112506p:plain

例えば、引っ越しというタスクであれば「引越し業者に見積もりを依頼する」「引越し業者を選定する」「荷造りをする」・・・といったステップが必要になります。技術書を読むようなタスクであれば、章ごとにステップを設けるのも良いかもしれません。

さいごに

機能としては、そこまで凄い機能があるというわけではなく、単純な機能面で見ると、TrelloやTodoistの方が優れています。

ただ、Web版とアプリ版は備わっていて、操作はとても直感的であり、動作もサクサクです。高度なタスク管理をしようと思わないのであれば、とても快適なツールです。

MicroSoftアカウントをお持ちでしたら、アカウント登録も不要です。ぜひ試してみてはいかがでしょうか?

Welcome to Microsoft To-Do

補足:明日の風は明日吹く

やりたいタスクを積んでいって、その中から今日やるタスクをピックアップして消化していくUIが、意外に気に入りました。「明日の風は明日吹く」スタイルで、明日のことは「今日の夜」か「明日の朝」に考えれば良いんです。

プライベートでは綿密なタスク管理はしたくないので、私にはこれくらいが丁度良いと感じました。

Todoistによるプライベート(個人)のタスク管理を始めてみた

こんにちは。私は今まで、タスク管理はTrelloを使ってきました。

www.konosumi.net

Trelloには満足しているのですが、ただ、最近一つ思うことがありまして、Trelloはタスク管理で言うとトヨタのカンバン方式なのです。

プライベートの細かいレベルのタスクを管理するとなりますと、全体を見通すよりも、今日何するといった情報が重要になります。そこで、より普通のタスク管理に近いTodoistも使ってみようと思ってみた次第です。

「エッジのたたないポッドキャスト」や「Rebuild.fm」のポッドキャストでも、Todoistの話題がありましたしね。

noedge.matchy.net

rebuild.fm

試しに使い始めているので、所感を書いていきます。

次の7日間という機能が非常に便利

Todoistは、日付で区切ることを重視したタスク管理ツールです。「今日は何をする、明日は何をする」を整理することに特化しています。

f:id:konosumi:20180427182954p:plain

特に「次の7日間」機能の使い勝手が非常に良いため、週ベースでのやること整理が非常にやりやすいです。

当然ですが、直近7日間だけではなく、翌月や翌々月のタスクを登録することもできます。無料版では使えないのですが、リマインダー機能を活用すれば、タスクを忘れないようにすることも可能です。

日付以外のタスク整理

Todoistでは、主に以下の分類でタスクを整理することができます。

プロジェクト

私の場合は、ブログ活動のためのプロジェクト、同人活動のためのプロジェクト、技術活動(技術力の強化等)のためのプロジェクト、といった具合に分けています。

他にも、趣味プロジェクトであったりとか、●●資格の取得プロジェクトなど、もちろん自由に追加することが可能です。

ラベル

プレミアム版の機能のため使えていないのですが、@メール、@保留、@15分のように、タスクに補足情報を追加するために使用するみたいです。

@(アットマーク)を付けるだけで補足情報を追加することが出来るので、お手軽ですね。Twitterのハッシュタグのような使い勝手と似ているかもしれません。

参考:https://support.todoist.com/hc/ja/articles/205195042

優先度

タスクに優先度を付けることができます。優先度は4段階でして、1〜4までを付けることができます。

f:id:konosumi:20180427184553p:plain

繰り返しタスクの登録が楽である

Todoistを使うと、毎日やる必要がある定型タスクを、簡単にタスク化することができます。予定に「毎日、毎週、毎月」と入れるだけです。お手軽ですね。

f:id:konosumi:20180427185643p:plain

繰り返しタスクは、今日のタスクを完了した時点で、(毎日の場合は)明日のタスクが自動的に作成されます。

使い勝手がとても良いため、これはTodoistで一番の機能だと思います。

カルマというモチベーションを高めるポイント機能

タスクを完了すると、カルマが上がります。カルマは、生産性を表すポイントのようなものです。

f:id:konosumi:20180427193121p:plain

私はそこまでではないのですが、人によってはカルマが積み上がっていくのが楽しくて、それがモチベーションを向上させます。

さいごに

Todoistを使ってみた印象としては、とても素直でシンプルなタスク管理であると感じました。Trelloは全体を俯瞰して見通すことに向いている一方で、Todoistはタスクを管理することに特化しています。

もし抱えているタスク数が少ないのであれば、Googleカレンダーにスケジュールを入れるだけでも十分かもしれませんが、タスク整理や繰り返しタスクの管理がやりやすいので、Todoistはおすすめです。

ラベルが使えなかったりと、プレミアム限定の機能も多いのですが、無料版でも十分管理はできそうです。しばらくの間は、Todoistでタスク管理をしてみようと思います。

認定スクラムマスター研修を受けて、認定スクラムマスターになるまでの感想と知見を共有する

Scrum Alliance(スクラムアライアンス)の認定を受けて、認定スクラムマスターになりました。

f:id:konosumi:20180324160954p:plain

認定スクラムマスター研修は、参加費用もそれなりである代わりに、内容も非常に濃い研修でした。忘れてしまう前に、内容をまとめていきます。

研修の進め方

認定スクラムマスター研修の進め方は、団体や年度によって異なります。「一律的にこれだ!」という決まりが、決まっているわけではありません。

逆に言えば、研修の内容は毎年ブラッシュアップされていくわけです。

私の場合は、唯一の日本人の認定スクラムトレーナー(CST)である江端一将氏が講師を勤め、課題を解いていく過程で知見を得ていく、実戦スタイルでの研修でした。

スクラムを知っている事は前提

研修といっても、スクラムについてゼロから学習していくわけではありません。予め、スクラムについて予習(もしくは実践)していることが前提となります。

そして、スクラムについての予習は絶対にしておいた方が良いです。

  • デイリースクラムとはどのような目的で開催されるのでしょうか?
  • スクラムでは「透明性」「検査」「適応」が3つの重要な柱になります。あなたは知っていましたか?

講義スタイルで進めるわけではなく、実戦スタイルでの研修になります。既に得ているスクラム知識を、補足したり実践するような場所であることを心掛けましょう。

研修は大変、でも実践はもっと大変

研修の間は、ずっと頭をフル回転し続けるような3日間になります。初日は疲れ果ててしまって、研修が終わった後はずっとお酒を飲んでました(笑)。

つらい側面もありますし、大変な研修でもありますが、合理性や論理性をとにかく追求し、チームを正しい方向に導いてくための3日間でした。

研修は「研修よりも、実務はもっと大変です」という一言で締めくくられます。

私も、それはその通りだと感じました。実務では、不足の事態がもっとたくさん発生します。スクラムマスターは、スクラムの奴隷であってもならず、臨機応変に対応できる必要があります。

研修を経て、自分が不得意とする点も見えてきたので、そこは復習しつつ頑張っていきたいと思います。

アジャイルサムライとカイゼンジャーニーで予習する

私は、過去に「アジャイルサムライ」や「スクラム実践入門」を読んでいたのですが、それぞれ研修でも役に立ったように感じます。

www.konosumi.net

今であれば、カイゼンジャーニーを組み合わせてスクラムを学習されるのも良いかもしれません。

  • アジャイルサムライで、アジャイルについて知る(知識編)
  • カイゼンジャーニーで、スクラムの実践的なプラクティスについて知る(実践編)
  • スクラム実践入門で、他社のスクラム事例について知ってみる(事例編)

カイゼンジャーニーは読み物としての側面もあって、純粋に読んでいて面白いです。数時間あれば読めますので、一読されることをオススメしますよ!

(注釈:カイゼンジャーニーはエンジニアの間で話題の書で、私も読みました)

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

さいごに

研修で得た教訓や課題を整理して、実際のスクラム開発を円滑に進めるよう、頑張っていきたいです。カイゼンジャーニーじゃないですが、最初から円満にスクラムがまわるプロジェクトの方が少ないであろうことは、想像に難くありません。

ベースとなる知識があって、それを臨機応変に組み合わせて行けるスクラムマスター(スクラムチーム)は、やっぱり強いです。

・・・でも、「知識」「行動」「マインドセット」が伴ってこそスクラムマスターなのですが、私の場合は行動とマインドセットが鍵でした。

「より良いプロダクトや、スクラムチーム(チームメンバー)のために、スクラムマスターとして頑張ろう!」

そう強く思えるマインドセットこそ、スクラム開発の第一歩なのかもしれませんね。

おまけ:オンライン試験と合否について

認定スクラムマスターの合否は、研修が終わってから、後日メールアドレスに合格者のみ通知されるようです。合格者にはオンライン試験の案内があり、私はオンライン試験を受けました。

  • 制限時間はなく、じっくりと腰を据えて受験することができます。
  • オンライン試験のため、受験場所に決まりはありません。

オンライン試験では「スクラムについての知識」に加えて「こういう局面において、スクラムマスターのあなたはどう行動しますか?」といった実践的な問題も出題されます。

じっくり考えていけば、答えにたどり着ける問題ではあったので、集中できる場所で落ち着いて受験されることをオススメ致します。合格すると、無事に認定証が発行されます。

ちなみに、認定スクラムマスターの合格率は、他の参加者に聞いてみたところ55%程度らしいです。ただ、試験の内容は毎年アップデートされますし、参加者のレベルによってもマチマチでですので、一概には言えません。

生産性を下げないことが重要 - 夢とコーヒーと私(omoiyari.fm ep27)

omoiyari.fmの最新回(ep27)を聴きました。

lean-agile.fm

配信自体は久しぶりなのですが、実は「engineer meeting podcast」も聴いているので、あまり久しぶりな感覚はなかったりします。

www.konosumi.net

主に生産性について話している回です。感想を綴っていきます。

生産性の記事を読んでいる間は生産的じゃない

私はタスク管理に興味があって、生産性やプロダクティビティの話は好きなほうです。プライベートもタスク管理をしていて、その件は過去にブログで書いています。

www.konosumi.net

生産性の話はかなり面白かったです。「生産性の記事を読んでいる間は生産的じゃない」は、まさに名言だと思います。

なぜ名言だと思ったかと申しますと、生産性やプロダクティビティの上げ方は人によって様々なので、あまり参考にならないことが多いのです。

blog.tinect.jp

私の意見としては、生産性を上げる方法よりも、生産性を下げない方法のほうが議論する価値があると思ってます。

ただ生産性をあげたいのであれば、一心不乱に頑張れば良いのです。しかしながら、世の中には様々な進捗の阻害要因があります。「長時間の会議によって進捗が進まない」は有名な話ですが、細かい例だってたくさんあります。

例えば、私は以前に英語学習をパソコンで聴きながらやっていたのですが、それは辞めて、iPodで勉強することにしました。パソコンだと、休憩と称してネットサーフィンばかりやってしまうからです。インターネットに繋げていないiPodであれば、英語を聴く以外にできることはありません。

私の意見としては「生産性は低いと思ったら対策を考えるくらいが丁度良いのかなぁ」と、感じております。

余談ですが、生産性の記事を読んでいる間は生産的じゃないという話は「勉強会に行く時間があったら勉強しろ」という側面に似ていますね(苦笑)。

「うーん、勉強会に出るヒマがあるなら勉強しろって思います」
引用:https://codeiq.jp/magazine/2016/06/42239/

勉強会という言い方にも問題がある気がしていて、勉強会は勉強しに行くのではなく、新しい技術のトレンドを知ったり、交流を目的とする人もいると思います。どのような目的を持って参加するのかにもよりますので、一概には言えないですけどね。

コーヒーの話

私の場合、通勤時間は缶コーヒーを飲みながらポッドキャストを聴くのがほぼ日課です。

スーパーで安い缶コーヒーを買い込もうといつも決意するのに、つい駅の自販機で買ってしまいます。ぐぬぬ、節約しなければ。

会社でもバリスタで入れたブレンドコーヒーを、ほぼ毎日飲んでいます。現状、コーヒーなしの生活が考えられないくらいには、コーヒーにハマっている気がします。

コーヒーを飲んでいる時の、一息つく感じのリラックス感が好きなんですよね。

f:id:konosumi:20171229030419j:plain

夢の話

私も、夢が明確な人には憧れます。改めて「夢は何だろう?」と自問自答してみると、なかなかに迷いますね。

このブログがもっと流行って欲しいとか、早く中間管理職というポジションから脱出したいとか、細かい目標はたくさんありますが、夢と言えるほど壮大ではないです(滝汗)。

子供の頃は電車の運転士になるのが夢だったのですが、完全に夢の彼方に消えて、今は普通にITエンジニアをやっています。

「夢を忘れた大人たち」で、歌詞が書けそうな気がしてきましたよ(苦笑)。

さいごに

新しい機材ですが、音質もクリアで良さげでした。積みゲストにも期待しております!

全く関係ないのですが、私も数年愛用していたイヤホンが断線しまして、つい先日から新しいイヤホンで聴いております。

ただ、ポッドキャストの視聴がメインですと音質にこだわる意味もあまりないため、普通のイヤホンですけどね。

プロダクトマネージャーとプロジェクトマネージャーの違い(engineer meeting podcast vol103)

みなさんは、プロダクトマネージャーという職種をご存じでしょうか?

最近では、プロダクトマネージャーカンファレンスといったイベントも開催されており、プロダクトマネージャーの知名度も向上してきました。

2017.pmconf.jp

一方で、IT業界では昔からプロジェクトマネージャーという職種があります。プロジェクトマネージャーは、情報処理技術者試験にも存在し歴史のある職種です。

www.jitec.ipa.go.jp

実は私も、過去にプロジェクトマネージャ試験を受けたことがあります。

さて、このプロダクトマネージャーとプロジェクトマネージャーなのですが、響きが似ているため大変ややこしいのです。何せ、両方とも略すと「プロマネ」ないし「PM」になります。

私も混乱しているので、ここで整理していきます。

違いをざっと整理する

非常にざっくり整理すると、以下のような特性があります。

プロダクトマネージャー プロジェクトマネージャー
自社開発向け 受託開発向け
プロダクトに責任を持つ プロジェクトに責任を持つ
プロダクトを成功させる プロジェクトを成功させる

これだけだと誤解を生むかもしれませんので、それぞれ解説していきます。

f:id:konosumi:20171208005906j:plain

プロジェクトに責任を持つプロジェクトマネージャー

プロジェクトマネージャーは、QCDを守ってプロジェクトを成功させることが目的になります。具体的には、以下の指標が重要です。

  • Quality(品質)
  • Cost(費用)
  • Delivery(納期)

つまり、開発費用を予算内に納め、期日までに開発し、品質の良いプロダクトをリリースすることが目標になります。

仕様が確定しているような受託開発では、プロジェクトマネージャーが活躍します。何故かと言うと、受託開発には以下の特性があるからです。

  • 受託開発では貰えるお金が決まっているため、費用を超過すれば赤字になってしまいます。
  • 納期や品質を守らないと、会社としての信用を失うどころか、最悪訴訟問題に発展する可能性もあります。

プロダクトに責任を持つプロジェクトマネージャー

プロダクトマネージャーは、プロダクトを管理します。具体的には、プロダクトをより良いモノに改善し、売れるプロダクトを目指すことが目的になります。

ビジネススキルは当然必要ですが、商品を売るためのマーケティングスキル、より良いユーザー体験を提供するためのUI/UXスキル、デジタルサービスであれば、基本的なテクノロジー知識も必要になってきます。

もちろん、プロジェクト内にマーケティング担当者や、UI/UXデザイナー、エンジニアがいることも多いのですが、彼らと会話しながらプロダクトを成功させるためには、幅広い知識が必要になってきます。

しかし、現実問題そんなに幅広い知識を持ったスーパースターみたいな人は、世の中にそうそう居ないと思います。結局のところ、うまくチームをマネージメントしながら、トータルで力を発揮してプロダクトを成功に導くことが使命になります。

マネージメントスキルは、当然ですがプロジェクトマネージャーでも必要です。だからこそ、どちらも○○マネージャーという職種なのです。

スタートアップや自社プロダクトの開発では、プロダクトマネージャーの手腕が試されます。プロダクトが生命線であり、最も重要であるからです。

さいごに

ざっくりとまとめてみましたが、私はプロダクトマネージャーとはミニCEOであると思っています。

会社の利益をあげることがCEOの役割ならば、プロダクトで利益をあげることがプロダクトマネージャーの役割です。そのためには、プロダクトを実際に使っているユーザーの声を聞いたり、UXを改善して顧客満足度をあげたりと、色々なことにチャンレジする必要があります。

正直に申し上げますと、プロダクトマネージャーというのはかなり凄い職種です。

「プロマネはいてもプロダクトマネージャーがいない新規事業の問題点」という記事がありますが、それはある種必然です。プロダクトマネージャーは要求レベルが高いので、簡単になれるものではありません。

diamond.jp

結局のところ、プロダクトマネージャーは多少未熟であっても、会社が育てていくしかないと思ってます。

ようやく日本でも定着してきた職種です。私も経験を積んで、プロダクトマネージャーになりたいですなぁ。

補足:engineer meeting podcast

本記事を書こうと思った理由は、エンジニアミーティングポッドキャストの「vol.103 プロダクトマネージャー・カンファレンス」を聞いたからです。

音声で聞いただけだと忘れそうなので、備忘録という意味も含めてまとめてみました。本記事は、私なりの見解も多分に含んでおりますので、ぜひオリジナルも聞いてみてください。おすすめです。

engineer-meeting.tumblr.com

soundcloud.com

スクラム実践入門で始めるスクラム開発【感想・レビュー】

スクラム実践入門という、技術評論社からリリースされている本を読みました。

スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)

スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)

  • 作者: 貝瀬岳志,原田勝信,和島史典,栗林健太郎,柴田博志,家永英治
  • 出版社/メーカー: 技術評論社
  • 発売日: 2015/03/18
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログ (4件) を見る

スクラム開発という言葉は、IT業界以外ではあまり馴染みがないかもしれませんが、数ある開発手法の中の一つです。

アジャイル開発の中ではもっともメジャーであり、約7割がスクラムを採用しているというデータもあるようです。

約7割がスクラム採用ということになっちゃっています。
引用:アジャイルの採用状況レポート2016の要約

本書は、ソフトウェア開発にフォーカスし、アジャイルの中のスクラムという開発手法について解説した本です。

ソフトウェア開発は困難である

本書がまず述べていることは、ソフトウェア開発は難しいということです。

ソフトウェアは、多くの機能やアルゴリズムによって構成されることが多く、複雑な仕様や設計になりやすいものです。認識違いや仕様変更などによって、手戻り作業を経験された方も多いのではないでしょうか?

また、ソフトウェアはリリースしたら終わりではなく、常に変化していきます。

このように、ソフトウェア開発は変化への対応を常に求められます。そこで登場するのが、スクラム開発という手法なのです。

スクラム開発とは?

従来のソフトウェア開発では、ウォーターフォール型という「仕様策定 => 設計 => 実装 => テスト」を、一本線で行なうスタイルのプロダクト開発が普通でした。

ウォーターフォール型とは、システムの開発を「基本計画」「外部設計」「内部設計」「プログラム設計」「プログラミング」「テスト」という工程に分けて順に段階を経て行う方法です。前の工程には戻らない前提であることから、下流から上流へは戻らない水の流れにたとえてウォータフォールと呼ばれています。
引用:ウォーターフォール型

しかし、このウォーターフォール型は、後戻りをせず一気通貫で行なう必要があります。変化にとても弱い開発スタイルなのです。

そこで登場するのが、スクラムという開発手法です。スクラムは、細かいスパンで設計からリリースまでを繰り返すことで、少しずつ動作するソフトウェアを育てていく手法です。

リリースという区切りが頻繁に発生するため、途中での横槍に強い(変化に強い)という特徴があります。

スクラムチームとは?

プロダクトの開発は、スクラムチームが一丸となって行ないます。なお、スクラムチームには、大きく分けて3つのロール(役割)があります。

プロダクトオーナー

スクラムチームが作ろうとしているプロダクトの最終責任者です。

開発チーム

プロダクトオーナーが要求する順番に従って、実際に開発していくチームです。

スクラムマスター

プロダクトオーナーと開発チームによるスクラムの実行を支援し、スクラムの円滑な遂行を支援するスクラムの推進者です。

なお、上記のロールはざっとした概要の説明になります。詳しい解説は本書をご確認下さい。

スクラムイベント

スクラムは、実際の開発作業とミーティングやコミュニケーションを中心に進んで行きます。

スプリント

スクラムでの開発単位です。1〜4週間のいずれかになることが多いです。スプリントの期間は、チームの趣向や特性によって決定します。

スプリントゼロ

開発環境の整備や、ビジネスモデルの検討など、最初に1回だけ行なう特別な事前準備スプリントです。

スプリントプランニング

スプリントで何をやるかという、計画を立てるミーティングのことです。

デイリースクラム

1日1回15分のタイムボックスで、進捗や予定の共有、問題の共有を行なうミーティングです。一般的には、朝に開催されることが多いです。

スプリントレビュー

スプリントが完了したら、スプリントの成果を確認します。成果物のことをインクリメントと呼びますが、要は動作するプログラムのことです。

実際にプログラムを動かして行ないます。

スプリントレトロスペクティブ

振り返りミーティングのことです。スプリント内で発生した良かった事、悪かった事、改善点などを振り返ります。

スプリント毎に振り返りを行なうことで、チームはどんどん良いチームへと進化していくことが理想です。

なお、上記のイベント概要はざっとした概要の説明になります。詳しい解説は本書をご確認下さい。

スクラムの成果物

スクラムには、3つの成果物があります。プロダクトバックログ、スプリントバックログ、インクリメント(成果物)です。

プロダクトバックログには「○○サイトにログインすることができる」といった、要求事項が書かれています。スプリント毎に優先度の高いプロダクトバックログを取り出し、スプリントバックログとして実際に開発できるレベルのタスクに落とし込んでいき、実装を開始します。

スプリントが終わると、インクリメント(成果物)が出来上がります。Webシステム開発の場合であれば、動作するプログラムが出来上がりますので、実際に動作させて確認します。

スクラムを支えるプラクティス

スクラム開発には、様々なツールやプラクティスがあります。

  • インセプションデッキ
  • リーンキャンバス
  • ユーザーストーリー
  • プランニングポーカー
  • バーンダウンチャート
  • KPT
  • 技術的負債

・・・といったものです。

スクラムには「理解は容易だが習得は困難」という特性があります。スクラムを遂行していると、必ずつまづくことがあります。そんなに時に役立つのが、本書で紹介されているプラクティスなのです。

理解は容易だが習得は困難である

スクラム開発そのものは、理解することは難しくありません。本書も、実際の活用事例の紹介も含めて200ページ前後であり、分厚い本ではありません。

スクラムでは「デイリースクラム」や「スプリントレビュー」「スプリントレトロスペクティブ」といった多くのミーティングを開催するため、コミュニケーションが非常に重要になります。

しかし、コミュニケーションにはトラブルがつきものです。プロダクトオーナーが高圧的であったり、ミーティングの場の空気が重いといったトラブルも想定できるでしょう。

また、スプリントの遂行中に、上司から別件のタスクをお願いされてしまった時はどうすれば良いでしょうか?もちろん、タスクを安易に引き受けてしまっては、目先のスプリントの完了に支障をきたすことになります。

本書には、完全網羅ではないものの、多くのスクラムの活用事例やトラブルシューティングが掲載されています。

読んでみて良書だと感じましたので、スクラム開発を知らない方も、ぜひお手にとってみてはいががでしょうか?

スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)

スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)

  • 作者: 貝瀬岳志,原田勝信,和島史典,栗林健太郎,柴田博志,家永英治
  • 出版社/メーカー: 技術評論社
  • 発売日: 2015/03/18
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログ (4件) を見る

アジャイルとウォーターフォールの違いと使い分け

こんにちは。私は、以前にアジャイル開発を知って以来、アジャイルで開発を続けています。

f:id:konosumi:20171123023832j:plain

私がアジャイルにハマることになるきっかけを作ったのは、アジャイルサムライという名著でした。

ただ、実際にアジャイル開発をやってみた結果、メリットやデメリットが色々と見えてきました。今回は、ウォーターフォール型の開発と比較しながら、考察していきます。

アジャイル宣言

アジャイル開発には、有名なアジャイル宣言があります。まずはご確認ください。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
http://agilemanifesto.org/iso/ja/manifesto.html

それでは、アジャイル宣言に沿いながら、実際に比較検討をしていきます。

プロジェクトメンバー数による違い - プロセスやツールよりも個人と対話を

アジャイル開発は、ドキュメントよりも動くソフトウェアを重視する傾向があります。

つまり、実際には納品をしない仕様書を作り込むくらいだったら、コミュニケーションで仕様を伝達し、ダイレクトに動くソフトウェアを開発していったほうが早いのです。

ところが、プロジェクトメンバーが増えれば増えるほど、コミュニケーションのコストは増大していきます。会議室にメンバーが一堂に会するだけでも、全員の15分が奪われてしまうのです。

コミュニケーションに対するコストが馬鹿にできないプロジェクトの場合、アジャイル開発は不向きになり、ドキュメントによる情報共有の効率のほうが勝ります。

アジャイル型の開発は少人数、ウォーターフォール型の開発は大人数のプロジェクトに適しているというのが、私の印象です。

ミニマムドキュメントという選択 - 包括的なドキュメントよりも動くソフトウェアを

ウォーターフォールのドキュメントと聞いた時に、エクセルの仕様書や設計書を思い浮かべる人はいませんでしょうか?

ウォーターフォールが嫌われやすい理由のひとつに、重厚長大で分厚い本のようなイメージの仕様書があります。ただ、これは仕様書を過剰に作り込んでしまうから発生してしまうことなのです。

現在は、モックアップやプロトタイピングを利用した画面設計が流行っています。

techlife.cookpad.com

最小限のドキュメントで情報共有を図ることが最近の潮流であり「プロセスやツールよりも個人と対話を」とは限らないのです。

これは、アジャイル型開発にも適用できます。アジャイル型開発のコミュニケーションコストの高さを、最小限のドキュメントで補うのです。つまり、アジャイルが定義している問題は包括的なドキュメントにあるので、それさえ解消してしまえば良いのです。

最小限のドキュメントによる効率的な情報共有を、私は強くおすすめいたします。

なお、クックパッド様の開発手法は非常に参考になりますので、ぜひご参照ください。

techlife.cookpad.com

アジャイルな顧客 - 契約交渉よりも顧客との協調を

顧客との協調を強くするためには、アジャイルな顧客が必要になります。アジャイルな顧客とは、平たく言ってしまえば協力的な顧客のことです。

つまり、協力的な顧客を獲得できるのであればアジャイル開発は優位性を持ち、そうでない場合はアジャイル開発の強みは減少してしまいます。

アジャイルは動くソフトウェアを重視しているので、実際に顧客にソフトウェアを触ってもらう必要があるのです。

・・・では、ウォーターフォール型開発の場合は協力的な顧客は必要ないのかと言うと、そうではありません。

ウォーターフォールが嫌われやすい理由のひとつとして、一枚岩の重厚長大なシステム開発によく用いられるので、後半の工程での手戻りが大きいといった理由があげられます。しかし、これは一枚岩だから発生するのです。

ウォーターフォールであったとしても、まずは最小限のプロダクトでリリースしましょうといった取り決めを締結できれば、リスクは抑えることができます。そこから、少しずつ機能拡張していけば良いのです。何も、一度のウォーターフォールですべてを解決する必要はありません。

結局のところ、アジャイルであろうがウォーターフォールであろうが、協力的な顧客は必要なのです。

変化量による違い - 計画に従うことよりも変化への対応を

アジャイルは変化への対応を柔軟にすることを重視します。言葉を言い換えてしまえば、アジャイルは変化が大きいプロダクトに向いているのです。

アジャイルは頻繁に機能を見直すようなスタートアップの自社プロダクトに、ウォーターフォールは変化量の少ない請負や受託開発のプロダクトに向いています。

なぜ、請負や受託開発に向いているかと申しますと、請負や受託開発では、計画の尊守をどうしても求められるケースが多いのです。そういった状況下において無理にアジャイルを回すくらいでしたら、素直にウォーターフォールで開発するという選択もありなのではないかと考えています。

視野を広く持ち、他の開発モデルも知ろう

開発モデルに関しては、以下の「tasuwo blog」様によくまとまっておりますので、ご確認ください。

tasuwo.github.io

ここで私が言いたいことは、一言に集約されます。

「アジャイルはウォーターフォールと比較されがちですが、開発手法はアジャイルとウォーターフォールだけではありません」

参考までに「tasuwo blog」様で言及されている開発手法を列挙してみます。

  • ウォーターフォールモデル
  • プロトタイピングモデル
  • スパイラルモデル
  • インクリメンタルモデル
  • イテレーションモデル

開発手法は、さまざまな開発モデルの中から、取捨選択された結果として検討されることが望ましいのです。

さいごに

私が本記事において言いたいことは、アジャイルサムライの教えと似ています。

今回は、アジャイル宣言に沿いながら比較検討をしてみました。しかし、最も大事なことは、自分の頭で考えることです。

アジャイルを実践してみた結果、コミュニケーションコストの増加に悩まされることもあれば、ウォーターフォールでプロジェクトを進めた結果、手戻りの影響に悩まされることもあります。

結局のことろ、自分のプロジェクトの性質にあったプロジェクト管理手法を選択する必要があります。どのプロジェクト管理手法が合うのかという、絶対的な最適解はありません。

だからこそ、我々は考える必要があるのです。