Morichanの投稿 - Crieit

プロダクトオーナーにプロダクトバックログの価値を理解させるためのツールの1つであることに気をつける。
プロダクトバックログアイテムの1つにリファクタリングとあっても、それだけではプロダクトオーナーは価値を見出せずに無視してしまうかもしれない。
ここに、顧客の価値を書く事で、プロダクトオーナーの注意を引きつけることができるはず。

スプリント計画のトピック

以下の要素を含める。

スプリントの価値
できるようになること
できるようにする方法

スプリント計画で開発者を割当てるのはスプリントバックログアイテムではなくタスクであることに注意する。
1つのスプリントバックログを、開発者全員でタスクに取掛かることが望ましい。

各イベントの理想的な時間配分

スプリント：1day ~ 4weeks
スプリント計画：8h/month
デイリースクラム：15min/day
スプリントレビュー：4h/month
スプリントレトロスペクティブ：3h/month

スクラム運用のテクニックについて

スクラムの要素 + α

以下は例として挙げる。

5つの役割 = 3 + 2
6つのアーティファクト = 3 + 3
7つのイベント = 5 + 2

5つの役割

プロダクトオーナー
開発者
スクラムマスター
ステークホルダー
スクラムメンター
- スクラムマスターを補助するための、スクラムチーム外の人
- スクラムマスターのコーチ役

6つのアーティファクト

プロダクトバックログ
スプリントバックログ
インクリメント
プロダクトゴール
プロダクトロードマップ
リリース計画

7つのイベント

スプリント
スプリントプランニング
デイリースクラム
スプリントレビュー
スプリントレトロスペクティブ
プロダクト計画
リリース計画

Geoffrey Moore氏のプロダクトビジョン・テンプレート

プロダクトゴールを見据えるためのテンプレートの例を、以下に示す。

<顧客ニーズの内容>がある<ターゲット顧客>のための<プロダクト名>は、<ユニークな顧客のメリットやセールスポイント>がある<プロダクトカテゴリ名>です。
<競合や代替手段名>と異なり、我々のプロダクトは<主な差別化ポイント>に強みがあります。

日本のSaaSにはまだ足りない…急成長を支える「プロダクトビジョン」を作るための8つのポイント - ALL STAR SAAS BLOG

同意形成のテクニック

難しそうなテクニックはなるべく避ける、簡単な合意にツールは必要ない。

抵抗ポイント

項目を複数並べ、各項目に対し、0=喜ばしい〜9=本当に嫌、の10段階で各人にポイントを振り分けてもらう
合計し、最も数値が低いものを選ぶ

5本指投票

5=素敵！〜1=反対で進めてはいけない、までを片手で出してもらう
項目を順に出していって、全員が3以上ならその数字で確定する

見積り手法

相対見積り

見積りポーカー
1. 最初にアンカー（指標）となるプロダクトバックログアイテムを開発者全員で選択し、5と仮定する
2. それと比較し、開発者に数字を提示してもらう（プロダクトオーナーとスクラムマスターは出さない）
3. 差がない場合は、その数値で確定し、次のプロダクトバックログアイテムを選択する
4. 差がある場合
  1. 最小数値を出した人と最大数値を出した人に意見を伺う
  2. 3回やってもまとまらない場合は、手順2. に進む
  3. 手順1.2. に戻る
5本指投票：Fist of Five
1. 全員が出した数字を大きい（小さい）順に出していく
2. 全員が3以上ならその数字で確定する
3. そうで無いなら、手順2.1に戻る

類似性に基づく見積り

大量のチケットを捌く時に役立つ。

MS, S, M, L, XLに相当するチケットを、それぞれに代表して1つずつ開発者が選ぶ
全チケットを、MS, S, M, L, XLに開発者が当てはめる（ここは手分けしてで良い）
全チケットを開発者が参照し、気になったチケットについて議論してもらう
プロダクトオーナーにチケットサイズをレビューしてもらう

スクラムでよく使用されるが、スクラムでは規定されていないもの

3つの役割／3つのアーティファクト／5つのイベント以外の全ては、スクラムでは規定されていないと考えて良い。
例えば、次の項目はスクラムでは無い。

プロダクトロードマップ
リリース計画
ユーザーストーリー
プランニングポーカー
デイリースクラムにおけるスタンドアップミーティング
- 補足：朝会のパターン:立ってるだけじゃないよ - Martin Fowler's Bliki (ja)

大規模なスクラムチームの運用

スクラムオブスクラムズ

スクラムチームの開発者に1人、開発者のスクラムオブスクラムズを用意する。同様に、スクラムマスターをスクラムオブスクラムズとする
全スクラムチームのデイリースクラムを、同じ時間に（もちろん各スクラムチーム毎に）対応する
デイリースクラム完了後、スクラムチームの代表者として、開発者のスクラムオブスクラムズとスクラムマスターのスクラムオブスクラムズを、それぞれの会議体として用意し、スクラムチーム間の内容を調整する
終わったら、各スクラムチームに戻って伝える（ここは会議体にする必要はない）

アジャイル移行チーム

組織をスクラムに適応するための「アジャイル移行チーム」というスクラムチームを用意しても良い。
開発スクラムチームで検知した妨害に関する項目が、アジャイル移行チームのプロダクトバックログとなる。

組織の障害

組織をスクラムに適応しようとする際に発生する障害の例を、以下に示す。

マトリックス化／分断したチーム
スペシャリスト／単一障害点
サイロ／ハンドオフ
権限を与えられていないPO
専門的な移行サポート無し（コーチング無し）
「私たちの会社は他社とは違う」という意識

実践UML記述法：シーケンス図で継承元（親クラス）のメッセージ（メソッド）を利用する際の書き方について

2021-11-26T19:37:42+09:00

TL; DR

クラス名::メソッド名 なんてどうでしょう？

本題：シーケンス図で継承元（親クラス）のメッセージを利用する

シーケンス図のメッセージは、ライフラインがクラス図のクラスと紐付いている場合、クラスの操作を使うことが一般的かと思います。

2つだけのクラスを持つクラス図とシーケンス図

@startuml
title クラス図の例

skinparam classAttributeIconSize 0

class 利用者 {
}

class クラス {
  + 操作()
}

クラス "1 - used" <-- "1" 利用者
@enduml

@startuml
title シーケンス図の例

participant ": 利用者" as 利用者
participant "used : クラス" as クラス

利用者 -> クラス: 操作()
@enduml

しかし、継承元クラス（親クラス）のメッセージを利用する際、クラスとしては持っていない（かのように見える）メソッドを呼出すように書く必要があります。

継承が1つ存在するクラス図とシーケンス図

@startuml
title 継承が1つ存在するクラス図の例

skinparam classAttributeIconSize 0

class 利用者 {
}

class 親クラス {
  + 操作()
}

class クラス {
}

親クラス <|-- クラス
クラス "1 - used" <-- "1" 利用者
@enduml

@startuml
title 継承が1つ存在するシーケンス図の例

participant ": 利用者" as 利用者
participant "used : クラス" as クラス

利用者 -> クラス: 操作()
note right: 表記上の違いが無い
@enduml

上記はわかりやすい例ですが、下記のように継承とメッセージが複数存在すると、どのクラスのどのメソッドが使われているのか把握しづらくなります。
特に、子クラスのメソッドで親クラスのメソッドを呼出すような形は、どれがどのクラスで実装されているのか把握しづらいです。

継承が複数存在して視認性が悪いクラス図とシーケンス図

@startuml
title 継承が複数存在して視認性が悪いクラス図の例

skinparam classAttributeIconSize 0

class 利用者 {
}

class 高祖父母クラス {
  + create()
}

class 曽祖父母クラス {
  + read()
}

class 祖父母クラス {
  + update()
}

class 親クラス {
  + delete()
}

class クラス {
  + 操作()
}

高祖父母クラス <|-- 曽祖父母クラス
曽祖父母クラス <|-- 祖父母クラス
祖父母クラス <|-- 親クラス
親クラス <|-- クラス
クラス "1 - used" <-- "1" 利用者
@enduml

@startuml
title 継承が複数存在して視認性が悪いシーケンス図の例

participant ": 利用者" as 利用者
participant "used : クラス" as クラス

利用者 -> クラス: 操作()
note right: それぞれのメッセージが\nどのクラスのものか\n把握が難しい
クラス -> クラス: read()
クラス -> クラス: delete()
クラス -> クラス: create()
クラス -> クラス: update()
@enduml

また、上記のような状態において、UML2系で記法の定義はされていません。

現状で最新のUML2.5.1では、メッセージの記法は以下のように定義されています。
request-message-label という部分が今回のターゲットとなるメッセージラベルです。
中身を確認すると、メソッド名に該当する message-name、引数に該当する input-argument-list の2つしか存在しません。
クラス図の属性や操作には prop-modifier という名で詳細を記述できるため以下様にもできるのですが、シーケンス図のメッセージには上記の様な補足も書けないことになっています。

 ::=  |  | ‘*’

 ::=  [‘(‘[] ’)’]
 ::=  [‘,’*]
 ::= [ ‘=’]  | ‘-’

;  の定義は省略する

About the Unified Modeling Language Specification Version 2.5.1

解決策

ここで、 message-name の定義を考えてみます。
定義は以下の通りです。

The message-name appearing in a request-message-label is the name property of the Message.
If the Message has a signature, this will be the name of the Operation or Signal referenced by the signature.
Otherwise the name is unconstrained.

request-message-labelに表示されるmessage-nameは、そのMessageのnameプロパティです。
Messageにシグネチャがある場合は、そのシグネチャで参照されるOperationやSignalの名前になります。
それ以外の場合、名前は制約を受けません。

ここでいう「シグネチャで参照されるOperationやSignal」は、多くはライフラインに紐付くクラスの操作（つまりメソッド）です。

操作を記述する際、クラス名の記載の有無についてまで明記はありません。
しかし、UMLの仕様書にも多く書かれている記述として クラス名::操作名 という書き方が使える様です。
であれば、メッセージ名としても同様の記述を使えば良いのではないでしょうか？

継承が複数存在するが視認性をある程度補えるシーケンス図

@startuml
title 継承が複数存在するが視認性をある程度補えるシーケンス図の例

participant ": 利用者" as 利用者
participant "used : クラス" as クラス

利用者 -> クラス: 操作()
クラス -> クラス: 曽祖父母クラス::read()
クラス -> クラス: 親クラス::delete()
クラス -> クラス: 高祖父母クラス::create()
クラス -> クラス: 祖父母クラス::update()
@enduml

結論

クラス図におけるクラスの属性や操作の補足的記法をベースに考えることが多いため、シーケンス図でも同様の書き方ができないかを調べた挙句、シンプルな記法を思いつきました。
遠回りした気もしますが、お蔭でさまざまな定義などの再学習もできたため、結果的には良かったと思います。
仕様書、万歳！

噂のGTDをTodoistで始めるための手順

2020-12-25T07:00:11+09:00

本記事は、Crieit なんでも Advent Calendar 2020の最終日 (12/25) の記事です。

TL; DR

TodoistでのGTDは、悪くはありませんが最適でもありません。
もしGTDに特化したツールがあれば、そちらを使う方がよいことは間違いないでしょう。
僕はTodoistを使います（意固地）。

本記事はTodoistに特化していますが、それ以外のTODOリストのツールでも使える方法があると思います。

はじめに

「タスク管理にTODOリストを使おう」と思い立っては三日坊主で辞めてしまう、という経験を何度もしており、4年前からアカウントを持っているTodoistを持て余していました。

Todoist: ToDoリストで仕事と生活を管理

そんな時、GTDというタスク管理方法があると、噂で耳にしました。
せっかくTodoistアカウントがあるから、これで挑戦してみようと考えました。

その結果、なんと2週間も（僕にとっては1週間以上も続いたことが奇跡）もTodoistを使い続けることに成功しました。
この手法は意外と僕に適しているのかもしれません。

15分で分かるGTD – 仕事を成し遂げる技術の実用的ガイド | POSTD

GTDは方法論であり、特別なツールが用意されているわけではありません。
また、僕はTodoistユーザーですが、TodoistにGTDの設定があるわけでもありません。

そこで本記事では、TodoistでGTDを実施するために、僕の使いやすかった方法を紹介します。
いくつか試行錯誤もあったため、それも交えて説明しようと思います。

なお、僕のGTDに対する理解は、上記リンク先ページの知識しか無いため、理解が間違っている可能性もあります。
ご注意ください。

ちなみに、この記事を書くために調べたら、ほとんど同じタイトルの記事を見つけてしまいました。
本記事での設定方法は下記と異なるため、本記事を読む際は、あくまで僕の使いやすかった例であると頭の片隅に置きながら読んでください。

Todoistを用いたGTD式タスク管理術 | キオミルブログ

Let's Start GTD by Todoist

本記事では、次の項目について記載しています。

GTDとは？
Todoistの整備
TodoistでGTDを実施する手順

GTDとは？

~~Great To Do~~ "Getting Things Done" と呼ばれる、物事をよりよく完遂するための手法（いわゆるタスク管理方法）の1つです。
何かしたいなーという記憶を、全てTODOリストに書出すことで、脳のメモリリソースを開放し、もっと生産的なことに時間を使おう！というものです。

特徴として、下記が挙げられます。

まずタスクをメモ書き（記録）する
- そのためには、どんな時でも記録できるものを常に手元に用意する
- TODOリストに入れるのは、そのあとでも良い
タスクを5種類に分ける
- インボックス
- 次にとるべき行動
- 連絡待ち
- プロジェクト
- いつかやる／多分やる
週次レビューで進捗を確認する
- 1週間に1回、タスクの進捗を確認する

まとめると、以下のような思想です。

したいと思ったことを、まず書出す
タスク化の敷居を下げる
タスクの優先順序を決める
常に管理できるTODOリストを目指す

Todoistの整備

TodoistでGTDを実施するために、僕が必要だなと思った設定などを、説明します。

プロジェクトを追加する

Todoistの「プロジェクト」機能に、GTDのプロジェクトを追加します。

僕は、GTDにおけるプロジェクトというものを、タスクの分類分けとして利用しています。
例えば、「仕事」「プロジェクトA」「学習」「私事」などです。

各プロジェクトにボードを追加する

各プロジェクトをボード表示にして、以下のボードを、以下の順番でそれぞれのプロジェクトに追加します。

実施予定／実施中／完了
連絡待ち
いつかしたい

これらは、それぞれGTDの下記に対応します。

次にとるべき行動
連絡待ち
いつかやる／多分やる

「次にとるべき行動」に「実施予定」を含めているのは、実施予定から実施中に移動するということが、個人的に手間と感じているためです。
僕は、基本的に各プロジェクトのページを見ることはあまりありません。
そのため、タスクを実施する前にプロジェクトページの展開とタスクのボード間移動をするのは、正直手間でしかありませんでした。
カンバンなど、チームで複数人でタスクを管理している場合は、誰が今何をしているかを可視化するために、実施予定と実施中を分けることには意味があると思いますが、個人であれば必要ないと思います。

また、「次にとるべき行動」に「完了」を含めているのは、チェックを付けると同じボード内の履歴に移動するためです。
ZenHubなどのカンバンツールと異なり、完了したタスクが自動的に完了ボードに移動する、という動作を実装しているTODOリストは多くありません（そもそもボードという概念が多くのTODOリストには無いですね）。
Todoistもご多分に漏れず未実装であるため、完了を実施中と同じボードに配置しています。

「いつかやる／多分やる」を「いつかしたい」と言い換えているのは、断定形ではなく希望形にすることで、よりタスク化の敷居を下げることが目的です。
気分の問題でもあるので、ここはご自由に決めて構いません。
慣れている人はIceboxと書いてもいいですね。

プロジェクトと分けているのは、軸が違うと思ったからです。
「プロジェクト」はタスク分類であるのに対し、「実施予定／実施中／完了」「連絡待ち」「いつかしたい」はタスクの状態だと思ったため、プロジェクトと各状態を、それぞれ別軸で管理しようと考えました。

