ひよこインフラてっく!

ひよこインフラエンジニア「ひよこ大佐」による技術ブログ的なもの。インフラ技術や仮想化、Pythonなど。

Fedora 31でVagrantが使えなくなったときの対処と、Vagrant 2.2.6をVirtualBox 6.1に対応させる方法

どうもひよこ大佐です。

タイトルの通り、Fedora 31でカーネルのアップデートに伴ってVagrantが使えなくなってしまったので、その際の対処法をご紹介したいと思います。

発生した事象

メインのPC(Intel Hades Canyon NUC)でFedora 31を利用しています。この環境ではAnsible Towerの検証用にVagrantVirtualboxを利用しているのですが、いつも通り dnf updateカーネルの更新を含む更新パッケージを適用し再起動したところ、vagrant upしようとすると以下のエラーが発生するようになりました。

カーネルバージョン:

$ uname -r
5.4.7-200.fc31.x86_64

発生したエラー:

VirtualBox is complaining that the kernel module is not loaded. Please
run `VBoxManage --version` or open the VirtualBox GUI to see the error
message which should contain instructions on how to fix this error.

エラーの指定通り VBoxManage --version を実行すると、以下のWarningが出力されます。

$ VBoxManage --version
WARNING: The vboxdrv kernel module is not loaded. Either there is no module
         available for the current kernel (5.4.7-200.fc31.x86_64) or it failed to
         load. Please recompile the kernel module and install it by

           sudo /sbin/vboxconfig

         You will not be able to start VMs until this problem is fixed.
6.0.14r133895

上記指示通りに sudo /sbin/vboxconfig を実行するのですが、以下の通りエラーになります。

$ sudo /sbin/vboxconfig

vboxdrv.sh: Stopping VirtualBox services.
vboxdrv.sh: Starting VirtualBox services.
vboxdrv.sh: Building VirtualBox kernel modules.
vboxdrv.sh: failed: Look at /var/log/vbox-setup.log to find out what went wrong.

There were problems setting up VirtualBox.  To re-start the set-up process, run
  /sbin/vboxconfig
as root.  If your system is using EFI Secure Boot you may need to sign the
kernel modules (vboxdrv, vboxnetflt, vboxnetadp, vboxpci) before you can load
them. Please see your Linux system's documentation for more information.

原因

Virtualbox 6.0はLinux Kernel 5.4.xに対応していないため、エラーが発生します。 以下のChangelogにも、Virtualbox 6.1からサポートしている旨が明記されています。

https://www.virtualbox.org/wiki/Changelog-6.1

Linux host and guest: Support Linux 5.4

Virtualbox 6.1への更新のため、公式サイトからrpmをダウンロードしインストールしました。

Linux_Downloads – Oracle VM VirtualBox

Vagrantでエラー発生

インストールしたところVirtualboxは正常に動作するようになりましたが、今度はVagrantでエラーが発生するようになってしまいました。

Vagrantのバージョン:

$ vagrant --version
Vagrant 2.2.6

発生したエラー

Vagrant has detected that you have a version of VirtualBox installed
that is not supported by this version of Vagrant. Please install one of
the supported versions listed below to use Vagrant:

4.0, 4.1, 4.2, 4.3, 5.0, 5.1, 5.2, 6.0

どうやら、現在(2020/1/10時点)リリースされている最新版のVagrant 2.2.6では、Virtualbox 6.1に対応していないようです。

ワークアラウンド

以下のGitHubのIssueに記載されているワークアラウンドにしたがって対処します。 Vagrant 2.2.6 doesn't work with VirtualBox 6.1.0 · Issue #178 · oracle/vagrant-boxes · GitHub

1. plugin.rb の編集

