1日1%成長するブログ

毎日成長するために仕事/プライベートで得た学びをアウトプットするブログです

アジャイル・スクラム開発とは?

スクラム開発の要素

  • プロダクトの要望を優先順位ごとに並べかえ、その順に機能を作る
  • 固定の短い期間(1〜4週間程度)の間隔で開発を区切り、その中で計画を立てる
  • プロジェクトの状況や進め方に問題がないか、メンバー同士で毎日確認し合う
  • 作っている機能が正しいかどうか、定期的に確認の場を設ける

メリット

  • 早めに軌道修正できる
  • 短い期間ごとに開発を区切りその単位で計画を立てていくため作業の工数見積が比較的正確になる
  • 短い期間で最大限の成果をあげる

役割

  • プロダクトオーナー

    • プロダクトの責任者
    • 投資利益(return on investment: ROI)を最大化することに責任を持つ
    • プロダクトに必要な機能を見極め、優先順位順にリストアップし次のスプリントで何をするかを決める
  • スクラムマスター

    • プロジェクトを円滑に進めるための調整役
    • スクラムを説明し効果的な実践を促す
    • 開発メンバーを守ったりして負荷がかかりすぎないようにする
    • 開発メンバーとの兼任の場合もあるが、プロダクトオーナーとは役割が全く違うので兼任はしてはいけない
  • 開発メンバー
    • 実際に開発をするメンバー

スプリントの流れ

  • プロダクトバックログを作る

    • 最初のスプリント開始前に用意する
    • 顧客目線での機能リスト
    • Trelloやホワイトボードやスプレッドシート等に顧客と話し合いながら優先順位をFIXさせる
  • スプリントプランニングミーティング

    • スプリント内で何を作るのか、どれくらい作るのかを決定する
    • スプリント(1-2週間が一般的)内に優先順位順にバックログから棚卸ししたタスクをタスク管理ツールに入れる
    • ツールはTrello, Zenhub等
  • デイリースクラム

    • チームの状況を共有するためのミーティング
    • 毎日5-15分程度の時間で昨日やったことや今日やること、そして行っている問題などを報告する
  • スプリントレビュー

    • スプリントの最終日にはプロダクトオーナーが成果物を確認する場を設ける。必ず動くアプリケーションを使って確認することが重要
  • スプリントレトロスペクティブ(振り返り)

    • スプリントの良かった点、改善すぺき点、そしてその要因と改善策などを各メンバーで議論しあい、次回のスプリントで活かす

今日の1%

プロダクトバックログの優先順位決め➔スプリント毎のタスク決め➔レビュー➔振り返りのサイクルを回すことで、短いサイクルで顧客のフィードバックを受けて本当に必要とされるものを作っていくのがスクラム開発。この全体像を理解していると、クライアントを導きやすい。

仕事が任されやすくなるために毎日意識すべきこと

前提編

良い仕事は良い人間関係から。

明るい挨拶を必ずする

職場で出会った人には必ず挨拶をする。素知らぬ顔をしないこと。 無視された人のことは必ず相手は覚えてます。そして無視するたびにあなたに対する親密度が下がります。

苦手だと感じる人ほど自分から話しかけるように心がける

働いていると、苦手だと感じる人が必ず出てきます。

でも自分で苦手意識を相手に持っていると相手もそれを感じ取って、壁を作られてしまいます。 これを繰り返していると非常に気まずくなりますね。

なので自分からこの人のことが好きだ!と思って話しかけることが大事ですね。

心がけ編

仕事のミスは自分でリカバリーする

自分で犯したミスは自分でリカバリーするという前提で考えること。 必要に応じて人の力を借りるのは大切ですが、あくまで自分が責任を持つと決めることが大事ですね。

仕事に対する労を惜しまない

仕事を頼まれた時にイヤイヤにやらずに、喜んで取り組むこと。 とはいえ、余裕がない時に人から仕事を頼まれると嫌な顔をしてしまいがちなので、 人から仕事を頼まれても大丈夫なようにタスクの予定を立てる時にバッファを設けると良いですね。

