LPICを受験してよかったと実感したこと

LPIC受験してよかった！

最近 LPIC-1 の101試験に合格しました！今回の記事では「LPIC受験してよかった」と思えたことを共有させていただきます！

CUI が大好き！これを機にしっかり学ぼう！

私は高校生の頃から CUI が好きで、無知ながらもインターネットでコマンドを調べたりして、さまざまな操作をしていました。黒い画面とにらめっこしてパソコンを操作している自分がハッカーのように思えて嬉しかったのを今でも覚えています。

ついにエンジニアになったので、ここらでしっかり Linux について勉強して、 GUI に頼らずもっと自由にパソコンを操作できるようになりたいという思いから、LPICを受けることにしました。

LPIC-1 101試験に合格したわけですが、資格を取れたこと以外にも「受験してよかった」と実感することがありました。

今回は LPIC を受験したことで実感した よかったこと について共有します！

受験してよかったと実感したこと

私が LPIC を受験してよかったと実感したことは大きく2つに分けることができます。

ひとつは Linux を勉強してよかったと実感したこと で、もうひとつは 受験勉強を通してよかったと実感したこと です。

具体的な例を挙げると以下のようになります。

• Linux を勉強してよかったと実感したこと

  • 正規表現を様々な場面で活用できたこと
  • Vim での開発効率が上がったこと

• 受験勉強を通してよかったと実感したこと

  • タイムマネジメントを意識するようになったこと
  • 仮想環境を実際に構築し、メリットを知れたこと
  • アウトプットする側に立てたこと

Linux を勉強してよかったと実感したこと

LPIC の受験勉強を進める中で、 エンジニアとしての基礎的スキルが身につきました。その結果、開発効率が上がったり、非エンジニアのメンバーの助けになれたりしました。

Vim での開発効率が上がったこと

私は LPIC の受験勉強を始める前から Vim を使って開発していました。Vim で分からないことがあったら Qiita 記事を見て、必要なコマンドだけを覚えるといったことをしていました。

しかし、受験勉強ということもあり、Vim のコマンドなどを満遍なく覚える必要があったので、今まで知らなかったコマンドやショートカットキーを知ることができました。結果的に開発効率が上がったと実感しています。

例えば、特定の文字列を検索する時に、わざわざビジュアルモードに移行して、文字列を選択し、 yy を叩いた後、/ + コピーした文字列を貼り付け としなくても、 Shift + 8 つまり * を叩くだけで実行できるわけです。

/ + コピーした文字列	Shift + 8

上記のような作業をコマンドひとつで実行できるようになっただけでも、開発効率が上がっているように思えます。

正規表現を様々な場面で活用できたこと

最近同僚達と一緒のチームで働くことになり、MTG である文言が含まれるファイルがいくつあるかを調べる場面でも正規表現の知識が役に立ちました。メンバーが使用している Editor が各々違うのですが、私が共有した正規表現を使って、チーム全員が該当するファイルを検索することができました。

また、非エンジニアの人が Google スプレッドシートの管理で困っているときにも正規表現の知識が役に立ちました。日付の列に入力されている文字列が ○月○日 (○曜日) 00:00 といったフォーマットになっていたのですが、曜日と時間の情報は必要ないとのことでした。必要ない文字列を手動で削除していたのですが、時間がかかると困っていたわけです。そこで、Google スプレッドシートには置換機能があり、正規表現を使用できることを知っていた私は、知識を活用して一括で必要のない文字列を削除する方法を教えることができました。

上記のように Linux 以外でも正規表現という基礎的な知識・スキルを様々な場面で活用できたのは、受験してよかったと思えたことのひとつです！

受験勉強を通してよかったと実感したこと

先に挙げたように業務に直結するようなスキルが身についたこともよかったのですが、受験勉強を通してよかったと実感できたことも数多くありました。

タイムマネジメントを意識するようになった

業務外に勉強時間をいかに確保するかを考えるようになったことは、受験勉強に限らずよい習慣になったと思います。

業務時間外に何か目標を立ててやることを決めないとどうしても怠けてしまいます。私は定時を過ぎてもだらだらと仕事をすることが習慣になってしまっていました。

