DaisukeのITメモ

一人前になる為に。

iOSアプリの開発環境について

目次

概要

iOSアプリの開発環境ツールについて、様々なサイトを見ても結局よく分からない下記観点を簡単に纏めてみた。 - 使用するツールと、使用する理由。 - 環境整備の手順。

必要ツール

  • Mac
    • iOSアプリの開発に必須なXcodeは、Mac上でしか動作しない。
  • Apple ID(いらないかも)
    • 後述のXcodeをAppStoreからインストールするなら必要。
    • Xcodeをxipファイルなどを使用してインストールするなら不要。
  • Xcode
  • Homebrew
    • MacOS上の開発に必要なパッケージ管理ツール。パッケージマネージャー。
      • パッケージのインストール,アンインストール,依存関係などを一元管理してくれる。
        • もし、パッケージマネージャーを使用しない場合:
          • ダウンロードして、インストーラーを立ち上げて、手順に沿ってインストールする、、、という手順を踏む必要が有る。
          • 更に、ライブラリ同士の依存関係などを考慮する必要が有る。
      • パッケージとは、実行ファイル,設定ファイル,ライブラリなどを1つに纏めたモノ。
    • Mac用のパッケージ管理システムでMacPortsというモノも有るが、ローカルに既存のパッケージを考慮せずインストールなどを行ってしまう。一方で、Hombrewはローカル既存のモノを極力使おうとしてくれる。
  • CocoaPods
    • アプリ開発用のパッケージ管理ツール。
      • Homebrewと同じく、パッケージのインストール,アンインストール,依存関係などを一元管理してくれる。
    • Homebrewはどちらかと言うと汎用的パッケージ向け、CocoaPodsアプリ開発用パッケージ向け、らしい。
  • Swift Package Manager(いらないかも)
    • CocoaPodsと同じく、アプリ開発用のパッケージ管理ツール。
    • CocoaPodsの代わりに使用できるらしい(詳細はよく分からない)。
  • Git

環境整備手順

  1. Xcodeをインストール。
  2. XcodeのCommand Line Toolsをインストール。
    • Command Line Toolsとは:
    • Macで利用できるコマンドラインツールの1つ。
      • コマンドラインツールとは:
        • コマンドを入力して操作するアプリケーション、CUIの事。
    • Homebrewのインストール手順に記載の通り、XcodeのCommand Line Toolsが無いとHomebrewをインストールする事ができない。
    • Command Line Toolsのインストール方法は下記の2つ。
      • CUIxcode-select --install
      • GUIXcodeのインストール後、初めて立ち上げた際に下記のようなダイアログが出て来るので、Installを押下。
        f:id:DaisukeInoue:20200930132518p:plain
        XcodeのCommand Line Toolsのインストール
    • Command Line Toolsのver確認方法。
      • Xcode > Preferences > LocationsCommand Line Toolsを参照。
  3. Homebrewをインストール。
    1. 上記オフィシャルサイトの手順に沿ってインストール。
    2. brew updateで、インストールしたHomebrewを最新化する。
      • 定期的に実行して、Homebrewを最新状態に保つのが良いらしい。
  4. Gitをインストール。
    • brew install gitを実行。
    • GUIからインストールもできるようだが、せっかくなら、Homebrewでインストールして管理したい。
  5. CocoaPodsをインストール。
    • brew install cocoapodsを実行。
    • 他にもいくつかインストール方法が存在するが、せっかくなら、Homebrewでインストールして管理したい。
  6. Homebrewでインストールしたツールを最新化。
    • brew upgradeを実行。
      • インストールした全てのformulaeのバージョンを一斉に更新。

所感

  • Macにデフォルトで搭載されているRubyなどの正体がいまいち掴めない。
    • それに付随するGemなどについても要勉強。
  • CocoaPodsなどはインストール方法が複数存在するが、最適方法の選定するにはまだ知識が足りない。
  • HomebrewCocoapodsの使い分けがいまいち掴めない。
  • Command Line Toolsの立ち位置がよく分からない。

WIP:VUCAとは

目次

概要

Agileについて学習した際に、Agileという概念が世の中に必要になった理由が気になった。 その理由に深く関係するVUCAについて以下に纏めた。