周りのために動く

自分にとって利益になるかどうか?ではなく、人やチームのためになることに積極的に動くこと。 人は人のことをよく見てます。自分のためだけにしか動かない人を人は信頼しません。 常にチームや組織にとって利益になるかどうかを判断軸に考えるようにしましょう。

他人を頼る

面倒くさい仕事ではなく、重要な仕事を他人に任せて信頼感を与えること。 自分の担当している仕事を分解して、人に頼めるものがないか?を考えましょう。 自分以外の人でも頼める仕事は積極的に頼っていきましょう。

有言実行する

自分で言ったことは最後まで責任を持ってやり抜くこと。 有言実行することが当たり前になると、どんどん物事が前に進んでいきます。

実践編

期限は厳守が基本

仕事は期限を守ることによって、初めて価値が生まれます。 期限を守ることは当たり前という意識を持ちましょう。

前例を探す

期限を守るためには全て自分ではやらずに、前例を上手く使いスピードアップを意識しましょう。

確認、連絡、報告 (かくれんほう)を行う

自分で情報をあつめ、やり方を上司に提案し、OKをとったら着手しましょう。 そして困ったら即連絡し、解消して仕事を進めましょう。そして完了したら必ず報告し、次の仕事に取り掛かりましょう。

上司の指示を待つのではなく、自分で提案して進めていくプロアクティブな仕事を心がけましょう。

イベントに積極的に参加する

一緒に働いているメンバーとの仕事以外の交流に積極的に参加しましょう。 普段は話せないことが沢山話せて仕事がより円滑になります。

出来たら自分がイベントを企画すると、より多くの人と仲良くなれます。

常に全体の目標を意識する

組織としての全体の目標を常に意識して今自分が何をするべきかを考えて仕事をしましょう。

自分に自信を持てる要素を増やす

自分に自信がある人は意見を堂々と発言することが出来ます。 そのため、自分に自信がない人は自信がない要素を出来る限り無くせるように努力しましょう。 筋トレするとか、ファッションセンスを磨くとか色々人によってやるべきことはあるはずです。

人の悪口を言わない

人の悪口を言う人は人からの評価が自然と下がります。人の悪口を言っている暇があったら、 自分で何とかしようという意識を持ちましょう。

一緒に働く人に関して情報収集する

一緒に働くメンバーのことをよく知っていると、コミュニケーションも捗ります。 何に興味関心があって、何を大切にしているのかを深く知るようにしましょう。

今日の1%

人に頼られる人というのは、生まれ持った才能ではなく毎日の信頼の積み重ねが出来ている人。 集団に貢献しつつ、自分の仕事はきっちりこなすそんな人を目指す。

価値の高い人材とは経営者目線で必要なことを考え、実行できる人

日本全国で400万近い会社がある中で「なぜ自分たちの会社が必要なのか?」を考えることはとても有益だと思います。 自分たちの存在価値は何か?誰に何の価値を提供するのか?これが見えていれば自分たちがやるべき仕事も見えてくると思います。

経営者目線で考えるとは

上記で挙げた自分たちの会社の存在意義は経営者層が本来考えるべき内容です。 経営者は常に考えを巡らせているはずですが、多忙なので出来ないことがとても多いはずです。

そこで現場の人間が積極的に考え動いてくれれば大助かりです。 結果価値が非常に高く評価されるようになるでしょう。

求められること➔自分がコミットできることの順番で考える

会社で仕事をする時、自分が得意なことや好きなことから考えてしまいがちですが まず会社に求められていることから考えるようにしましょう。

そして、その求められることも経営レベル➔部署レベルとブレイクダウンしながら考えられるとなお良いと思います。 次に求められることが見えてきたら、自分がコミットできることを決めてそれを仕事にします。

ここで重要なのはこのプロセスを自分一人で考えず、経営陣や上司と一緒に話して決めるということです。

会社を選ぶ時は