/usr/share/vagrant/gems/gems/vagrant-2.2.6/plugins/providers/virtualbox/ 内の plugin.rb 内の module Driver (52行目) のブロックの末尾に、autoload :Version_6_1, File.expand_path("../driver/version_6_1", __FILE__) の行を追記します。

   module Driver
      autoload :Meta, File.expand_path("../driver/meta", __FILE__)
      autoload :Version_4_0, File.expand_path("../driver/version_4_0", __FILE__)
      autoload :Version_4_1, File.expand_path("../driver/version_4_1", __FILE__)
      autoload :Version_4_2, File.expand_path("../driver/version_4_2", __FILE__)
      autoload :Version_4_3, File.expand_path("../driver/version_4_3", __FILE__)
      autoload :Version_5_0, File.expand_path("../driver/version_5_0", __FILE__)
      autoload :Version_5_1, File.expand_path("../driver/version_5_1", __FILE__)
      autoload :Version_5_2, File.expand_path("../driver/version_5_2", __FILE__)
      autoload :Version_6_0, File.expand_path("../driver/version_6_0", __FILE__)
      autoload :Version_6_1, File.expand_path("../driver/version_6_1", __FILE__)
    end

2. meta.rb の編集

編集が完了したら、 /usr/share/vagrant/gems/gems/vagrant-2.2.6/plugins/providers/virtualbox/driver/に移動し、 meta.rb 内の driver_map (58行目) のブロックに "6.1" => Version_6_1, の行を追記します。

driver_map   = {
  "4.0" => Version_4_0,
  "4.1" => Version_4_1,
  "4.2" => Version_4_2,
  "4.3" => Version_4_3,
  "5.0" => Version_5_0,
  "5.1" => Version_5_1,
  "5.2" => Version_5_2,
  "6.0" => Version_6_0,
  "6.1" => Version_6_1,
}

3. version_6_1.rb の作成

最後に、2の手順と同じディレクトリ( /usr/share/vagrant/gems/gems/vagrant-2.2.6/plugins/providers/virtualbox/driver/ )で以下のコマンドを実行し、 version_6_1.rb を作成します。

$ sudo wget https://raw.githubusercontent.com/briancain/vagrant/fb4e6985e142da56bad143d70600cd3695c91757/plugins/providers/virtualbox/driver/version_6_1.rb

実行後、念の為パーミッションやオーナーが他のファイルと同じになっているか確認してください。

$ ls -la
合計 172
drwxr-xr-x. 2 root root  4096  1月 10 13:38 .
drwxr-xr-x. 7 root root  4096  1月 10 13:32 ..
-rw-r--r--. 1 root root 15850 11月  8 07:41 base.rb
-rw-r--r--. 1 root root  6188  1月 10 13:34 meta.rb
-rw-r--r--. 1 root root 18521 11月  8 07:41 version_4_0.rb
-rw-r--r--. 1 root root 22909 11月  8 07:41 version_4_1.rb
-rw-r--r--. 1 root root 23969 11月  8 07:41 version_4_2.rb
-rw-r--r--. 1 root root 25784 11月  8 07:41 version_4_3.rb
-rw-r--r--. 1 root root 28392 11月  8 07:41 version_5_0.rb
-rw-r--r--. 1 root root   357 11月  8 07:41 version_5_1.rb
-rw-r--r--. 1 root root   357 11月  8 07:41 version_5_2.rb
-rw-r--r--. 1 root root  3811 11月  8 07:41 version_6_0.rb
-rw-r--r--. 1 root root   357  1月 10 13:38 version_6_1.rb

これで、エラーが解消されました。同じ事象に悩んでいる方は参考にしていただければ幸いです。

OSSU(Open Source Society University)でコンピューターサイエンスを学ぶ

新年明けましておめでとうございます。ひよこ大佐です。

コンピューターサイエンスを基礎からしっかりと学び直したいと思っているITエンジニアの方は多いのではないでしょうか。

私自身、文系大学からそのまま新卒でIT業界に飛び込んだため、基本的な知識は業務上身につけていますが、体系的にコンピューターサイエンスを学ぶ機会がありませんでした。