Agileとは

daisukeinoue.hatenablog.com

VUCAについて

参考文献

VUCAとは?意味・VUCA時代の対応方法・OODAループを紹介 | | 人事部から企業成長を応援するメディアHR NOTE

Agileとは

目次

概要

従来の(レガシーな)開発手法であるウォーターフォールに代り、デジタルな開発手法Agile開発が台頭している。
そのAgileについて纏めてみた。

Agileとは

VUCAの時代の中で、目的を達成し、その成果を最大化する為の考え方,概念。
ソフトウェアの開発方法論というよりは、ビジネスの作り方らしい。

台頭の理由

下記のように、ウォーターフォールの開発手法と現在のビジネス環境にギャップが生じているため。
ウォーターフォールでは対応しきれなくなってきた。

ウォーターフォールとは

ウォーターフォール開発は名前の通り、水が下に向かって流れ落ちていくように、要件定義,外部設計,内部設計といった各工程を手戻りしないよう進めていく開発手法。

  • メリットとして、システムのゴールや各工程の成果物が明確で、進捗状況が把握しやすいことが挙げられる。
  • デメリットは、前工程が確実に完了していないままに進め、どこかで手戻りが発生すると、多くのコストが必要となる事。
    • 要件定義の大前提が誤ったまま開発を進め、テスト工程になどでそれに気付いた場合、それまでの全工程が無駄になってしまい、0から作り直しという事も。
    • システムの動作を確認できるのは、コーディングが完了する開発の中盤以降となるので、ユーザーからのFBが得られるのは、それ以降の工程。
      • システム利用者の意見を、要件定義や設計工程の段階で全て洗い出す必要が有る。

一方で、現在のビジネス環境は

世の中がVUCAの時代を迎えている事で、企業の方針や取り巻く状況もどんどん変化が速くなり、予測できない未来が次々に訪れている。
スピード感が必要な事業や、Try&Errorを繰り返しながら進んでいく領域では、WhatやHowが最初に完全にfixしている必要があるウォーターフォール開発では対応しきれなくなってきた。
VUCAについては下記記事を参照。 daisukeinoue.hatenablog.com

Agileの前提

WFの様な従来の開発手法では、あらかじめ全ての要求を集め、その為に必要な期間,人員などのコストを見積もる。
一方、Agileでは、「事前に全ての事を正確に予測し、計画する事はできない。」という事を前提としている。
よって、Agileでは、期間や人員を決定,固定し、その範囲内で大事な要求(重要なモノ,リスクが高いモノ)から順にプロダクトを作成する。

思想

下記の様な思想から成り立っている。

  • 関係者は目的達成の為に互いに協力し合いながら進める。
  • 一度に纏めて作るのではなく、小さな単位で少しずつ作成し動くモノを早い段階から届け、ユーザーやステークホルダーからの評価,FBを繰り返し得る事で、作っているモノ自体や計画を調整し、成果を最大化する。

思想の根底

上記の思想は、下記の考えが根底に有る。

  • ソフトウェアを作成する目的は、作成自体ではなく、その先に有る、成果をあげる事(あげ続ける事)。
  • 成果とは、ユーザーやお客様の課題を解決したり、お金を稼ぐ事。
  • よって、何の為に作るか(why)を常に明確にしつつ、現在作成しているモノが本当に成果を実現できているのかをこまめに確認しながら進めていく必要が有る。
  • その過程で、当初作ろうと思っていたモノよりも良いアイディアが出てくればそれを受け入れ、作るモノを変えていく事で、成果の最大化を図る。

実現手法

Agileを実現する為の手法には例えば下記の様なモノが有る。

所感

  • Agile案件の契約形態における制限など有るのか、有るならどのようなモノなのか気になった。
  • Agileが向いている案件,向いていない案件を判断する考え方も気になるので、今後の学習課題とする。
  • AgileとDevOpsの関係性を明確に理解できていないので、今後DevOpsについても自己学習したい。

参考文献

なぜアジャイル開発?ウォーターフォール開発からの脱却 | Qbook

Scrumのまとめ_SCRUM BOOT CAMP THE BOOKを読んで

目次

概要

