第4話 コンフリクトは怖くない！解決方法【連載】マンガでわかるGit ～コマンド編～

Webサービスやアプリ開発の現場では必須のバージョン管理システム「Git（ギット）」。Gitは、専用のソフトを使えばクリックで直感的に操作することもできますが、いざというときにコマンドが使えると便利です。

第3話 では、2つのブランチを統合するマージコミットの作り方と、その仕組みを学びました。

$ git merge [ブランチ名]

（マージする）

今回の第4話は、コンフリクトについてです。なにそれ…と思われる方も、このお話しを通して、わかばちゃんと一緒にコンフリクトについて学んでいきましょう。

【筆者】湊川 あいさん

フリーランスのWebデザイナー・漫画家・イラストレーター。マンガと図解で、技術をわかりやすく伝えることが好き。 著書『わかばちゃんと学ぶ Git使い方入門』『わかばちゃんと学ぶ Googleアナリティクス』『わかばちゃんと学ぶ Webサイト制作の基本』『運用ちゃんと学ぶ システム運用の基本』が発売中のほか、マンガでわかるGit・マンガでわかるDocker・マンガでわかるRuby・マンガでわかるScrapbox・マンガでわかるLINE Clova開発・マンガでわかる衛星データ活用といった分野横断的なコンテンツを展開している。

･Amazon著者ページ
･Twitterアカウント

マージ中にコンフリクトが発生したら

コンフリクト解決！の練習

1.まずは、わざとコンフリクトさせてみよう

第3話 と同じように、新しいブランチ「news」を作り、newsブランチとmasterブランチでそれぞれのコミットを作りましょう。自分がnewsブランチで作業していたら、その間に別の人がmasterブランチを更新していたという想定です。

前回と違うのは、わざとコンフリクトさせるために同じ行を編集することです。

 

▼ newsブランチにチェックアウトした状態で、sample.txtをこのように編集してコミット

▼ masterブランチにチェックアウトした状態で、sample.txtをこのように編集してコミット

では、マージしてみましょう。
マージするためのコマンドは、

$ git merge [統合したいブランチ名]

 

でしたね。

newsブランチからmasterブランチへ取り込みたいので、masterブランチにチェックアウトしたうえで、

$ git merge news

 

と打ち込みます。

すると、マージは行われず、このような文章が表示されるはずです。

よし！コンフリクト成功だな。

あはは、コンフリクト成功っていうのもおかしな話だね。

英語でも恐れることはありません。翻訳してみましょう。

CONFLICT (content): Merge conflict in sample.txt
→コンフリクト：sample.txtの中でマージの衝突が起きました

Automatic merge failed; fix conflicts and then commit the result.
→自動マージが失敗しました。衝突している箇所を修正して、その結果をコミットしてください

何をすればいいかは基本的にGit様がこうやって親切に教えてくれるから、その通りにすればよい。

 

2.ファイルを開いてコンフリクトを修正する

 

では、sample.txtを修正するためにファイルを開いてみましょう。

うわっ、なんか変な記号が書き込まれてる！

 

変な記号とは失礼な！これはGit様が目印として書き込んでくれたのだ。

<<<<<<< HEAD
から
======= まで：
→今自分がチェックアウトしているブランチでの変更

=======
から
>>>>>>> news まで：
→取り込もうとしたブランチでの変更

 

修正するときはこの記号も合わせて消すようにな。Git初心者だと、この記号がなんなのかわからず、消さずにそのままコミットしてしまいがちだ。

ギクッ……！ えっと、今度のハイキングは雨天決行なんですよね。
じゃあnewsブランチの変更内容を残して、と。これでOKですね！

▼ 修正後のsample.txt

3.修正したファイルをステージし、コミットしなおす

 

ステージに乗せて

$ git add sample.txt

コミット

$ git commit -m "sample.txtのコンフリクトを修正"

 

ふーん、コンフリクトのあとは普通にコミットするだけでいいんだ。これでうまくマージできたね！コンフリクト、怖くなかった！

▼ マージが成功している（SourceTreeで表示したコミットツリー）

コンフリクトの修正が難しい場合

コンフリクトの箇所が多すぎて、修正が難しい場合、マージの途中であっても--abortオプションでマージを中止できます。

 

$ git merge --abort

 

あまりにも差分が多すぎる場合は、どちらか一方のブランチのコミット内容が、最新のコミット内容に比べ極端に古いことが多いです。その場合は、最新のコミットから新たにブランチを作って、そこに自分が追加したいコードを加えるといいでしょう。

まとめ

さて、ここまででコンフリクトの解決方法がわかりました。

・コンフリクトした箇所を修正して、コミットしなおす

$ git commit -m

（通常のコミットと同じコマンドです）

 

・コンフリクトした箇所が多すぎて修正が難しい場合、マージを中止する

$ git merge --abort

（マージを中止する）

これでコンフリクトが起きても、落ち着いて対処できますね。

Gitにはまだまだたくさんのコマンドがあります。
次回は、git revert（リバート）について学んでいきましょう。

エンジニアの皆さん、日々のスキルアップの時間は十分に取れていますか。 リクルートスタッフィングでは、エンジニアのスキルアップを応援するため、登録者限定で情報配信などを行っています。 リクルートスタッフィングでの就業に関わらず使えるものですので、これを機にお役立てください。

▼登場キャラクター紹介

▼わかばちゃんが登場する書籍

・わかばちゃんと学ぶGit使い方入門
・わかばちゃんと学ぶGoogleアナリティクス
・わかばちゃんと学ぶWebサイト制作の基本

▼ これまでの「マンガでわかるGit」

第1話「リポジトリの作成」
第2話「ブランチの概念」
第3話「マージの仕組み」
第4話「コンフリクトの修正」
第5話「git revert」
第6話「git reset 3種類」
第7話「git reflog」
第8話「git switchとgit restore」
第9話「git diff」
第10話「git cherry-pick」
第11話「git stash」
第12話「git grep」
第13話「git blame」
第14話「git remote」
第15話「.gitconfig でコマンドを短縮」
第16話「.gitconfig と .git/config で複数のGitアカウントを使い分ける」
第17話「prune オプション」
第18話「git tag」
第19話「detached HEAD 状態って何？」

【イベントレポート】ゼロから学ぶクラウドの世界 クラウドの現在、未来はどうなるのか？そしてエンジニアは、どう学ぶのか