「タスク確認（土曜日は週次レビュー）」タスクを毎朝の繰返しタスクとして追加する

「タスク確認（土曜日は週次レビュー）」というタスクを、毎朝の繰返しタスクとして追加します。
このタスクは、その名の通り、その日のタスクを確認する、というタスクです。
このタスクのプロジェクトの分類については、特に決まりは無いと思います。
僕は「私事」の「実施予定／実施中／完了」に分けていますが、インボックスでも良いかもしれません。

朝の時間は、出社予定前など、1日の始まりの時間として設定するといいと思います。
僕の場合は、基本テレワークであるため、毎朝8:30に設定しています。

休日？気にする必要はありません。
その日までに実施すればよいので、時間設定は実はあまり重要ではありません。

完了したいタスク数を1に設定する

Todoistは、1日どれだけタスクを実施できたらゴールか、という指標として「完了したいタスク数」を設定できます。
これを、1に設定します。

これは、タスク数で一喜一憂したくなかったことが目的です。
デフォルト値は5なのですが、4つや3つしかタスクをしていない日があったら、まるでその1日が未達成な日であったかのように思ってしまい、地味に傷ついてしまいました。
これを1にすることで、「タスク確認（土曜日は週次レビュー）」タスクさえすれば、必ずゴールできるという素敵仕様になっています。

個人的には、GTDを継続する秘訣にもなっているので、騙されたと思ってやってみてください。
朝一番に「1日のゴールです」と言われるのは、なかなか心に優しいですよ。

（有料版の場合）タグを準備する

僕は無料版のため使えませんが、タグを使うと便利だろうなーと思うことはあります。

例えば、大枠としてプロジェクトを利用し、副枠としてタグを使うといった、プロジェクトとタグを親子関係で利用すると便利そうです。
「仕事」プロジェクトの中でタスクを作って、その中で「プロジェクトA」タグと「プロジェクトB」タグを使い分ければ、タスクの見通しが良くなりそうです（今は全部ごっちゃにしています）。

有料版は、他にも様々な機能があるため、GTDをもっと続けられたら有料版にしてみようかなと思ってます。

TodoistでGTDを実施する手順

では、TodoistでGTDを実施するための手順、および、設定方法などを、以下に記します。

タスクリストを充実させる

最初にGTDをやってみようと思ったら、まずは1時間かけてしたいことを書出すそうです。
僕は、1時間で思い出せるとは思わなかったので、1週間かけて、やってみたいことを書出しました。
これは、向き不向きがあるので、個人で方法を決めてください。

ちなみに、この時点でTodoistを使う必要はありません。
書出したタスクは、紙やメモアプリなどに記録すれば十分です。

説明のため、僕が書出した結果の抜粋を、以下に記します。
もちろん、GTDの実施というタスクも、同じタスクだろうと思って書出しました。

タスク確認（土曜日は週次レビュー）
GTDの実施
サンスクリットの勉強
月1プロジェクト

1週間経つと、タスクもそれなりの量に増えてくるので、タスクリストが充実したら次に進みます。

タスクをプロジェクトに分類する

書出したタスクリストが、それぞれどのプロジェクトに該当するかなと想像し、各プロジェクトに移動します。
最初は未設定のボードに移動するとよいです（後でボード移動する際にわかりやすいため）。

僕は、以下のように移動しました。

タスク確認（土曜日は週次レビュー）
GTDの実施: 私事
サンスクリットの勉強: 学習
月1プロジェクト: 仕事

最初は多いため、じっくりプロジェクトを分類しましょう。
この時、新しいプロジェクト分類が見つかったら、新規作成したほうが手っ取り早いです。

各プロジェクトのボードに分類する

タスクリストをプロジェクトに分類し終わったら、各タスクの状態を決めましょう。
先に書いた通り、タスクの状態は、以下の3つです。

実施予定／実施中／完了
連絡待ち
いつかしたい

「実施予定／実施中／完了」のタスクは、必ず日時を指定しましょう。
そうしないと、予定にならず「いつかしたい」タスクとの差別化ができません。

繰返し実施するタスクは、繰返しタスクとして設定しましょう。
僕は、毎日より間隔の空く繰返しタスク（隔週、月1などのタスク）については、「連絡待ち」に配置しています。
これは、毎日のタスク確認を少しでも楽にするためです（後述）。

なお、ボードに追加する際には、サブタスクである程度のタスク分割をしておくと良いです。
特に、「実施予定／実施中／完了」に配置したタスクについては、タスク分割をしておくことをオススメします。

僕の場合は、以下の通りです。
可読性向上のため、「実施予定／実施中／完了」は「実施予定」に変えています。

タスク確認（土曜日は週次レビュー）: 私事 > 実施予定（繰返し、日時指定済み）
GTDの実施: 私事 > 実施予定（日時指定済み）
- GTDについて調べる: 私事 > 実施予定（日時指定済み）
- タスクを書出す: 私事 > 実施予定（日時指定済み）
- タスクを分類する: 私事 > 実施予定（日時指定済み）
- 1週間続ける: 私事 > 実施予定（日時指定済み）
- まとめをブログに書く（本記事！）: 私事 > 実施予定（日時指定済み）
サンスクリットの勉強: 学習 > いつかしたい
月1プロジェクト: 仕事 > 連絡待ち（繰返し、日時指定済み）

ちなみに、本節完了時点で、「GTDの実施」タスクのサブタスク上位3つは終わっていることになります。

タスク確認タスクを完了する

以上で、TodoistでのGTD実施準備は完了です。
タスクを確認したので、「タスク確認（土曜日は週次レビュー）」をチェックしましょう。

はい、今日はゴールできました！
後は、したいと思っているタスクを順次こなしていけばよいでしょう。

GTDを実施するにあたってのTips

Todoistで（あるいはそれに限らず）GTDを実践する際に、僕が心がけているTipsを記します。

タスクの記録について

「タスクの記録」とは、脳で考えていること（記憶）を文字に起こすこと（記録）です。
記憶は瞬時に消えやすく、思い出すために体力を使うものであるため、できるだけスグに記録することが大切です。
そのため、できるだけ手間のかからない、簡単に記録できることが望ましいです。

簡単な方法として、記録方法とタスク管理ツールを別にする、という方法があります。

タスク管理ツールは管理するものであるため、なるべく自動で管理しやすいツール（使いこなせるのであれば多機能でも良い）が望ましいです。
僕は、これをTodoistと捉えました。

一方の記録方法ですが、とにかく瞬時に記録できることが望ましいため、人によってはアナログなノートなどもありだと思います。
お風呂場など、今までは記録が難しい場所でも、文明の利器を使うことで、AlexaやGoogleアシスタントなどに記録できます、素晴らしいですね。
僕は現在、お風呂場については一旦無視しています（本当はもったいない）が、それ以外ではiOSアプリのDraftPadというアプリで記録しています。
とにかく起動が早いため、思ったことを瞬時に記録できます、オススメですよ。

‎「DraftPad」をApp Storeで

タスクの追加方法

前述したとおり、タスクを追加する際には、以下のことを実施します。

タスクの記録
タスクのプロジェクト分類
タスクの状態分類
サブタスクでのタスク分割

特に、「実施予定／実施中／完了」に分類するタスクについては、サブタスクでのタスク分割を推奨します。
タスク分割しておくことで、ある程度の見積りが取れますし、それによっていつ実施すべきかも決まりやすいからです。

また、Todoistでは、サブタスクにも日時指定ができます。
タスク自体が数日かかる場合などに便利ですので、ぜひ使ってみてください。

タスク確認タスクとは？

タスク確認は、毎朝実施すると良いです。

「タスク確認（土曜日は週次レビュー）」タスクとは、毎日、もしくは、週1で実施する、TODOリストの見直しタスクです。
毎日のタスク確認と、週次レビューでは、見る範囲が異なります。

タスク確認で見る範囲

基本的に、今日のタスクと、各プロジェクトの「実施予定／実施中／完了」ボードのタスクを眺めればよいです。
眺めてみて、1日に余力がありそうだと思ったら、今日のタスクに「いつかしたい」タスクを入れるのもよいでしょう。

週次レビューで見る範囲

基本的には、全てのタスクを見直します。
特に、「いつかしたい」タスクはちゃんと見直しましょう。

「いつかしたい」タスクを眺めて、したい欲が高まってきたら、日付を指定して、「実施予定／実施中／完了」に入れると良いです。
逆に、絶対しないという意思が固まったら、削除するか、「アーカイブ」プロジェクトを用意してそこに入れちゃいましょう。

おわりに

この記事が公開されたことで、僕の「GTDの実施」タスクは完了です。

GTD、思ったより良い感じです。
このまま続けてみるので、皆さんも挑戦してみてはいかがでしょうか？

それでは、よいお年を。

「製品開発の知識」読書メモ

2020-11-04T00:31:27+09:00

TL; DR

アジャイルでやってこう！

メモ書きの割にまとまってないけど、それだけ重要な点が多いってことで許してください。
それくらいには、読んでためになる内容が多かった印象です。

はじめに

「製品開発の知識」という書籍（以降、本書と呼びます）の内容要約、および、自身の感想などを記します。

本書は、2002年に発売の古い本ですが、2016年には第15版が登場しています。
今回は、その第15版を読みました（何が違うかは把握できてませんが、多分ここかなーという目星はついた程度です）。

本書の要約については、である調で記します。

箇条書きについては、次のルールで記述しています。
簡単に書くと、項目自体についてを太字で、項目の説明を常体で、それぞれ書いていきます。

項目1
- 項目1-1
  - 項目1-1の説明
- 項目1-2
項目2
- 項目2-1
- 項目2-2
  - 項目2-2の説明a
  - 項目2-2の説明b
  - 項目2-2-1
  - 項目2-2-2
    - 項目2-2-2の説明

「製品開発の知識」

製品開発の現場では、マニュアル的な知識よりも基礎知識の方が重要である。
本書はヒット商品そのものではなく、ヒット商品を生み出す企業体質についてを記述する。

製品価値の役割

製品価値の役割は、以下の2点。

付加価値創造

付加価値の源泉は以下の3点。

顧客にとって高い価値の提供
低コストでの提供
競合企業に対する優位性の確保（希少価値の提供）

付加価値の高い製品開発により、次の対象に大きく貢献する。

従業員
- 給与を潤沢に支払えるため
社会
- 税金を多く納められるため

企業の将来の担保

以下のバランスが重要。

短期的な視点
- 利益および業績の追求
長期的な視点
- 将来的な競争力を左右する技術／製品開発力の蓄積

製品開発マネジメント

マネジメントすべき対象は、以下の3点。

創造性

以下のバランスが重要。

細かい行動規程
自由な発想

複雑性

複雑性を持つ対象は、以下の通り。

技術
開発組織
- 社内の人間だけでなく、社外の人間も巻き込む必要がある

不確実性

不確実性を持つ対象は、以下の通り。

市場
- 顧客が期待する価値
- ニーズに関する価値観
- 製品の持つ価値の持続性
技術
- 技術対象
- 最終的な総コスト

製品開発と競争力

差異化の源泉は、以下の通り。

製品
- 特定機能
- 勝負軸
- 製品分野
製品開発能力
- 技術力
  - 特に、核となる技術を1点に絞る「コア技術戦略」が重要
- 組織プロセス能力
  - 競合企業よりも短期間／低工数／高品質を実現できる組織力のこと
- 価値創造能力
  - 製品／市場戦略に関する能力
    - 顧客ニーズ（特に潜在的なニーズ）に合致した製品を開発する能力のこと
  - 独自のビジネス・システムを構築／活用する能力
    - 複数の企業を巻込んで、1つの製品の開発準備から販売網までのフローを「ビジネス・システム」と呼ぶ
    - そのビジネス・システムをうまく活用することで、独自の販売網構築から業界標準策定までを可能にする

イノベーションのタイプ

イノベーション対象という視点でのタイプは、以下の通り。

市場的革新
- 既存技術の組合せが新しいもの
技術的革新
- 製造技術
  - 品質や生産効率の向上など
- 製品技術
  - アーキテクチャ
    - 製品要素の組合せなど
  - 要素技術
    - 製品要素そのものの機能向上など

この枠組みを利用する利点は、次の2点。

イノベーションのタイプに応じて戦略が変化し、戦略に応じてPMやメンバーが変化する
企業内での製品開発PJの組合せを考えられる
- 企業内で、全て一方の革新性を取るような製品開発だけを実施しない

イノベーションの判定

イノベーションの判定は、以下の2点。

イノベーションの基準点

基準点としては、以下の2点。

市場に存在しなかった技術
特定企業が利用できなかった技術
- 既にある技術を、他産業の企業が利用できた場合は、イノベーションになりうる

イノベーションの変化量

変化量としては、以下の2点。

機能やコストの変化量の大小
特定企業の保持する既存技術のベクトルの方向性の差異
- 特定企業が保持している既存技術の応用として対応できない技術を利用できた場合は、イノベーションになりうる
- 既存技術の存在が、新技術の足枷になることもある可能性に注意

イノベーションのパターン

イノベーションを起こすためには、以下の2つの戦略に分けられる。

改善重視型戦略

既存機能の改善を重視する戦略。

市場で売れる製品のライフサイクルが短い場合
- 機能的には比較的小さな差異でも、新製品を次々に投入することが重要である場合
市場／顧客ニーズがわかりにくく、かつ、製品コンセプトが重要な場合
- 売上げの予測が立てにくい場合は、改善内容を変えて次々に開発した方が良い
- 必要以上の高頻度な新製品の開発は、投資が過度に増え、在庫管理が大変になることに注意
フォロワー戦略を取る場合
- リーダー戦略企業が新市場の開拓や新技術の導入に成功したことを確認した後で、迅速に同様の製品を開発する戦略

革新重視型戦略

既存機能に囚われずイノベーションを重視する戦略。
基本的には、改善重視型戦略の逆を取る。

市場で売れる製品のライフサイクルが長い場合
市場／顧客ニーズがわかりやすい場合
技術の優位性を製品のアピールポイントにできる場合
技術的に大きな優位性を維持できる場合
リーダー戦略を取る場合
- 誰よりも早く革新的な製品を開発する戦略

なお、リーダー戦略およびフォロワー戦略は、どちらが良いというわけで無く、それぞれに一長一短が存在する。

イノベーションのジレンマ

イノベーションを生み出すために乗り越えるべきジレンマとして、以下の3つが存在する。

研究開発と製品開発のジレンマ
- 初期段階では研究内容の技術や方向性が定まっておらず、投資の多くが無駄になりやすい
- 初期段階では大量生産ができず、量産効果が得られない
- 累積生産量が少なく、学習効果を享受できない
技術革新のジレンマ
- 革新技術のコストは既存技術のコストより高い
- 既存顧客に革新技術は対応できない場合がある
- 初期段階では革新技術が本当に既存技術より優れていることを判別できない
組織のジレンマ
- 事業部門の視点と研究開発部門の視点が異なる
  - 事業部門は、比較的短期的な視点から、既存技術より全ての面で優れた新技術の提供を期待する
  - 研究開発部門は、長期的な視点から、既存技術より優れた技術を提供できる可能性を提供する

重要な点は、新旧技術の利点欠点を理解しつつ、どちらかを適切なタイミングで意思決定するリーダーの存在である。
革新的技術の投資は、タイミングを見計って遅すぎない段階に実施する必要がある。
または、競合企業が革新的技術に投資している中、自企業だけ既存技術で優位性を高める戦略もある。

なお、日本企業では、イノベーションの多く（特に、破壊的イノベーションの多く）が大企業から生み出されている。
これは、次の2点を象徴している。

日本の大企業における柔軟性に富んだ開発組織能力に裏づけされた強さ
大企業を脅かすベンチャー企業の弱さ