私現在ではオンラインで卒業できる大学院や、edXUdacityなどの大規模オンライン講座(MOOC)により、ハーバードやMITなどの一流大学の良質な講義を無償で受けることもできるようになりました。また、JAISTAIITなどでは社会人でも入学しやすい社会人コースを設けており、働きながらでもコンピューターサイエンスを学ぶことが容易になってきました。

つまり、もはや文系のITエンジニアだったとしても、やる気と時間さえあればいつでもコンピュータサイエンスを学ぶことができる素晴らしい環境にいるわけです。

前述したとおり現在ではさまざまな「学び方」がありますが、「どこから手を付けたらいいのかわからない」「コースが多すぎて混乱する」という方もいるかと思います。今回は「OSSU(Open Source Society University)」というプロジェクトについてご紹介します。

OSSUとは?

OSSUとは、オンライン上の教材を利用してコンピューターサイエンスを自己学習するためのプロジェクトです。edXやcorsera、Youtubeなどのオンラインの教材を組み合わせ、体系的にコンピューターサイエンスを学ぶことができるようになっています。

(GitHubページのSummaryから引用)

The OSSU curriculum is a complete education in computer science using online materials. It's not merely for career training or professional development. It's for those who want a proper, well-rounded grounding in concepts fundamental to all computing disciplines, and for those who have the discipline, will, and (most importantly!) good habits to obtain this education largely on their own, but with support from a worldwide community of fellow learners.

Webページ: ossu.firebaseapp.com

GitHub: github.com

どうやって学習するのか

OSSUのGitHubにある「Curriculum」に沿って学習を進めていきます。初学者であれば、「Core CS」からスタートするのがよいでしょう。基本的なCSの知識をすでにある程度持っている方は、「Advanced CS」から始めることもできます。

始めるコースを決めたら、あとはカリキュラムに書かれている「Duration」や「Effort」の時間を目安に、学習を進めていきます。

例えば、Core CSの「How to Code - Simple Data」であれば、edX上で提供されているコースなので、edXでEnrollし学習を進めます。コースでの学習が完了したら、カリキュラムで指定されている次のコースに進みます。

詳細なコースの一覧については、GitHubのページを参照してください。 computer-science/README.md at dev · ossu/computer-science · GitHub

学習すると何が得られるのか

edXや各種サービスに散らばっているコンピューターサイエンスの教材を基礎から進めていくことができるため、無料で体系的にコンピューターサイエンスを学ぶことができます。もし「コンピューターサイエンスをどう学んだらよいかわからない」という方で、英語に抵抗がないのであればぜひ活用してみてください。

OSSUが向いている人

  • 独学が苦にならない人
  • できるだけお金を使わずに学びたい
  • 学位が欲しいのではなく、コンピューターサイエンスを学び直せればよい
  • 英語の教材でも苦痛ではない

OSSUが向いていない人

  • 学位が欲しい
  • 一緒に学ぶ仲間がほしい
  • 日本語でコンピューターサイエンスを学びたい

学習の方法にはそれぞれ向き、不向きがありますので、自分にとってどのような方法が良いのか、考えながら学習スタイルを決めると良いと思います。

私もこれから地道にOSSUの学習を進めていきつつ、学習レポートなども定期的にアップできればと思います。

ひよこ大佐とロードバイク: (1) ロードバイク納車

2020年、明けましておめでとうございます。今年も宜しくお願いいたします。

私のTwitterをフォローしている方はご存知だと思いますが、ロードバイクにハマり、遅いながらも週末にロングライドに出掛けたり、Zwiftでバーチャルライドを楽しんだりしています。2020年はじめての投稿は、そのロードバイクを購入した経緯と、「ひよこ大佐、新宿で立ち往生」事件についてお話したいと思います。

購入までの経緯

転職をきっかけにロードバイクを購入することになるのですが、ロードバイクが欲しいと思ったのはこれがはじめてではありません。

もともと中高生のころにルイガノのTR1という安いクロスバイクに乗っていたので、スポーツバイク自体は経験がありました。しかし、ロードバイクは「細いタイヤで怖い」「スポーツ志向の人が乗るもの」というイメージがあり、価格の高さもあってずっと手を出せませんでした。