この記事では、2019年6月26日に開催したイベント「ゼロから学ぶクラウドの世界 クラウドの現在、未来はどうなるのか？そしてエンジニアは、どう学ぶのか」をレポートします。講師には、NRIネットコムのクラウド事業推進部の部長であり、数々のクラウドサービス解説書籍を執筆されている佐々木 拓郎さんをお迎えし、クラウドの基礎から、最新のクラウドの潮流、そしてクラウド関連の知識を養う際に効果的な勉強方法まで、幅広く教えていただきました。

■今回のイベントのポイント
・クラウドの潮流は2つ。「コンテナ化」と「サーバーレスアーキテクチャ」
・隣り合う分野を掛け合わせる「T型人材」という考え方
・クラウドの学び方で重要なのは「具体的な目標設定」

【講師プロフィール】
佐々木 拓郎さん
NRIネットコム クラウド事業推進部 部長。専門はクラウドに関するコンサルティングから開発まで。主な著書として『クラウドエンジニア養成読本』（技術評論社）、『AWS認定資格試験テキスト AWS認定 ソリューションアーキテクト-アソシエイト』（SBクリエイティブ）、『Amazon Web Services パターン別構築・運用ガイド』（SBクリエイティブ）、『Amazon Web Services 業務システム設計・移行ガイド』（SBクリエイティブ）、『Rubyによるクローラー開発技法』（SBクリエイティブ）などがある。

クラウドの潮流は2つ

講師である佐々木さんは、アマゾン ウェブ サービス ジャパン株式会社の「APN AWS Top Engineers 2019」と「APN Ambassadors 2019」にも選ばれている、いわばAWSのプロ中のプロ。今回のイベントでは、「クラウドの潮流を何となく把握してもらう」「技術の勉強の仕方のヒントを得てもらう」「家に帰ったら、クラウドのアカウントを作ってもらう」をゴールとし、クラウドについて詳しく佐々木さんに教えていただきました。

現在クラウドには大きく2つの潮流があり、「コンテナ化」と「サーバーレスアーキテクチャ化」という流れがあるそうです。

コンテナ化とは、仮想化の手法の1つで、1つのOS上に独立した仮想的なユーザー空間を作り出し、それをコンテナのようにプラットフォーム上に並べたり、置き換えたりして利用します。

▲コンテナ型の仮想化では、1台の物理サーバー上で1つのOSしか動かさないため、ハードウェアリソースを効率良く使うことができる

現在、このコンテナ化を支えているのが、コンテナ型仮想化エンジン「Docker」と複数コンテナを管理するオーケストレーションソフト「Kubernetes」です。

▲Dockerでコンテナ型の仮想環境を構築し、複数のコンテナをKubernetesで管理する

一方、サーバーレスアーキテクチャとは、仮想サーバーを利用せずにアプリケーションを構築する設計のことだそうです。ただし、仮想サーバーを利用しないといっても、「ユーザーがメンテナンスすべきサーバーがない」というだけで、そのバックエンドにクラウドベンダーが用意したサーバーがあり、イベント駆動により、各アプリが必要に応じてコンピューターリソースが提供されるという仕組みのことを指します。

▲サーバーアプリケーションが1秒間しか起動されなければ、1秒間分の利用料しか課金されずに済む、といった利用も可能になるサーバーレスアーキテクチャ

クラウドの進化に伴った「T型人材」という考え方

このようにクラウドサービスそのものが進化してくると、おのずと、その利用方法や求められるエンジニアのスキルも変わってきます。

これまでは、インフラエンジニアやアプリケーションエンジニアなど、担当する領域が明確にわかれていました。しかし、コンテナ化やサーバーレスアーキテクチャが普及すると、従来の区分ではわけることが出来なくなってきます。

そうなると、エンジニアの境界（領域）も、これまでと違って曖昧になっていきます。そこで登場するのが「T型人材」という考え方だそうです。

T型人材とは、フロントサイド／サーバーサイド開発、インフラ構築、クラウドの種類、ミドルウェアなど、幅広く浅い理解を持ちながら、いずれかの分野について、より深い知識を備えている人を指します。

▲広く浅くでも構わないので、周辺の知識を持つことが大切。それがT型人材

佐々木さんは、クラウド時代が進めば、プロビジョニングやオーケストレーションで使われる「Infrastructure as Code」（コードによるインフラの構成管理）のように、コード化する範囲が広がるため、これまで以上にコードが書けるエンジニアが必要とされると予測しています。

もちろんコードが書けるだけでなく、業務知識や技術力など、専門分野あるいは得意分野を身につけていくことが大切だということです。ただし、専門分野／得意分野も、単一の分野で勝負するのは茨の道だといいます。なぜなら「単一分野においては、必ず上の人は、たくさんいるから」だそうです。そこで佐々木さんは、「隣り合う分野を掛け合わせること」をお勧めされました。

▲分野を掛け合わせると、ベクトルのように合成された結果で評価される。そうして自分が第一人者になれる分野を作ればよい

コツは「隣接する複数のスキルを身につけること」だそうです。なぜなら「隣接分野だとベクトルが合成されやすい」とのこと。例として、アプリとインフラや、アプリとデザインなどを示してくださいました。

そして、効率的な成長をするためのポイントとして「変化を楽しむ」「ちょっと背伸びをする」「チャンスが来やすい仕組みを作る」を挙げます。チャンスが来やすい仕組みとは「組織内の第一人者の分野を作る、あるいは、やりたい事をアピールしておくこと。そうすると仕事が集まりやすくなる」ということだそうです。

クラウドの学び方

では、自身のスキルセットにクラウドを追加するにあたり、何をどう勉強していけば良いのでしょうか。ここでも佐々木さんが効率的な学び方を示してくださいました。大切なのは「目標の具体化」「教材の選択」「実際に手を動かす」「アウトプットをする」ということ。

中でも重要なのは「目標設定」。たとえば失敗しやすい目標とは「AWSを使えるようになりたい」というもの。「使える」というのが一体どのレベルを指しているのか分かりません。成功しやすい目標は「負荷に応じて自動でサーバーが増減するシステムを作りたい」というような具体的なものだそうです。ただし「目標はあまり高くしない」ことがポイントだそうです。

学習教材については、AWS公式サイトや、いわゆるBlack Beltシリーズと呼ばれる書籍、各種オンラインセミナーなどが紹介されました。分からないことはGoogleで調べるという人もいますが「Googleはキーワードを知らないと調べられない。でも書籍はページをめくれば知らない情報が出てくる」のが利点だそうです。