製品戦略

製造業にとって製品戦略は、企業戦略の下位概念ではなく、経営戦略とオーバーラップして考えるべき重要なものである。

製品戦略の役割

外部環境との関係として重要なステークホルダーは、次の3つである。
自社を含めて、通称 4C と呼ぶ。

顧客
競合企業
協力／補完企業

製品戦略の分野

製品戦略の分野は、次の3つに大別できる。

製品技術戦略

短期的な視点。

マーケットイン戦略（市場の要求から製品を開発する戦略）より、プロダクトアウト戦略（存在しない市場を生み出す製品を開発する戦略）の方が、最終的に取得できるパイは大きい。

製品市場戦略

短期的な視点。

選択と集中を徹底し、限られた数の新製品でヒットを狙う戦略
多数の新製品を、なるべく小さい投資と低い開発／製造コストで開発する戦略
- マスカスタマイゼーション戦略
  - 低コスト戦略（標準化した製品として量産効果を享受する戦略）と高付加価値戦略（顧客の要望に全て答えて付加価値を高める戦略）のいいとこ取り
  - 部品共通化戦略
    - 疎結合化することで共通部品を作成し、コストを抑える戦略
    - 経営資源や技術や部品までも共通化できることはすると良い
  - 高付加価値汎用化戦略
    - 従業員の半数以上を営業として顧客配属させることで、膨大な顧客情報から共通化できそうな要求を見つけることが可能（キーエンス社の場合）

製品展開戦略

長期的な視点。

製品ドメイン戦略
- 既存技術による市場範囲の拡大、または、既存市場に対する技術範囲の拡大の、どちらかの戦略が存在する
- 既存の製品ドメインから大きく離れすぎた多角化は、成功の確率が低いことが研究で証明済み
- 製品展開マップ
  - 製品の技術プラットフォーム／製品プラットフォーム／製品ラインの関係を可視化できるフレームワーク
  - 技術プラットフォーム
    - コア技術と呼ばれるようなもの
  - 製品プラットフォーム
    - アーキテクチャ（組合せ）

製品開発プロセス

最初から完璧な設計開発を実現するという発想でプロセスを考えるべきでは無い。

製品開発の業務

製品開発の業務は、以下の5つに大別できる。

製品企画

製品コンセプト、技術計画、収益性計画を検討する。
製品開発終了まで常に参照し、実際とのギャップを埋める必要がある。

収益性計画は、原価企画という手法で定めると良い。
原価企画とは、顧客価値の視点から見た販売価格から、経営戦略上必要とされる利益目標を差し引いた金額（目標コスト）を、製品企画の段階で設定する手法のこと。
逆に、コストの積上げ式で最終的な販売価格を決めるのは悪手となる（市場での競争力が失われてしまうため）。

設計開発と試験／テスト／解析

設計者が設計案を創出する必要がある。
その設計案が実際に目標や製品コンセプトにあっているかを検証する。
この「設計案の創出」と「検証」を繰返すことで、設計は具体化する。

要素技術開発

キーとなる要素技術の開発は、他の要素技術に先駆けて進める必要がある。

生産準備

製品設計開始前に、生産条件を製品技術者に提示する。
これにより、生産しやすい製品設計が可能となる。

開発管理

原価企画によるコスト管理が良い。

製品開発の複雑性

製品開発の複雑性の要素は、次のように分けられる。
イノベーションのタイプと部分的に似ている。

市場／顧客ニーズの複雑性
- 顧客ニーズがネットワークの外部性（顧客数によって価値が変わるようなもの）や流行によって変化する場合
- 顧客ニーズが暗黙的で捉えにくい曖昧な性質を持っている場合
- 製品開発によっては、初期から顧客の潜在ニーズを取込む必要がある
製品技術の複雑性
- 要素技術の複雑性
  - 技術の新しさ
  - 技術開発の内容と機能との因果関係
- 製品アーキテクチャの複雑性
  - 部品間関係の複雑性
    - インターフェイスのモジュール化／標準化の有無
    - インターフェイスの高精度性や緻密性の必要性
  - 部品点数の多さ

組織マネジメント

組織体勢の種類は、以下の通り。

機能重視組織
- 専門家を束ねる組織
- 有効的な場面
  - 特定分野の新技術開発
  - 長期プロジェクトに配属する技術者の技術獲得
  - 各機能部門の相互依存性が低い場合
プロジェクト重視組織
- プロジェクトメンバーを束ねる組織
- プロジェクトを重視せずに組織を重視している場合は成功しない
  - 組織間に壁があってはならないように、プロジェクトに貢献することで自部門にも利益があることを事業部長や研究所長に理解させる仕組みが必要
- 有効的な場面
  - 機能横断的にプロジェクトを成功させたい場合
  - 短期プロジェクト
  - 各機能部門の業務間の相互依存性が高い場合
ハイブリッド型組織
- 両方のいいとこ取り組織
- 確立方法
  - 開発メンバーの役割に応じて、機能重視組織とプロジェクト重視組織に分けつつ、両方をミックスする
  - 製品開発プロセスのある時点で、機能重視組織からプロジェクト重視組織に変更する

PM の権限については、以下の通り。

プロジェクトの牽引、および、組織としての効率的なプロジェクトの推進のためには、企業のトップが PM を全面的にサポートする必要がある
プロジェクトを重視する場合は、 PM もそれに応じて権限を強くする必要がある

製品開発プロセスのマネジメント

製品開発プロセスのマネジメントをする際に重要となる用語として2点、また、コンカレント・エンジニアリングを機能させるために必要な活動について1点、それぞれ挙げる。

コンカレント・エンジニアリング

製品開発業務の各工程を、並行して実施する開発手法のこと。
特に設計と生産技術の間における並行化が、製品開発プロ性巣の成否に影響が大きい。

フロントローディング

問題解決の前倒し、つまり、後工程で起こりうる問題を、なるべく早期に顕在化させること。
これにより、プロジェクトにおける開発期間短縮、および、工数削減が実現できる。

コンカレント・エンジニアリングを機能させるために必要な活動

実際に製品開発プロセスを効率的に促進するためには、関連機能間のコミュニケーションと情報交換が重要である。

「生産しやすい設計」ノウハウの蓄積と共有

設計開始前に、生産技術から設計へ、生産要件に関する情報を十分にインプットすることが大切である。
つまり、設計時に守るべきポイントを提示することで、設計に生産技術の要素を組込むことが重要である。

この時、失敗事例をデータベース化しておくと良い。

ただし、ルールを厳しくしすぎると創造的な設計活動に悪影響をもたらすため、定期的な見直しが必要である。

効果的な情報移転の方法

設計の途中過程であっても、情報を生産技術部門に逐一報告するとよい。
ただし、生産準備が全て無駄になっては意味がないため、未完成であっても有意義な情報である必要がある。

チームとして一体感がなければ、責任問題を問われる可能性を恐れて、前段側は情報を出せない。
共同で問題解決に取組む姿勢が必要となる。

企業間関係のマネジメント

製品開発には複数企業が関わることが一般的になっている。

企業間関係のタイプ

企業間関係のタイプには、次の2種類が存在する。

垂直的関係
- 製品の上流／下流工程という関係
- 分業化が進んでいる
  - 製造業の組立て受注を専門とする EMS (Electronics Manufacturing Services)
  - 半導体設計のみを請負う「ファブレス」
  - 半導体生産のみを請負う「ファウンダリ」
水平的関係
- 競争企業間関係
  - 製品や技術の共同開発
  - 技術供与（ライセンシング）
  - ジョイントベンチャー（合併）
  - 競合企業から製品を供給してもらい、自社のブランっで販売する OEM (Original Equipment Manufacturer)
- 重要な課題
  - 自社の請負範囲
  - 自社の企業ネットワーク内での立ち位置
  - 他社との関係性の濃淡

外部調達の決定基準

内部で開発／製造する部品を選択する際の観点として、以下の3点を挙げる。

部品の付加価値
- 設計／生産することが高い付加価値になるか
- 次の場合は、自社内で実施すべき
  - 顧客への価値が高い
  - 企業の強みを反映したコア技術
  - 技術の発展性／応用性が高い
部品の供給企業
- ある部品を供給する優れた企業が複数あるか
- 次の場合は、自社内で実施すべき
  - 優秀な部品企業の数が少ない
部品の設計特性
- その部品が他の部品とどれくらい相互依存性を持つか
- 次の場合は、自社内で実施すべき
  - 他の部品との相互依存性が高い
  - 標準化されていない

企業ネットワークの構築

企業ネットワークを構築することで、部品調達が優位になる場合がある。
取引企業の数によって、それぞれ以下のような優位点がある。

多数企業から調達する優位点
- 特定の調達企業への依存度が低下し、取引交渉力が有利になる
- 部品調達の上で柔軟性が増し、より最適な部品を購入できる可能性が上がる
- 1社に依存することにリスクを減らせる
少数企業から調達することの優位点
- 規模の経済性を期待でき、大量購入によるコスト削減が見込める
- 調整や取引の業務コストを削減できる

基本的に、取引企業は多すぎても少なすぎても良くない。
基本的には、2〜3社と取引することが最適だと（本書では）考えられている。

デザイン・イン

コンカレント・エンジニアリングの組織プロセスに、部品企業を組込む（製品開発プロジェクトに、部品企業を早期から参加させる）こと。
これにより、手戻り削減が期待できる。

デザイン・インを実施するためには、以下の条件が必須である。

部品設計が全く決まっていない初期段階から、部品企業を選択する必要がある
部品企業の開発能力が高い必要がある
- 言われた通りに作るだけではダメ
自社とその部品企業が相互に信頼している必要がある
- 部品企業が競合企業に情報を漏洩されては困る
- 自社が部品企業の部品設計データを粗悪に扱ってはならない
綿密なコミュニケーショが実施できるインフラが必要である

かつての欧米企業では、調達供給関係である企業は疑心暗鬼の関係であった。
そのため、デザイン・インの考え方は、欧米企業では一般的ではなかったが、近年では取入れている企業が増えている。

持続的な製品開発能力の構築

優れた製品開発能力とは、自由と規律、コストと付加価値、繊毛性と統合性、といった、矛盾する目標を高次元で統合的に解決する仕組みによって成立つ。

相反する要素

相反する要素の組合せ、および、解決策は、以下の通り。

自由と規律
- これらの関係は、本質的に相反するものではなく、むしろ補完的なものとして考えることが大事である
- 自由
  - 技術開発が失敗しても責められない環境
  - 上司は技術者が提案した新しいアイデアを決して潰してはならないと言う文化
- 規律
  - そもそも開発してよい内容に制限がかかっている
コストと付加価値
- コスト
  - 共通化によるコスト削減
  - 優れたサプライチェーンによる他社との関係の良好化
- 付加価値
  - 受注生産によるカスタマイズ
専門性と統合
- 部門横断プロジェクトの効果的な活用によって、専門技術部門とプロジェクトを組合せることができる
- 部門横断プロジェクトによる製品開発の成功体験の積重ねが大切である
オープン化と信頼構築
- この2つのトレードオフの打破が求められている。
  - グローバルな視点から最適なパートナーを、戦略的に取捨選択する
  - 緊密な信頼関係によるデザイン・インを、効果的に実行する

企業例

二律背反を高度な視点から解決できた企業の例を、以下に示す。

シャープ
- 重要な技術開発や新製品開発の組織横断プロジェクト化「緊プロ」
  - 25年に渡るプロジェクト組織の広範囲化による部門間の壁の破壊
トヨタ自動車
- 競合他社への部品供給の推奨、および、系列に拘らない最新技術の共同研究先企業の選定
  - 系列企業との緊密な信頼関係によるグループ企業間での相互学習を促進する仕組みの構築
  - 製品開発における広範なネットワークの構築
シスコ・システムズ
- 多くのベンチャー企業の買収
  - ベンチャー企業の活力や革新技術
  - 大企業の開発組織や顧客開拓力

今後特に注目される視点

本書が、2002年当時（から2016年までの間）に注目している視点は、以下の通り。

企業外部の技術力の獲得
情報技術による製品開発の仕組みの根本的な改革

おわりに

全体的に、ソフトウェア開発ではアジャイルに相当することを、ハードウェアでも実施することが望ましいということが言われていました。
が、これは新製品開発での話である、という前提を考慮すれば、そうでない場合（いわゆる保守／運用）ではどうすべきか、については書いてないと言えますね。

製品開発を会社として本気で取組むためには、会社の文化から変えていかないといけないみたいです。
そこまでちゃんと取組めている会社がどれだけあるのか......？という疑問は残りますが、企業選択の時点では考えるべき観点の1つかもしれません（就職／転職しかり、株式購入しかり）。

また、保守運用チームと新製品開発チームを併用している会社の場合（今の多くの企業はそういう感じな気がしますが）、どのように両立させると良いか、気になりました。
保守運用チームと新製品開発チームの両方が Win-Win になるためには、「ハイブリット型組織」が生かせるような、そうでもないような......

それと、営業チームと開発チームとの関係について、ほとんど書いてなかった点が気になりました。
そこが知りたいところでもあるのですが、製品開発に営業はいらないってことなのでしょうか？
いや、そんなことはないはず......

後、本書でチラッと書いてましたが、デファクト・スタンダードの対義語はデジューリ・スタンダードというらしいです。

Galaxy Angel（無印）を 64bit の Windows 10で動かす際のTips

2020-10-25T04:17:51+09:00

TL; DR

異常にもっさりしてしまいのは、対象 DirectX が古く、 FPS が早くなりすぎるのが原因です。
FPS を60に固定化することで、解決できます。

本記事の内容は、あくまで自己責任でお願いします。
ゲームの動作対象外であるため、万が一のことがあっても僕は責任を持てません。

はじめに

かつて一世を風靡した、 Galaxy Angel をご存知でしょうか？
ブロッコリーによる、キャラクターメディアミックス企画 Project G.A. のゲーム版第1作品です。
通称、 GA （無印）と呼びます。

アニメ版ではコミカルギャグ調一辺倒、ゲーム版ではシリアス一辺倒と、作風／キャラの性格／背景などがまるで違う作品として、後世に多大な影響を与えたシリーズとして有名ですよね？（同調圧力）

ギャラクシーエンジェルとは (ギャラクシーエンジェルとは) [単語記事] - ニコニコ大百科

ゲーム版では、 ADV（アドベンチャー）パート／艦内移動パート／ SLG（シミュレーション）パートの3つで構成されています。
この中でも SLG パートは、 DirectX をゴリゴリ駆使したであろう、 3D で宇宙空間を舞う戦闘機を自在に操作できるシステムであり、個人的に一番オススメできる部分です。
特に通常戦闘時の BGM が良い！

INTRODUCTION | GALAXY ANGEL

PC ゲームとして 2002 年に発売した今作は、当然ながら動作確認環境は Windows 98 以上、 DirectX 8.1 以上と古く、64bit 版 Windows 10 での動作は想定されていません。

しかし、僕は何としてでも、このゲームを、特に SLG パートを、いま遊びたいと思いました。
その際に、引っかかった点と解決策を、それぞれ記します。

Galaxy Angel（無印）を Windows 10 で遊ぶための軌跡

GA（無印）を Windows 10 で遊ぶためには、次の作業が必要です。
調べてから知ったんですが、このゴリゴリ 3D ゲームを CD に突っ込んでたんですね......

CD-ROM でのインストール
修正パッチの適用
- FAQ | GALAXY ANGEL
ゲーム起動準備
ゲーム起動

本記事では、ゲーム起動準備についてのみ説明します。
インストールと修正パッチ適用はできたものとして、以降の内容を読んでください。

全画面強制起動を止める

起動すると厄介な問題が後に控えているので、全画面強制起動を確認したい場合は、次節での FPS 設定を終わらせてからにしましょう。