しかし転職を機に、いままでずっと気になっていたけれども手を出せなかったロードバイクを買いたい!という気持ちが強くなりました。自分自身はとんでもなく運動音痴で、走れば常にビリ、体育の授業は本当に嫌いで、高校の部活で1年くらいテニスをしていた程度で、社会人になってからはことさら運動とはほとんど無縁でしたが、自転車で走ること自体は好きだったので、いつかその自転車の最先端であるロードバイクには乗ってみたいとずっと思っていました。

最初は予算の兼ね合いもあり、GIANTやルイガノなどの比較的低価格なモデルを検討していましたが、TREKのサイトを見たときにEmonda ALR5のマット塗装の美しさに一目惚れしてしまい、その日のうちに六本木のTREKショップで思い切って購入しました。確か18万ぐらいしたと思います。

f:id:hiyokotaisa:20200102003618j:plain

TREK EMONDA ALR5

ただ、ロードバイクを買えばそれで終わりではありません。「他にも揃えないといけませんよ」と店員さんに言われ、サイクルコンピューターとサドルバッグとライトはBontragerのものを購入しました。

ペダルとヘルメット、ポンプや工具類はTREKで買うと高かったので、Amazonで揃えました。PWTの工具は安くてそこそこ使えるのでオススメです。

まだ転職したばかりだったのでロードバイクとその他もろもろを合わせて20万の出費は痛かったですが、初めて納車された瞬間は「ああ、このカッコいいロードバイクが自分のものになるんだ」と感動したのを覚えています。

納車初日、そしてはじめてのパンク

2018年4月、TREK六本木で無事にエモンダを受け取りました。乗り出すと、クロスバイクと比較にならないほどスイスイ進むロードバイクに感動しながら、40km近く離れた埼玉の自宅を目指し走り始めました。慣れない道で迷ったりしながらも、新宿に着くまでは比較的順調な道のりでした。

事件は新宿で起きました。大通りを右折したところで「あれ?進まないな」と思い、タイヤを見てみると後輪がペシャンコになっていました。どうやら路肩のガラス片か何かを踏んでしまったようで、完全にパンクしてしまっていました。

幸いパンク修理キットは持っていたので、とりあえず自力で交換をしようとスマホで手順を調べながらおそるおそる作業をはじてました。

しかしはじめてのパンク修理、うまくタイヤを外してチューブを入れ替えることができません。30分ほど格闘しますが、外れる気配もなく、全くどうにもなりません。

「もうこれはプロに頼むしかない」とGoogle自転車店を探すと、まだ閉店していないスポーツサイクルショップの大手Y店がヒットしました。「これでなんとかなるかもしれない」と店の前まで押して歩き、店のドアを開けると店員さんに怪訝な顔をされてしまいました。めげずにパンク修理をお願いできるか聞いてみたところ、「いやーあと30分で閉店するので無理ですね」とあっさり断られてしまいました。結局店を追い出されてしまい、状況はまた振り出しに戻ってしまいます。

頼みの綱のY店に断られ、今から六本木に戻ることもできず、夜9時過ぎに新宿のど真ん中で、走れないロードバイクを抱えたまま僕は途方にくれてしまいました。家まではまだ30km以上あります。その時は鍵もないので、駐輪場に置いて電車で帰ることもできません。もちろん輪行袋なんか持ってないので、電車やタクシーに載せて帰ることもできません。 

それでも何とか家にたどり着かなければ、明日の仕事にも行けなくなってしまいます。そのためには、どうにかしてパンクを直す必要がありました。

まだ空いている自転車店はないかと必死にGoogleマップを調べたら、たった1軒だけ、小さな自転車店が営業中になっていました。

「これでだめなら自宅まで30km歩くしかない」と祈るような気持ちで電話を掛けたら、店主の方に「もうそろそろ閉店するけど、修理するからとりあえず持っておいで」と言われ、思わず泣きながら「すぐいきます!」と叫びました。