手を動かして勉強していくときに気を付けなければいけないのは、セキュリティ。たとえばソースの中にAWSへのアクセスキーを直書きしてしまい、そのままGitHubの公開リポジトリにプッシュしてしまうという事故は、よくあるそうです。最近では、そもそもアクセスキーを利用せずに済ませる事ができるので原則使わないことが推奨されています。どうしてもアクセスキーを利用する必要がある場合は、ソースの中にアクセスキーを書き込まず、環境変数を利用する方法が望ましいそうです。

▲手を動かして学ぶ際に、最低限押さえておきたいセキュリティ

どうしても不安であれば「セルフペースラボ（Qwiklabs）」の利用がお勧めだそうです。このサービスは、ほぼ無料で、30分間だけAWSやGCPが使えるというサービスです。時間が過ぎると、作成した環境を勝手に消してくれるので、初心者にもお勧めだそうです。

▲初心者にも安心して試せる「セルフペースラボ」

ちなみに、アウトプットをすることは敷居が高いように感じますが、気になったキーワードをTweetするだけでも意味があるそうです。

今回のイベントの参加者からは、クラウドの勉強方法が具体的にわかったとの声を多くいただきました。また、「セルフペースラボ」を使って、実際に手を動かして学んでみる方も多いのではないでしょうか。株式会社リクルートスタッフィングが運営するITSTAFFINGでは、弊社に派遣登録いただいている皆さまのスキル向上を支援するこのようなイベントを、定期的に開催しています。皆さまのご参加をお待ちしております。

【インタビュー】元バーテンダーが心がけたのは、いくつかのスキルを併せ持った“スキルプラス”によるキャリア形成

エンジニアとしてのキャリアを考える上で、スキルアップに不安を持つ方は多いのではないでしょうか。株式会社リクルートスタッフィングが運営するITSTAFFINGでは、スキルアップのために努力されている登録スタッフにインタビューをし、普段のお仕事で気を付けていることや、スキルアップのための取り組み方について、定期的にご紹介します。

今回お話をうかがった田中敦士さんは、もともとバーテンダーをしており、友人とコンセプトバーを経営していたそうです。そのまったくの異業種から、ITの世界に飛び込みました。その後、会社の設立や登録派遣などを経て、現在はフリーランスとして活躍中。これらのご経験を経て、心がけていることはなにかを教えていただきました。

バーテンダーからインフラエンジニアへ。勘違いが生んだ華麗なる転身

「日本バーテンダー協会にも所属するバーテンダーを6年ほど務めており、友人と一緒に、当時としてはまだ珍しかったコンセプトバーを立ち上げました。スキューバダイビングやサーフィンが好きだったので、コンセプトは『海』。深海をイメージした内装に、BGMは波の音、床には砂を撒いて、雰囲気を出していました」

しかし「一生、飲食をやっていくのは難しい」と考えた田中さんは、バーテンダーの道から離れることを決意した。1995年9月頃だという。

田中さんが転職先として選んだのは、大手通信機器系メーカーのグループ会社で、ちょうど契約社員を募集していた。ITの知識を持ち合わせていなかった田中さんがなぜ？と思うかもしれないが、実は転職先の会社が「〇〇システム建設」という社名だったことから「建設現場の仕事だろう」と勝手に思い込んでいたという。

「配属先に、軍手と作業服を持っていったら、仕事は入力オペレーターというもので、協力会社からヒアリングしてデータを入力し、ファイリングをしていくという業務でした（笑）」

驚くことに田中さんは、このとき初めて本格的にPCに触れたそうだ。しかし、そこから急激な勢いでPCに関する知識やスキルを習得していく。

覚えたExcelやAccessを活用し、顧客に業務改善を提案、推進していくようになる。いつしか田中さんは、顧客はもちろんのこと、勤務先の会社にとっても、無くてはならない存在へと成長していった。もちろん収入も、どんどん増えていったという。

会社を立ち上げ、仕事が順調に進んでいく

そのような中、会社から田中さんに、正社員化の打診があった。しかし田中さんは断った。

「業務委託契約を結ぶ契約社員ということもあり、当時の月収は90万円ほど。それが正社員になると5分の1ぐらいになってしまうのが嫌だったんです」

対個人での業務委託契約では上限があったのだろうか、田中さんの事情を理解した同社役員から今度は「田中さん、自分で会社を作れば？」と提案された。そうすれば対法人で業務委託契約ができるという。

結果、田中さんは会社を立ち上げ同社の仕事を続けていった。その後も、大手シンクタンク、コンビニチェーンなどに向けたさまざまな仕事を手掛ける。

「ある自動車メーカーの東京本社におけるシステム構築プロジェクトの仕事を受けました。そこでは、システム管理の責任者を任され、ヘルプデスクの設置や、Notes Dominoを使ったイントラネット環境を構築するなど、さまざまな仕事を手掛けました。3000万円近い予算を承認無しで動かせるのが面白くて仕方ありませんでした」

当時の月収は20代半ばにして150万円に達していたという。と、ここまでならよくあるサクセスストーリーだったかもしれない。しかし、この後、田中さんは大きなアクシデントに見舞われてしまう。

体調を崩した後の再スタートは、登録派遣から

トントン拍子に、エンジニアとしてのスキルの幅を広げ、収入を上げてきた田中さんだったが、事故に遭い、うつ病を発症してしまった。

「あの時は本当に大変でした。何をするにも気力が湧かず、思考能力が低下し数字も6までしか数えられなくなってしまったんです。結局、医師に従い、仕事を休んで静養するしかありませんでした」

業務を離れ、休養をとることにした田中さんは無職となった。休養後、仕事を復帰するに当たり、田中さんが選んだのは登録派遣だった。派遣先についての希望も、地理的な条件のみ。

そして紹介されたのが、通信事業者の基地局刷新のための進捗管理のプロジェクトだった。

「Excelが使える人を募集していて、当初は一般派遣の平均的な時給でしたが、最終的には派遣先社員の給与(年収)を上回りました」

もちろんExcelで進捗管理を入力するだけで時給を上げていったわけではない。

プロジェクトには設計会社や施工会社など、複数の協力会社が関わるため、進捗の確認やすり合わせも時間がかかり、何とも効率が悪い。そこで田中さんは、関係する会社のスタッフを定期的に呼び寄せ、一部屋に集めてその場で図面の修正などを行わせた。