インストールした GA.exe をダブルクリックすると、全画面でゲームを起動してしまいます。
今時 PC ゲームで全画面強制なんてまず無いですが、昔のゲームあるあるですね。

これを防ぐには、ショートカットを作成します。

まず、GA.exe をコピーして、適当なディレクトリ（一般的にはデスクトップでしょうか？）に右クリックで「ショートカットの貼り付け」を選択すれば、ショートカットを生成します。

次に、生成したショートカットを（ダブルクリックではなく）クリックで選択し、右クリックで「プロパティ」を選択すると、ショートカットファイルのプロパティ画面を表示します。

そして、「ショートカット」タブを選択し、「リンク先」の項目の最後に -w を入力して「OK」を押してください。

before: "C:\Program Files (x86)\BROCCOLI\GalaxyAngel\GA.exe"
after: "C:\Program Files (x86)\BROCCOLI\GalaxyAngel\GA.exe" -w

以上で、設定は完了です。
ショートカットをダブルクリックすると、ウィンドウ表示でゲームが始まります。

FPS を固定化する

一度、ショートカットをダブルクリックしてみてください。
「にゅにゅにゅにゅにゅ、ブロッコリーにゅ」というデジコの声と共に、映像が流れると思います。

Di Gi Charat Official WebSite でじこのへや

問題は、そのあと、真っ白な画面がしばらく続きながら、BGMだけ流れている状態になってしまう点です。
これは、ゲーム画面描画が異常に遅いだけで、1分ほど待機すれば、起動画面が表示されます。

何故かわかりませんが、他のウィンドウやデスクトップなどをクリックすると（ゲームウィンドウを非アクティブ化すると）、描画がスムーズになります。

これは、対象 DirectX が古すぎて、 FPS を固定化できていないことが原因のようです。
以前調べた時は、 FPS が 240 くらいになっていました。

dmm版ギャラクシーエンジェル Windows10でのウィンドウモードプレイの仕方まとめ / Twitter

これを解決する方法の1つに、 DEC と呼ばれるツールを利用する方法があります。

DEC の入った ZIP ファイルをダウンロード／解凍し、中身を GA（無印）が入ったディレクトリに置いちゃいましょう。
既定では、ウィンドウ画面の左上に、 60 FPS で固定化している様子を表示しているはずです。

これで、設定完了です！
ショートカットをダブルクリックし、ゲームを楽しみましょう！

おわりに

僕には大事な情報ですから、記録のために書いておきました。
ご興味がある方や、手元に CD が残っている方は、ぜひ楽しみましょう。

DMM 版もあると聞いて調べたんですけど、今はもうリンクが切れてるため、おそらく販売停止ぽいですね、残念......

ギャラクシーエンジェル　PC版について。 - Togetter

username や filename は、これから区切ろうと思う（userName や file_name としようと思う）

2020-10-20T14:04:20+09:00

TL; DR

区切らない場合、属性が追加される際に面倒になると思いました（実際なりました）。

はじめに

username とか filename を区切らない派でしたが、今日から区切る派（userName, file_name などと命名する派閥）になろうと思います。

区切る派に変更した理由

急に新しい name 属性が増えた際に、対応が面倒だと気づいてしまいました。

例1

username （ユーザー名）属性が存在する際に、「ユーザー表示名」属性が必要になった場合、 userDisplayName と username が併存しているのは気持ち悪いです。
かといって、 displayname は長すぎて、個人的には区切りたい欲が強くなりますが、その場合は displayName と username が併存するため、やっぱり気持ち悪いです。

例2

filename （ファイル名）属性が存在する際に、「入力ファイル名」属性が必要になった場合、区切りとして input_filename は違和感があります。
かといって input_file_name と filename が併存しているのは気持ち悪いです。

おわりに

命名は難しいですね。

Qrunch から Crieit に引越しする

2020-10-05T00:21:23+09:00

TL; DR

Qrunch から引越しました。

はじめに

Qrunch がサービス終了することになり、引越し先を決めなければならなくなりました。

一旦、 Crieit に移行することにし、 Qrunch との違いなどを記載しようと思います。

引越し手順

以下の手順で、手動で引越しします。

Qrunch 記事のエクスポート
Crieit への記事追加（下書き）
下書き記事の公開
Qrunch 記事のカノニカル設定付与

Qrunch 記事のエクスポート

Qrunch の記事をエクスポートし、Markdown 形式のテキストファイルをダウンロードします。

Crieit への記事追加（下書き）

エクスポートした記事ファイルから、次の3つを移行します。

記事本文
記事タイトル
タグ／カテゴリ

下書きとして全17記事を保存します。

下書き記事の公開

下書き記事を、順次公開します。
公開するごとに URL を記録しておきます。

Qrunch 記事のカノニカル設定付与

Crieit に公開した記事の URL を、 Qrunch 記事のカノニカル設定 URL に付与します。
カノニカル設定をすることで、 Qrunch の記事購読者の流出防止を期待してます（正しい使い方なのかは分かりませんが......）。

Qrunch の記事は 2020/10/4 まで編集可能であったため、それまでに何としてでもこれを設定したかったです。

Tips

単純に移行は、やはりできませんでした。
そのため、いくつか移行時にコツがあるため、それについて記載します。

Qrunch 記事の絵文字が一部正常にエクスポートできない

Qrunch の記事として記載していた絵文字が、一部正常にエクスポートできませんでした。
こちらは、単純に記述すれば問題ありません。

Crieit のコード記述 Markdown でコードタイトルが記述できない

Crieit のコード記述 Markdown は、コードタイトルが記述できません。

この問題に気づいたのは、記事を公開してからです。
記事記述中のプレビューと、記事公開時の画面では、表示が異なっていました。
コードタイトルを記述している場合、正常にコード表示できません。

しかも、 Markdown の構文解析を常時実施しているわけではなさそうで、一部だけコードのように記述される場合があるなど、表示させるためには多少のコツが必要っぽいです。

Qrunch のタグとカテゴリを合わせる必要がある

Qrunch には、タグとカテゴリの2種類が存在しました。
当然、 Crieit にはタグの1種類しか存在しないため、合わせる必要があります。

Crieit のタグはコピペで設定できない

Crieit のタグは空白文字区切りでないため、エクスポートファイルのタグ表示欄を単純にコピペはできません。
コピペする場合、1タグごとにコピペする必要があります。

おわりに

永住の地が無いことは承知の上ですが、一旦はこれで腰を落ち着かせようと思います。
使い勝手が違うため、いろいろ間違っているかもしれませんが、ご了承ください。

PowerShell で Git の reset/stash などを使う際に履歴を指定する方法

2020-10-04T23:29:37+09:00

本記事は、 Qrunch からの移転記事です。

移転元: PowerShell で Git の reset/stash などを使う際に履歴を指定する方法 - 雑木林

TL; DR

中括弧で表記する文字列は ' で囲みましょう。

はじめに

みなさんおなじみ、履歴を戻すコマンドは、下記の通りです。

gitで履歴を戻すコマンド（実行不可）

git reset HEAD@{0}

また、スタッシュを適用するコマンドは、下記の通りです。

gitでスタッシュを適用するコマンド（実行不可）

git stash pop stash@{0}

しかし、 PowerShell で上記を実行しようとすると、次のエラーが発生し、履歴リセット／スタッシュ適用できません。

PowerShellで履歴を戻そうとした際のエラー

error: unknown switch `e'

解決策

PoserShell では、中括弧に特別な意味があるため（スクリプトブロックと呼ぶらしい）、中括弧内の文字列をコマンドとして実行してしまうからみたいです。

about_Script_Blocks - PowerShell | Microsoft Docs

' で囲み文字列化することで、実行できます。

gitで履歴を戻すコマンド（文字列化）

git reset 'HEAD@{0}'

gitでスタッシュを適用するコマンド

git stash pop 'stash@{0}'

または、中括弧エスケープ処理をすることでも可能です。
PowerShell のエスケープシーケンスは ` ですよね。

gitで履歴を戻すコマンド（エスケープ処理）

git reset HEAD@`{0`}

git reset HEAD@{1} results in error · Issue #106 · dahlbyk/posh-git

おわりに

エラー文だけでは理解できず、地味に苦労しました。
PowerShell は ~~めんどくさい~~ 奥が深いですね。

実践UML記述法：ユースケース図におけるユースケース間の関係の書き方を疑似コードから逆変換して考える

2020-10-04T23:28:17+09:00

本記事は、 Qrunch からの移転記事です。

移転元: 実践UML記述法：ユースケース図におけるユースケース間の関係の書き方を疑似コードから逆変換して考える - 雑木林

TL; DR

ユースケース図の include および extends は、それぞれメソッドおよび if 文が真の場合のメソッドに変換できます。
また、拡張点は if 文の真偽値判定に変換できます。

本題：ユースケース図におけるユースケース間の関係の書き方を疑似コードから逆変換して考える

UMLのダイアグラムの1つに、ユースケース図というものがあります。
ユースケース図とは、ステークホルダーとシステムの関係を、簡易的に図として表現するものです。

以下のような図を、人生で1度は見たことがあるはずです。

@startuml
title 冷蔵庫利用者のユースケース図

left to right direction

actor "利用者" as user

rectangle 冷蔵庫 {
  usecase set_item as "食品を入れる
  ---
  extension points
  食品にラッピングが付いている"
  (食品を取る) as get_item
  (ドアを開ける) as open_door
  (ラッピングを外す) as remove_wrapping
  set_item ..> open_door : <>
  get_item ..> open_door : <>
  set_item <.. remove_wrapping : <>
}

user --> set_item
user --> get_item
@enduml

問題点

ここで、よく混乱するのが include および extend の意味、および、矢印の向きです。

include は、あるユースケースは別のユースケースを包含している、という意味を表します。

ユースケースBの中には、ユースケースAが含まれていることを示します。
「has a」関係、つまり、「ユースケースB has a ユースケースA」の関係が成り立ちます。

extend は、あるユースケースが別のユールケースを拡張する、という意味を表します。

ユースケースAに対して、機能を追加するようなユースケースBの関係を示します。

ユースケース図(Use Case Diagram) - UML入門 - IT専科

この包含と拡張、という単語の違いは、個人的には非常に理解が難しかったです。
それにより、以下の疑問が顕在化します。

どのように include と extend を使い分けるのか
なぜ extend の矢印の向きは include と逆なのか

しかし、下記ページにより、長年の疑問が解けたので、解説しようと思います。

ユースケース図のincludeとextend:アーキテクト360

解決策

エンジニアは、図で理解するより、ソースコードで理解する方が簡単ですよね。
ということで、上記ユースケース図の例を、疑似コードに置換えてみます。

冷蔵庫利用者のユースケース疑似コード

# TODO: 例として挙げたユースケース図からは、ユースケースの実行順序までは読取れない

def ドアを開ける:
    # ドアを開ける際の処理記述

def ラッピングを外す:
    # ラッピングを外す際の処理記述

def 食品を入れる:
    if 食品にラッピングが付いている:
        ラッピングを外す()
    ドアを開ける()
    # 食品を入れる際の処理記述

def 食品を取る:
    ドアを開ける()
    # 食品を取る際の処理記述

各ユースケースは、各メソッドと対応します。

include の関係先ユースケース（例における「ドアを開ける」ユースケース）は、関係元ユースケース（例における「食品を入れる」ユースケースおよび「食品を取る」ユースケース）の共通部品として、関数内で呼出すメソッドとして対応します。

extend の関係元ユースケース（例における「ラッピングを外す」ユースケース）は、関係先ユースケース（例における「食品を入れる」ユースケース）を一部拡張するため、拡張点「食品にラッピングが付いている」場合にのみ呼出すメソッドとして対応します。

ここで注意ですが、例として挙げたユースケース図からは、ユースケースの実行順序までは読取れないことに気をつけてください。
例えば、「食品を入れる」ユースケースで実行する、「ドアを開ける」ユースケース／「ラッピングを外す」ユースケース／「食品を入れる」ユースケースの3つ（3番目は、ユースケース自身のユースケースを指す）は、本来は前後関係がありますが、ユースケース図からは読取れません。
「ドアを開ける」前に「食品を入れる」ことはできませんし、「ラッピングを外す」前に「食品を入れる」ことは、本来はできないので、疑似コードでは順序を指定してます（ドアを開けた後にラッピングを外すことはできますが、電気代が掛かるので、先にラッピングを外しています）。

表でまとめると、下記の通りです。

ユースケース図	疑似ソースコード
ユースケース	メソッド
`include`	関係元ユースケースの内部で実行するユースケース
`extend`	関係先ユースケースの内部で、拡張点が真の場合に実行するユースケース
拡張点	`extend` の関係元ユースケースを実行する場合は真を表す真偽値

こう見ると、最初の疑問点がはっきりすると思います。

どのように `include` と `extend` を使い分けるのか

include の関係先ユースケースは、複数のユースケースから呼出されることを想定し、共通部品化すると良いです。

extend の関係元ユースケースは、まず関係先ユースケースを共通部品化し、ある分岐点（拡張点）でのみ実行するユースケースとして外出しすると良いです。

なぜ `extend` の矢印の向きは `include` と逆なのか

ここは、私の個人的な見解を述べます。

extend が include と逆向きなのは、 extend の関係元ユースケースが拡張点を求めていることが理由と考えます。
すなわち、 extend の関係元ユースケースは、関係先ユースケースにおける拡張点に「依存」していると言えるのではないか、と考えます。

疑似コードを見ればわかりますが、 extend の関係先ユースケースに拡張点が存在しないユースケース図は、どのような場合に関係元ユースケースが実行されるのか、判断できかねます。
つまり、 extend の関係元ユースケースと、関係先ユースケースの拡張点は、セットであると考えるのが自然です。
さらに言えば、 extend の関係元ユースケースは、関係先ユースケースの拡張点なしには関係を結ぶことは難しく、拡張点に依存して存在を維持している関係である、と言うこともできます。

結論

ユースケース図の関係は、疑似コードから逆変換して考えてみると、理解しやすい気がします。
UMLは高度に抽象的であるため、具象的な疑似コードに置換えることで、把握しやすいのかもしれません。

これを元に、ユースケース図がもっと流行ることを期待します。

GitHubのデフォルトラベルを和訳 + 絵文字付加

2020-10-04T23:26:27+09:00

本記事は、 Qrunch からの移転記事です。

移転元: GitHubのデフォルトラベルを和訳 + 絵文字付加 - 雑木林

TL; DR

絵文字	原文	和訳
🐛	bug	不具合
📝	document	ドキュメント
🔙	duplicate	別チケット有
✨	enhancement	新機能など
🤝	good first issue	初心者歓迎
🆘	help wanted	助けて！
⛔	invalid	不適当な内容
❔	question	質問
❌	wontfix	意図的な中止

はじめに

GitHubのリポジトリを最初に作成すると、Issue／プルリクのラベルとして、下記が出現します。

これらの意味を知りたくなったので、調べてみます。
ついでに、該当しそうな絵文字を探して付けてみます。

各ラベルの説明と和訳と絵文字

以降、各ラベルについての説明と和訳、そして絵文字を付けてみます。

下記に参考ページを載せます。

About labels - GitHub Help

bug

特に言う必要は無いと思いますが、バグですね。
ただ、日本ではバグという言葉は強すぎるという意見もあるので、「不具合」の方がいいかもしれません。
絵文字は 🐛 でいいんじゃないですかね。

documentation

これは、比較的最近作られたラベルですかね？
上記画像のリポジトリは2年前くらいに作ったので、存在しないです。

純粋に、「ドキュメント」で良いと思います。
絵文字は 📝 にしましょう。

duplicate

これは、既存のIssueが既に立っていることを示します。
「別チケット有」なんてどうでしょうか？
絵文字は、ドンピシャなものが無かったのですが、 🔙 とします。

enhancement

新機能や要望のIssueでよく見かける気がします。
「新機能など」とすることで、機能追加以外についてもこのラベルで対応できるのではないでしょうか。
絵文字は、みんな大好き ✨ です。