Scrumについて学ぶ為にSCRUM BOOT CAMP THE BOOK(翔泳社)*1を読み、重要そうなポイントを纏めてみた。

Scrumとは

Agile開発を実現する為の開発手法の1つ。 基本的には、下記の要素から成り立つ。

  • 5つのイベント
  • 3つのロール
  • 3つの成果物
  • 5つの価値基準

5つのイベント

スプリント

目的(存在意義)

他のイベントのコンテナ(入れ物)。

  • 開発期間を最長1ヶ月の繰り返し単位で区切った時の、その1区切りの事。
  • 各スプリントの長さは同じでなければならない。例えば、1ヶ月を4スプリントで構成する場合、5日/スプリントとなる。
  • devチームはこの期間の中で、決められた作業を行う。
  • スプリント期間の大きさは、プロダクトの規模やdevチームの人数,成熟度やビジネス状況などを踏まえて決定する。最短1週間、最長4週間が一般的らしい。
  • スプリント最終日に作業が残っていても、スプリント期間は固定値なので、必ずスプリントは終了し、スプリント期間の延長は行わない。*2
  • 固定期間で区切り、それを繰り返す事で、devチームに集中しやすいリズムが生まれると同時に、全体のゴールに対する進捗把握を用意にしたり、リスクに対応しやすくなったりする。

成果物

  • インクリメント(スプリント終わりにRVしてもらう為の、動くモノ)。

スプリント計画会議(スプリントプランニング)

目的(存在意義)

スプリントを始める前に、下記の項目を決める為の会議。

  • このスプリントで何を作るのか?(What)
  • どうやって作るのか?(How)

下記の様なルールが有る。

  • スプリントの冒頭で実施する。
  • 会議時間は一般的に1スプリント期間の5%分の時間。(1ヶ月/スプリントなら約8h。)
  • 第一部と第二部から構成される。

成果物

  • スプリントゴール(スプリント目標)
  • スプリントバックログ

詳細

(リンク貼る)

デイリースクラム

目的(存在意義)

devチームがスプリントゴールに向かって進んでいるかの進捗を日次で検査する事が目的。 

  • devチームの人数に関係無く、15分のタイムボックスで行い、延長はしない。 
  • 下記の様な3項目をdevメンバー各自が皆に向けて報告する形式。
    • スプリントゴール達成の為に、昨日何をやったか。
    • スプリントゴール達成の為に、今日何をやるか。
    • スプリントゴール達成に向けて、障害となるモノが有るか。
  • もし上記で障害となるモノが有るという話になっても、ここでは問題解決の話をせず、別途その会議を設ける。タイムボックスを守る事が大切。
  • スプリントの残り時間でどの様に作業を進めていくかをPOに報告できる様にしておく。

スプリントRV

目的(存在意義)

スプリントの終わりに、スプリントの成果物(インクリメント)をPOやステークホルダーがRVし、フィードバックを得る事が目的。

  • スプリントレトロスペクティブの前に行う。
  • POが主催し、RVしてもらいたいステークホルダーをPOが招待する。
  • 今のスプリントについて話し合う。
    • devチームは、プロダクトバックログの中でできたモノ,できなかったモノを事前に整理しておく。
    • スプリントで上手くいかなかった事,直面した問題,解決法なども共有,議論する。
    • プレゼンテーション等による説明などではなく、実際に動くモノ(インクリメント)を見せる。
  • 今後のスプリントについて話し合う。
    • FBを元に、プロダクトバックログを見直す。
    • 全体の残作業や進捗を報告し、今後の予定や見通しを共有する。
    • PBL(プロダクトバックログ)に追加すべき項目の有無について議論する。
    • 今後の開発においてボトルネックとなりそうな点について議論する。
    • 現在の進捗を踏まえて、リリース日や完了日を予測する。
  • スプリントRVに使える時間は、1スプリントの約2.5%(1ヶ月/スプリントなら、4h)。

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

目的(存在意義)

  • devチームだけで今回のスプリントを振り返り、下記3点を決めて次に生かす事が目的。
    • Keep(devチームとして良かった点,継続したい点。)
    • Problem(devチームとしての問題点,改善すべき点。)
    • Try(devチームとして次スプリントでの挑戦事項。今後のアクションプラン。) 直近スプリントでの開発活動において、もっと成果を出す為に改善すべき点を洗い出し(検査)、次回スプリント以降のアクション項目を決める。
      また、1度に多くを改善しようとし過ぎると難しいので、Tryは多すぎない方が良い(恐らく、1〜3項目程度)。  
  • レトロスペクティブに使える時間は、1ヶ月/スプリントなら約3h。