だからこそ、今回の受験勉強をきっかけにタイムマネジメントを意識して、可能な限り定時で帰れるように工夫するようになったことは、受験勉強を通してよかったと実感したことのひとつです。

受験勉強に限らず、自分への投資の時間、アウトプットするための準備時間などを確保するためにも、タイムマネジメントは引き続き意識していきたいところです。

仮想環境を実際に構築し、メリットを実感できたこと

私は macOS を使用して開発を行なっているのですが、受験勉強用に読んでいた Linux 標準教科書では CentOS の使用が前提となっていました。

Linux標準教科書

新しくパソコンを買うお金もないので、使用しているパソコンに CentOS の環境を構築する方法を調べると Docker や VirtualBox を使って環境構築できることを知りました。

Docker や VirtualBox という技術に巡り会えたことで、本来の環境を汚さずに別の環境を構築する素晴らしさを知ることができました。

また余談にはなりますが、 Docker を使えばチーム全体の開発環境を共通化して環境依存の不具合などを減らすことができたり、環境構築の手間が減るので新しいメンバーがすぐに開発に参加できたりするようです。

そういった仮想環境を使って開発をすることのメリットを知れたり、実際にその技術を使ったりしたことは、とても貴重な経験になったと感じています。

アウトプットする側に立てたこと

アウトプットする側に立てたことは、私の中では非常に大きな進歩だったと思っています。

今までも学んだことをアウトプットしようと意識はしていました。しかし「僕みたいな初心者がアウトプットしてもいいのか」「自分よりはるかに専門的でクオリティの高い記事を書いている人がいる」といった様々な心理的ハードルが邪魔をして、結局アウトプットができていませんでした。

LPIC の受験勉強をするにあたって、メモベースでもいいので学び記事を必ずアウトプットするというミッションを与えられました。上長から与えられた半ば強制的なミッションのおかげで私は 記事をアウトプットする ことへの心理的ハードルがすごく低くなりました。

さらに嬉しいことに、自分が想像していたよりもはるかに多くの方が閲覧してくださっていることがわかり、アウトプットへの心理的ハードルが一段と低くなりました。

これは上長からの後押しがあったことも重要な要因にはなっていますが、アウトプットへの心理的ハードルが低くなったことは、受験勉強を通してよかったと実感したことのひとつです。これからもどんどんアウトプットしていきます！

終わりに

LPIC を受験したことで、もちろんエンジニア的スキルも成長した部分がありました。しかし、それ以上に副作用的に違う技術を学べたことや良い習慣が身につくような環境に身を置けたことは、私にとって大きな成長に繋がったような気がしています。

引き続き、 LPIC-1 102試験や LPIC-2 ・ LPIC-3 の受験勉強を進めようと思います！みなさんも興味があったら、ぜひ LPIC を受験してみてください！

スタートアップの2年目エンジニアが考える優先順位付けとスケジューリング

はじめに

私はスタートアップのエンジニアになって2年目になりますが、タスクの優先順位の付け方に課題を抱えています。

チームで仕事をする場合は、優先順位の付け方を間違うと周りに迷惑をかけてしまいます。

• 私が経験した例
  • 優先順位を高く設定していたタスクが、実はそこまで高くなかったと発覚し、本当に優先順位が高いタスクに取り組めなかった。
  • 不確実性（把握できていないこと）を考慮せずに優先順位を付けてスケジューリングし、期限に間に合わずチームに迷惑をかけた。

優先順位の付け方に悩んでいる時、上長から以下の4つの軸で判断することを勧められました。

• 優先順位の判断軸
  • 重要度
  • 緊急度
  • 仕様的不確実性
  • 技術的不確実性

重要度と緊急度

まずは重要度という軸と緊急度という軸です。

「重要度が高くて、緊急度も高いタスクの優先順位を高く設定して対応すること」といえば、当たり前のように感じます。

しかし、ここで勘違いして欲しくないのは、重要度も高く、緊急度も高いタスクだけをやればいいということではありません。 重要なのは 重要度が高くて、緊急性が低いタスクに時間を割くこと です。

『時間管理のマトリクス』

上記の考え方は7つの習慣に出てくる『時間管理のマトリクス』を参考にしています。

完訳 7つの習慣 人格主義の回復