good first issue

直訳では「最初のIssueに良い」ですかね。
実は「最初のコントリビューター向けのIssue」、という意味があるそうです。
意訳ですが、「初心者歓迎」なんてどうでしょうか？
絵文字は 🤝 なんていいですね。

OSS 貢献における GitHub の Issue 探しについて手始めに調べてみた - Qiita

help wanted

GitHubのヘルプページには「メンテナが課題やプルリクについて助けを求めていること」とあります。
ということで、意訳ですが「助けて！」としてみます。
最後のびっくりマークにより、声を大にして求めている感じを出しています。
絵文字は 🆘 がぴったりです。

invalid

文法エラーなどでもよく登場しますが、直訳では「無効な」という意味です。
Issueにラベル付けすることを考えると、「不適当な内容」としてみると良いかもしれません。
不適切とまでは言わないが、Issueに価値が無くなってしまったことを伝えたいです。
絵文字は悩みましたが、このラベルが付いたらクローズされそうなので、 ⛔ としてみました。

question

質問する際に使えますね。
和訳も「質問」で良いと思います。
絵文字は ❔ としてみます。
❓ もありますが、デフォルトラベルの背景色が赤紫っぽかったので、白色の方にしました。

wontfix

不具合はあるが未修正のままにするなどのように、あえて変更しないことを意味します。
「意図的な中止」とすることで、意図が伝わる気がします。
絵文字は ❌ がいいですかね。

おわりに

英語だととっつきづらいものも、日本語にすることで理解が進みますね。
絵文字文化ももっと広まることを願います。

Gitのコミットメッセージに絵文字付きプレフィックスを適用する

2020-10-04T23:25:37+09:00

本記事は、 Qrunch からの移転記事です。

移転元: Gitのコミットメッセージに絵文字付きプレフィックスを適用する - 雑木林

TL; DR

コミットメッセージのプレフィックスは、Angularスタイルを基準としています。
また、各プレフィックスに絵文字を付ける際は、下記のようにしています。

プレフィックス	絵文字	絵文字の綴り
feat	✨	sparkles
fix	🐛	bug
docs	📝	memo
style	📁	file_folder
refactor	♻️	recycle
perf	⚡️	zap
test	✅	white_check_mark
chore	🍰	cake
init	🎉	tada
merge	🔀	twisted_rightwards_arrows
review	👌	ok_hand
wip	🚧	construction

はじめに

コミットメッセージにプレフィックスを付ける文化が、少しずつ広がっています。

一方、コミットメッセージに絵文字を付ける文化も、広まりつつあります。

両者を組合せれば、最強のプレフィックスが出来上がるのではないかと考えました。
ということで、絵文字付きプレフィックスという考え方を提案し、ここに記すこととします。

コミットメッセージにおける絵文字の付け方

コミットメッセージに、絵文字名を : で挟むことにより、GitHub上で表示できます。
また、コンソール上では、 emoji-cli などを利用することで、表示が可能です。

コマンドラインで emoji を扱う - Qiita

例えば、 ✨ (sparkles) という記号をコミットメッセージに書きたい場合、コミットメッセージを次のように記述します。

:sparkles: feat(ruby): やさしい日本語ページのルビタグ対応

すると、GitHub上のコミットメッセージとして登録されます。

covid19-miyazaki/covid19: 宮崎県(非公式) 新型コロナウイルス感染症対策サイト / Miyazaki COVID-19 Task Force website

コミットメッセージの1行目は、表示できる文字数に制限があるため、長すぎる絵文字名の絵文字は気をつけたほうがいいかもしれません。

git commit 時に書くコミットメッセージ1行目の表示文字数上限を調べてみた - Qiita

各プレフィックスと絵文字の紐付け

大前提として、プレフィックスを使う場合は、リポジトリ内で統一する必要があります。
これは、プレフィックスを使ったとしても、意味がわからなければ伝わらないからです。
同様に、多くの種類の絵文字を使うことも否定的です。
これからの時代は、プロジェクト毎に、コーディングスタイルと共にコミットメッセージスタイルも定義する必要があると思います。

今回は、Angularスタイルのプレフィックスを参考にします。
~~理由は、それ以外のスタイルを知らないからです。~~

angular.js/DEVELOPERS.md at master · angular/angular.js

また、絵文字については、Gitmojiを参考にします。
~~理由は、サイトが綺麗だからです。~~

gitmoji | An emoji guide for your commit messages

オリジナル絵文字を利用する場合は、GitHubで使える絵文字チートシートを参考にします。

🎁 Emoji cheat sheet for GitHub, Basecamp, Slack & more

以降、各プレフィックスの内容を説明し、それに見合った絵文字を紹介します。

feat

feat: A new feature

新機能を追加する際に利用します。

Gitmojiでは、同等の絵文字として ✨ (sparkles) を定義しています。
新機能を導入する際に使う絵文字です。

:sparkles: Introducing new features.

ということで、 feat には ✨ (sparkles) を利用します。

余談ですが、新機能というと、無かった機能を追加した際のみにも聞こえます。
僕の場合は、既存機能を変更する際や、既存機能を削除する際にも使っています。
変更／削除についても、変更することによって統一性が図れるとか、削除することによってUIが向上するとか、変更／削除そのものが機能追加という場合が多いなーと思っていたからです（いわゆる enhansement と同じ意味として捉えています。
これについては、プロジェクト毎に決めておくといいかもしれません。

fix

fix: A bug fix

不具合を修正する際に利用します。

Gitmojiでは、同等の絵文字として 🐛 (bug) を定義しています。
意味は全く同じです。

:bug: Fixing a bug.

ということで、 fix には 🐛 (bug) を利用します。

また余談ですが、個人的には、修正コミットに 🐛 を付けることは、若干抵抗があります。
GitHubでIssueファーストの開発をしていると、Issueでは不具合発見として 🐛 を付けて、修正プルリクとして 🐛 の絵文字を付けてしまいませんか？
🐛 という絵文字自体には2つの意味があるからです。

不具合発見時
不具合修正時

前者は 🐛 で問題ないのですが、後者については考える余地があるはずです。
もし虫網や虫籠の絵文字があれば、それを使っていたのですが......

コミット時に不具合を意図的に入れることは考えられない点と、不具合発見時をコミットメッセージで表すことが無い点、さらに不具合 == バグ == 🐛 を知らないエンジニアがほぼいない点を考慮して、 fix には 🐛 がいいかなと考えました。

docs

docs: Documentation only changes

ドキュメント類を修正する際に利用します。
修正と言っていますが、追加や削除時にも使ってよいと思います。

Gitmojiでは、同等の絵文字として 📝 (pencil) を定義しています。
ドキュメント類を記述する際に利用します。

:pencil: Writing docs.

また、 pencil と memo は、GitHubでは同じ絵文字として認識されます。

ちなみに、鉛筆だけの絵文字は pencil2 です。
~~これは酷い......~~

ということで、 pencil では文字ベースとして判断しづらい点から、 📝 (memo) を利用します。

style

style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)

ソースコードの可読性を変更する際に利用します。
Lintを適用した際や、空行を追加した際など、振舞いに変化を与えない変更が該当します。

Gitmojiでは、 🎨 (art) が当てはまるかもしれません。
🎨 は、ファイル構造を変更する際、または、ソースコードのフォーマットを変更する際に利用します。

:art: Improving structure / format of the code.

style という観点で言えば、2番目の意味に該当することは間違いありません。
また、1番目の意味も、ファイル構造の style という側面で見れば、該当すると見ることもできます。

しかし、 art という単語からは、UIに関連しそうなイメージが付きます。
実際、下記のようなIssueも上がっています。

🎨 for design and 📐 for structure · Issue #320 · carloscuesta/gitmoji

style という内容に合わせるため、ここでは 📁 (file_folder) を利用します。

📁 File Folder Emoji

refactor

refactor: A code change that neither fixes a bug nor adds a feature

ソースコードの可読性を向上する際に利用します。

Gitmojiには、同等の絵文字として ♻️ (recycle) を定義しています。
意味はほとんど同じです。

:recycle: Refactoring code.

ということで、 refactor には ♻️ (recycle) を利用します。

perf

perf: A code change that improves performance

パフォーマンスを向上する際に利用します。

Gitmojiには、同等の絵文字として ⚡️ (zap) を定義しています。
意味は全く同じです。

:zap: Improving performance.

ということで、 perf には ⚡️ (zap) を利用します。

test

test: Adding missing or correcting existing tests

テストコードを追加する際や、既存テストコードを修正する際に利用します。

Gitmojiには、同等の絵文字として ✅ (white_check_mark) を定義しています。
意味は全く同じです。

:white_check_mark: Updating tests.

また、チェックマークの絵文字は、他にも ✔️ (heavy_check_mark) が存在します。

正直、どちらでもいいとは思います。
個人的には、Windowsでの開発が多かったため、 ✔️ を利用していました。
✔️ のチェックの色が緑色で、わかりやすかったためです。

しかし、他OSではチェックの色が黒色で、わかりづらくなっています。
一方、 ✅ は、殆どのメーカーが緑色矩形の白抜きチェックであり、わかりやすくなっています。

ということで、 test には ✅ (white_check_mark) を利用します。

chore

chore: Changes to the build process or auxiliary tools and libraries such as documentation generation

自動生成ツールによりファイルを変更する際に利用します。
chore とは、雑務という意味があります。

choreの意味・使い方・読み方 | Weblio英和辞書

Gitmojiには、該当する絵文字はありません。
一部分で該当しそうな絵文字は、いくつか定義しています。

少し頭を悩ませましたが、英語圏のスラングである 'It's a piece of cake' から取って、 🍰 (cake) を利用します。

it's a piece of cakeの意味・使い方・読み方 | Weblio英和辞書

Angularスタイル以外

以下は、Angularスタイル以外のコミットメッセージで利用する絵文字です。
プレフィックスは付けても付けなくても構いません。

First commit

最初のコミットとしてよく使われる first commit ですが、Gitmojiでは 🎉 (tada) として定義しています。

:tada: Initial commit.

ということで、 first commit には 🎉 (tada) を利用します。
プレフィックスは init とします。

余談ですが、個人的には first commit を空メッセージにするのは懐疑的です。
必要無いから消したのか、書き忘れたのか、空メッセージでは判断できないためです。

Gitの最初のコミットは空コミットにしよう - Qiita

Merge commit

マージ実行時のコミットですが、Gitmojiでは 🔀 (twisted_rightwards_arrows) として定義しています。

:twisted_rightwards_arrows: Merging branches.

ということで、マージコミットには 🔀 (twisted_rightwards_arrows) を利用します。
長いですが、マージコミットの1行目はあまり重要であることは少ないため、問題なしとします。
プレフィックスは merge とします。

Review commit

レビュー指摘反映時のコミットですが、Gitmojiでは 👌 (ok_hand) として定義しています。

:ok_hand: Updating code due to code review changes.

ということで、レビュー指摘反映コミットには 👌 (ok_hand) を利用します。
~~あまり個人的には多用しないようにすべきとは思いますが......~~

WIP commit

作業中コミット (WIP: Work in Progress) ですが、Gitmojiでは 🚧 (construction) として定義しています。

:construction: Work in progress.

ということで、作業中コミットには 🚧 (construction) を利用します。
プレフィックスは wip とします。

おわりに

現在ではプライベートリポジトリでしか利用してませんが、個人的には可読性が上がっている気がします。
これを開発チームに展開して共有できれば、また違った世界が見えるかもしれません。

絵文字は、用法用量を守り、適切にご利用ください。

ちなみに

Gitmojiでは、本記事と似たようなIssueが立っていました。
もしかしたら、Gitmoji側で方針が決まるかもしれません。

Add a "semver" field for each emoji · Issue #429 · carloscuesta/gitmoji

こんなリポジトリもあります。
これを使えば、本記事の内容をPJで統一しやすくなりますね。

negokaz/git-fancy-message-prefix: A Git prepare-commit-msg hook for fancy commit message

Qrunchにおける自身のブログページからタグを消す方法

2020-10-04T23:24:24+09:00

本記事は、 Qrunch からの移転記事です。

移転元: Qrunchにおける自身のブログページからタグを消す方法 - 雑木林

TL; DR

次の2つを実施すれば良いです。

「よく使うタグ」モジュールの除去
記事下のタグ表示エリアの除去

はじめに

以前、Qrunchにおけるタグとカテゴリの使い分けについての記事を書きました。
その際、「タグはQrunchサービス全体の分類子として、カテゴリは自身のブログ内の分類子として、それぞれ使い分けができそう」と書きました。

Qrunchのタグとカテゴリの使い分けベストプラクティス

しかし、Qrunchのブログページにおけるデフォルトデザインには、何ヶ所かタグを表示しています。
そのため、タグをブログページでは使わないようにするための手法が、完全に使えるとは言えません。

本記事では、Qrunchのブログページからタグを消す方法を記します。

タグを消す方法

まず、デザイン修正方法を記します。

Qrunchでは、ブログページのデザインをカスタマイズできます。
ダッシュボードのサイドバーにおける、デザイン欄を選択してください。

すると、「デザインの設定」ページに飛びます。
この画面から、デザインを修正していきます。

Qrunchのブログページに存在するタグ表示エリアは、サイドモジュールとフッターの2箇所です。
それぞれについて、消す方法を記します。

サイドモジュールからタグを消す

サイドモジュールからタグを消す方法は、ワンクリックで可能です。

サイドバーにおける「サイドモジュール」欄の「よく使うタグ」項目を削除すれば良いです。

フッターからタグを消す

フッターのデザインは、カスタムCSSで消します。

サイドバーにおける「カスタムCSS」欄のテキストエリアに、 .content-module.tag-content-module.entry-content-module クラスを非表示にするCSSを入力します。

.content-module.tag-content-module.entry-content-module {
    display: none;
}

おわりに

これで、Qrunchのブログはカテゴリでしか分類できなくなりました！
タグをカテゴリをうまく使い分け、よいQrunchライフを送ってください。

Sublime Text起動中に「LocalBridge.exe - 正しくないイメージ」というエラーが発生する場合の対処法

2020-10-04T23:22:43+09:00

本記事は、 Qrunch からの移転記事です。

移転元: Sublime Text起動中に「LocalBridge.exe - 正しくないイメージ」というエラーが発生する場合の対処法 - 雑木林

TL; DR

Officeというアプリを消しましょう。
うまくいく場合があります。

Skypeが入っている場合も、消せる場合は消しましょう。

はじめに

Sublime Textを起動中、突如謎のエラーダイアログが出てくる場合があります。

LocalBridge.exe - 正しくないエラー

X:¥Users¥USER_NAME¥AppData¥Roaming¥Sublime Text 3¥Packages¥IMESupport¥imesupport_hook_x64.dll は Windows 上では実行できないか、エラーを含んでいます。
元のインストール メディアを使用して再インストールするか、システム管理者またはソフトウェアの製造元に問い合わせてください。
エラー状態 0xc000012f。

このエラーダイアログ、Sublime Text起動直後は特に発生しませんが、数分起動し続けていると出てきます。
しかも、Sublime Textが起動中は、エラーダイアログを消しても消しても邪魔してきます。
Sublime Textを消した後、数回エラーダイアログを消し続けることで、ようやく消えます。

これを完全に消す方法を探ります。

原因

どうやら、 IME Support プラグインが原因のようです。

https://github.com/chikatoike/IMESupport/issues/27

IME Supportプラグインでは、 imesupport_hook_x64.dll というライブラリを利用しています。
このライブラリの実態を、実はOfficeアプリ（後述）でも利用してしまっており、OfficeアプリとSublime Textの両方で同じライブラリを掴もうとする際に、エラーダイアログが出現してしまいます。

1-1/3+1/5-1/7+1/9-・・・:Sublime Text3の設定メモ - livedoor Blog（ブログ）