転職などで会社を選ぶ時は、その会社が何の価値を社会に提供していて将来どんな世の中にしていきたいのかを重点的に見るようにしましょう。そこが共感できて、自分がその会社で具体的にどんな仕事をして貢献できるのかが見えていれば、それは幸せな転職になると思います。

今日の1%

  • 価値が高い人材とは、自分たちが社会に提供する価値を認識し、そのために具体的な貢献が出来る人
  • 価値認識➔自分の役割がイメージできていない状態で会社を決めてはいけない
  • 自分で考えるだけじゃなく、経営層の人間と密にコミュニケーションをとって仕事をしていくのが大事

ソフトウェアエンジニアが価値を出すためには毎日どうやって過ごせばよいのか?

f:id:masaru_furuya:20170921201744j:plain

最近仕事をいかに楽しむか?をテーマに色々考えてます。もうかれこれ6年近くエンジニアをしてきているので、ただコードを書くことだけに楽しさを感じられなくなってきたんですよ。

特にフリーランスをやっていると、基本的には手離れの良い作業系の仕事が任されることが多いので自分で仕事を楽しくする工夫を考えるのは必須だと思ってます。

楽しい = 価値を出しているという仮説

価値を出すためには、言われたことだけやってるだけじゃダメなんですよね。それならコードを自動で書いてくれる機械でもあったら、それでいい。

顧客に価値を出すために自分からガツガツ行動しないといけない。 自分で主体的に考えて行動するってこと自体、やりがいがあって楽しいんですよね。

だから結果的に楽しい = 価値を出している状態なんだと思ってます。

そもそも価値って何?

ではそもそも価値って何でしょうか?

自分は価値とは何かの課題を解決することと定義しています。

また価値の種類にはプロフィットコストの二つがあります。 利益を生むものと、時間・費用といったコストを削減するものです。

セールスの新規顧客獲得はプロフィット面の価値、エンジニアの業務効率化ツールの開発はコスト面の価値と言い換えることが出来ます。

価値を出すとは?

価値を出すとは、自分ではなく他人の課題を解決することです。

自分の場合は価値を感じると表現しますよね? それは人やサービスに価値を出してもらった結果というわけです。

なので、価値を出すには相手の課題解決がありきだという前提があります。

ここが理解できておらず、自分は何でこんなに頑張っているのに評価が低いんだ…と嘆いている人は他人の課題をどれだけ解決して価値を出しているのかを省みた方がいいです。

まあ自分も人のこと偉そうに言えないから、この記事を書いて自念しているのですが笑

価値の総量を意識する

価値の総量 = 頻度 ✖️ 大きさ

その人が出している価値には総量があって積み重なっていくものだと思います。 言い換えると信頼残高と言えるかもしれません。

例えば新入社員やインターンが雑務を任されるのは、この頻度を増やすためです。

新人がいきなり大きな価値を生むことは出来ないので、いろんな人の小さな課題解決を積み重ねていくことで価値の総量を増やしていくというわけです。

価値の頻度を高めるには?

ここがエンジニアにとって重要だと思ってます。何故ならエンジニアの仕事はすぐに価値を出せる性質のものじゃないからです。

開発に1か月、成果測定に1か月…と結果が出るまで数ヶ月かかることも珍しくありません。なので、日頃の細かいことで価値を出していくのが大事なのだと思います。

例えば、

  • 開発スピードを上げて、1日に何個も重要なタスクのプルリクエストを出す

  • ミーティングでは事前に内容を把握し着地点を考えておきそのためのファシリテーションを行う

  • 開発メンバーで困っている人がいたら積極的にフォローする

  • 職場の近くの美味しいお店をサーチしてメンバーに共有する

  • 飲み会を企画して他チームとのコミュニケーションの場を作る

  • 他チームに課題ヒアリングしてすぐに解決できることは対応する

とかetc

開発に限らず、複数アイデアは考えられると思います。 自分は現在進行形でここは課題に感じている所なので、改善していこうと思っています。

価値の大きさを高めるには?