また、同プロジェクトでは各担当者からのヒアリングを行うために、ITだけでなく、建築、電力、通信、法律などの知識も必要になる。そこで田中さんは、業務の傍ら、それらの分野の基礎知識を1つずつ身につけていったという。これらの努力により、進捗上の問題点がすぐに明らかになるなど進捗管理の効率が上昇し、田中さんは図面チームのリーダーを任されるようになったのだ。

キャリア形成の極意は、スキルプラス

登録派遣を経て、現在はフリーランスとして、以前も仕事をしていた大手シンクタンクで、業務委託というカタチで働いている。

自身を「雑務のエキスパート」と呼び、毎月100ページ近い顧客への報告書作成や、ネットワークやサーバーのセキュリティー管理業務など、ありとあらゆる仕事をしている。ただし、オーバーワークにならないよう、18:00までには退社するようにしているという。

そんな田中さんに、キャリア形成の極意を聞いてみた。

「私の場合は、人がやりたがらないことを率先してやるように心がけています。若い人は、『スキルアップ』に目が向きがちですが、私はスキルアップではなく、スキルプラスの方が大切だと考えます。あるスキルについてレベルが高い人は自分以外にも大勢います。しかし、いくつかのスキルを併せ持った人となると、その組み合わせ次第ではありますが、かなり限られてきます」

振り返ってみれば、田中さんのキャリアは、何か一つの技術分野を極めていくスペシャリスト型ではない。もともとExcelやAccessの職場での活用と提案からスタートし、現場で発生するさまざまな雑務をこなしながら、異なる分野のスキルを一つひとつ加えていったオーソリティ型と言える。そうして出来上がった稀有な存在に、高い付加価値がついているのだ。

最後に、スキルプラスのために日々実践している手法を紹介してくれた。

「本は1つのテーマについて最低2冊は読みます。1冊は基礎解説である程度全域を網羅しているもの。もう1冊は図解などで、部分的な理解を深めていくものを選んでいます。自宅で使うPCも遊び用と勉強用を分けており、勉強用のPCでは、次の日の仕事のために、いろいろ試したり、人と話すために調べものをしたりしています。そうすることで気持ちが切り替えられるし、勉強用PCのブラウザの閲覧履歴そのものが自分にプラスされたスキルの記録にもなりますよ」

直面する課題を一つひとつ解決していくために努力を続けることは、一見簡単そうに聞こえるが、成し遂げるのは難しい。しかし、結果がついてくることを知っている田中さんは、今日もスキルプラスのために励んでいるだろう。

第3話 マージの仕組みを見てみよう【連載】マンガでわかるGit～コマンド編～

Webサービスやアプリ開発の現場では必須のバージョン管理システム「Git（ギット）」。Gitは、専用のソフトを使えばクリックで直感的に操作することもできますが、いざというときにコマンドが使えると便利です。

第2話 では、ブランチの概念の理解と、ブランチの作成・確認・切り替えを習得しました。

$ git checkout

（チェックアウトする）

 

$ git branch   

（ブランチを作る）

今回の第3話では、2つのブランチを1つに統合する「マージ」を実践。その仕組みもあわせて学びましょう！

【筆者】湊川 あいさん

フリーランスのWebデザイナー・漫画家・イラストレーター。マンガと図解で、技術をわかりやすく伝えることが好き。著書『わかばちゃんと学ぶ Git使い方入門』『わかばちゃんと学ぶ Googleアナリティクス』『わかばちゃんと学ぶ Webサイト制作の基本』『運用ちゃんと学ぶ システム運用の基本』が発売中のほか、マンガでわかるGit・マンガでわかるDocker・マンガでわかるRuby・マンガでわかるScrapbox・マンガでわかるLINE Clova開発・マンガでわかる衛星データ活用といった分野横断的なコンテンツを展開している。

･Amazon著者ページ
･Twitterアカウント

マージするタイミング

どのようなタイミングでマージをすることが多いのでしょうか。主なケースを2つ、マンガで見てみましょう。

1.目的としていた作業が終わり、変更を反映したいとき

2.masterブランチ上の新しいコミットを取り込みたいとき

実際にマージしてみよう

マージのコマンドは次の通りです。

$ git merge [統合したいブランチ名]

前回、developブランチにチェックアウトしている状態でsample.txtに変更を加え、コミットするところまで終えましたね。

▼ 今のブランチの状態

今からmasterにもコミットを作りたいので、この状態からmasterブランチにチェックアウトをします。

$ git checkout master

 

  develop
* master

masterにチェックアウトできました。

それではこの状態で、新しくsample2.txtを作り、ステージしてから、コミットします。

$ echo "Happy Git" > sample2.txt
$ git add sample2.txt
$ git commit -m “sample2.txtを作成”

これで、ブランチが二股に別れた状態になりました。

▼ 今のブランチの状態（わかりやすいように、コミットIDは省略しています）

いよいよマージしてみましょう。
マージするためのコマンドは、

$ git merge [統合したいブランチ名]

です。

今回は、developブランチからmasterブランチへ取り込みたいので、
masterブランチにチェックアウトしていることを確認し、

$ git merge develop

と打ち込みます。

コミットメッセージの編集画面になります。

「a」キーで入力モード、「esc」キーでコマンドモードになります。
特に追加するメッセージがなければ「esc」キーを押してから「ZZ」と入力してコミットメッセージを保存します。

するとどうでしょう。
見事、2つのブランチが1つに統合されました！

▼ 今のブランチの状態

マージの仕組み

第2話 でブランチの仕組みを学んだからには「マージの仕組みも知りたい！」と思っている方のために、マージのコミットオブジェクトものぞいてみましょう。

$ git cat-file -p [マージコミットのID]

気がつきましたか？

通常は1つのコミットにつきparent（親）は1つですが、マージコミットの場合、驚くべきことにparentが2つあるのです。なぜなら、2つのコミットから1つのコミットを生成しているからです。お父さんとお母さんから子どもが生まれるようなイメージでしょうか。

えーっと、じゃあ普通のコミットは雌雄同体のアメーバで、マージコミットはお父さんとお母さんがいるって感じ？

不思議な比喩だな……。まぁ『マージコミットには2つ親がいるんだ～』ぐらいの認識でいいだろう。

親が3つになったり、4つになったりはしないの？たとえば3本のブランチを一気にまとめて統合したいときが、もしもあったらどうするの？

普段、3、4本のブランチを一気に統合するってことはあんまりないけど、マージの仕組み自体、統合できるブランチは2本までだから、1つずつ統合していくことになるよ。

ふーん！