1kmほど離れた店まで自転車を担いで走り、すぐにパンクを直していただけました。夜遅くに嫌な顔せずに修理してくれたうえ、温かい声をかけていただいた「プロジェクト・エス」の店主の方には本当に今でも感謝しています。

プロジェクト・エス

結局18時過ぎには六本木のショップを出発したのに、家についたのは23時過ぎでした。何度も坂で脚が攣り、お尻が痛くなり、ヘトヘトになりながらなんとか帰宅し、「絶対にパンク修理を練習しよう」と心に誓いました。

こうして無事(?)ロードバイクを入手する流れとなりました。

(2)につづきます。

【小ネタ】GitHubのIssueのステータスをAnsibleから確認する

この記事は、「Ansible 3 Advent Calendar 2019」14日目の記事です。(遅刻してすみません) qiita.com

どうも、ひよこ大佐です。

今回も役に立ちそうで役に立たない、でもちょっとだけ役に立つAnsibleの小ネタをご紹介します。

Ansibleから、「どうしてもGitHubのIssueを確認して、ステータスに応じてなにかしたい!」ということ、ありますよね? 多分あると思うんです。 ないよという方は考えてみてください。ほら、ありますよね? あるんですよ!

なので、今日はそんなときにとても役に立つモジュールをご紹介します。

github_issue

github_issue」モジュールは、特定のGitHubのIssueの状況を確認できます。以下のように指定することで、registerに指定した変数にGitHubのIssueの情報を格納することができます。

---
- hosts: localhost
  tasks:
    - name: Get GitHub Issue via Ansible Playbook
      github_issue:
        organization: ansible
        repo: awx
        issue: 2139
        action: get_status
      register: result

    - name: Show result
      debug:
        msg: "{{ result }}"

パラメーターに、参照するリポジトリやIssueの番号を指定します。今回は私が作成してまだOpen状態になっている以下のIssueを参照してみます。

github.com

「action」パラメーターは、「get_status」以外にもいろいろ指定できそうな雰囲気を醸していますが、現時点では「get_status」しか指定できません。そのうち新しい機能が追加される可能性もあるので、楽しみに待ちましょう。

実行する

では、実際に実行した結果を確認してみましょう。

$ ansible-playbook -i hosts test.yml 

PLAY [localhost] ***************************************************************

TASK [Gathering Facts] *********************************************************
ok: [localhost]

TASK [Get GitHub Issue via Ansible Playbook] ***********************************
changed: [localhost]

TASK [Show result] *************************************************************
ok: [localhost] => {
    "msg": {
        "changed": true,
        "failed": false,
        "issue_status": "open"
    }
}

PLAY RECAP *********************************************************************
localhost                  : ok=3    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

「issue_status」が「open」となっているので、現在このIssueがOpenであることがわかります。このステータスをもとに、後続のタスクの条件分岐させたい場合などに活用できます。 現時点では、そのIssueがOpenかClosedのどちらかであることしかわからないので、今後の機能拡張次第ではより有用なモジュールになると思われますので、今後に期待しましょう。

Windowsでメンテナンス開始前にログインしているユーザーに通知する

この記事は、「Ansible 3 Advent Calendar 2019」13日目の記事です。 qiita.com

どうも、ひよこ大佐です。昨日に引き続き小ネタ風味のネタですが、今回はもう少しだけ役に立つモジュールを紹介します。

例えばWindowsをターゲットにPlaybookを実行して再起動を実施するようなシチュエーションで、もしログインしているユーザーがいる場合に備えてログアウトするように通知を流したいというケースがあります。今回は、そのような場合に使えるモジュールを紹介します。

Windowsホストにメッセージを表示するモジュールは2種類あります。

それぞれ若干挙動が違います。

win_msg

このモジュールは、ダイアログとして指定したメッセージをポップアップ表示させます。以下のようなテスト用のPlaybookを作成し、実行してみましょう。

