カテゴリー: 日日是好日（不定期更新日記）

最近は仕事が忙しくて、太極拳の稽古にも顔を出せていない。

多忙になると、必要なことを後回しにしない、朝から有効に時間を使おうとする、など、割と利点も多い。生活も充実してくる。

マイナス面としては、（時間短縮という言い訳を自分にしながら）歩かなくなる、趣味に割く時間が無くなる、人と会わなくなる、といったところがあげられる。

趣味には当然、体を動かす、ということも含まれる。歩かなくなる、ということと相まって、どんどん体が豚になっていくのである。

先日、京都の「第一旭」というラーメン屋に、自宅用の生ラーメンを注文した。自宅で仕事をするときなどは、鍋（スープ用と麺用）を２つ使って、ささっと10分くらいで作って食べる。外出するより、はるかに効率的だし、旨い。７月から９月頭にかけての猛暑もあって、私はますます仕事以外での外出をしなくなっていた。

ある猛暑の昼、いつものように自宅でラーメンを啜っていると、頬の内側に激痛が走った。

鏡で口の中を映してみると、右頬の裏に、おせち料理で出てくる黒豆くらいの大きさの、口内炎ができていた。

「疲れているからな…。」と自分を慰めながら、痛みをこらえてラーメンの続きを啜り始めた。

暫くすると、今度は左の頬の裏側に激痛が走ったのである。

再度、鏡で口の中を映すと、今度は左頬の裏に、同様の血豆が出来ている。

口を閉じて、鏡で自分の顔をよく見ると、両頬が垂れて、ほうれい線が目立っている。要するに、豚化しているわけである。チャーシューはもう食えない。共食いになるからだ。

この時の推理では、度を越えた肥満で、頬の裏側まで肉がついてしまい、食事中に両奥歯で噛んでしまったのではないか、ということである。

その後は、夕食は炭水化物を控え、野菜スープを飲むようにしている。

来週は少し時間も空くので、太極拳の稽古にも行くつもりだ。

8月から、あるお客様の業務プロセス改善に関わらせていただくことになった。

巨大企業にしか存在し得ない業務であり、その業務内容も用語も、特殊きわまりない。属人的な判断や手作業も多い。

したがって、「こう提案すべき」、「他のプロジェクトではこうだった」、などということが全くできない。

元請けのプロマネの方に必死で喰らいつきながら、資料を読み、アウトプットを作っている。

不思議なもので、資料を読んでいるだけ、という状態では得られなかった安心感のようなものが、手を動かすことによって出てくる。

最初は意味もチンプンカンプンで頭に入ってこなかったプロセスや用語でも、理解というものを通り越して、スッと頭に入ってくる瞬間が多くなってくるからだ。

「スッと頭に入ってくる」というよりはむしろ、実はもうその段階では、大部分の専門用語はもはや自分の中で血肉になっているのかもしれない。

気付いたらキーボードを通して、いつの間にか資料に落ちている、ということが良くある。

感覚としては、なんとなく、歌を覚えるときの体験に似ている。「うろ覚え」という状態から、「暗譜」に脱却するときの心理状態かもしれない。

この感覚に対して、「用語が受肉する」、という表現は適切だろうか、、、とにかくそんな感じである。この感覚を他者と共有するのは難しいだろう。

独りよがりかもしれないが、こうなると既存プロセスの矛盾点や組織の壁などが理解できたような気分になるし、それに伴なってなんとなくユーザの苦労や苦悩も理解できた気にもなって、急にお客に対するシンパシーが湧いてくるのである。

ただ、こういったシンパシーには良い面と悪い面があるので、自分自身の気分をコントロールしながらやらねば、と思う。

■ 覚えたことから記録。

No	モード	コマンド	説明
1	閲覧	h	カーソルを一つ左へ移動する（行の先頭まで行ってしまうと、それ以上打っても無反応）。
2	閲覧	j	カーソルを一行上へ移動する（行の定義：行頭から改行コードまで）。
3	閲覧	l	カーソルを一行下へ移動する（行の定義：行頭から改行コードまで）。
4	閲覧	k	カーソルを一つ右へ移動する（行の終端まで行ってしまうと、それ以上打っても無反応）。
5	閲覧	x	一文字消す（現在カーソルがあたっている文字）。消した後は元々その右にあった文字にカーソルがあたることになる。
6	閲覧	dd	一行消す（現在カーソルがある行）。消した後は次の行が上に詰められる。カーソルはその行にあたることになる。
7	閲覧	u	一つ前の処理を取り消す。n回押すとn個分処理が戻る。
8	閲覧	j	改行を消す。

ある超大手製造業様の先進的なプロジェクトに関わらせていただいている。

ここでは、議事メモをとるのは私の役目になっている。

メモの編集は、最初はgVimでやっていた。

しかし、急ぐのでまた今xyzzyを使おうとしている。