今回はそのままマージできたけど、それぞれのブランチで同一行に変更があった場合、Gitが人間に「どっちの行の変更を採用すればいいの？」と尋ねてくることがあるんだ。これをコンフリクトという。コンフリクトについては次回取り上げよう。

Gitって親切なんだね！

まとめ

さて、ここまででマージの仕組みとコマンド操作がわかり、

$ git merge [ブランチ名]

（マージする）

が使えるようになりましたね！

Gitにはまだまだたくさんのコマンドがあります。
次回は、コンフリクトについて学んでいきましょう！

▼登場キャラクター紹介

▼わかばちゃんが登場する書籍

・わかばちゃんと学ぶGit使い方入門
・わかばちゃんと学ぶGoogleアナリティクス
・わかばちゃんと学ぶWebサイト制作の基本

▼ これまでの「マンガでわかるGit」

第1話「リポジトリの作成」
第2話「ブランチの概念」
第3話「マージの仕組み」
第4話「コンフリクトの修正」
第5話「git revert」
第6話「git reset 3種類」
第7話「git reflog」
第8話「git switchとgit restore」
第9話「git diff」
第10話「git cherry-pick」
第11話「git stash」
第12話「git grep」
第13話「git blame」
第14話「git remote」
第15話「.gitconfig でコマンドを短縮」
第16話「.gitconfig と .git/config で複数のGitアカウントを使い分ける」
第17話「prune オプション」
第18話「git tag」
第19話「detached HEAD 状態って何？」

【イベントレポート】Pythonでデータ処理と機械学習を始めよう

株式会社リクルートスタッフィングが運営するITSTAFFINGでは、弊社に派遣登録いただいている皆さまのスキル向上を支援するイベントを、定期的に開催しています。

2019年6月14日のイベントでは「Pythonでデータ処理と機械学習を始めよう」を開催。データの前処理を効率的に行うためのライブラリ「Pandas」を使って、機械学習の最も初歩的なモデルが作られるようになるまでを、書籍『Pythonによるはじめての機械学習プログラミング』の著者でもある早川敦士さんが分かりやすく解説してくださいました。

■今回のイベントのポイント
・プログラミングの準備として、データの取り扱いが大切
・データ分析のライブラリ「Pandas」を使いこなそう
・Pythonは、データに触れることが上達への近道

【講師プロフィール】
早川 敦士さん
株式会社FORCAS、株式会社ホクソエムに所属。前職のリクルートコミュニケーションズではB2Cマーケティング、現職のFORCASではB2Bマーケティングプラットフォームのデータ分析及び開発を担当。大学在学中に『データサイエンティスト養成読本』（技術評論社刊）を共著にて執筆。その後も『機械学習のための特徴量エンジニアリング』（オライリー・ジャパン刊）や『Pythonによるはじめての機械学習プログラミング』（技術評論社刊）などで執筆活動を続けている。国内最大級のR言語コミュニティであるJapan.Rを主催。

機械学習プログラミングの準備。データの取り扱い方

機械学習とは、コンピューターにデータを読み込ませ、アルゴリズムに基づいて分析をさせる手法のことです。そのため、ソフトウェアに“学習させるため”のデータが大量に必要となります。

しかし、そのデータがきちんと整形されていなかったり、データに重複や抜け落ちがあったりすると、正しい学習効果を得られません。機械学習を行うプログラムそのものは、豊富なライブラリを使って組むこともできますが、学習データは独自に集めてきたものも多くなります。そうなると、データの取り扱い方こそが大切とも言えます。

今回のイベントでは、機械学習そのものについての解説もありましたが、「機械学習エンジニアへの第一歩は、データの読み込みと書き出しの方法を知ることが大切」と早川さんはお話しされ、ほかのイベントではあまりお目にかかることのないデータの取り扱いについても詳しく解説されました。そこでまずは、Pythonのデータ分析で利用するツールを簡単にご紹介いただきました。

・scikit-learn
機械学習用ライブラリで、機械学習のデファクトスタンダードとも呼ばれる。手法のカバー範囲も広く、統一されたインターフェイスが特長

・Pandas
データフレームを提供するためのツールで、おおざっぱに言えばExcelのようなもの。データの加工や集計に使う

・SciPy、NumPy
Pythonを使われる方には馴染みの深い数値計算用ライブラリで、ベクトル計算や行列計算に便利な命令が多数用意されている

・Plotly
グラフ描画ライブラリ。きれいなグラフが描け、使い勝手の良さが支持されている

次に主要なデータ形式の特徴について学びました。機械学習分野で使われる主要なデータ形式として、Excel形式、JSON形式などがあるそうです。

・Excel形式
小さなデータであれば一覧性が高いという特徴がある。大きなデータである場合には、データ文字列中にカンマが存在する可能性があるため、カンマよりタブで区切ることをお勧め

・JSON形式
JavaScript Object Notation の略。WebサービスのAPIにより提供されるデータ形式は、ほとんどこの形式が使われている。ほか、MySQLやPostgresなどのデータベースの出力や、Webサイトのクローリング形式、ブログ記事などにも使われている

データを扱うためのライブラリ「Pandas」

次に、ライブラリ「Pandas」を使ってデータを読み込みました。サンプルではiris.data.csvというCSV形式のデータを読み込み、データフレームに格納しています。そして、最後に読み込んだデータの概要を表示します。

import pandas as pd
df = pd.read.csv('iris.data.csv', header=None)
dfinfo()

データの概要を表示したら、行数と列数は、しっかり確認しておくと良いそうです。

次に読み込んだデータの一部を表示してみます。データの上から10行分を表示する場合は、次の命令を記述します。

df.head(n = 10)

行数はnで指定します。データの終わりからn行を表示するにはtail()を使います。

ちなみに、このようなプログラムを1つ1つ試しながら結果を参照・実行できるものとして、早川さんが使われていた便利なツールが「Jupyter Notebook」です。「Pandas」と組み合わせて使用すると、簡単にデータ分析ができるそうです。

▲Jupyter Notebookは、プログラムを実行し、実行結果を記録しながら、データの分析作業を進められるように設計されたツール。結果をすぐに画面で確認できるのも便利

Pandasで要素を抽出

格納データの任意の部分を表示させる命令もいくつか学びました。

データ位置を数値で指定して表示させるには、ilocメソッドを使います。1行目の2列目を表示するには次のように指定しますが、行も列も0スタートなので1行目が0、2列目が1になる点は注意が必要です。

df.iloc[0, 1]

また、locメソッドを使うと、列名を指定してデータを取り出すこともできます。1行名から5行目までの列名1と列名2の列データを抜き出して表示するには次のように指定します。