価値の大きさを高めることは以下の2つの方向性に分類できると思っています。

  1. 自分で仕事の価値の大きさを高める

  2. 価値の頻度を高め、価値が大きい仕事を任せてもらいやすい状況を作る

1は一見つまらなそうな仕事でもその背景を知り、価値を出すために能動的に行動していくことです。開発の仕事でもこの開発はどんな価値を提供するのか?を常に意識するのは重要なのと同じです。

そして長期的に見て非常に効果が高いのは2です。価値の頻度を高める過程で自分を評価してくれる人は必然的に増えるので、結果的に大きい仕事を任せてもらいやすくなります。

今日の1%

自分で価値を高めること以上に価値を出す頻度を増やすことが重要。 そのために開発以外の領域でも幅広く価値を出して、大きな仕事のチャンスを得られるようにする。

Webアプリ開発プロジェクトの開発開始までに行う5つのステップ

1. 企画書を作成する

プロジェクトの目的と何をするか?を説明する資料

一人で企画を考える場合とチームで考える場合だと、 やり方が全く異なるので、企画段階の話は別記事でまとめたいと思う。

2. ワイヤフレームを作成する

企画書でやることが決まったら、次は画面一覧と各画面に表示する項目と用途を記載する。

画面が決まっていないと開発は進めようがないので、 開発の前にここは必ず決めておかないといけない。

メンバー全員でホワイトボードに図を書きながら書くような場合もあるし、 PMがスプレッドシート等で作成して揉んでいくような進め方になると思う。

3. 工程を細分化する

ワイヤフレームが決まったら作るものは大体決まるので、次は工程を細分化する。 Webアプリの開発だと大体、要件定義、共通設計、デザイン、コーディング、JavaScript、サーバーサイド、テスト、フィードバック修正の流れになるかなと思う。

工程に分けたら、それぞれの工程で漏れが無いようにタスクを分割していく。 これをスプレッドシートに記入して一度チームメンバーに一つずつ共有していく。

懸念事項なども記入したら、これをイシューかチケットに登録して 今後のコミュニケーションを出来る場所を用意する。

4. マイルストーンを決める

工程を細分化しても、そのままだと各担当のタスク量が多すぎて、ざっくりとした見積もりしか立てられない。 なので各画面/機能毎にいつまでに作るか、全体の大まかなマイルストーンを最初に決める。

これによってメンバーもタスクの優先順位が立てられやすくなる。

ここのマイルストーンの立て方がアジャイルウォーターフォールだと違うのかなぁと思っているので、調べて別の記事にしたい。

5. 見積もりを立てる

マイルストーンが決まったら担当者で見積もりを立てる。厳しそうだったら相談してもらう。

今日の1%

  • 1エンジニアやデザイナーとしてプロジェクトにジョインした時も、 プロジェクトマネージャーの視点を持って仕事をすることによって、スピードも質も向上させることが出来る

毎日の仕事を楽しむためのモチベーションマネジメント

仕事って人生の大半の時間を占めてるわけですが、なかなか楽しむのって難しいですよねー。 締め切りに間に合わせることに必死で、楽しむ余裕なんてないやい!って状態に陥ることよくあります。

でもどうせなら日々の仕事を楽しみたい!という訳でどうすればいいのか考えてみました。

仕事が楽しいってどういうこと?

楽しい仕事っていうのはモチベーションが上がる仕事だと思うんですよ。

www.amazon.co.jp

モチベーションの定義はこちらの本の言葉を借りると、 「目標の魅力」✖︎ 「達成の可能性」なんですね。

この2つの変数がより高くなればなるほど、モチベーションが上がる。楽しい仕事だというわけです。

目標の魅力を高めるには?

報酬といっても、お金に限った話じゃないです。 例えば仕事を部下に依頼する時に、仕事に対する期待を明確に伝えることも報酬を高めることに繋がります。 どうでもいいと思われてる仕事よりも難易度が高くても期待されている仕事の方が嬉しいし、やる気が出るじゃないですか。

こういう目の前の仕事の上位にある「なぜやるのか?」を伝えることをラダー効果と呼びます。