解決方法（暫定）

Officeアプリをアンインストールすることで、解決できます。

Officeアプリというのは、いわゆるWordやExcelといったMicrosoft Officeの1アプリではなく、特に必要ない「新しい Office を始めよう」または「My Office」というような名前の、Office製品自体を管理するアプリのようです。

このアプリをアンインストールしても、他のExcelやWordといったMicrosoft Officeのアプリは消えないので、問題ありません。

おわりに

Sublime Textを使う人は、ほとんどがIMESupportを入れていると思うのですが、ほとんどエラー対処法が見つからなくて困りました。
これで、少しでもエラーダイアログのイライラが解消できたら幸いです。

実は

また表示されました。
今度は SmartAudio3.exe になってます。

Officeアプリ消したけど、他にも掴んでいるんでしょうか？
続報を待て！

Qrunchのタグとカテゴリの使い分けベストプラクティス

2020-10-04T23:21:48+09:00

本記事は、 Qrunch からの移転記事です。

移転元: Qrunchのタグとカテゴリの使い分けベストプラクティス - 雑木林

TL; DR

タグはたくさん書こう。
カテゴリは少なく書こう。

はじめに

Qrunchで記事を書くときに、真っ先に出てくるタグをカテゴリ。

この2つの違いを正確に理解している人は、果たしてどれだけいるんでしょうか？
僕はわかりません！

ということで、Qrunchのタグとカテゴリの挙動から、どのように使い分けたらいいのか、そのベストプラクティスを探ります。

挙動調査

下記のような記事を作成し、タグとカテゴリの挙動を調べます。

事前知識

タグとカテゴリを知る前に、どうしても理解しておく必要があるものがあります。
それは、「Qrunch.net」と「Qrunchブログ」です（この2つの名称は、本記事独自のものです）。

「Qrunch.net」とは、いわゆるこの画面です。

Qrunchの記事として書かれた様々な項目が、一覧として表示されています。

一方、「Qrunchブログ」というのは、上記画面の記事を書いている各ユーザーが主体のブログのことです。
これは、各ユーザーごとにフォーマットが異なります。

Qrunchというサービスは、この「Qrunch.net」と「Qrunchブログ」の2つを併せ持つサービスのことです。
ということを前提に、話を進めていきます。

また、「Qrunchブログ」のフォーマットは、Editorialを利用しています。

カテゴリ

記事にカテゴリを付けると、「Qrunchブログ」における記事上部にカテゴリとして表示されます。

また、「Qrunchブログ」の側面に、既存の記事全てのカテゴリを「カテゴリ」という項目として一覧表示しています。

しかし、「Qrunch.net」の記事の方には、何も表示されません。
「Qrunch.net」を色々見てみましたが、それらしい項目は見つかりませんでした。

「Qrunchブログ」のカテゴリをクリックすると、同じカテゴリを付けている自身の記事が一覧表示できます。

つまりカテゴリとは、「Qrunchブログ」にのみ表示される分類子ということです。

挙動調査まとめ

タグは「Qrunch.net」と「Qrunchブログ」の両方に影響を与えるのに対して、カテゴリは「Qrunchブログ」にのみ影響を与えるみたいです。

また、タグもカテゴリも分類子であり、タグは「Qrunch.net」における他ユーザーの記事も表示できるのに対し、カテゴリは「Qrunchブログ」の自身の記事のみ表示できるようです。

ベストプラクティス

次のような使い方を提案します。

タグの使い方

記事におけるタグは、その記事に関連していそうなキーワードをできるだけ書いておきましょう。

これにより、次のような効果が期待できます。

「Qrunch.net」からのユーザー流入の向上
- 他ユーザーの記事のタグと同じタグを指定できれば、関連記事としてユーザー流入を見込めます。
「Qrunch.net」における他記事タグとの表記揺れの解消
- 大文字小文字を区別する仕様があったり、英語表記カタカナ表記といった表記揺れを解消することで、同じタグの指定率の向上が見込めます。

しかし、次のようなデメリットも存在します。

「Qrunchブログ」の関連記事が見つかりづらい
- 自身の「Qrunchブログ」で関連記事を見つけたい場合、どのタグで検索すれば良いかわかりづらい
タグの管理が大変になりやすい
- 全ての表記揺れに対応する場合、タグの表記揺れ対応項目を全て記録しなければ、タグから関連記事への遷移が困難になってしまいます。

上記デメリットを解消するのが、カテゴリの利用です。

カテゴリの利用

記事におけるカテゴリは、自身の「Qurnchブログ」における分類子として、自身が管理できる量だけ記載しましょう。

これにより、次のような効果が期待できます。

タグ乱立による「Qrunchブログ」関連記事検索性低下の防止
- 自身の「Qrunchブログ」内では、タグ検索ではなくカテゴリ検索を使うことで、「Qrunchブログ」内の関連記事の検索性を維持できます。
タグ乱立によるタグ管理性低下の防止
- 自身の「Qrunchブログ」内では、カテゴリ検索による関連記事への遷移を主軸とするため、タグ管理をする必要がなくなります。
- カテゴリ管理はする必要がありますが、カテゴリの量は少なく（管理できる量だけ記載）するため、管理の負担は少なくなります。
独自の分類子による「Qrunchブログ」内の検索性向上
- 自身の「Qrunchブログ」でしか通用しない独自の分類子を、カテゴリとして指定することにより、「Qrunch.net」のタグとは無関係そうな分類子を独自に定義できます。
- シリーズ物などに独自カテゴリを指定することで、「Qrunchブログ」の検索性の向上が見込めます。

カテゴリが「Qrunch.net」に影響を与えないことを逆手にとった活用法が考案できます。

おわりに

Qrunchにおけるタグとカテゴリは、影響範囲が異なります。
つまり、タグはQrunchサービス全体の分類子として、カテゴリは自身のブログ内の分類子として、それぞれ使い分けができそうです。

もちろん、タグの濫用は御法度ですよ。
他ユーザーの迷惑にならない程度に、全く無関係のタグは付けないようにしましょうね。

用法用量を守って、良いQrunch生活を送りましょう！

Qrunchの記事を間違えて全削除してしまった！！！から頑張って復活させた

2020-10-04T23:21:00+09:00

本記事は、 Qrunch からの移転記事です。

移転元: Qrunchの記事を間違えて全削除してしまった！！！から頑張って復活させた - 雑木林

それは起きてしまった悲劇

2020年4月25日、早朝4:30頃の出来事でした。
「数か月ぶりにQrunchでも書こう」
16日間もの長期休みを手に入れ、仕事終わりに動画鑑賞で夜明けを迎える直前に、ふと思い立ったのです。

記事の内容は、タグとカテゴリの整理についてです。
そのため、記事を書く前に、まずは自身のQrunch記事のタグとカテゴリの整理をしておきたかったのです。

一旦、既存の全記事に目を通し、タグとカテゴリを整理しました。
更新が必要な記事は更新ボタンを、そうでない記事は戻るボタンを、それぞれ押下して、整理していきました。

PlantUMLはこちら

@startuml
title Qrunchにおける記事更新の画面遷移

hide empty description

state "Qrunchトップ" as qrunch
' state "ダッシュボード" as dashboard {
    state "ダッシュボードトップ" as dashboard
    state "記事の管理" as console
    ' [*] -> dashboard.top
    ' dashboard.console -> [*]
' }
state "記事" as entry
state "更新完了" as updated
entry : do / 更新すべき箇所を確認する

[*] --> qrunch : https://qrunch.net を開く
qrunch --> dashboard : 自身のアイコンから\n「ダッシュボード」メニューを選択する
dashboard --> console : 「記事の管理」\nメニューを\n選択する
console --> entry : まだ見ていない記事を開く\n[未確認記事が有る場合]
entry -> updated : 更新する\n[更新内容が有る場合]
updated --> console : 「記事の管理」メニューを\n選択する
entry --> console : 戻る\n[更新内容が無い場合]\n/投稿未完了ポップアップの表示
console --> [*] : [未確認記事が無い場合]
@enduml

そして、「記事を書く」ボタンを押しました。

記事を書こうとしたところ、ちょっと思い立って、編集画面で1箇所も手を入れずに、戻りました。
すると、ステートマシン図における「戻る」契機実施時と同様、「投稿未完了ポップアップ」が出たので、キャンセルを押下しました。

「記事の管理」画面に戻ってくると、何やらタイトルも内容も書いてない記事が生成されているようにみえるじゃないですか（再現画像です）。
（赤枠で囲った箇所です。 ~~え、どう見てもテーブルヘッダーですか？夜更かしで疲れてたんですよ！~~）

深く考えずに、チェックを入れます。
すると、チェックを入れたすぐそばに「記事を削除する」メニューが登場しました（再現画像）。

この時、僕は下の欄にある全ての記事にチェックが付いていることに気づきませんでした。
深く考えず、削除しようとします。

すると、Qrunchくんは丁寧に「削除した記事は戻せません」と警告してくれます。
優しいです。

でも、僕は空記事を削除したいので、気にせずOKします。

押した後、すぐには画面上に変化がありません。
空記事もそのまま残っているので、不思議だなと眺めていました。

直後、気づきました。
「あれ、この欄って、空記事じゃなくてテーブルヘッダーじゃね？」と。

焦るものの、まだ画面上には残っています。
一縷の望みをかけ、リロードします（悪手）。

すると、リロードするたびに、記事が消えていくではありませんか！
焦りますが、それでも正常性バイアスにより、リロードを続ける手は止まりません。

なんということでしょう。
綺麗になりましたね。

エンジニア魂に火がつく

焦りました。

記事が無くなることで被る被害は、下記の通りです。

記事の内容というドキュメントが消える
記事の内容を再び第三者に見てもらう機会が消える
過去の栄光が消える

1番目と2番目の理由により、ドキュメントが消えるのは非常に困りました。
また、プチバズった記事により今月（2020年4月現在）のQrunch「今日／今週／月間トレンド」第1位を総なめしたことで、僕の精神が支えられていたこともあり、3番目の理由によって非常に落胆してしまいました。

こんな時、どうすればよいでしょうか？

僕が最初に考えたのは、Qrunchのフィードバックで、全記事消しちゃいましたと泣き言を垂れることでした。
しかし......
初期のころから応援している／何度もTwitterで記事を拡散してくれる／ときどき拍手を50個くらいくれる......
そんなQrunch運営に「泣きつく手段がフィードバックかよ」と冷静になり、踏みとどまりました。

次に考えたのが、報告記事にすることでした。
Qrunch運営なら、きっと見てくれるだろう。
そんな期待を込めて、「消えちゃいました！助けてください」という報告記事を書こうと思いました。
~~（既にキャプチャ画像にタイトルだけの記事の下書きを作ってるのが見えてますね）~~
これなら、別に見てもらわなくても、ポエム記事として書けば正当化できます。

しかし、書こうとする直前で思いつきました。
せっかくなら、エンジニアらしく、記事を復活させてみよう、と。
運営の手間を取らせなくても、自分だけでできることをしてみよう、と。

ここで、僕の記事の内容は変わりました。

Qrunchの記事を削除してしまった際の手順

長い前段は終わりです。
ここからが、本記事の主題です。

すなわち、もしQrunchの記事を削除（全削除）してしまった場合、どうすればよいかの手順をここに記します。
僕が実際に行った事のうち、成果があったものについてのみ書きます（効果がなかったけど試してみたことについては、後程書きます）。

動作確認環境を、以下に記します。

Windows 10 Pro: version 1909, OS Build 18363.778
Google Chrome: version 80.0.3987.163（Official Build）, 64 ビット

ブラウザ上のWebページを遷移させないように保存する

まず大切なのは、現場保存です。
やみくもに動いてしまうのは、逆効果になりかねません。

まず、いま開いているQrunchの画面を表示しているブラウザ（タブ）を、残しておきましょう。
Chromeの場合、裏で待機しているタブ画面を呼出す際に、強制的に再読込する場合があるため、別ウィンドウで置いておくと良いでしょう。

また、HTML形式でローカル保存しておきましょう。
もし記事が残っている画面で保存できれば、記事のタイトル／タグ／URL等を記録できます。

僕は、偶然にも別タブでQrunchブログを開いていたため、そちらをローカル保存しました。

編集画面を戻る

偶然にも、僕は直前まで記事の編集をしていました。
そこで、開いているタブを戻ると、なんと、記事がそのまま残っているじゃないですか！

しかし、「記事を更新する」ボタンを押下すると、下記画面に遷移してしまいます。

そこで、記事の内容をコピーし、別記事として新規作成することで、記事の内容を避難させました。
（新着記事を荒らしてしまいました、すみません。）

僕の場合は、全8記事中6記事を更新したため、6記事はそのまま再作成できました。

Googleキャッシュに頼る

残り2記事ですが、うち片方の記事は大した内容を書いていないため、無くなっても問題ありません。
しかし、もう1つの方の記事は、アドベントカレンダーにも連携しており、またビューも多かった、思い入れのある記事でした。
この内容が消えるのだけは避けたかったです。

そこで、閃きました。
ビューが多いなら、Googleキャッシュにあるんじゃないだろうか？と。

調べてみると、なんと......
ありました！！

キャッシュしているWebページのHTMLを展開し、内容をタグごと直接記事にコピペすれば復活できます。

これで、ほぼ全ての記事を復活できました。

まとめ

記事の内容は復活できましたが、記事の記録は復活できませんでした。
しかし今は、ドキュメントさえ残ってくれたら、あまり気にすることはないかなと考えています。
トレンド1位という記録に浮かれすぎていた自分には、いい薬だったかもしれませんね。

まとめると、以下の通りです。

Qrunchの記事を全削除しちゃいました
頑張って復活させました
一部復活できなかったものがありますが気にしてません
仮に戻せるとしても、現状で特段困っていないので問題ありません

追記

なんと、Qrunch開発者である @codomisu さんから、直々にコメントをいただきました。
バックアップがあるとのことだったので、復旧をお願いしたところ、全て復旧していただけました。

しかも、僕が頑張って復活させた記事については、下書きへと変更してくださる気の利きように、感服いたしました。
復旧を確認次第、手動復活記事は消そうと思っていたので、ありがたかったです。

その上、実はここで一切触れていない下書き記事についても、復旧していただけました！
下書き記事については、そもそも要らないかなと無視していたのと、公開されてないし無理だろうと諦めていたので、まさか戻ってくるとは思いませんでした。

新たにまとめると、運営に泣きつけば全て解決していたのでは？というオチでした！！！
~~@codomisu さんには頭が上がりません。またファンになってしまうじゃないですか。~~

以上です、ご清覧ありがとうございました。

おまけと追記

要望

Qrunch運営さんがこの記事を読んでくれた時のために、要望を書いておきます。

記事一覧のテーブルヘッダーは、色を付けるなど、テーブルデータとの差異を強くしてほしい
記事削除時のメッセージは、別の場所に表示してほしい
（余力があれば）ユーザーによる削除処理ロールバックを可能にしてほしい

Qrunch開発者の @codomisu さんが検討してくださるとのことです。
ありがとうございます！

旧記事URL

削除してしまった旧記事のタイトルおよびURLを、下記に記します。
保存できなかった記事については、 ⭐ 絵文字を併記しています。

こちら、 @codomisu さんの手動復旧により、全て回復しました。

試してみたが駄目だったこと

「Qrunchの記事を削除してしまった際の手順」として試してみたが効果が無かったものについて、下記に示します。

Chromeキャッシュの呼出し

Chromeのキャッシュに記事内容が保存されていることを期待して、 ChromeCacheView を使ってみました。
実際に保存されている記事もあったものの、その全ては別手段で取得できるものでした。

また、キャッシュの中からjQueryを発見したので、URLが直接書いてあったりしないかと期待して探したのですが、当然のようにありませんでした。

アーカイブサイトの利用