df.loc[[0, 1, 2, 3, 4] , ['列名1', '列名2']]

Pandasの便利なメソッド

応用編として、アンケートでの回答の重複が無いかどうかを確認するという例も学びました。回答番号の欄がすべて異なっているかどうかを確認するため、uniqueメソッドでユニークな行がどれだけあるかを調べ、それをデータ全体の合計と比べるというものです。

df["回答番号の列名"].unique()

また、アンケートのなかでユニークな回答が、全部で何種類あるかを求めるには、次のように記述します。

df["列名"].value.counts()

そのほかにも、合計はsum()メソッド、平均はmean()メソッド、最大値はmax()で求められることなど、基本的なメソッドを使って、データを集計したり、データの表示を工夫したりする方法を学びました。これだけでも十分に面白いと感じることができましたが、もちろん、イベントはそれだけでは終わりません。

繰り返し行うデータ集計にも便利なPython

より実践的な事例では、生のデータを整形しながら、機械学習プログラムに利用できる形式に変換する方法を、段階を踏まえながら学んでいきました。

事例では、サイト『Stack Overflow Annual Developer Survey』からダウンロードした、データ『survey_results_public.csv』を使いました。

import pandas as pd
df = pd.read.csv('~/Downloads/survey_results_public.csv',
low_memory = False)
df_info()

このデータを基に、データの型変換、カテゴリを追加する、複数回答を異なる列に展開、4種類ある回答を3種類にまとめるなどの具体的な処理を行っていきました。

また、データを文字列として扱うと、数値に比べて余計にメモリを消費してしまうため、これをコンパクトに格納するテクニックなども紹介してくださいました。

学んでいくにつれ、こうしてデータをさまざまな形にして出力できるのは楽しいと感じられる一方で、データにいろいろな操作を加え整形していくうちに「あれ？今、自分は何をしていたんだっけ？」と迷子になってしまうことも多いようです。

そのため、「常に確認しながらやっていくことが大切。だからJupyter Notebookを使うと良い」と早川さんは教えてくださいました。

こうしたデータの整形はExcelでもできますが、1度Pythonで書いておけば、次回も同じ処理をそのまま実行することができ、さらには機械学習のプログラムの前段に組み込むこともできます。日々の集計や週ごとの集計など、繰り返し行う作業であれば、Pythonで書いておくと良い、とのことでした。

また、Plotlyによるグラフ化についても、教えていただきました。

▲Plotlyで描いたグラフは、マウスオンで内訳表示されるほか、拡大や保存などもマウス操作でできるなど、使い勝手が良い

とにかくデータに触れることが上達への近道

この後、実際にscikit-learnを利用した機械学習プログラムの例もいくつか紹介してくださったのですが、このレポートでは割愛します。

これまで機械学習のプログラミングについてのイベントはいくつかありましたが、こうしたデータの前処理に関するものは深堀されていなく、とても参考になったとのお声を参加者から多くいただきました。

早川さんは、「興味のあるデータは探せば意外と見つかるので、練習のつもりで、データにたくさん触れてみることが大切です」と締めくくってくださいました。

【コラム】プログラマを目指すときに知っておきたい基礎用語とは

プログラミングの知識を身につけようと思ったとき、最初のハードルになるのが「専門用語」です。勉強すればするほど知らない用語が登場するため、1つずつ調べながら学ぶことになるかと思います。インターネットを使うと簡単に調べられるようになった一方で、“知らない用語”は調べられないものです。

そこで今回は、プログラミングをするときに最低限知っておきたい基礎的な用語をご紹介します。似ている用語と比較をしているので、その違いも意識してみてください。

【筆者】増井 敏克さん

増井技術士事務所代表。技術士（情報工学部門）。情報処理技術者試験にも多数合格。ビジネス数学検定1級。「ビジネス」×「数学」×「IT」を組み合わせ、コンピュータを「正しく」「効率よく」使うためのスキルアップ支援や、各種ソフトウェアの開発、データ分析などを行う。著書に『おうちで学べるセキュリティのきほん』『プログラマ脳を鍛える数学パズル』『エンジニアが生き残るためのテクノロジーの授業』『図解まるわかり セキュリティのしくみ』（以上、翔泳社）、『シゴトに役立つデータ分析・統計のトリセツ』『プログラミング言語図鑑』（以上、ソシム）がある。

機械語とプログラミング言語

コンピュータは、人間が設計書を書けば動いてくれるわけではなく、「機械語」と呼ばれる言語で指示を出す必要があります。しかし、機械語を人間が書いたり読んだりするのはとても大変です。

そこで「プログラミング言語」を使って、人間にとってわかりやすい記述ができるように工夫をしています。ただし、コンピュータにはプログラミング言語が理解できないので、これを機械語に変換する必要があります。

ソースコードとプログラム

プログラミング言語のルールに沿って書かれたものを「ソースコード」と呼びます。そして、このソースコードを機械語の「プログラム」に変換することで、コンピュータが実行可能になります。

なお、プログラムと似た言葉に「ソフトウェア」や「アプリケーション」があります。ソフトウェアはハードウェアと対比して使われる言葉で、プログラムだけでなくデータや文書などのファイルも含みます。また、アプリケーションは「応用ソフト」と訳されるように、OS(基本ソフト)以外のソフトウェアを指します。

コンパイラとインタプリタ

ソースコードをプログラムに変換する方法は、「コンパイラ」と「インタプリタ」に大きく分けられます。

コンパイラはソースコードからプログラムに事前に変換しておくことで、実行時に高速で処理を行えます。ただし、ソースコードに修正が発生した場合は、毎回変換作業をやり直す必要があります。

インタプリタは実行時に変換しながら処理を行うため、コンパイラよりも処理に時間はかかりますが、ソースコードを修正した場合もすぐに実行ができます。

ただし、最近では「バイトコード」と呼ばれる中間言語の増加や、「JITコンパイラ」という方式を採用した言語の登場など、コンパイラやインタプリタの分類が難しくなっています。

また、機械語に変換するのではなく、他の言語のソースコードに変換する「トランスパイラ」と呼ばれる言語も登場しています。

コーディングとプログラミング

プログラマがソースコードなどを記述することを「コーディング」といいます。ただし、プログラマの仕事はこのコーディングだけではありません。ソフトウェア開発の大きな流れとして、「V字モデル」という言葉があります。