そんな自分を戒めて、今宵はまた苦心惨憺しながらgVimで議事録を書くことにする。

ある製造業の企業様の、ERP刷新のお手伝いをしている。

大規模な刷新なので、インフラや基盤もチームが編成されてサブプロジェクト化されている。私はそこにメンバの一人として末席に置いてもらっている。

2018年9月現在、いよいよ要件定義、という段階に来ているが、業務担当やアプリケーション担当から、基盤に対する要求が一向に降りてこない。したがって、見切りである程度の準備を始めるより仕方ない。

大抵の大規模プロジェクトはうまくいかない（うまくいったように見せているプロジェクトが大半である）。

このあたりは、経営層、コンサル、ＳＩベンダ、エンドユーザなど、いろんな人の思惑の食い違いや、例えば組織などの構造的な問題があったり、参画する背景の違う様々な利害関係者（そしてそれぞれが特有の文化やプロトコルを当たり前のように押し付け合う）が集まって混沌とするために、そもそもコミュニケーションが成り立たなかったり、そのことによって多大なコストと時間を浪費するなど、原因を挙げればきりがない。この件については日を改めて整理したいと思う。

今回テーマとしたいのは、文書やその内容の体系化（管理）の問題だ。

以前、データセンターの仮想基盤構築のプロジェクトで、PMOの一員として参画したことがあった。途中までは、利害調整が仕事の大半を占めていたと記憶している。

基盤チームの単体テストの品質があまりにも酷かったため、「テストチームのリーダーをやってください。」と、プロジェクトマネージャから依頼を受けた。とっ散らかすだけとっ散らかして、時間もカネも無い状態でのパスである。

その時点で、単体テストは100％終了していることになっていた。後からよくよく調査すると、構築チームのリーダーが、単体テストフェーズでやるべきことを結合テストフェーズに先送りしていたから、そのように見えていた、というカラクリであった。まあそんなこはどのプロジェクトでもよくある話しで、プライドが高く、かつ心の弱い担当は大抵こういうことをしでかす（そいつの上司が「叱責」以外に管理の手段を持たないからだ）。

もっと問題なのは、現場のメンバがテストフェーズにおいて、「思いついたテストを全部やったから満点。」みたいな曖昧な話しで終わっている場合が、あまりにも多いことだ。

テストのフェーズになると、「どれだけ機能が実現できていて、どれだけ品質が担保されているか」、という目的で、要件定義書が読み返されることは、まずほとんどない。

これで何が起こるかというと、サービスリリース前になって、要件に対する品質保証が丸っぽ抜け落ちていたり、酷い場合には、機能が実装されていない（設計書がない）などという、あまりにもお粗末な話しになる。大抵なる。

私は、１週間ほどかけて、要件定義書の記載内容を構造化してコード化し、基本設計書の記載内容にもコードを振り、Excelで紐付けを行なった。

さすがにテスト項目までは手が回らなかったので、ここは現場のメンバーに依頼して、基本設計書の記述内容とテスト項目とのマッピングをやってもらった。

この結果、要件に対してテスト項目の全てが紐づくようになり（m:nの関係で非常に複雑なものにはなるのだが）、要件毎の進捗や品質保証のカバー率が可視化できるようになった。

最初は構築メンバーの負担を増やすことになり、「いきなり来た奴が仕事を増やしやがって。」みたいな感じで随分嫌われたが、途中から私がやりたかったことを理解してくれたようで、態度も随分やわらかくなった。

※というよりは全量と進捗が見えて、「あとどれだけやれば終わり」、ということが認識できるようになった段階で、他人に接する態度にも余裕が出たのかもしれない。

マネジメント側からは、建て直し結果そのものは評価されたが、取り組んだ内容や手法に関する評価は一切なかった（そもそも手法には興味がなかったようである）。

その後、これらをシステム化したりルール化したり手順化したり、ということについては、その他の業務に追いまくられてタイムアップで挫折した（余暇でやるほどのモチベーションも湧いてこなかった）。

現在のプロジェクトでは、インフラ構築を担当される方が、最初からそういった紐付けのスキーム（管理粒度は最小ではないが）を持っていらっしゃったようなので割と安心している。

苦い経験を多少なりともスキームやツールに落とし込んでいるあたりは、さすが大手、という感じである。

私はもう少し細かい管理が必要なのではないかと感じたのだが、ご担当曰く、「パラメータの一つ一つまで紐づけると時間とコストがかかる。」とのことで、これも尤もな話しであろう。

プロジェクトが火の車になってしまったのでそれを立て直す、というフェーズであれば、ある程度は整理にコストをかけることも黙認されるのであろうが、まあこの手の話しにはバランス感覚は必要だわな、、、。

某企業様の人事システムパッケージ選定のRFPを書き終えた。

システム担当の方が随分面倒を見てくださったおかげで、想定よりも早く終わった。