---
- hosts: all
  tasks:
    - name: Pop up dialog to notify the maintenance
      win_msg:
        display_seconds: 60
        msg: "本日19時よりメンテナンスのため、このマシンは再起動されます。19時までに作業ファイルを保存し、ログアウトしてください。"

上記Playbookを実行すると、以下のようにダイアログが表示されます。作業中でも気が付きやすいので、個人的にはこちらを利用するのがおすすめです。

f:id:hiyokotaisa:20191212155827p:plain

win_toast

こちらもWindowsホストへメッセージを通知するモジュールですが、表示される通知の種類が異なります。ダイアログではなく、Windows 10やWindows Server2016で利用できる「トースト通知」として送信されます。

以下のようなPlaybookを作成します。記述内容はwin_msgモジュールと似ていますが、「async」を指定しないとexpireするまでタスクの実行が進まなくなるので、必ずasyncと組み合わせて利用してください。

---
- hosts: all
  tasks:
    - name: Send toast notification for the maintenance
      win_toast:
        expire: 60
        title: "System Upgrade Notification"
        msg: "本日19時よりメンテナンスのため、このマシンは再起動されます。19時までに作業ファイルを保存し、ログアウトしてください。"
      async: 60
      poll: 0

こちらのPlaybookを実行すると、以下のように通知されます。

f:id:hiyokotaisa:20191212155933p:plain

※今回の検証では、win_toastモジュールはWindows Server 2019では正常に通知されませんでした。お使いの環境によっては正常に動作しない可能性がありますので注意が必要です。ちなみにコミュニティモジュールなので、レッドハットによるサポートを受けられるモジュールではありません。

実際のメンテナンス作業では、明確なメンテナンス時間を設けてログインができないようにアクセスを遮断する運用もありますが、Windowsではそういった運用が難しいケースもあります。その場合は、メンテナンスを周知することと併せて上記のようなポップアップを表示させることで、不要な社内からのクレームを回避することができます。

【小ネタ】Ansibleでcowsayを有効化/無効化する

この記事は、「Ansible 3 Advent Calendar 2019」12日目の記事です。

どうも、ひよこ大佐です。

本格的な冬が始まる12月、めっきり寒くなっていまい、家から出たくないという方も多いのではないでしょうか。私もあまりの寒さに趣味のロードバイクも全然乗れていません。そんな日には、ブログを書くに限ります。 今回は、役に立ちそうで役に立たない、でもちょっとだけ役に立つAnsibleの小ネタをご紹介します。

皆様は、「cowsay」はご存知でしょうか。こんな感じのかわいい牛の絵文字が表示されます。

$ cowsay "モーーーーー"
 ________
< モーーーーー >
 --------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

Ansibleでは、cowsayコマンドが有効な環境では、デフォルトでcowsayによる表示がされます。ですので、cowsayによる表示を有効化したい場合は、cowsayをインストールするだけで有効化されます。

$ ansible-playbook -i hosts test.yml
__________________
< PLAY [localhost] >
 ------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

 ________________________
< TASK [Gathering Facts] >
 ------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

ok: [localhost]
 ______________
< TASK [debug] >
 --------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

ok: [localhost] => {
    "msg": "piyopiyo"
}
 ____________
< PLAY RECAP >
 ------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

localhost                  : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

「なんじゃこりゃ」と思った方、安心してください。もちろんオフにすることもできます。/etc/ansible/ansible.cfgを見ると、以下のセクションがあります。

don't like cows?  that's unfortunate.
# set to 1 if you don't want cowsay support or export ANSIBLE_NOCOWS=1
#nocows = 1

# set which cowsay stencil you'd like to use by default. When set to 'random',
# a random stencil will be selected for each task. The selection will be filtered
# against the `cow_whitelist` option below.
#cow_selection = default
#cow_selection = random

ここで、nocows = 1を記述することでcowsayによる表示を無効化することができます。ちなみに、 cow_selection = random を有効化すると、こんな感じで牛以外のなにかがランダムに表示されたりします。