著書には以下の内容が書かれています。

第Ⅰ領域へ時間を割くことは避けられないが、第Ⅱ領域へ時間を割くことによって減らすことはできる

例えば、新機能を実装したときに、既存のコア機能が使用できなくなったとします。

コア機能が使用できないのでユーザ影響がかなり大きいと判断できます。よって重要度も高く、緊急度も高いので第Ⅰ領域のタスクになります。優先順位を高く設定して取り組むべきです。

しかしよくよく考えてみると、新機能の実装時に既存のコア機能が使用できなくなってしまうことを防げなかったことを問題視すべきではないでしょうか。テストを書いたり、リリース前の動作確認時にコア機能の動作も確認したりするなど、未然に防ぐ手段を考えることが重要になるはずです。

この場合、未然に防ぐ方法を考えることの重要度は非常に高いですが、緊急度は低いです。よって第Ⅱ領域のタスクになります。

つまり、第Ⅱ領域へ時間を割くことで、第Ⅰ領域の問題の発生を減らすことができるわけです。だから、重要度が高くて、緊急度が低いタスクにも時間を割くべきなのでしょうね。

また私が働いているようなスタートアップでは、いかに限られた時間で重要な課題にフォーカスするかが重要になります。

しかし、優先順位の高いタスクの割り込みが多いとパフォーマンスに大きく影響したり、割り込みの度に意思決定に体力を消費するため大事な場面での意思決定を間違ってしまったりします。

参考: スタートアップは行動しない / フォーカス、ツール、オペレーションについて

こういった違う視点でも、重要度と緊急度が高いタスクを発生させないように第Ⅱ領域のタスクに時間を割くことが重要であるとわかります。

仕様的不確実性と技術的不確実性

もう2つの判断軸として、仕様的不確実性と技術的不確実性という基準を設けています。

仕様的不確実性: 要件や仕様において不明確な部分の多さ 技術的不確実性: 実装する上で不明確な部分の多さ

不確実性に向き合う思考

上記は「エンジニアリング組織論への招待 不確実性に向き合う思考と組織のリファクタリング」という著書を参考にしています。

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

この著書の一説に以下の内容が書かれています。

エンジニアリングの本質が「不確実性の削減」であることに気づかずにいると、確実でない要求仕様にフラストレーションを抱え、確実でない実現手段にストレスを感じ、確実なものを確実な手段で提供したいというような決してありえない理想を思い描いて、苦しい思いをすることになってしまいます。

私も仕様や実装方針が定かでないのに対応してしまい、予想外のことに直面するという経験をしたことがあります。 結果手戻りなどが発生して、スケジュール通りに進めることが難しくなり、チームに迷惑をかけてしまいます。

そうならないためにも、私は「仕様的不確実性」と「技術的不確実性」が低いものから、優先順位を高く設定して対応するようにしています。 不確実性が低いものから対応すれば、予想外のことに直面する可能性も低く、スケジュール通りに進めやすくなるからです。

一方で不確実性が高いタスクは焦らず、上長とも認識を合わせながら、不確実性を削除していくようにしています。

また「仕様的不確実性」と「技術的不確実性」は低くて、30分以内で対応できそうなタスクは、重要度と緊急度が低くても優先度を高く設定するようにしています。すぐに対応できそうなタスクをいつまでも残しておきたくないという思いからです。

終わりに

優先順位付けやスケジューリングが不安定だと、チームに迷惑をかけてしまい、士気を下げてしまうかもしれません。さらにスタートアップとなるとサービスの成功にも大きく関わってくるのではないかなと感じています。

私もまだまだ優先順位付けやスケジューリングで迷うことがありますが、この考え方でいくつか改善された部分もあります。この記事を読んで、私と同じ状況で悩んでいる方の助けになれば幸いです。

ランチタイムのグループ分けを自動で行う「UnitLunch」をリリースしました

ランチタイムのグループ分けを考えるのが大変。。。自動化しないともう無理だ！

過去のデータを元に偏りがないようにグループを分けて、毎回違うメンバーとランチを食べにいきたい。そんな希望を叶えるために、自動グループ分けツール「UnitLunch」を作りました！

ユニットランチとは