ほどなく、某別企業様からAI絡みで業務整理のお仕事が舞い込んだ。

所謂、「どの会社にでもあるスタッフ業務」の整理ではなく、かなり特殊な業務なので非常に属人的で、それゆえに定型化が非常に難しい。

なので、「これで100点」というイメージがない。

少しずつ合意しながら進めるしかない…。

【軽い日記】

今日は、過去にお客様から頂いた検収書のサンプルをPDF化する前にシュレッドしてしまうという失態をやらかしてしまった（ことに気がついた）。

PDF化したものはきっちり画像まで確認してからシュレッドするという習慣をつけなければと痛感した。

【gvimと他ツール（メーラー）との連携】

さて、メールクライアントはSylpheedというオープンソースのものを使っている。

メール作成時にはsylpheedの標準機能ではなくて、gvimが使いたい。

したがって、「外部エディタを自動的に起動する」という設定と併せて、外部エディタにはgvimを指定しておいた。

これで、メール作成時には難なくgvimが立ち上がるようになった。

しかし、gvimでメールを書いて保存したら、sylpheedに引き継がれてきたメール内容が文字化けしていた。

色々調べた結果、_vimrcに設定した「fileencoding」がまずかったということが判明した。

以下のようにエンコーディングの順番を変えるだけで、日本語の文字化けは解消された。

変更前：set fileencodings=iso-2022-jp,utf8,euc-jp,cp933

変更後：set fileencodings=utf8,iso-2022-jp,euc-jp,cp933

良かったこれで今日も寝られる。

【メールクライアントにSylpheedを選択している理由】

Sylpheedを使っている理由はいくつかある（以下のとおり）。

■ メニューが素直である（直感的に理解しやすいし、要らないものがついていない）。

■ メール1通を1物理ファイルとして保存してくれているし、ディレクトリ構造も見たままなので、非常にシンプルでよい。

特に後者はメールをいつまでも保持しておくメール貧乏性には本質的な問題である。

以下のような自問自答をした結果、やはりメールファイル単位は最小で管理されるすべきであるという結論に至った。

Ｑ：メール1通につき、1ファイルになっていると何が良いのか？

Ａ：別に良くない（というより、全メールを巨大な1物理ファイルとして管理しているほうが異常）。

Ｑ：全メールが巨大な1物理ファイルになっていると何がまずいのか？

Ａ：最低でも2つの弊害がある。

・１つ目：巨大なファイルが破損したらどう復旧するの？

・２つ目：復旧のことを考えて、バックアップを毎日とるとして、そんなでかいファイル毎日バックアップ取るの？バカじゃないの？

上記のような葛藤を経て、僕はSylpheedを愛用している。

バックアップもすぐ済むし、万が一、メールファイルが1つや2つ破損していたとしても、全体的には影響しないし、トラブル時の復旧も破損したファイルを選んで上書きすれば良いだけなのですごく使いやすい。

自分の所有するローカルPCにVimを導入した。

これまで、「xyzzy」という非常に優れたテキストを使用していたが、これを泣く泣く放棄し、「Vim」に乗り換えるという、吾が人生において非常に重要な決断をした。どれくらい重要かというと、京都から東京に引っ越してきて20年近くになるが、「もうそろそろ京都弁やめるか。」という程のものではある。

「xyzzy」を離れ、「Emacs」でもなく、「Vim」を選択した理由はいくつかある。

■ xyzzy（emacs系の和製エディタ）は個人がご厚意で提供なさっているエディタなので、諸々の理由（たとえば、Windowsの新バージョンリリース）で使えなくなってしまう可能性がある。

■ UnixやLinuxに標準で搭載されているエディタはviであり、どちらかというとemacs系よりはviの操作に慣れておくほうが良い。

■ 導入数において、emacsがviに押されている（viのほうがシェアが高い）。

■ emacsはWindows環境への導入のハードルが高い（日本語入力とか、なんか色々大変そう…）。

■ その他いろいろ。

昨日（2018/08/19）、ようやく初期導入が完了した。

以下の２点で躓いた。以下に記述する。

■ Windows環境であっても、環境変数「HOME」は設定したほうが良い。

■ 画面からマウスで設定した内容はvimが保存してくれないため、フォントや色設定は「_vimrc」ファイルに明示的に設定しないとダメ。

「_vimrc」ファイルのについては、ウェブで公開されている情報をもとに、以下のように設定しておいた（足りないフォントやカラーテーマはダウンロードして導入した）。

set encoding=cp932
set guifont=ProggyCleanTTSZBP:h14
set guifontwide=Osaka－等幅:h12
set ambiwidth=double
set encoding=utf8
set fileencodings=iso-2022-jp,utf8,euc-jp,cp932
set iminsert=0
set imsearch=-1
colorscheme farout

現在は「vimtutor」と格闘中である（本ページの編集もEmacsキーアサインで行なっている有様…何とか慣れなければ…）。