Work Tips

This slide is based on the knowledge I have gained from my working experience in IT.

The technical content is intended for IT newcomers,
and I have left terminological accuracy behind in order to give you a somewhat good understanding of the subject first :-)

Transcript

1. © 2025 north-lion https://github.com/north-lion WORK TIPS IT業務に役立つかもしれないコラム集
2. © 2025 north-lion https://github.com/north-lion 参考までに、いくつか原因と対策（実践例）を挙げます。 原因① 集中力不足（長時間の連続作業、定時後作業、急ぎの対応） ⇒対策 修正終えて保存したら、時間をおいて見返す。 ※数時間後や翌日など、万全なコンディションで行うのがミソ 原因② 複数文書にまたがって作業が必要 ⇒対策 一つミスを見つけたら、再度全部の文書を同じ観点で見返す。 見つけるたびに、なくなるまで繰り返す。 以上の作業を「余裕があれば」、「バックアップ(予備)工数」などと して捉えるのではなく、必要な作業として予め工数に含めて作業にあ たってもらえると、優秀な担当職に一歩近づきます。 #1.ミスを減らすにはどうするか？ • 傾向と対策 目で追うだけでは絶対に見落とす！自分の目を過信しない 特にExcelの文章はスペルミスや間違いに気づきにくい。 ① 便利なツールが使える環境なら、ツールを利用しないともったいない 文章をコピーして、テキストエディタに張り付けると気づけるかも。 ➢ 同じような文字が並んでいる文章は、規則性のある文字列を見つけることができれば、 検索機能を使って検索をかけると一目瞭然（画像の例ではフルーツがフルーソになっている！）。 ➢ 修正前後の文章の比較であれば、VS Codeの機能やWin Mergeが便利 VS Codeの方が一々ファイル保存しなくとも比較可能なので、ちょっとした確認には向いている。 VS Code テキスト比較操作キャプチャ ② 周りを気にしなくて良い環境なら、声に出しながら対象文章を読んでみるのも良い （いわゆる指差呼称。ITの場合、指ではなくてマウスカーソルだが…） • まとめ 必ず作成後に全体的にチェックをする。「チェック」をする時は目以外も動かす。 サクラエディタ VSCode なぜドキュメントの記載ミスは起きるんだろう？ ミスは起きるもの。原因を挙げてもキリがない ので、ミスをどう減らすかを考えよう なるほど。（真面目な人は時間を作って「なぜな ぜ分析」をしよう） 今回はとくにありがちなドキュメントの記載ミス に焦点をあてて考えていくよ ※出演者：コトネ（挿入アイコン.人物の切り絵）
3. © 2025 north-lion https://github.com/north-lion #2.発想の転換（報連相編） 今回の話は、退屈な話になるかも というと？ 技術的な話ではなくて、取り組み方の持論みたい になるから • 起 改めていうと、フリーランスでもない限りは、同じ組織の上司足り得る人は、若手にスキルは求めていない。 試しに聞いてみたら「報連相ができる人」とか「コミュニケーションが取れる人」みたいなことをいうと思 われる。 • 承 間違ってはいないが、ただ「大事だからする」と思ってやっていると、形式的なものになる。 “報連相”とか”コミュニケーション”という言葉自体が便利な言葉で、肝心なのは「他の人に伝わるように話 せること」とか、「相談した結果などのメモを取ること」ができる人だと思う。 • 転 実は、報連相を重要視するという考えは、日本人は特に顕著。日本人である以上は、この仕組みにもれなく 組み込まれてしまう。この文化が不得意な人は、発想の逆転をして欲しい。 「何のために報連相するのか？」。答えがなければ、まずは自分のためにしよう。 例えば、 自分のためであれば、伝える努力やメモを取る意欲が沸くなと思った人。良い感じです。 苦手な人はやり過ぎるぐらいが丁度良いですが、闘争心が先走る人は喧嘩腰にならないようにだけ、気を付 けてもらえると助かります。 • 結 日本の「推し量る」、「汲み取る」といったコミュニケーションとは反対に、海外では「何事も明確に」、 「細かいことでも文書化(証跡を残す)」することが好まれます。 肝心なものとして挙げた「他の人に伝わるように話せること」、「相談した結果などのメモを取ること」と いうのは、言葉は違えど、海外の考えにもマッチしているように思えます。 実は（２回目）、SEの上流工程ほどこのスキルは必要です（要件定義、設計など）。 考え方の参考までに聞いてくれればと :) ・自分が責任を取りたくないために、作業範囲の確認をする。 ・自分の作業（＝時間）を無駄にしたくないために、確認を取る。 ・自分の作業実績に文句をつけられないよう、理由を準備し報告する。 What is Ho-Ren-So? ※出演者：タイチ（挿入アイコン.人物の切り絵）
4. © 2025 north-lion https://github.com/north-lion 「前談」 見積はあくまで見積 見積と実績の完全マッチは不可能。 どこまでもいっても、どれだけ現実と の差を埋めることができるかの勝負。 ★ただし、 「見積はあくまで見積という考え ≠ （ﾉｯﾄｲｺｰﾙ）工数に責任を持たない」 ということに注意されたし。 #3.考察（内向けの工数見積） どうやったら想定工数と実工数がマッチしていく んだっけ？？？ 実際に考えてみた。 ここでは区別のために、案件の発注金額に係る見 積を「外向けの工数見積」、開発内における各作 業の見積を「内向けの工数見積」とします。 • 各工程共通のポイント（要件定義除く） 原則、不明確な部分が無い状態で工数を見積る 不明点がある状態では正確な工数も見積もれないし、作業着手も待った ✓ 以下を工数に含めて見積もること ⚫ 不明点の確認/機能要件（どんな処理をさせるのか）の把握 ⚫ 作り終えた後に、成果物を見返す時間を作る つまり、提示した工数をまるまる使って「ドキュメントに実際に手を加える作業が終わる」 という見積は既にアウト！ということ。 ✓ 上記を行った上で着手開始。さらに、 ⚫ 作業中に不明点がでてきたら･･･ ⇒ すぐに確認を取る ⚫ 作業中に不安な所(これで良いのか？)がでてきたら･･･ ⇒ 中間報告的にすぐに認識合わせを行う。 どちらも、見積時点で「しっかり決まっていなかった部分」になるため、最重要事項。 場合によってはリスケが必要になる可能有なので、聞く内容を整理した後、なるはやで確認を取る。 ✓ 以上のことから 1日(約8時間)の間に複数作業を詰め込むのは得策ではないと考える(特にアジャイルでは)。 原則、１作業最低工数１日と考えておくのが精神衛生的に良い。 ※出演者：タイチ（挿入アイコン.人物の切り絵） Other. 仕様書作成のアドバイス 特に、仕様書を作るのに時間がかかる人/実装のイメージをするのが苦手な人向け ★最初から公式な設計書に手を加えない。綺麗な設計書を作ろうという意識は捨てる。 正式ドキュメントに落とす前に、テキストファイルなどにラフな設計書を書く。 ⇒そして、それを１回目の認識合わせや正式ドキュメントへ落とし込むベースに使う。
5. © 2025 north-lion https://github.com/north-lion #4.よく使うショートカットキー Ctrl Z ＋ Alt A ＋ 直前のコード修正を取り消そうとしたら、行ごと 消えたんだが ——— ？！ あるある。 同じ操作でも複数のショートカットキーが用意さ れていたりするよね。 改めて普段よく使うものを整理してみようかな。 Ctrl A ＋ C ＋ Ctrl V ＋ Ctrl Y ＋ Ctrl S ＋ Ctrl F ＋ Ctrl R ＋ ソフト共通（きほんてきに） 全選択（フォルダ内のファイル、表示中のテキストなどを） ＜allのA＞ コピー(選択中のファイル/テキスト/図形などを) コピーしたものをペースト（効率重視型） ※Ctrl + Pでもできるが、マウス片手で握ってると割と使わない Ctrl 操作取消（一つ前の状態に戻す） 操作戻し（操作取消の戻し) Ctrl + Shift + Z（効率重視型）のときもある。 ※Ctrl + Y はキーが離れていて指がつりそうになるので、使えるときは後者の方が好 編集中のファイル保存 ＜saveのS＞ 検索メニュー表示 <findのF> 置換メニュー表示 <replaceのR> サクラエディタ Alt M ＋ Excel （テキスト全選択状態で）昇順ソート <replaceのR> （テキスト全選択状態で）重複行のマージ ※マージ前にソート必須 <mergeのM> Ctrl Page Down ＋ 右隣のシートへ移動 Ctrl Page Up ＋ 左隣のシートへ移動 Excel/パワポ/drow.io Ctrl D ＋ (選択中の図形を)複製 Windows Windows R ＋ [ファイル名を指定して実行]ダイアログ表示 ◆ cmd：コマンドプロンプト起動 ◆ calc：電卓起動 ◆ control：コントロールパネル表示 ◆ excel：エクセル起動 ◆ powershell：パワーシェル起動 ショートカットキーを駆使すると作業効率が良くなるかも？ 一気に覚えようとはせず、忘れたら見返す。を繰り返すと自然 と手が覚える。 Windows Shift ＋ ＋ S スクリーンショット (画面キャプチャ)メニュー表示 Ctrl Home ＋ シートの左上セルへ移動 ※Windowsキーには ではなくて が印字されていることもある ｽﾀｰﾄ opt
6. © 2025 north-lion https://github.com/north-lion #5.理解した気になるTEACHING（DOCKER編） ③ Dockerコンテナ：保存したDockerイメージは「ラン(run)」することで、スナップショットを撮った時点の環境 を再現する。この環境は、Dockerコンテナという箱の中で稼働している。 ※Dockerをインストールしているホストマシン(母体)とは別に、論理的に分離された領域にコンテナという形で 環境が作られる。Dockerコンテナ ≒(ニアイコール) 仮想マシン。 ➢ 制限 あくまで論理的に分離しているだけなので、CPUやメモリ、ストレージはホストマシンに依存する。 Dockerイメージはストレージが許す限り複数個保存できるし、DockerコンテナはCPUやメモリが許す限り複数個同時 で稼働させることができる。 ➢ ここまで聞いて、Dockerを使うと何が嬉しいのか？ ✓ ホストマシンとは分離された領域に仮想マシンを構築するので、個々人の端末に左右されない動作環境およびア プリケーションを提供できる。 ✓ Dockerイメージ、Dockerコンテナといった単位でアプリケーションを維持できるので、管理が楽。 ※今回は割愛するが、docker-composeという、複数のコンテナを効率良く管理するためのツールもある。 業務でDocker（ドッカー）を使うらしい。ところ でDockerって何？ もはや普及されつくした技術、Dockerについて ざっくり説明するよ • 導入 はじめに、Dockerはプラットフォーム（サービスやシステム、ソ フトウェアを動かすための基盤）である。 Dockerの第一印象といえば、画像検索してもらうと分かる通り、 背中にいくつもの箱(コンテナ)を背負ったくじらである。実はこ のコンテナ一つ一つには、アプリケーションを実行する環境が詰 まっているのだ･･･！ ➢ アプリケーションを実行する環境とは？ 理解するには、最低限３つの用語を知る必要がある ① Dockerファイル：Dockerイメージを作成するための指示書。指示 書には以下のようなことを記載する。 ② Dockerイメージ：Dockerファイルの指示に従って「ビルド (build)」すると作られる。ビルドの内容を簡単に説明すると、環境 を組み立て、組み立てた環境のスナップショットを撮り、Dockerイ メージとして保存する。といった動作が行われる。 ※この時、組み立てた環境はDockerイメージを作るための一時的な ものなので、撮り終えたら削除される。 ファイル名は「Dockerfile(拡張子無)」で作るのがスタンダード • ベースイメージ（≒OS） ※実行基盤。DockerHubという所に公開されているので、 使用用途に合致したものを利用することになる • 使用するツール • セットする環境変数 • OSに載せるファイル ※javaであれば、warやjarといったビルド成果物を載せる Docker Container Dockerfile # OS FROM amazonlinux:2 # Tool RUN yum –y install aws-cli # Environment Variable ENV HOGE=“huga” # File Copy from Local COPY ./application.jar / ENTRYPOIINT [“java”, “- jar”, “application.jar”] Docker Image build run 補足 ・DockerはLinuxカーネルありきの技術なので、DockerをインストールするホストマシンはLinux系OSであることを前提としている。 ・では、Windowsでは使えないのかというと、WSL(Windows上でLinuxを動作させる機能)を有効化することで、WSL経由で使用可能になる。 ・UbuntuやDocker Desktop(2021年に商業利用は有償化しました)の裏では、バックエンドでWSLが動いています。
7. © 2025 north-lion https://github.com/north-lion Gitの世界 #6.理解した気になるTEACHING（GIT編） Gitってファイルの変更履歴を管理できる便利 ツールっていうふわっとしたイメージしかないけ ど、他に何ができるの？ Gitってやれることが多くて、開発にとって必要 な様々な機能が提供されているんだ。 GitHubやGitLabといった製品は、Gitを操作する ためのGUIの提供を始め、SNSみたく世界の開発 者と繋がることができたりなど、より開発を発展 させるための独自機能を提供してくれているよ。 ローカル リポジトリ リモート リポジトリ サーバー PC プッシュ コミット Version.6 コミット Version.5 コミット Version.4 コミット Version.3 ~ main develop feature プル ブランチ ◆ 用語 ⚫ リポジトリ：ファイル置き場。ことIT業務においては、複数人でソースコードを共有＆作業するために使うため、 サーバー上で管理する。区別のために、サーバー上に作成したリポジトリをリモートリポジトリと呼び、サーバー からローカルに複製(クローン)したリポジトリをローカルリポジトリと呼ぶ。 ⚫ Pull（プル）：リモートリポジトリの更新をローカルリポジトリへ反映する ⚫ Commit（コミット）：リポジトリおよび作業ファイルのセーブポイント。コミットという単位で作業記録が残り、 前回コミットとの差分比較や、過去時点のファイル状態の復元などができる。 ⚫ Push（プッシュ）：ローカルリポジトリの状態をリモートリポジトリへ反映する。コミットしただけではリモート リポジトリへ反映されないので、リモートリポジトリへ反映すべきものはきちんとプッシュすることに注意。 『公開する』という意味を込めて、Publish（パブリッシュ）ともいう。※個人的にはこの呼び方の方が好き ⚫ Branch（ブランチ）：ある時点のリポジトリの状態を複製し、複製したものに手を加えていきながら開発を行う。 この複製したものをブランチという。ブランチを作るときは、『ブランチを切る』という。ブランチを上手く利用 することで、開発～リリースまで一元管理することができるなどのメリットがあったりする。 ⚫ Merge（マージ）：あるブランチに対して、別のブランチの変更内容（修正ソース）を統合すること ◆ Git運用 ➢ 「ブランチをどう使うか？」という運用ルールをブランチ戦略と呼ぶが、考え方の基礎となるものがなくては立 ち行かない。そこでGitフローという、某氏が提案したブランチ戦略を基本とすることが多い。 ➢ 普通、ブランチの運用ルールを決める際に、コミットルールというものも同時に決める。 コミットする際に、コミットメッセージというものを書くことができる。この記載の仕方にもルールを設けるこ とで、チームとして統一感のある、洗練されたリポジトリ運用をすることができる。 具体的なルール例については、（補足資料）Git運用の基本にて補足します。
8. © 2025 north-lion https://github.com/north-lion #7.理解した気になるTEACHING（GIT編 EXPANSION） チームでGitを利用したら、是非活用したい機能 がある。Git自身が持つ機能ではなく、GitHubや GitLab等で提供している機能だよ。 ⚫ Branche Protection Rule（ブランチ保護ルール）： ブランチに対するルールを設定できる機能。組織開発用に機能拡充された特殊な利用プランを除き、通 常のGitHubにおいてはリポジトリの作成者のみが作成可能な設定。 イメージを沸かせるために、どんな内容が設定できるかの一部を載せます。 ⚫ Issue（イシュー）： プログラム内にバグや、要改善部分が見つかった時に、イシュー（日本語で”課題”の意）を作成するこ とができる。プルリクと同じようにソースコードを指示してコメントを残したり、共同開発メンバー間 でメッセージを送りあうことができる。 ✓ GitHubで公開されているOSSで、課題が数年間オープンのまま残っているようなリポジトリを見ると、 「メンテナンスされていない」という印象を受けるのもまた事実。 但し、無償で使わせてもらっている立場であれば、文句を言ってはダメです。 Gitの基本知識を前提とした内容になります。 「#6.理解した気になるTeaching（Git編）」を先 にお読みください。 また、GitHubを例にあげて説明をします。 ◆ 機能 ⚫ Pull Request（プルリクエスト）： 絶対に利用するといっても過言ではない機能。例えば、feature ブランチで開発した内容をdevelopブランチへ反映（マージ） したい時に、反映して問題ない内容かどうか、チェックを依頼 する機能。要はレビュー依頼。※プルリクとか、PRと略す。 ➢ レビュワーも変更内容をコンソールから確認でき、指摘したい ソース行を指示してコメントを残すこともできるので、レ ビュー関連のやり取りがとても楽になる。 ✓ ブランチに対しての操作を何も制限しない状態だと、誰でも自 由にマージできてしまう。なので、基本的に「ブランチ保護 ルール」という設定を併せて作成し、承認されないとマージで きないように制限をかける。 プルリクエスト操作キャプチャ ①.保護対象のブランチを指定（Google翻訳) ②.適用ルールを選択式で設定（Google翻訳)
9. © 2025 north-lion https://github.com/north-lion #8.開発していく中で得意なものを作る • 開発工程 ※実際、どの工程で何を作るかはその時々による 1. 要件定義 ➢ どういったシステムを作るかユーザーと会話、仕様検討 2. 基本設計（Basic Design） ➢ ドキュメント系の作成（インターフェース仕様書、機能仕様書、システム構成図、CRUD図など） 3. 詳細設計（Detail Design） ➢ 詳細設計書、クラス図、シーケンス図 4. コーディング ➢ プロジェクト/クラス（ソースコード）作成 5. 単体テスト（Unit Test） ➢ 単体テスト仕様書作成、テストクラスの作成、単体テスト実施 6. 結合テスト（Integration Test） ➢ 結合テスト仕様書作成、機能テスト、疎通テスト 7. システムテスト(System Test) ➢ シナリオテスト（≒一気通貫テスト）、性能テスト、負荷テストなどの非機能要件面のテスト 8. 本番リリース/ローンチ ➢ 配信手順書作成、本番環境へのデプロイ、初稼働確認 9. 運用保守 ➢ エラー監視、障害復旧作業、機能改善提案など 改めて、ITって知っているか知らないかの世界だ よね。 そうだね。新しいサービスやツールは続々と出て くるし、例え何十年やっていたとしても「おおよ そ全てのものを知っていて、扱うこともできる」 というのは、ITマニアでもない限り不可能だね。 じゃあ、知らないものは「知らない」といっても、 変なことではないよね？ 技術的なものについてはYesだけど、それ以外の 決まり切ったこと（お約束）は知っておこう。 例えば、開発工程はどの現場でも大体同じだね。 ニュアンスは似てるけど、言葉本来の意味から考 えると微妙に違うもの、「広義の意味では～」や 「狭義の～」とか、いざ定義しようと思うと結構 難しかった…。そんな感じなので、間違っていて も恥じずに、伝われば良し！ あとは、色々ある工程の中で、 何か一つでも『これは得意です』といえるものを作ろう。 システム構成図の作成マスター、テストクラスの作成マ スターなど、どんなに小さい単位でもOK。 完ペキに作ろうとするのには必然的に「システム/機能に 対する理解」と「PM/PL/TL達との対話(※) 」が必要。 思考力が鍛えられて、視野が広くなるよ！ ※PM = プロジェクトマネージャー, PL = プロジェクトリーダー, TL = チームリーダー 出演猫：Pusheen（挿入アイコン.ステッカー）
10. © 2025 north-lion https://github.com/north-lion #9.雑学（IT界に生息する生き物） 著名なツール/サービスにはキャッチーな名前が つけられたり、ロゴ（キャラクター）が存在する その由来を知ると、開発者の生活環境やツールへ 込められた想いなどが透けて見えたりする。 今回はそんなIT界に生息する生き物達を調査する 独特なロゴは印象に残りやすいね。ついでに、 「どういうものか」も簡単に知っておこう。 <カエル> (JFrog) モビードック (Docker) <ニシキヘビ> (Python) <タヌキ> (GitLab) オクトキャット (GitHab) <雄猫> (Tomcat) <キュウリ&ピクルス> (Cucumber & Gherkin) gradlephant (Gradle) <ジャワコーヒー> (Java) <モカコーヒー&チャイ> (Mocha & Chai) 開発言語 ソース管理・共有・公開 アーティファクト管理 ※アーティファクト= JFrogにおいてはビルド成果物のこと 仮想化 (実行環境のコンテナ化) テストツール サーブレットコンテナ ビルドツール ※キャラクター名不詳のものは括弧（<>）書きで和名を記載。 ここで紹介するのは一部なので、興味を持ったら他にどんなキャラクター（ツール）が存在するのか、是非見つけてみてほしい。
11. © 2025 north-lion https://github.com/north-lion #10.考察（外向けの工数見積） • ざっくり指標 ✓ 一般的に1人でがんばって1人月で開発できるステップ数は1,000Stepといわれている。 ✓ 小規模開発(1,000Stepの完全新規機能1つのみ)とした場合の工程別工数割合（※筆者の概算） • 主な見積に必要な要素 ◆ 実績（似たような機能の開発実績があれば見積精度が上昇） ◆ 開発の種類（新規開発 or 流用開発 or 保守開発 etc.） ◆ 開発機能数 ◆ 機能毎のStep数概算(小規模：1KStep, 中規模：3KStep, 大規模：5KStep ※テストクラス込) • 例）開発機能数：完全新規4機能(1機能1,000Step)の場合 前回、「内向けの工数見積」について考察したけ ど、「外向けの工数見積」はどのように見積もっ ているのか、ざっくり知っておこう。 おさらい。 案件の発注金額に係る見積を「外向けの工数見 積」、開発内における各作業の見積を「内向けの 工数見積」とします。 案件の受注があってこそだから、知っておくと少 し考え方が変わるかもね。 用語確認 まずは用語の確認をして、その後ざっくり指標を 提示するよ。 用語 意味 工数 作業量のこと。以下で記載する〇人月、〇人日といった単 位で表す １人日 1人が1日で完了できる作業量 １人月 1人が１か月で完了できる作業量。 例えば、３人で作業して２か月で終わる作業量の場合、 「3人×2か月 = 6人月」となる。 ※一般的に１か月 = 20人日 ステップ数 ソースコードの行数。1,000ステップの場合、1KStep（キ ロステップ）とも書く 基本設計 10% 詳細設計 19% コーディング・UT 31% IT 20% ST 20% 工程別工数割合 基本設計 詳細設計 コーディング・UT IT ST [コーディング・UT]：4機能×1,000Step = 4人月 [基本設計]：9.8% × 5人月 / 31.4% = 1.25人月 [詳細設計]：19.6% × 5人月 / 31.4% = 2.5人月 [IT]：19.6% × 5人月 / 31.4% = 2.5人月 [ST]：19.6% × 5人月 / 31.4% = 2.5人月 Total：12.75人月 コーディング・UTの工数を軸に 比率計算
12. （補足動画）VS CODE テキスト比較操作手順
13. （補足資料）GIT運用の基本 ブランチ 種類 読み 用途 main メイン テストが完了し、製品として問題のない状態のソースをここに 公開する最終地点 hotfix ホットフィックス 緊急のバグ対応時に急遽切られるブランチ release リリース リリースできる状態になったソースをここに載せる。リリース した時点のソースを管理するのにも役立つ develop デベロップ メインブランチに直接手を加えないために必要とし、開発専門 のメインブランチ的な立ち位置 feature フィーチャー 機能単位や(アジャイルの)タスク単位などに小分けした、ブラ ンチの最小単位 ▪ブランチ戦略（ブランチの分け方） タイトル接頭辞 （一部抜粋） 用途 add 新規ファイルや機能追加 feat 新しい機能の追加（addと被ってややこしいので、基本addかfeatのどちらか を使う） fix バグ修正 test テストクラスの修正・追加 ci CI/CDのための変更 docs ドキュメントの修正（機能の挙動に変更の無い部分の修正） chore どの分類にあてはらまない場合。「雑用」とか「雑務」という意図で使う ▪コミットルール ※リストは一例のため、最終的にはチーム内で運用しやすい接頭辞を設けて使っていくことになるゾ！ feat: 〇〇機能の追加 （改行） △△対応により、××を行う機能の新規開発 コミットメッセージ例 Git運用の流れ まとまった対応(期間)毎に、 「バージョンタグ」というものをつけて管理する 本番運用中にバグ発覚した際に切る 個別機能開発 v1.2.0リリース準備 のために切る バグ修正をしたら developへも反映
14. （補足動画）プルリクエストの作成 戻る #7.理解した気になるTeaching（Git編 expansion）