次の図のように要求分析から始まり、要件定義や基本設計、詳細設計などが前段として存在し、その上で実装をする作業がコーディングです。コーディングを行ったあとには、単体テストや結合テスト、システムテスト、受け入れテストが待っています。

このうち、設計や実装、テストまでの広い範囲が「プログラミング」だと考えられます。この言葉の指す範囲は曖昧で、その会社や組織によってプログラマが担当する範囲は異なることがあります。

データ構造とアルゴリズム

『アルゴリズム＋データ構造＝プログラム』という本があるように、プログラムを作る上でアルゴリズムやデータ構造についての知識は必須です。

「データ構造」によって、プログラム中どのようにデータを格納するかが決まります。整数や小数、文字などを格納する「基本データ型」だけでなく、これらを組み合わせた「配列」、その格納方法や取り出し方として「キュー」や「スタック」などの言葉も知っておきましょう。

一方、プログラムでの処理手順を示したものが「アルゴリズム」です。配列の中から欲しいデータを見つけ出す「探索」や、昇順や降順に並べ替える「ソート」など、基本的なアルゴリズムは書籍などで学んでおきましょう。

計算量とオーダー

複数のアルゴリズムの中から、最適な手法を選ぶためには基準が必要です。その基準として「計算量」という考え方がよく使われます。

“良い”アルゴリズムには、処理するデータが増えても、それほど処理時間が長くならないと考える「時間計算量」と、メモリやディスクをそれほど消費しないかを考える「空間計算量」といった基準があります。

その中でも、アルゴリズムの比較では時間計算量がよく使われ、「オーダー」という表記がよく使われます。オーダーを考えるときは、入力のデータ量（サイズ）が大きくなったときに、処理時間がどれくらい増えるのかを調べます。例えば、繰り返し（ループ）において、その実行回数を数えてみるとイメージしやすいでしょう。

フレームワークとライブラリ

最近ではアプリケーションを作成する際に、「フレームワーク」を使うことが一般的になりました。

フレームワークは多くのプログラムで共通して使える処理の枠組みのことで、Windowsの場合は.NET Framework、iOSのApp Frameworks、Webアプリを作成する場合のWebアプリケーションフレームワーク、CSSフレームワークなどがあります。

フレームワークに似たようなソフトウェアとして「ライブラリ」という言葉が使われることがありますが、ライブラリはメールの送信やログの記録、数学的な関数や画像処理など、便利な機能をまとめたものです。

フレームワークを使って共通の処理を土台として実現し、ライブラリを使ってアプリケーションに独自の機能を簡単に追加できます。

APIとシステムコール

ソフトウェアがライブラリを呼び出すときのインターフェイスとして「API（Application Programming Interface）」があります。Windowsの機能を呼び出すときにはWin32 APIなどが使われ、WebアプリでもGoogle Chart APIや、SNSの自動投稿用として、そのサービスの提供元からAPIが提供されています。

また、OSが提供するインターフェイスを「システムコール」といいます。ハードウェアを制御するソフトウェアを作りたい場合には必須の知識ですが、ゲームや組み込みなどの開発を行わない場合には、使う場面が減っています。

テスト手法とテスト駆動開発

ソフトウェアは開発するだけでなく、「テスト」が必要です。テストは、作成したプログラムが使用通り動作しているか、不具合がないかを確認する作業です。

正しいデータや操作を正常に処理できるかを確認するだけでなく、誤ったデータが与えられた・想定外の操作が行われた、といった場合にも異常終了しないことを確認する必要があります。

なお、テストで不具合が見つかった場合に、その原因を調べて修正する作業や、修正する必要があるか探す作業のことを「デバッグ」といいます。

また、そのテストが動作するように実装する開発手法として、「テスト駆動開発」があります。テストを自動的に実行できる環境を用意することで、プログラムを修正した場合にも、他に悪い影響を与えていないかチェックできる可能性が高まります。

ウォーターフォールとアジャイル

開発手法としてウォーターフォールやアジャイルなどが取り上げられることがあります。

「ウォーターフォール」はV字モデルにおける要件定義や設計、開発、テスト、運用というステップを大きな流れとして、できるかぎり逆方向に戻ることがないように進める方法です。

一方、「アジャイル」はこのサイクルを小さな単位で繰り返す方法だと考えられます。

ただし、実際にはアジャイルにはスクラム開発やXP（eXtreme Programming）のほか、いくつかの手法があります。スクラム開発の場合であれば、見積ポーカーという見積手法や、スプリント計画、デイリースクラム、スプリントレビューなどプロジェクトを進めるにあたり、さまざまな手法が用いられており、単純にサイクルを小さくするだけではありません。

おわりに

プログラマとして働く上では、次々と新しい用語が登場します。それらを1つずつ学ぶだけではなく、複数のキーワードを関連付けて、調べていくことが大切です。知らない用語を見つけた、新しい用語が気になった場合には、これまでとどう違うのか、その違いを比べながら学ぶようにしましょう。

このコラムの内容は、2019年7月10日に開催した「プログラマを目指すときに知っておきたい基礎用語とは」と題したイベントで、より詳しく増井さんにご解説いただきました。今後も皆さまのスキル向上を支援するイベントを定期的に開催いたします。ぜひご参加ください。

【インタビュー】優れたコードよりも、当たり前のことを。年収1000万円フリーランスエンジニアへの道

エンジニアとしてのキャリアを考える上で、スキルアップに不安を持つ方は多いのではないでしょうか。株式会社リクルートスタッフィングが運営するITSTAFFINGでは、スキルアップのために努力されている登録スタッフにインタビューをし、普段のお仕事で気を付けていることや、スキルアップのための取組み方について、定期的にご紹介します。

「フリーランスとして年収1000万円」ーーそう聞くと、自分とは遠い世界、たとえば天才的なコードをスラスラ書けるとか、難しい要件のシステムを巧みに設計してしまう、そんな想像をされる方もいるかもしれません。今回お話をうかがった永井充さんは、フリーランスとして年収1000万円を実現しているそう。しかも、かつてITスタッフィングで登録派遣のエンジニアとして活躍していた一人です。現在のポジションをどのように獲得していったのでしょうか。

エンジニアへの道で一度挫折を味わう

永井さんは大学の水産学部を卒業。当時は、インターネット環境といえば、せいぜい大学や大企業の汎用コンピュータがつながっているぐらい。そのため、永井さんも学生時代にコンピュータに深く関わったわけではなかった。

しかし就職はソフトウェア開発会社へ。1988年のことである。まだインターネット普及前とはいえ、当時すでにコンピュータ業界は今後普及していく期待の業種だった。