アーカイブサイトを閲覧するために、僕が時々使う Internet Archive: Digital Library of Free & Borrowable Books, Movies, Music & Wayback Machine を利用してみました。
実際には、Qrunchトップページしか保存していないようでした（ブログの規模によって異なる可能性あり）。

1週間の在宅勤務で得た知見：その利点と欠点

2020-10-04T23:20:15+09:00

本記事は、 Qrunch からの移転記事です。

移転元: 1週間の在宅勤務で得た知見：その利点と欠点 - 雑木林

TL; DR

在宅勤務の利点と欠点は、個人差があると考えます。
私は在宅勤務したい派ですので、利点が多めに存在します。

皆さんも可能であれば、1度は在宅勤務を経験して、在宅勤務の利点／欠点を探してみてください。

はじめに

とある問題に対応するため、昨今では在宅勤務へと舵を切らざるを得ない企業が増えています。

弊社も、制度としての在宅勤務は認められているものの、実際に利用している方は多くない印象でした。
しかし、弊社でも「在宅勤務を推奨する」との通達が下りました。

私の所属しているチームでは、ほぼ全員が在宅勤務を実施することになり、先日で丁度1週間が経過しました。

個人的には、在宅勤務をしてみたいという欲望が渦巻くさなかの出来事であり、棚ぼた気分で1週間を過ごしました。
そこで得た知見、いわゆる在宅勤務の利点と欠点を、ここにまとめます。

在宅勤務の利点

私が感じた、在宅勤務の利点は、以下の通りです。
各項目について、それぞれ説明します。

満員電車に乗る必要が無い
朝の時間でゆったりできる
だらだらと残業しない
無駄な外食が減る
洗濯物を干せる
文章によるコミュニケーションをしっかりするようになる
うるさくても許される

満員電車に乗る必要が無い

在宅勤務の利点として、よく上げられる項目の1つです。

私自身、満員電車で苦痛を感じることは無いと思っていました。
しかし、電車に乗らない生活を1週間続けていると、心の変化をかなり実感できました。

簡単に言うと、朝から集中できます。

今思えば、電車から下車する際、疲れを感じていた気がします。
下りた時のホッとする感情は、車内で緊張している証拠だと言えます。
つまり、朝の集中力が、満員電車に吸い取られているわけです。

その集中力を、業務に充てることができ、心なしか朝の集中力が上がったように感じます。

朝の時間でゆったりできる

通勤時間が減るため、朝と夕の両方で、それぞれ1時間の空白ができます。
私は、その朝の時間をゆったりする時間に充てています。

ゆったりするとは、単純に寝ているわけではなく、起きる時間はいつもと同じに設定しています。
ただし、目を覚ました後は、いつ布団から出てもよい時間としています。

この利点は、朝から急ぐ必要が無くなる、というものです。

朝の時間は貴重だ、とよく言われますが、その理由は時間が無いからだと考えます。
にもかかわらず、私は贅沢にも、朝1時間をゆったりする時間として設定しているわけです。

そのうえ、今までは必須であった朝のタスクが、在宅勤務により減ります。
具体的には、着替えや髭剃りやお化粧などです。
これらは、テレビ会議必須のチームでは結局しなければなりませんが、私のチームでは、夕方にテレビ会議があるため、朝していた着替え等を、昼休み以降にずらすことができます。

この効果は想像以上でした。
目が覚めてしばらくはスマホを眺めつつ、だらだらと起きて顔を洗い、軽い食事を済ませてPCに向かうわけです。
その頃には、完全に脳みそが起きていることを実感できます。

よく、在宅勤務の欠点としてオンオフの切替ができない、というものが挙げられますが、私はこの時間を設定することで、PCに向かう瞬間にスイッチを切換えやすくすることができました。

だらだらと残業しない

だらだらと残業してしまう癖がある方は、もしかしたら会社から出るのが億劫だからではないでしょうか？

私はまさにそうで、会社から出る前に、外の天気を調べたり、忘れ物が無いかを確認したりする時間で、そのまま5分10分と居ついてしまうことが珍しくありませんでした。
在宅勤務では、外の天気を調べる必要も、忘れ物の確認も必要ありません。
終わるときは「終わります」と一報を入れて終わりです。

これも、前述の在宅勤務の欠点としてよく挙げられるオンオフの切替に一役買っていると考えています。

無駄な外食が減る

在宅勤務ということは、キッチンも冷蔵庫もあるわけです（無い場合もありますが）。
であれば、わざわざレストランやコンビニに寄らずとも、自宅で適当に調理すれば済みます。

私は料理を全くしない人間ですが、保存がきくパン類を事前に買いだめしておき、仕事中はモグモグして業務に従事しています。

事前に買いだめするということは、単価の高いコンビニではなく、比較的安価なスーパーで購入できます。
レストランに行く必要も無くなりました。
移動という運動もしなくなり、消費する食品量自体も減っている気がします。

詳細に計算したわけではないですが、食費については体感1/3まで減少しています。

洗濯物を干せる

洗濯物を朝から干している方は、凄いです。

私は、家を出る15分前に起きるダメ人間ですので、朝から干すためには、前日に洗濯機を回さなければ、洗濯物を干すことができません。
つまり、前日に洗濯機を回し損ねると、丸1日洗濯できない日が増えてしまいます。

在宅勤務では、洗濯機を朝から回しても、昼に干せば問題ありません。
布団だって、今までより干しやすくなります。

朝したいけど、時間が無くて諦めていたことができるようになると、生活の幅が広がります。

文章によるコミュニケーションをしっかりするようになる

現在のチームでは、Slackを利用したチームメンバー間のコミュニケーションを取っています。
以前までは対面とSlackの区別ができておらず、どちらを使ってコミュニケーションを取ればよいのかがわかっていませんでした。

在宅勤務では、強制的にSlackでのコミュニケーションを強制させられます。
これにより、齟齬のない文章で状況を伝えたり、timesチャンネルで自身の状況を常時報告したりする機会が増えました。

また、在宅勤務では、相手の状況がわかりません。
そのために、どれだけ忙しいのか、機嫌が良いのか悪いのか、文面からは何も見えてきません。

人によっては、上記をデメリットと感じる方もいますが、私はメリットと感じています。
つまり、何も考えずに質問したり、報告したりできるわけです。

私は、対面で質問する場合、どうしても相手の顔色を窺ってしまう癖があります。
文面では、相手の顔が見えないため、怪訝な顔をされていても、私には伝わりません。
物怖じせずに質問でき、それにより業務が進み、Win-Winの関係になっているんじゃないかな、と考えています。

~~......決して、話しづらい人がいるわけではありません。私が人一倍、相手の顔色に敏感なだけです。~~

うるさくても許される

BGM流し放題、独り言し放題です。
キーボードを強く叩いても怒られませんし、にゃーんと言いすぎて解雇されることもありません。

逆に、周りがうるさいことも気にしないで済みます。
向かいの人のキーボード打鍵音が気になりますか？後ろの人の悪態が気になりますか？隣を歩く人が気になりますか？誰かの貧乏ゆすりで揺れる机が気になりますか？どこからか聞こえるドローンの音が気になりますか？

それらが全て、在宅勤務で無くなります。

在宅勤務の欠点

私が感じた、在宅勤務の欠点は、以下の通りです。
各項目について、それぞれ説明します。

運動しない
日に当たらない

運動しない

1週間の平均歩数が、5000歩以上だった前週と比べ、なんと191歩まで下がってしまいました。
私が行う唯一の運動が歩行である現在、その歩行距離の極端な減少は大きな問題となるはずです。

今は若さという力で無理やり抑えていますが、今後は意識的に運動する必要があるかもしれません。

日に当たらない

実は1週間、ほとんどカーテンを開けずに生活していました。
誰が見ても、健康に良くないことは一目瞭然です。

意識的にカーテンを開けるようにする必要はありそうです。

おわりに

まだ1週間ですから、欠点についてはそれほど深刻に考えていません。
利点についても、これから少しづつ増えていく可能性はあります。

また、一般的によく言われる利点としての「使える時間が増える」ということについては、私がゆったりする時間として使っているため、そこまでメリットとしては感じていません。
夕方の時間は普通に増えているので、今後は何かできたらいいなと考えてはいます。

個人的に、在宅勤務か出社勤務のどちらが良いかと聞かれたら、今は間違いなく在宅勤務を選びます。
在宅勤務は好き嫌いがはっきりしやすいと思うので、社会人全員が在宅勤務を実施するとは考えていません（し、全員ができるとも思っていません）。
しかし、選択肢が増えることはいいことですね。

PowerPointのスライドサイズ制限対策あれこれ

2020-10-04T23:19:34+09:00

本記事は、 Qrunch からの移転記事です。

移転元: PowerPointのスライドサイズ制限対策あれこれ - 雑木林

TL; DR

下記に、3原則を記します。

デザインは大きく変わる覚悟をすべし
たくさんの手段の中から1つづつ試しすべし
地道な努力がサイズ削減の達成を約束するだろう

ユーザーの声も募集しています。

某社員
私は40MBのパワポを2MBまで削減できました！

はじめに

社内の規定などで、PowerPointのスライド（以降、パワポと呼ぶ）サイズ制限をかけているような場合、せっかく綺麗に作ったパワポが提出できない、なんてことがあったりします。
それでなくても、常日頃から容量も125GBしかないようなちんけなPCを使っている場合 ~~（えらく具体的ですね）~~ 、データサイズとの戦いは日常茶飯事です。

最初からサイズ容量を超えないように作ることも大事ですが、保存するごとにサイズが大きくなっていく様を見続けてパワポ作成を続けるのは、精神衛生的によろしくありません。

最初はサイズを無視して作成しつつ、後でサイズを下げる方法は、一見遠回りをしているようでいて、実はサイズと戦う時間を一括にまとめるという、きわめて効率的／合理的な手法だと考えます [要検証] 。

本記事では、どのような削減方法があるのか、何をすればよいのかを、1つづつ紹介していきます。
~~サイズ制限のために画像はありません。~~

事前準備

パワポサイズ肥大化の原因特定

パワポのファイル、いわゆる .ppt や .pptx ファイルが、zipファイルの拡張子違いであることは、意外と知られていません。

まずは、作成した .ppt または .pptx ファイルをコピーし、コピーしたパワポファイルの拡張子を .zip 拡張子に置換えてみましょう。
その後、コピーしたzipファイルを解凍すれば、中身が出現します。
これにより、どのファイルがサイズ肥大化の原因となっているかを判断できます。

主に画像ファイルが圧倒的にでかいため、そちらを見てみましょう。
解凍したディレクトリ内の ppt/media/ ディレクトリに入っていると思います。
明らかに大きな画像ファイルがあれば、そのファイルが本当に必要かどうかを考えておくのも大切です。

画像ファイルの種類や保存形式

PNGファイルは縦横の大きさを小さくしても、大きくする際に戻しやすい（可逆圧縮）性質があります。
一方、JPGファイルはその逆で、大きくしようとするとのっぺりとなりやすい（不可逆圧縮）性質があります。

可逆圧縮と不可逆圧縮のどちらが優れているかはTPOで異なりますが、データサイズの観点から見れば、不可逆圧縮形式のファイルのほうがデータサイズは小さいため、本記事の対象としては優位性が高いです。

他にも、たとえば画像ファイルの種類、ビットマップ形式であるJPGやPNGとベクター形式であるSVGの違いや、具体的な保存方法などを知っておくと、どうすれば画像ファイルのデータサイズが削減できるか、といったことが理解しやすくなります。

実践

事前準備ができたら、あとはパワポサイズを削減してみましょう。

PDFにする

意外と盲点ですが、 .ppt または .pptx 形式である必要がないなら、いっそのことPDFファイルにしましょう。
40MB程度のパワポが6MB程度まで減るので、もし可能であれば試してみてください。

欠点としては、それより下げる方法がない、ある意味では最終手段ということですが......

フォント埋込みを諦める

どんなにデータサイズが小さなパワポでも、フォント埋込みをした瞬間に6MBくらい増えてしまいます。
10MB程度なら許してもらえる環境であればよいですが、2MBレベルを求められる環境では無理です、諦めてください。

実際に発表で利用する場合は、フォント埋込みの代わりに画像として置換える、なんて技もあります。

もし、課題の提出用であれば、フォント埋込みをする必要もないかもしれません。
代わりにトップ画面にでかでかと「〇〇フォントを利用していますが、埋込めませんでした！」って書いておけば、デザインについてとやかく言われることは無いのではないでしょうか？

画像のアート効果で容量肥大化を防ぐ

PowerPointの機能として、「画像のアート効果」を選べるものがあります。
これは、普通の画像を簡単に「マーカー手書き風」にしてくれたり、「フィルム粒子風」にしてくれたりするため、意外と使える場面が多くて重宝できます。

しかし、中にはデータサイズ肥大化に貢献してしまうアート効果というものもあります。
例えば「フィルム粒子」効果では、画像をドットレベルでザラザラにするため、非常にデータサイズが大きくなります。
このような、データサイズを大きくしやすいアート効果はなるべく使わないようにしたいです。

画像の必要性を考える

本当にその画像が必要か、考えることも大切です。

セクションごとにスライドを挿入している場合、そこに表示する画像は本当に必要か？図形で代用できないか？などを考えてみましょう。
意外と不必要な画像を使っていることは多いです。

複雑な図形は1枚の画像に置換える

1スライドに何枚も画像を入れている場合、それらすべてを1枚の画像として貼り付けることで、データサイズを削減できることがあります。
特に、1スライドだけにしか使ってないような画像がたくさんある場合に重宝する手法です。

画像を圧縮する

スライドで利用している画像ファイルサイズを、直接圧縮できる機能があります。

下記の参考ページなどで紹介されていますが、「パワポ画像圧縮」で調べてもたくさん出てきます。
脳死で「電子メール用」レベルまで圧縮しましょう。

「PowerPoint」で作成した重い資料の容量（サイズ）を下げる方法 | @niftyIT小ネタ帳
https://koneta.nifty.com/koneta_detail/180928000645_1.htm

スライド自体を画像にする

下記のような参考ページでも書いてありますが、フォント埋込みを諦めた時点で、デザインの崩壊は防げません。
しかし、1枚のスライドを丸々画像にすることで、デザインを維持しつつデータサイズを削減できることがあります。

フォントの埋め込みだけじゃない！ – 環境に依存しないプレゼン資料の作り方 3種 | The Power of PowerPoint
https://thepopp.com/フォントの埋め込みだけじゃない-フォントイン/

注意点ですが、全スライドを画像にすると、逆にデータサイズが大きくなることもあります。
各スライドごとに変更してみて、データサイズ遷移を見守ってください。

おわりに

テラバイトが当たり前の時代になっても、いまだにサイズ制限をかけているのは時代錯誤も甚だしいですね。
とはいえ、1個人が現状を大きく変えることは難しいです。
できることをやりつつ、もし偉くなったら「サイズ制限なんて無くそう」と言ってください。

企業に所属する前に、大学で学んで良かったこと、もっと学んでおけば良かったこと

2020-10-04T23:18:52+09:00

本記事は、 Qrunch からの移転記事です。

移転元: 企業に所属する前に、大学で学んで良かったこと、もっと学んでおけば良かったこと - 雑木林

TL; DR

必要になって、自ずと勉強できれば、それで大丈夫です。
気軽に生きていきましょう。

でも、読書だけはガチでやっておきましょう。
大学で読みたい本は、全て読み切ることをオススメします。

社会人枠です

本記事は、宮崎大学アドベントカレンダー2019における8日目のエントリー記事です。

ペーペーですが、これでも社会人として生活しています。
ちょっと前まで学生だったので、学生時代に得たものを整理したいなと思いました。

学生さんは、ご参考までに、今後の学生時代を謳歌してください。
そうでない方は、自分もこんな時代があったと、ノスタルジーに浸ってください。

学んで良かったこと