成果物

3つのロール

下記3ロールを合わせて、Scrumチームと呼ぶ。

プロダクトオーナー(PO)

プロダクトのWhyとWhatを担当。

何に責任を持つか(何を保証するか)

プロダクト。プロダクトの投資対効果,収益性。

特徴

  • プロダクトの価値を最大化する事が役目であり、その品質に責任(結果責任)を持つ。1プロダクトに必ず1人必要。
  • プロダクトバックログの管理者。PBLの並び順の最終決定権限を持ち、開発によりPBLが完成しているかを確認する。
  • devチームに相談できるが、干渉はできない(直接指示出しなどはできない)。
  • ステークホルダーと協力し、下記の様な事をする。
    • プロダクトのビジョンを明確にし、それをdevチームに共有する。
    • PBLの内容を確認したり、作る順番や実現時期を相談する。
    • PBLの内容をステークホルダーが理解できる様に説明する。
  • リリース計画を定め、予算を管理する。
  • PBLの作成,更新は、devチームと協力してやる事も有るが、最終的な責任は全てPOが背負う。(POが決定した事を他人が勝手に変更してはならない。)
  • devチームが作成したPBLの成果を受入れ or 却下する。

開発チーム(dev)

プロダクトのHowを担当。

何に責任を持つか(何を保証するか)

PBLをスプリント内でどのように実現するか。

特徴

  • POが定めたPBLの項目をその順序に従って開発する。
  • 3~9人が適切。
    • 上記の人数の理由は、下記の様な要因により開発効率が落ちるため。
      • 3人未満の場合は相互作用が少ない。
      • 10人以上の場合はコミュニケーションコストが増える。
  • 全員揃えばプロダクトを作る能力が揃う様に構成されるべき。
    • これを機能横断的なチームという。
    • 特定の作業しかしないチームやメンバーはなるべく作らない。
    • メンバー毎にできる事,できない事は有りつつも、作業を進める過程で、なるべく多くの事をできる様になる事が望ましい(作業を属人化させない)。
  • 肩書きやサブチームは無し。
  • devチームの仕事の進め方は、devチームのメンバーの合意でのみ決定され、外部から指示される事は無い。
    • これを自己組織化と呼ぶ。
    • devチームで主体的に作業を進める事によって、devチームの能力は継続的に向上する。

スクラムマスター(SM)

サーバントリーダーシップ。Scrumの門番を担当。

何に責任を持つか(何を保証するか)

Scrumのプロセスの円滑性。

特徴

  • Scrumのプロセスを円滑に回し、プロダクトを上手く作れる様にPO,devチームを支える。
    • Scrumのルール,成果物(PBLなど),プロセスなどをPO,devチームに理解させ、効果的な実践を促す。
      • PO,devチームが慣れていない内は、各イベントのファシリテートをやったり、先生,トレーナー役として振舞う。
      • PO,devチームが慣れてきたら、必要に応じて作業の補助をしたり、作業のヒントを与えたりする活動にシフトする。
    • マネージャーや管理者ではない(上下関係は無い)。
    • タスクのアサインや進捗管理もしない(devチームのメンバーと兼任の際は例外)。
  • Scrumの外部からの妨害や割り込みからPO,devチームを守る。

3つの成果物

プロダクトバックログ(PBL)

概要,ルール

  • 機能,要求,要望,修正などの、プロダクトに必要な項目のリスト。
  • プロダクトにつき1つ。
  • PBLの項目は、ユーザーストーリー形式で記載する。
    • ユーザーストーリーとは、「〜として、〜ができる。」など。
      • 例)「ユーザーとして、ID,Passを入力してログインできる。」など。
  • PBLは、一度作成して終わりではなく、常にメンテナンスして最新に保つ(項目の追加,削除,並べ替えなど)。
    • 順番は優先度ではなく、明確な優先順位。実現する(したい)順番に上から並べる。
      • その項目が実現された時に得られる価値やリスク,必要性などによって決定する。
      • それぞれの項目は、PBL上で一意の順番を持ち、devチームはその順番に従って開発する。
  • 優先順位上位の項目については、作業工数見積もりを済ませておく。
    • 見積値は、時間などの絶対値ではなく、作業量の相対値で見積もる(基準値に対する相対見積り)。