永井さんが担当したのは大手証券会社のシステム開発。ターゲットはメインフレーム（汎用機）で、開発言語はCOBOLやFORTRANという今ではマイナーになってしまった言語。研修でコーディングを覚え、プログラマとして活躍した。

「結局、その会社には10年ほど在籍しましたが、自分にはコーディングは向いていないと感じました。それよりシステム全体を見渡すような上級SEを目指したいと思い、転職に踏み切りました」

転職先は営業が中心のシステム開発会社で、永井さんは客先でPMを担当。時代はちょうどWindows 3.1からWindows 95に移行する時期で、ホストコンピューティングからクライアントサーバ型のシステムへの移行も始まっていた。

「サーバーコンピュータもコンパックやIBMのタワー型筐体で、LANも今のようなTCP/IPではなく、Netware社のプロトコルで接続していた時代です。『ダウンサイジング』というキャッチフレーズが流行り、新たなプロジェクトが、それこそ山のように生まれていきました」

永井さんは同社で15年ほど務めたが、結果、この会社も退職することになる。その理由は、担当した大きなプロジェクトで損失を出してしまったこと。悩んだ挙句に責任をとって退職した。

偶然知った派遣という世界が再びエンジニアの道へ

もうエンジニアはこりごりと思い、次に転職したのは外資系保険会社の販売代理店で、職種は営業だった。2011年のことである。

「歩合制なので、売れているうちは収入も大きく伸ばすことができました。最初のうちは、友人や知人を頼って売っていったのですが、次第に手持ちの人脈も尽きてきます。そうなると苦しいですね。しかし、この仕事で、電話や手紙など、人脈構築のために地道な努力をすることを学びました（笑）」

永井さんは、結局、一定の成績を保てず、3年ほどで代理店契約を切られてしまい、無職になった。「奥さんに申し訳ない」という気持ちでいっぱいの永井さんは、警備員のアルバイトをしながらすぐに職探しを始めた。しかし、いくつもの求人に応募し、その都度、面接でスキルや経験を聞かれることの繰り返しが次第に煩わしく感じるようになってきたという。

「そんなとき、知人から聞いた派遣会社のWebページを覗いてみると、いろいろな仕事が豊富にあり、とても驚きました。登録時に自分の職歴やスキルを書いておけば良いのもとても便利でした」

もうこりごりと思ったIT業界だが、20年以上の経験があり、PMまで経験していることは自身の強みと考え、派遣スタッフとして電力系企業や通信キャリア系企業のPMまたはPMOの仕事を選んでいった。

自身に対する人件費に見合ったサービスを提供できているか？

その後も、いくつかの派遣先を経験した永井さんだが、2018年に、派遣からフリーランスへの転機となるプロジェクトに携わることになる。

そのプロジェクトとは、派遣先であるITサービス企業でPMOスタッフとして働くというものだった。

「実質PMとして動いていて、主に化粧品通販会社のコンタクトセンターなどを任されました。改修や機能追加などもあり、常にバックログが10件ほど走っていて、収支を考えながら、人員をどのように配置していくかを考えるのが、とても面白い仕事でした」

このようなプロジェクトを任され、収支や人件費について考えることで業務に対する視野が広がり、フリーランスとして働くことを決めた。

しかし、フリーランスになることに不安はなかったのだろうか。よく言われるのは、仕事が無くなったときに困らないかという問題である。

「その点については、常に5社ほどエージェントと連絡を取り続けています。加えて、これまで派遣でお世話になった仕事先のキーパーソンの方々にも。なかには『今の仕事が無くなったらウチに来て』と言ってくださる方もいらっしゃいます」

今の仕事をこなすだけでなく、先を見据えた営業活動も。こうした地道な関係構築は、かつて外資系保険会社の営業をしていた時に身につけたものだそう。

「ちなみに、無職だったときにやっていた警備員のアルバイトですが、今でも週に1回だけやらせてもらっているんです（笑）。休日は人を集めにくいらしく、重宝されています。これも将来、仕事がまったく無くなったときの保険のようなものですね」

年収1000万円のフリーランサーからのアドバイス

永井さんにとって、フリーランスになって良かったと感じている部分はどこだろうか。

「たとえば年収1000万円を達成するには、ざっくり時給にして5,600円が必要です。その上で月に160時間、そして12カ月間きっちり働かなければなりません。その点、フリーランスは準委任業務という契約なので、契約次第ですが、月ごとに結果を出せれば時間に縛られることがなく、働き方を自分で調節できます」

実際に、永井さんは、そのときの忙しさに合わせて仕事の時間を月140時間から180時間の間でコントロールしているという。

働き方が調節できて収入も向上する“良いことづくめ”のように見えるフリーランス。永井さんの話を聞いて自分も目指したいと思った方もいるのではないだろうか。そんな方に向けて、永井さんから心強いアドバイスをいただいた。

「私は人より優れたコードが書ける訳でもなく、卓越した設計ができるわけでもありません。PMの経験はありましたが、PMとしての個々のスキルだけなら、自分より上の人は世の中にいくらでもいると思います。そんな人たちと、同じ土俵ではとても戦えません。それならば、どうするか。人が嫌がること、やりたくないと思うことを率先して引き受けるようにしています。たとえば、プロジェクトの進捗管理は、担当者から煙たがられるので、多くのPMが嫌がる業務の一つですが、これもしっかりとやる。PMの仕事だから当たり前と思うかもしれませんが、そこがとても大切です」

加えて、永井さんはフリーランスとして活躍するためのポイントとして、きちんと会社に来る、トラブルが発生したときに逃げない、きちんとした恰好をする、の3つを挙げてくれた。「こうした当たり前のことを続けるだけでも大きな武器になる」という。

「フリーランスか派遣社員かというのは契約上の問題に過ぎません。大切なのは周囲の人たちに、いかに気持ち良く仕事をしてもらうかということです。たとえば、トラブルが発生したときに逃げないこと。これは、自分自身が解決に直接役立てなくても構いません。とにかくその場にいることが大切なのです。誰かを手伝えるかもしれないし、チーム一丸となって解決に当たるんだ、というムードをその場に作り出せるかもしれません。何ができるのかではなく、どう動くのかが大切です。きちんと仕事をしていけば、道は必ず開けてきます」

なにが自分の強みなのか、しっかり理解している永井さん。スキルを上げることももちろん大切だが、それとは別に、自分が周囲のためにできることを探してみるのも良いかもしれない。