私のインターン先の会社では1週間に2回、2~3人のグループに分かれて、ランチを食べに行っています。私たちをこれを「ユニットランチ」と呼んでいます。

少人数だからこそ、仕事中には話せないプライベートな話も聞けるので本当に楽しい！まだ知らない美味しいお店との出会いも楽しみのひとつです！

楽しみだらけのユニットランチなのですが、たったひとつだけ苦労していることがありました。

それは、ユニットランチの グループ分け です。

グループ分けの難しさ

ユニットランチが始まってからすでに1年半が経過しましたが、私がグループ分けを担当しています。

グループ分けの時に気をつけていることは、 可能な限り同じグループになったことがない人を組み合わせることです。

ただ1年半も手動でグループ分けを続けていると、連続で同じ人とグループになったり、同じグループになる頻度が高くなってしまったりと、理想的な組み合わせが難しくなってきました。。。

ツールがない！！

そこで、グループ分けの作業をコンピュータに任せようとツールを探し始めました。 ただ、私が求めているようなツールがなかなか見つかりません。

そんなとき、社員の方が 過去のデータを元に偏りなくグループ分けを行うアルゴリズム について書かれた記事を共有してくださいました。

Chatbotを使ってシャッフルランチを続けた話 | GRIPHONE ENGINEER'S BLOGtech.griphone.co.jp

この記事のおかげで、どうすれば偏りなくグループ分けができるかわかりました。 あとはもう実装するだけです！ツールがないなら作ってしまいましょう！

「UnitLunch」の仕組みと使い方

仕組み

今回作成したツール「UnitLunch」では、参考記事にある 今までのマッチングデータを元に組み合わせを評価するアルゴリズム だけを採用しています。

以下のようなアルゴリズムで1グループの組み合わせを評価しています。このアルゴリズムでは、評価値が小さいほど過去に同じグループになったことがないことを示しています。

$$ E_f({t,n}) = \sum_{i=1}^{N_t} \sum_{j=i+1}^{N_t} f(p_{t,i}, p_{t,j}, n) $$