[kyagisaw@hiyoko-hadesnuc ~]$ ansible-playbook -i hosts test.yml 
 __________________
< PLAY [localhost] >
 ------------------
  \
   \    (__)               
        o o\               
       ('') \---------     
          \           \    
           |          |\   
           ||---(  )_|| *  
           ||    UU  ||    
           ==        ==    

 ________________________
< TASK [Gathering Facts] >
 ------------------------
  \
   \   \_\_    _/_/
    \      \__/
           (oo)\_______
           (__)\       )\/\
               ||----w |
               ||     ||

ok: [localhost]
 ______________
< TASK [debug] >
 --------------
     \
      \
          oO)-.                       .-(Oo
         /__  _\                     /_  __\
         \  \(  |     ()~()         |  )/  /
          \__|\ |    (-___-)        | /|__/
          '  '--'    ==`-'==        '--'  '

ok: [localhost] => {
    "msg": "piyopiyo"
}
 ____________
< PLAY RECAP >
 ------------
     \
      \
          oO)-.                       .-(Oo
         /__  _\                     /_  __\
         \  \(  |     ()~()         |  )/  /
          \__|\ |    (-___-)        | /|__/
          '  '--'    ==`-'==        '--'  '

localhost                  : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

正直使いどころはあまり(まったく?)ありませんが、日々の業務に疲れた方はぜひ有効化してみて、かわいい牛さんに癒やされてください。 以上、ちょっとしたAnsibleの小ネタでした。

『Ansible構築・運用ガイドブック』が発売されました

どうも、ひよこ大佐です。

11月27日に、拙著『Ansible構築・運用ガイドブック インフラ自動化のための現場のノウハウ』が出版されました。Amazonやその他書店でお買い求めいただけます。

f:id:hiyokotaisa:20191201195222j:plain

この本を書いてみて思ったこと

今回、はじめて技術書を、しかも単著で書くことになり、書き始めた当初は想像もしなかったさまざまな苦労や学びがありました。いろいろな方にご迷惑をおかけし、もしかしたら今の自分の能力では書き上げることは無理かもしれないと何度も心が折れそうになりましたが、なんとか実際に本の形となりました。

自分が書き上げたものが、本として皆様のお手元に届けられるようになったことは大変嬉しく思います。今回の記事では、そんな技術書を書き上げるという経験から得られたものを皆様にフィードバックできればと思います。

技術書をどのように書くか

「技術書」と一口に言っても、その内容はさまざまです。製品の使い方を説明したものや、『Infrastructure as Code』のような概念を説明したもの、どちらかというと自己啓発に近い本まで、多種多様なIT技術書が毎月たくさん出版されています。最近では技術書典などで同人誌として技術書を書く方もたくさんいますので、従来の「商業における技術書」と異なる新しい形態の「技術書」もどんどん生み出されています。そのなかで、「どういった技術書にするべきか」は作者の一存に委ねられています。

「Ansible」というトピックにフォーカスしても、「Ansibleそのものの使い方の説明」「Ansibleを組織に導入するための課題の解決」など、いくつもの切り口があります。その中から「どういう本にしたいのか」をしっかりと意識していないと、本当に書きたいものが書けなくなってしまいます。「自分がこの本で何を読者に伝えたいのか」ということを、常に執筆中は意識しておく必要があります。

華美な日本語ではなく、わかりやすさに徹する

もともと大学で4年間クリエイティブライティングという学問を専攻し、「書くこと」について人より向き合ってきたという自負がありましたが、今回1冊の技術書を書くにあたってあらたに学ぶことが沢山ありました。特に「わかりやすい文を書く」という難しさは、技術書を書くうえで何度も直面しました。

※気がついたら大学のページでも私が本を出版したことが紹介されているようです。大学の先生方には在学中大変お世話になりました。 www.tais.ac.jp

日本語は曖昧な言語であるとよく言われますが、曖昧な表現で書き進めていても、書いている本人はそれが曖昧な表現だということに気づけません。筆者の頭の中には書くべき「全体像」があり、それを文章として落とし込む作業をしています。多少意味が通らないような表現や何を指しているかわからない表現があったとしても、自分の書いた文章であれば無意識に補完して読み進めることができてしまいます。私が査読で指摘されるまで全く違和感がないまま書いてしまった曖昧な表現は多々ありました。

小説でももちろん悪文はありますが、ある程度の決まりごとを守っていれば自由に記述することができます。ただ、技術書のような「情報を正確に読み手に伝えるための文章」では、華美なレトリックや独特の言い回しで個性を出そうとするよりも、「読みやすさ」を重視した平易な表現を中心にするほうがより多くの読者に受け入れられやすいものになります。

これはブログなどでも同様で、無意味に思わせぶりな表現だったり、少しかっこつけた文章よりも、誰でも理解できるような文章で書いたもののほうがスッと頭の中に入ってきます。もちろん、どのような表現を使っても筆者の自由ではあるのですが、読みにくい文章はそれだけで「作品」の価値を毀損してしまいます。

技術的な文章をわかりやすく説明するには、「誰がこの文章を読むのか」「何も知らない人がこの文章を読んだ時に、迷うような箇所はないか」というポイントを、原稿を書き終わって一息ついたあとにチェックすることのが重要です。これは自分でチェックするのももちろん有効ですが、もし周りに査読してもらえるようなエンジニアがいれば、他人に一度読んでもらうことで自分では気が付かなかった「不親切」な部分に気づくことができます。

幸い商業出版では日本語のプロフェッショナルである「編集者」の方の協力を得ることができますので、どうしても表現したいことがうまく書けない場合は、編集者と相談しながら進めるのもよいでしょう。

技術書を書くのは、トピックに対する知識も大事なのですが、「わかりやすく書く能力」というのも実は非常に重要です。

技術書における「ストーリー」

技術書はブログ記事と違い、ひとつひとつの章は分離しているようで完全には別れておらず、最初から最後まで繋がっているひとつの「作品」のようなものです。多くの読者が頭から読み始め、最後まで読みすすめていくことを考えると、「本の起承転結」は小説だけでなく技術書であっても重要だと気づかされました。

単純なトピックごとで章を分けるのではなく、前半の問題提起、それに対する「Ansible」という解決策の提示、といった本そのもののストーリーの流れを考えつつ執筆する必要性に気がついたのは、執筆を始めてからしばらく時間が経ってからでした。これは前述した「技術書をどのように書くか」という部分にも繋がってくるのですが、誰かに何かを伝えるには、「伝えたい内容」を明確にしたうえで、それをストーリーとして構築したものを提起しないと、ただ情報を羅列しただけのものになっています。

時間に余裕などない

初めての技術書ですし、できるだけ詳しいものを書こうとしていたのですが、とにかく時間がありませんでした。よりよいものを作ろうとするあまり締切に終われ、結果編集の方や査読に協力いただいた方にも多大なご迷惑をかけてしまいました。今回の執筆でもっとも反省するべきところです。

「もっと時間があれば」と今でも考えますが、仮にもう1年あったとしても、まったく同じことを思うでしょう。出版までの時間は有限で、趣味で書いているものではない以上、どこかのポイントで「完成」とすべきなのです。ですので、「限られた期限でどこまで書けるか」という想定を書き始める前から持っておかないと、延々と完成しない文章をひたすら書き続けることになってしまいます。

最後に

技術書典などが盛り上がりを見せる昨今、「技術書を書く」ことは特別なものではなくなってきました。多くの人がより技術について文章で説明する能力を求められることが多くなってくるでしょう。ただ、技術書を書くのは本当に楽しいことです。私もあれだけしんどいと思いながら原稿を書いていたのですが、一息ついたらまたなにか本を書きたいと思うようになっていました(出版社の方、ご連絡お待ちしております)。

来年の「技術書典8」もエントリーしていますので、こういった「技術を文章で説明する」ことをライフワークとして継続的にやっていければいいなと思っています。