以降、大学で学んで良かったことを記述します。
自慢話みたいなものです、温かく眺めてください。

対人コミュニケーション

学生時代にお酒を飲むようにしていたのは、社会人はお酒を飲めたほうがいいのかな、と漠然と考えていたからですが、大当たりでした。
私の所属しているプロジェクトチームは、学生時代の研究室以上に飲み会が多く、2次会も何度かありました。
2次会を楽しめる人間でよかったなと、2次会に参加するたびに思っています（だいたい奢ってくれます）。

あまり口数は多くないですが、Slackなどのコミュニケーションツールでは喋るようにしています。
自身のtimesチャンネルがあるため、独り言を言いやすい環境でもありますが、ネット弁慶時代の性格をうまく活用し、ネット上では話しやすい雰囲気を務めています。
お蔭で、プロジェクトチーム外の人からも話しかけられることが多く、自身からも質問しやすく、社内の雰囲気は良好です（個人の感想です）。

仕事は人対人のコミュニケーションで成立しているため、コミュニケーションを避けては通れません。
しかし、話せれば良いわけではなく、しっかり会話が成立し、人間関係を良好にすることが肝心です。
人間関係が良くなれば信頼してもらえますし、そうなれば新人であっても、けっこう話を聞いてもらえます。
これを活用し、自身からの提案が通ったりすると、仕事も楽しくなりますよ。

コミュニケーションが苦手？――なら「なたもだ」で解決すればいいじゃない
https://www.atmarkit.co.jp/ait/spv/1912/11/news005.html

自動化への意識

現在の所属プロジェクトには、CI/CD環境が一部整っていますが、すべてが自動化されているわけではなく、非常にまどろっこしく感じる時があります。
しかし、中には機械的に淡々と同じ作業をしている人もいるため、メンバー全員が自動化を考えているわけではないのだな、と意外に思いました。

とあるシステムに、バイナリファイルを手動で設定しなければならないディレクトリがありました。
そのバイナリファイルを更新するためには、手動でコンパイルしたバイナリファイルを、手動で上書きし、手動でプルリクをしなければなりませんでした。
私は嫌だったので、自動化したいと提案し、そして実装しました。

人手による作業はヒヤリハットの温床になるため、できるだけ潰しておきたいです。
その考え方が、私の自動化への意識を生み出してくれました。

開発環境におけるこだわりと柔軟性

現在の所属プロジェクトの開発環境ですが、IDEとしてほぼ全員がVS Codeを使用しています。
しかし、僕だけなぜかVimをメインで使用しています。
開発環境に対して強制が無かったというのもありますが、PythonならVimでいいかなという気持ちで独自路線を進んだのが、正直な理由です。

ですがその際に、チームの開発環境に合わせる必要があります。
VS Codeで利用しているプラグインやLintツールがあれば、それをVimに組込まなければなりません。
私はVimの設定を多少いじれたので、VS CodeじゃなくてもPythonを編集できることを証明しつづけています。

一方で、妥協したものもあります。
既存システムにRustを使っていたものがあったのですが、代替品としてPythonを使っていたシステムがあり、そちらに移行すべきか否か、という話が持ち上がりました。

個人的には、Rustを勉強していたこともあり、Rustを推したい欲がありました。
しかし、他のメンバーはPythonの方が読みやすいです（当時は私しかRustを読めていませんでした）。
属人化が怖かったため、私からPythonのシステムに変えてほしいと頼みました。
結果として、多くのメリットが生まれました。
今でも若干後悔していますが、これで良かったとも思っています。

こだわりは大事、妥協も大事です。
折合いを付けることが重要なことですね。

ソフトウェア工学

オブジェクト指向という概念を理解できていない人は、意外と今でもいます。
TDD文化がないプロジェクトはたくさんありますし、UMLを正しく読み書きできない人もたくさんいます。
テスト手法とかカバレッジ測定とか、名前は知ってても開発で使える道具にできる人は、あまり多くいません。

ソフトウェア工学は、システム開発全般で使える、かなり汎用的な知識を学べる学問だと思います。
学生時代にCI/CD環境を整えたのは、想像以上に役に立っています。

様々なプログラミング言語／ツールの概念や利用方法

事前に学習して良かったと思ったプログラミング言語／ツールは、以下の通りです。
これらを学生時代に学んでいたことで、会社のチーム配属直後からスムーズに開発を担当できました。

Perl
Git/GitHub
CI/CD
Slack
C++
Raspbian/Raspberry Pi

私はPerlを勉強していましたが、それによりRubyやPythonなんて比較的簡単に使えるだろうと自己判断していましたし、実際にチームで開発やレビューを行う立場となっています。
Gitを使っていたことで、GitHubでのプルリクという文化や、コンフリクトとの格闘について、長く苦しめられることもありませんでした。
なにより、CI/CD環境の構築を経験していたおかげで、どのようにシステムをアップデートするのかの概要理解は非常に役立ちました。
ラズパイに至っては、知らなければ使い方すらわからない気がしますが、スムーズにRaspbianをmicroSDカードに焼いて ssh [email protected] できました（簡単なことですが、意外と凄いことだと思いますよ）。

これらに関しては、運の要素が結構絡みます。
もし配属先のプロジェクトが、SVNでバージョン管理しているCOBOLシステムサーバーの保守運用（コミュニケーションツールはEメール）みたいな場合、全く役に立たなかった可能性もあります。
気負わずに、勉強したいことをすればいいと思います。

もっと学んでおけば良かったこと

以降、大学でもっと学んでおけば良かったことを記述します。
反面教師として、ご活用ください。

Javascript

現在のJavascriptについては、殆ど理解できていません。
流行っているものは勉強したくない、という私の天邪鬼な性格が災いしました。
それは、以下に示す、私の学生時代に使っていた言語からも、お察しできると思います（1つだけ例外あり）。

Perl
Java
C++
Rust

流行というものは、使われているから発生するものです。
現に、私の所属しているチームでもJavascriptを扱っていますし、もしかしたら私も今後触ることがあるかもしれません。
しかし、基本的な文法ならともかく、JavascriptはPerlやC++と同じくらい闇が深いと考えているため、モチベーションも相まってなかなか触りたいと思えません。

すごく勿体ないことですし、自身の性格を直すためにも触ってみようかなと思ったり、逡巡したりを繰返す日々を過ごしています。

Webサイト開発

Javascriptの節とも関係していますが、基本的な HTML + CSS + Javascript + Webサーバー という構成Webサイトについては、1度しっかりと勉強したほうが良かったかもしれません。

学生時代にふるーいCGIサーバーを触っていたせいで、HTMLはWebサーバーで丸ごと動的生成するものだと思っていました。
HTMLとCSSで体裁を整えて、中の要素だけをWebサーバーで動的生成するほうが、シンプルで疎結合だと気付いたのは、業務で取扱うようになってからです。
HTMLとCSSとJavascriptとWebサーバーの役割を、もっとちゃんと学習すべきだったなぁと反省しています。

Docker

とある業務でDockerを触る機会がありました。
そこで、次のようなDockerfileを作ってしまい、動かないなーというミスを2日ほど経験しました。

1番目のsetup.shはどうして動かないの？

# 前略

CMD ["bash", "./setup.sh"]
CMD ["bash," "./run,sh"]

初歩的過ぎるミスなのか、調べてもどこにも「CMDコマンドでは2つのコマンドを実行できない」という文言を見つけきれませんでした（公式サイトにもちょこっと書いてあるだけでした）。
今ではDocker無しの生活は考えられませんが、学生時代にちょっとでも触っておけばよかったです。

サーバー運用

とにかくネットワーク系は苦手でした。
大学でもネットワークの授業はありましたが、基本的なコマンドさえ頭から消えていました（arp、netstat、iptables などなど）。
しかし、ネットワーク系を触るとなると、インフラを整備するような環境でもない限り、あまり機会が無いと思います。

また、基本的なサーバー運用時のイロハも学んでおけばよかったです。
プロセスの整理、インタフェースの把握、デーモンの理解、ネットワーク設定などなど、サーバー運用で学習できる内容は数知れません。

学生時代にこれらを学ぶ機会はあまり無いかもしれませんが、せっかく研究室にサーバーがあったのに、使いこなせなかったのは勿体なかったです。

ライセンス関係

学生時代、ツールは実質タダ、OSS使い放題の環境でした。
しかし、社会人になるとそう簡単ではありません。

学生であればフリーソフトでも、商用になった途端に有料というツールは珍しくなくなってきました。
もし商用利用不可／商用利用有料のツールでしか開発できない人間になってしまうと、非常に苦労すると思います。
私も、GitKrakenが使えなかったり、CLionが使えなかったりと、ライセンスの壁を認識して過ごしています。

またOSSについても、ライセンスが問題になる場合があります。
いわゆるGPL汚染と呼ばれるものですが、実際にお金を取得するプロジェクトでは、かなり気をつけなければなりません。
この辺りは、ソフトウェア工学としてフォローできそうな気がします。
ぜひ、どなたか研究してみてはいかがでしょうか？

読書

本を読む時間が減ります。
読む気力が残っていない日々ばかりです。

大学というのは、タダで高額な書籍の読み放題機関であると心得るべきでした。
時間もたっぷりあったはずなので、悔やんでも悔やみきれません。

料理

正直、こんなにコンビニ弁当の日々が続くとは思っていませんでした。
朝はパン、昼は外食、夜はコンビニ弁当のルーティンができてしまい、気付けば5キロ太っていました。
食費も結構かかります。

しかし、想像以上に料理ができません。
都会の部屋の狭さもあり、効率的な動きを余儀なくされます。
基本がなっていない人間に効率的な動きを求められても、なかなかうまく行きません。

それでも最近は少しずつ自炊をしています。
カレーを作ると2時間、麻婆豆腐を作ると1時間かかりますが......

振返って一言

いろいろありましたが、学生時代は楽しかったです。
もちろん、今の生活も楽しいです。

なんだかんだ言って、その場その時を生きていける力が最も大切なことかもしれませんね。

実践UML記述法：スクリプト言語（Python, Perl, PHPなどなど）における可視性をUMLで記述する1考察

2020-10-04T23:17:50+09:00

本記事は、 Qrunch からの移転記事です。

移転元: 実践UML記述法：スクリプト言語（Python, Perl, PHPなどなど）における可視性をUMLで記述する1考察 - 雑木林

TL; DR

スクリプト言語における可視性をUMLで記述する場合、リバースエンジニアリングによる結果論的可視性を書くといいかもしれない

本題：スクリプト言語における可視性をUMLで記述する

UMLには可視性という概念があります。

Javaにおけるアクセス修飾子とほぼ同等のもの、と考えておけば間違いではありません。
public、private、protected、およびpackageです。

スクリプト言語（ここではPython、Perl、PHPといったいわゆるP言語を対象としておきます）には、絶対的な可視性はありません。
例えばPythonであれば、変数の前にアンダースコアを付けることで「疑似的に」プライベート変数を設定できますが、実際に外部から参照できないわけではありません。

問題点

スクリプト言語で開発する場合、UMLにおける可視性の情報は無意味です。
それどころか、余計な情報として「ノイズ」と言われても仕方ありません。

UMLには可視性を書かなくても構文的に問題ないため、可視性の情報無しでも大丈夫です。
しかし、それでは次のような問題が起こりえます。

UserクラスがInformationクラスと関連しているクラス図

@startuml
class User {
    printText()
}

class Information {
    text
    message
}

User --> "1\ninfo" Information
@enduml

さて、上記のクラス図から「UserクラスはInformationクラスのtext変数を参照しているが、message変数は参照していない」という情報を読み取れるでしょうか。

UserクラスがInformationクラスを持っているPythonコード

class User:
    info = Information()
    # クラス図におけるprintText()メソッドと対応
    def print_text(self):
        print ("{}".format(info.text))

class Information:
    text = "This is printed"
    message = "Oh no!"

お分かりの通り、クラス図からでは理解できません。
しかし、クラス図から変数の利用状況が理解できなければ、結局コードを読まなければならず、UMLの浸透には貢献できません。

余談ですが、クラス図ではprintTextとキャメルケースにしているところ、Pythonコードではprint_textとスネークケースにしています。
これは、UMLがキャメルケース、Pythonがスネークケースを推奨しているためです。

解決策

発想を逆転します。
設計時に可視性を決めるのではなく、コード上で利用しているか否かを判断し、それをUMLに反映してはどうでしょうか？

UserクラスがInformationクラスと関連しておりmessage変数は利用していないクラス図

@startuml
class User {
    - printText()
}

class Information {
    + text
    - message
}

User --> "1\n- info" Information
@enduml

上記のクラス図から、「少なくとも」Informationクラスのmessage変数を外部クラスは参照していないことがわかります。
また、他の変数（info）やメソッド（printText()）についても、外部からの参照はないことがわかります。

上記のクラス図を見ただけで、Informationクラスはtext変数にのみ注意すればよく、message変数はInformationクラス内部を見れば把握できることがわかります。

結論

どうでしょう。
あくまで視点を変えただけですから、「言われなくてもその通りじゃん」と言われればごもっともです。
UMLを設計ツールとして可視性を考えるのではなく、UMLをあくまで可視化ツールとして利用するという考え方であれば、UMLを利用しやすくなるのではないでしょうか。

vimrcファイル（環境設定ファイル全般）はGitHubで管理するといいのではないか

2020-10-04T23:17:10+09:00

本記事は、 Qrunch からの移転記事です。

移転元: vimrcファイル（環境設定ファイル全般）はGitHubで管理するといいのではないか - 雑木林

はじめに

皆さんは、出先にvimrcファイルがあれば良かったのに、という経験はありませんか？

偶然にも、私はそんなことが何度かありました。

例1：インターンシップ

それは、とあるインターンシップでのことです。

回想はじめ

偉い人「AWSサーバ1つあげるから、これで何か作ってください」
私「よっしゃいじり倒したろ、さてapacheの設定ファイルは......」
私「Vimの設定がデフォルトで全然使えん！！！」

回想おわり

さて、私はこの時、偶然にもGitHubにvimrcファイルを置いていたため、クローンしました。
するとどうでしょう、行番号も碌に表示していなかったVimに、命が吹き込まれたのです。

私は、このインターンシップを大成功で収めることができました。

例2：新しい業務用パソコン

それは、新しい業務用パソコンがたくさん届いた時のことです。

回想はじめ

私「さて、環境構築するか」
新パソコンA「Vim無いよ」
新パソコンB「Vim無いよ」
新パソコンC「Vim無いよ」
私「......これ全部同じことしないとならんの？」

回想おわり

さて、私はこの時、偶然にも（以下略）

私は、たくさんの新しい業務用パソコンにいち早くVim環境を整えることができました。

例3：vimrc編集後

それは、突発的にvimrcファイルを書換えた時のことです。

回想はじめ

私「ふへへ、ついに最強のvimrcを書いてやったぜ」
私「さて、これを私が利用している別のパソコンにも入れなきゃ」
私「えーっと、家のデスクトップ、家のノート、新パソコンA、新パソコンB、新パソコンC......」
私「......今日はそろそろ帰ろう」

回想おわり

さて、私はこの時、偶然にもGitHubでvimrcファイルを管理していたため、新しいvimrcをpushしました。
別のパソコンを使う際にpullすればいいだけですから、その日は何も考えずに帰りました。

数日後、別のパソコンを利用時にvimrcをpullするとどうでしょう、Vimが生まれ変わったのです。

私は、常に最新のvimrcをどこでも利用できるのです。

おわりに

vimrcは便利ですが、慣れてしまうとデフォルトのVimが苦痛になってしまいます。
いち早く自分の環境に（PCを）適応させるため、GitHubで環境ファイルを管理するのは1つの手だと思います。

上記を活用して、快適環境の生活を過ごしませんか。

追記

GitHubで管理する前は、USBにvimrcを入れて生活していました。
書換えた時に面倒なことになるのは、お察しの通りです。