プログラミング 働き方/生き方

【書評】仕事を4倍早く終わらせる方法!?

ども、チキゾーです。

会社で若しくは学校で、他の人と一緒にプロジェクトをしていて中々予定通り進まなかったり早く進められないと悩んでいる方!

「スクラム」と言う開発手法を使うと仕事が4倍早く終わらせられる・予算内に収まると言われています。

目次

■目次

スクラムの使い方

スクラムに必要なスキル

実際に現在外資IT企業にて、私はプロジェクトマネージャーもしておりますがこの方法を使った所、非常に良く機能しました。

ご存知の方がいらっしゃると思いますが、私は元々プログラマーで開発に従事していました。

今回はこの「スクラム」と言う開発手法についての本の感想と、スクラムの使い方などをご紹介していきます。

スクラムの使い方

小さいサイクルを回していく

最終的に作るものを因数分解して、一番小さい物から作り上げていくべき。

まず最初に小さい物から作り上げる事で、プロトタイプが出来上がって早い段階で見せられるからです。

今までの開発手法はウォーターフォールと言う開発手法でした。

この開発手法は、最初に全てを計画して変更なしで一気に仕上げていくと言う物です。

多くの企業ではこの様になプロセスに基づいてプロジェクトを進行しています。

全体的な長さは3ヶ月から6ヶ月くらいでしょうか。

まず最初に、解決策を提案しどこを改善したら良いのか、どれくらいのインパクトが見込めるかなどを査定します。

その後に技術者が入ってきて必要なものを炙り出します。

計画が終わり次第、技術者は全ての機能を0から作り完成品まで持っていきます。

一見効率的ですが、大体の場合は上手くいきません。

本書の中で興味深かったのはFBIのデータ管理システムのケースで巨額の予算をかけたのにもかかわらず結果的に予算オーバーし大きな遅れが出てしまいました。

この例を本を読むとわかるのですが、問題が幾つかありました。

問題

  • 後で気づいて追加して欲しい場合、変更が難しい
  • 理解が技術者とビジネスマンで違う場合、最後までその違いに気づけない
  • 最初からいつ終わるかの予想が立てにくい

この3つの問題を解決できるのが、「スクラム」です。

基本的には近いプロセスなのですが、1度で全てを仕上げるのではなく分解した小さい物から仕上げていく形です。

この方法を取る事で出来るのは:

ポイント

  • 一回目のサイクルが終わった後、追加事項や変更がかけやすい
  • 理解の確認を何度も行う事ができる
  • 最初の数回のサイクルでスピード感がわかるため、完成の日程が立てやすい

これはビジネスマンにとっても、技術者にとっても有益な事で確認が複数回できると現在の状況が分かりますよね。

しかも、1つの機能が終わるたびにプロトタイプを見る事ができるので感想も受けやすい利点があります。

これを行うために、きちんとしたサイクルを守らなければいけません。

それは:

簡単な流れ

  • 作る物の責任者を決める
  • 横断的なチームを作る
  • 各個人の権限を確認する(商品責任者は最終決定権がある、ビジネスマンはお客さんからの声を集めるなど)
  • 会議の進行役を決める(各ミーティングを効率的にするため)
  • プロジェクトに必要なタスクを因数分解していく
  • 2週間で終わらせるものを決める
  • 計画を立てる
  • 進行具合を見える化する
  • 出来た物の発表を関係者全員にする
  • 改善点を探る

横断的なチームを作る

自分達だけでなく、他の部署の人達や上司などの人も入れるべき。

様々な視点の意見や、必要な機能やお客さんが何を必要としているかなど知る事で優先順位をつけやすいからですね。

上で書いてある横断的にチームを作る、と言う意味は様々な部署の人を巻き込んでチームを作る必要があります。

ここで大切なのは批判的な人も入れる事です。

プロジェクトでは苦手な人や批判的な人を入れると遅くなったりすると危惧する人がいますが、その問題は結局いつかきます。

だったら最初から入れてしまった方が、全体の同意をもらえるので後々問題になりません。

特にその「ややこしい」人が上司や役員の場合、最初から絶対に入れておくべきです。

その他にも、横断的なチームを作る事で、お客さんへのアプローチや感想を集めるのがやりやすくなります。

特に大きな企業はチームが細分化されているため、非常に行い辛いと思いますが全員を含める必要はありません。

チームは大きくても6人ほどにしましょう。

その理由として人が多いとミスコミュニケーションが多くなると言うのが書いてあります。

本書の中では:

((チームの人数)*チームの人数-1)/2=コミュニケーションのルートの数

と言う計算式があります。

これは人が増えれば増えるほど、コミュニケーションが複雑になり大変になると言う事です。