$$ f(x, y, n) = \left\{ \begin{array}{} f(x,y,n-1)+1 & (n\ 回目に\ x\ と\ y\ が同じグループの場合)\\ f(x,y,n-1)×0.5 & (n\ 回目に\ x\ と\ y\ が異なるグループ\ もしくは\ いずれかが参加していない場合)\\ 0 & (n=1) \end{array} \right. $$

$$ N_t：グループ\ t\ の人数 $$

$$ p_{t,i}：グループ\ t\ の\ i\ 番目の人 $$

$$ p_{t,j}：グループ\ t\ の\ j\ 番目の人 $$

$$ n：n 回目のシャッフルランチ $$

つまり、全グループの評価値を合計した値が最小となる組み合わせが最適となるわけです。

使い方

では、使い方について説明します。

まずは Google スプレッドシート を開き、新しいスプレッドシートを作成します。

次に画面上部にある ツール をクリックし、 スクリプトエディタ を選択します。

Google Apps Script の画面が表示されます。

GitHub に公開してある main.gs のコードをコピーします。

github.com

コピーしたコードを Google Apps Script のエディタ上に貼り付けて、保存します。（任意のプロジェクト名で保存してください）

先ほど開いた Google スプレッドシート の URL をコピーして、コード内の URL 挿入部分に貼り付けてください。

Google スプレッドシート に戻り、「メンバー情報」というシートを作成してください。
ここはユニットランチに参加しうるメンバーの情報を保存します。

メンバー情報シートに 名前 と ID の列を作成してください。
注意: ID は1から順に割り振ってください。

次に「履歴」というシートを作成してください。
ここには今までのユニットランチで誰がどのチームだったかを記録します。

注意: ID 順に左詰めで名前を入力してください。ID の番号と列数が同じになるようにしてください。

最後に「参加者」というシートを作成してください。
ここには 参加者名 と ID と 1グループの人数 を入力してください。

いちいちIDを調べるのは面倒だと思いますので、IDの列には以下の数式を入力すると良いでしょう。

=VLOOKUP($A2, 'メンバー情報'!A:B, 2, FALSE)

注意: 必要ない関数はグループ分けを実行する前に削除して下さい。

これで準備は整いました！

グループ分けの実行

Google Apps Script の画面を開いて、 createGroup を選択し、 再生 ボタンを押して実行してください。

※ 実行すると承認を求められると思うので、許可してください。

しばらくしてスクリプトの実行が終了したら、ページ上部の 表示 をクリックし、 ログ を選択します。

表示される ログ を見ると、参加者IDがグループごとにまとめられています！

最後に履歴シートに誰が同じグループだったかを入力します。
2行目が1回目のユニットランチの履歴で、以降は下の行に追記していきます。

※ 誰が同じグループだったかがわかればいいので、私は適当にアルファベットを入力しています。

まとめ

今回は MVP（Minimum Viable Product）ということもあり、まだまだ手動で操作しなければならない作業が多いです。。。

今後改善していく部分としては、

• グループ分けの結果をIDではなく、名前で表示するようにする
• グループ分けの結果を履歴に自動で入力する
• 必要なシートをワンクリックで自動生成できるようにする

などが挙げられます。

もっと使いやすくなるようどんどん改善していきます！

ランチタイムのグループ分けで困っている方は、ぜひ使ってみてください！

文書作成とプログラミングに共通する課題

背景

私の会社では GitHub を使って開発を行なっています。改善すべきところを見つけたら Issue を作って対応する。1年以上も続けていることなのに、Issue の書き方がよくないため、上長に余計なコストをかけてしまっていました。

そのとき CTO に勧められたのが 「 SE のための図解の技術、文章の技術 」という本です。この本を読んで、私が作成した Issue が読み手に伝わりにくい原因を知ることができました。さらに、プログラミングスキルが伸び悩んでいる原因にも共通する部分があることに気づきました。

SEのための図解の技術、文章の技術

私が感じた「文書作成」と「プログラミング」の共通点についてまとめようと思います。

全体を階層構造で考える

文書作成の場合

伝わりやすい文書を書くためには、実際に書き始める前に文書の「構成」を考えなければならないと書かれていました。その構成を考える際に、文書全体を階層構造にしておくことで、読みやすく、理解しやすい文書を作成できるということです。

私は Issue 作成に限らず、日報やドキュメントを書くときも、構成を全く考えずに書いていることに気がつきました。書いている途中で何を書いているのか分からなくなることが多いです。

プログラミングの場合

これはプログラミングでも同じだなと、本を読んでいて気がつきました。

私は仕様がある程度固まってくると、まだあまり整理できていないのに、すぐにプログラムを書き始めます。すると文書作成と同様、書いている途中で何を実装しているのか分からなくなります。

また、しっかり仕様を整理したわけではないので、仕様の考慮漏れがあるなどして、手戻りが発生してしまっています。

まとめると...

文書作成にしても、プログラミングにしても、全体を階層構造にすることで複雑な事柄を細分化し、簡潔にまとめることが大切だと感じました。

巨人の肩の上に立つ

文書作成の場合

読み手が理解しやすい文章を書くには、長い歴史を経て作り上げられたパターンを使うことが勧められていました。

例えば、「序論ー本論ー結論」や「起承転結」という展開パターンです。

長い歴史から確立されたこのパターンは、人間が順を追って事象を把握、理解する際の思考の流れに合ったものであり、理解の仕組みを反映したもの考えられています。

つまり、このパターンの沿って書けば、自然と読み手が理解しやすい文章をかけるということです。

プログラミングの場合

これはプログラミングでも同じだなと思いました。

例えば、私が使用しているオブジェクト指向言語にも、デザインパターンと呼ばれるパターンがあります。

これも上記と同様に私よりもはるかに優れたエンジニアたちが長い歴史を経て確立した設計パターンです。システム設計で困った時に、デザインパターンを使うことで解決する問題も多いでしょう。

まとめると...

文書作成にしても、プログラミングにしても、すでに確立されているパターンを使うことで、目標を達成しやすくなるということです。巨人の肩の上に立つというのは本当に大切だなと再確認しました。

所感

文書作成で抱えていた課題とプログラミングスキルの伸び悩みの原因に共通する部分があったことに驚きました。

今回の学びは汎用的なもので、他にも活かせる部分があるはずです。一つの学びをより広い範囲で活用できるようになりたいものです。