責任者,作成者,管理者

PO。

作成されるタイミング

スプリント計画会議第一部よりも前。

スプリントバックログ(SBL)

概要,ルール

  • 選択したPBLと、その具体的な作業一覧を合わせてSBLと呼ぶ。
  • スプリントで実現する為に選択したPBLをどう実現するか(How)を具体的な作業として洗い出し作業計画を立てる際(スプリント計画会議第二部)の成果物。

責任者,作成者,管理者

devチーム。

作成されるタイミング

スプリント計画会議第二部。

インクリメント

概要,ルール

  • これまでのスプリントでの成果と、今スプリントで完成したPBL項目を、合わせたモノ。スプリントの成果物。
  • リリースするかどうかに関わらず、実際に動いて、検査可能な状態でなければならない。

責任者,作成者,管理者

devチーム。

作成されるタイミング

スプリント終了時。

5つの価値基準

  • 確約:それぞれの人がゴールの達成に全力を尽くす事を確約する。
  • 勇気:正しい事をする勇気を持ち、困難な問題に取り組む。
  • 集中:全員がスプリントでの作業やゴールの達成に集中する。
  • 公開:全ての仕事や問題を公開する事に合意する。
  • 尊敬:お互いを能力有る個人として尊敬する。

Agileとは

VUCAの時代の中で、目的を達成し、その成果を最大化する為の考え方,概念。

詳細

Agileについての詳細は下記記事を参照。 daisukeinoue.hatenablog.com

Scrumの全体像

f:id:DaisukeInoue:20200823021753p:plain
Scrumの全体像

所感

  • PBLの作成タイミングがいつなのか、明示的に示せなかった(スプリント計画会議第一部よりは前なんだろうけど。。。)。
  • 開発チームの適正人数が3~9人で、10人を超えるとコミュニケーションコストが高くなってしまうルールが、個人的には腹落ちしなかった(そういう研究結果が有るんだろうけど。論文読んでみたい。)。
  • Scrumのルールはテンプレートで、実案件ではこれ通りにはいかない事が多いので、案件毎にカスタマイズしなければならないらしいが、下記2点がどこなのか気になった。
    • Scrumルールの中で比較的テンプレ通りにいきやすい点、もしくは、テンプレ通りをなるべく遵守すべき点。
    • Scrumルールの中で比較的カスタマイズする事が多い点、もしくは、テンプレ通りを遵守する必要性が比較的低い点。

所感に対する追記(先輩方からのお言葉や提供情報など)

PBLの作成タイミングがいつなのか、明示的に示せなかった(スプリント計画会議第一部よりは前なんだろうけど。。。)。

スプリント計画会議第一部より前に、PBL作成用のsprintを設ける事が多いらしい。
sprint0がそれにあたるらしい。 (要勉強

開発チームの適正人数が3~9人で、10人を超えるとコミュニケーションコストが高くなってしまうルールが、個人的には腹落ちしなかった(そういう研究結果が有るんだろうけど。論文読んでみたい。)。

Amazonのジェフベゾスが提唱しているtwo pizza teamの記事が参考になる。

Scrumルールの中で比較的テンプレ通りにいきやすい点、もしくは、テンプレ通りをなるべく遵守すべき点。

Scrumのルールとして明記されているルールやプロセス。

Scrumルールの中で比較的カスタマイズする事が多い点、もしくは、テンプレ通りを遵守する必要性が比較的低い点。

Scrumのルールとして明記されていないようなルールやプロセス。

*1:参考文献:SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発 | 西村 直人, 永瀬 美穂, 吉羽 龍太郎 |本 | 通販 | Amazon。 一部、他サイトからの補足事項アリ。

*2:ただし、状況によって、現在のスプリントでの作業が意味を為さなくなった場合などは、POの判断によってのみスプリントを中断する事も有る。