良いチームを作る事で大切なのは各分野のキーパーソンを集める事です。

どうでも良い人はやめましょう。

各個人にそれぞれの役割を与える必要があるので、それぞれに特化した人がキーです。

完成予定日を見積もる

最初は分からなくても良いんです!スクラムを繰り返すうちにわかるんです。

最初の数回のスプリント開発でどれくらいのスピード感で動くかわかる為、2−3週間で現実的な完成予定日がわかるからです。

プロジェクトを始めるときにどれくらいで終わるか、と言うのを聞かれると思いますが、大型のプロジェクトの場合難しいですよね。

と言うか、絶対予想はあってません。

人間は分別は得意ですが、予想は苦手です。

なので、最初に図る必要があるのです。

まず最初にとりあえず最初のサイクルを初めてみると開発の最低ラインが分かります。

そこからは開発が遅くなる事はないので、1週間で終わらせるのがXくらいだとするとY週間くらいかかる、と言うのがわかるのです。

例として、本書の中で上司やクライアントにスケジュールを求められた時は、「とりあえず時間を数週間ください。それで大体の期間が分かります。」

と言ったような返答が書いてありましたので、是非使ってみてください。

この本の良いところはノウハウというよりも、実際にあったケースが多く書かれていたので筆者がどのようにして難しい状態からコミュニケーションとスクラムを使って解決したのか伺う事ができます。

スクラムに必要なスキル

因数分解する力

プロジェクトの一番最初にする事は完成物を見越して、どんな物を作る・タスクを終わらせる必要があるのか知る必要がありますよね。

最初に因数分解しておく事で、優先順位付けとプロトタイプの確認のみにエネルギーを使えます。

スクラムを行う上で必要なスキルの1つとして、因数分解する力が必要です。

イーロンマスクも「物理の第一原理を使え。」とどっかのYouTubeビデオで言ってましたね。

コンサル系の仕事にも似たフレームワークがありますが、問題を砕いていく力がスクラムが成功するかどうかを大きく左右します。

車を例にとると、新しい車をデザインする際に必要なのは:

メモ

  • ロゴデザイン
  • ライトの設計
  • フェンダーのデザイン
  • バンパーのデザイン
  • 内装のデザイン
  • などなど

細かいパーツがたくさん出てきます。

ただこれを1週間、もしくは2週間ほどでできる量に区切って制作し、フレームにつけていく事ができれば進行具合が分かりやすく、感想や変更点もあげやすいですよね。

このように分解せずに全てやろうとするとほぼ確実に失敗します。

そして最初に全て分解する事で、残りは作る事のみです。

この方が毎回消費するエネルギーは低く、各個人も自分の役割に集中できます。

コミュニケーション力

技術的な難しさや専門用語など、誰でもわかりやすい様に説明できる様にならなければいけません。

チームに様々な人材が揃っている為、一番わかりやすい言葉でないと理解できないからなんですね。

スクラムはチームです。

チームでコミュニケーションが取れないと上手くいきません。

技術者でもきちんと分かりやすい言葉で、潜在的なリスクやどれくらい掛かるかなどの説明ができないと期待値のコントロールが非常に難しくなります。

説明するのも大切ですが、聞く姿勢も同時に大切です。

わからなければ質問し、理解に努めましょう。

会議の中で知ったかぶりをする人がいますが、スクラムの場合個人に大きな役割と責任が伴う為極限まで不明な点は無くす必要があります。

私の経験で技術者の方は説明が苦手な場合があるので、練習として技術的な事を子供でもわかるように説明するのがオススメです。

そして、ビジネスマンの方も最低限の技術が分かるようウェブサービスの事やプログラミングを知っておく事が大切です。

無駄をとことんなくす努力

会議ではそのプロジェクトの事にのみ集中しましょう。

時間が限られており各部署の人間も関わる為、取れる時間は結構少ないからです。

本書の中にもあるとおり、会議は2−3時間ほどの物から15分と短い事があります。

スクラムではその時間以上には絶対に使わないというルールがあるので、無駄な話を無くす為に議題が常に決まっています。

1日15分の会議(デイリースタンドアップ)例をとると:

  • 昨日何をしたのか?
  • 今日何をするのか?
  • 何か解決しなければいけない問題があるか?

その他にも様々な会議の議題や例が紹介されており、そして様々な実際のシチュエーションと共に書かれているので自分の状況にあった物は必ず見つかると思います。

私の場合IT企業に勤めておりますので、多くの例が実現可能でした。

今、プロジェクトマネージメントでお悩みの方には良い本だと思いますので是非読んでみてください。

-プログラミング, 働き方/生き方
-,

Copyright© チキゾーブログ , 2020 All Rights Reserved.