www.genkipolitan.com

達成の可能性を高めるってどういうこと?

つまり簡単に達成できそうだなぁと感じられるほど、やる気がでるってことです。 宝くじ1億円が1000万人に1人だったら、買う気しないけど、100人に1人だったら即買いたくなるのと同じです。

1. 今日やる仕事のゴールを設定する

2. 仕事のステップを漏れなく分割する

3. それぞれかかる時間を見積もる

4. 着手して難しそうだったら優先度を考えてマイルストーンを調整する

1-3を朝に行い、着手してからはゴールを意識しながらマイルストーンを調整することで達成の可能性を高めることができます。

まとめ

前述したマイルストーンの設定の上、さらに「なぜこの仕事をやるのか?」の仮説を思考するようにしましょう。

一言で書くよりも、「xxxな人にとってxxxがxxxの理由で不便だったため、これで改善されると、業務が改善されて使える時間が増える」からなように文章ベースで具体的に考えると思考が深まります。可能ならこの仮説を人にぶつけて精度を高めていきましょう。

リモートワークでチーム開発する時に便利なツール・ドキュメントまとめ

Webサービスをチームで開発する時に便利だなと思ったツールや、ドキュメントをまとめてみました。 これからプロジェクトを始める時の参考にブックマークして使ってもらえると、嬉しいです。

プロジェクトの説明資料

  • Googleドキュメントが多いです
  • 作る目的やターゲットユーザー、機能を明記しておきましょう

ER図

  • システムの全体像を把握するために必須
  • 新しくエンジニアが加入した時のために必ず用意しておきましょう

MySQL :: MySQL Workbench

MySQL Workbenchを使うと既存のデータベースをそのままER図に出力できるので、とても便利です。

ワイヤーフレーム & 画面遷移図

  • これは新しく画面を作る時にデザイナーさんと認識を合わせるのに、あると便利です
  • これはGoogleドキュメントやワイヤーフレームツールで作ることが多いですかね

デザイン共有ツール

  • ワイヤーフレームからデザインが固まったらデザインカンプを共有するわけですが、いちいち画像をダウンロードするのは面倒です
  • そこでデザインデータをオンラインで共有できるZeplinというツールがあるのでこれを使うようにしています。

zeplin.io

モックアップ

  • これはデザインの画像同士を繋げて画面遷移を試せるサービスです
  • 実際にサービスを触りながら雰囲気が掴めるので、オススメです

www.invisionapp.com

環境構築手順書

  • これはGithubのREADME.mdやWikiに書いておくことが多いです
  • 新しい人が入ってくる時には必須なので用意しておきましょう

シードデータ

  • Webサービスを最低限動かすために最初から必ず必要となるデータです
  • これが無いと、自分で一つずつデータを入れる必要があるので必須です

自動テスト環境 (CI)

  • 書いたコードが実行できるかを担保する上でテストは必須です
  • ロジックが多めになるサーバーサイドは必ず書きましょう。
  • 自動テストツールとしてはCircleCIが手軽でオススメです。

circleci.com

コード解析ツール

  • コードの品質を保つためにコード解析ツールも必須です
  • 国内だとSideciがオススメです

コードレビュー自動化のためのCIサービス | SideCI

動作確認用サーバー

  • 実際に今作っているサービスを動かして試す環境です
  • HTML/CSSのみの場合と、データ以外は本番環境と全て同じのステージング環境を用意する場合があります

コード共有

  • Githubの有料版ならプライベートリポジトリが作れます。
  • あとはBitbucketやGitlaboが候補になると思います。

github.com

チャットツール

  • Slackで連絡を取りつつ1日1回はappear.inで顔を見ながらビデオ会議が良いかと思います。 slack.com appear.in

タスク管理

開発者同士で使うなら、Trello, Waffle, Pivotal Tracker等色々とありますが、 Slackとビデオ会議で情報共有がしっかりと出来てれば、ぶっちゃけ何でもいい気がしてます笑

trello.com waffle.io www.pivotaltracker.com