Posts for: #2023/09

コワーキングとコミュニティ

0時に寝て3時、5時ぐらいに起きて7時に起きた。

ストレッチ

先週に比べれば、出張を終えてのんびり過ごしていたのもあってかなりよくなっている気はした。足の張りはどこも目立つほどではなく、左の太もも後ろの筋肉の張りが強かったぐらいで復調している感じはした。腰もそれほど自覚症状はなかったものの、トレーナーさんからみると硬めだったという話しもあり、たしかに部位によってはきついところもちらほらあって、腰はまだまだ復調していないことがわかった。今日の開脚幅は開始前155cmで、ストレッチ後158cmだった。暑さも和らいで時間も出来てきたので少し運動してもよいかもしれない。

コワーキングとコミュニティ

2014年11月に発刊された Coworking Magazine の創刊号がある。昨年ぐらいまでは amazon に在庫があって購入できたが、いまみたら在庫がなくなったようだ。2014年に出版して2022年まで在庫が残っていたという雑誌ではあるが、内容はとてもよいものだと私は思う。2014年頃、コワーキングという新しい働き方のスタイルが日本に輸入され、広まっていったときのそのときの雰囲気や価値観を本書から読み取ることができる。多くのコワーカーたちがコメントしていたり、インタビュー記事もあったりして、コワーキングの価値やコミュニティの良さを語っている。こうやって出版という形で残しておくことで、その歴史の過程を学ぶ機会にもなることが本書から伺える。

私はコワーキングのような価値観や働き方を2016年頃から知ることになり、私もコワーキングスペースで作業したりするようになった。しかし、当時はワークスペースとして利用しているだけでそれはコワーキングと呼べるものではなかった。本書を読んでいて、ある人はコワーカーとはコミュニケーションを取る人たち、またはコミュニティに参加する人たちを指すのだと話していた。コミュニティ参加しなければ、コミュニティの恩恵を受けることが難しく、その状態をコワーキングとは呼べないようだ。2022年6月に カフーツさんを訪問 して、いとうさんとコミュニティについて話してみて、私の知っている IT 業界のコミュニティの在り方とコワーキングにおけるコミュニティには通じるところがあって、それ以来、コミュニティを学ぶことや課題管理のヒントになると考えて、いとうさんの主催しているオフライン/オンラインイベントにも参加するようになった。

コワーキングの価値はコミュニティやコラボレーションにある。作業場としてのワークスペースではない。コラボレーションと言うと、企業間の業務提携だったり、新商品企画を共同でやるとか、そういう大きなものをイメージしてしまうが、コワーキングにおけるコラボレーションとはそんな大きな話しではない。ただ一緒に作業しながら、軽く雑談したり、なにかのテーマで話し合ったり、その場に一緒にいることで生まれるコミュニケーション全般を指す。共通の話題や課題に対して一緒に考えたりする行為で構わない。もっと小さいものだと気付けるようになった。

それは私がマイクロ法人を経営して1人で黙々とずっと仕事をしていても、この延長上に新しい価値を築けるような気がしないというのを実感した後だった。リモートワークと相談相手 にも書いたが、会社に勤めていると自然と同僚とコラボレーションしている。マイクロ法人には同僚がいないのでコラボレーションによる気付きや刺激を受けることができない。コワーキングは1人会社やフルリモートワークのような、同僚が身近にいない人たちへコラボレーションの価値を提供しているということを、身に染みてわかるようになった。

IT 業界では Open Source Software の歴史をみると、古くは1950/1960年代の Unix に端を発し、1990年代の Linux の公開、1998年の Netscape 社の Mozilla Firefox のソースコード公開などの大きなエポックメイキングを経て、社会運動としての OSS 文化や OSS コミュニティが発展してきた。その歴史の過程で日本では2010年前後から IT 勉強会という、主に Web 業界の様々なバックボーンをもつプログラマーが技術情報を共有するようになった。OSS の技術はみんなで共有するものという価値観があるが、それはこういった IT 勉強会によって草の根的に広まっていったと思われる。私もそんな IT 勉強会に参加して技術を研鑽してきたプログラマーの1人なのでまさに生き証人でもある。それはまさにコワーキングの人たちが言う、コミュニティのそれとまったく同じである。IT 技術という共通の話題で困っていることを共有したり、不具合を改善したり、新しいプロダクトを開発したりしていた。製造業の人たちには驚かれたが、web 業界はコンテンツを公開して広告費で儲けるビジネスモデルであることから、自社の技術情報やノウハウをすべて公開してしまう。ビジネス上では競合他社であっても、別会社の開発者とも仲良くなって技術情報を共有している。それが業界全体のレベルの底上げをしてきた。いまもその文化は変わっていない。

次にくる流れとして、IT 業界のプログラマーはどんどん独立していくと私は考えている。いまもフリーランスになる人は増えつつあると思う。スキルも経験もない若い人が安易にフリーランスになることはお奨めしないが、20年も働いてきたベテランはどんどんフリーランスになって、組織の枠に収まらない活躍をしていけばよいと思う。マイクロ法人を経営することのハードルも歴史上、もっとも低くなっていると私は思う。私が経営できているのだから普通のプログラマーでも経営できる。しかし、1人で働いていると、私が陥ったような「行き詰まり」を覚えるようになるかもしれない。コワーキングやコミュニティはそれを防ぐきっかけになるのではないか?と思うようになってきた。この「行き詰まり」に名前を付けたい。私が感じたのは次のようなことになる。

  • 自身が成長しているように思えない
  • 日々の生活で気付きや刺激がなくなる
  • 新しいことに挑戦する気概がなくなる
  • 自分の状態が自分で判断できない
  • 誰に何を相談していいか分からない

もしかしたら会社に勤めているときも同じような状況になっているときもあったかもしれないが、会社に所属していると、仕事はいくらでも上から降ってくるし、仮にぼーっと何もしなくても給料は毎月もらえる。この先どうやって生きていくのか?という、生命としての根源的な問いから目を背けてしまうような錯覚がある。なんの後ろ盾もないマイクロ法人やフリーランスになることでこういった根源的な問いから目を背けられなくなる。私の場合、そのことに2年目で気付けるようになった。今後のビジネスにおいても、直接的ではなく間接的にコミュニティというのはキーワードだと考えている。コミュニティへの理解を深めるためにもコワーキングには今後も注目していきたい。

初めて lvm を操作してみた

0時に寝て何度か起きて7時に起きた。最近は寝る前にはてブのアプリで適当に記事を読みながら寝ることが多い。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今日の議題はこれら。

ここ1-2週間ぼーっとしていて、忙しくもなく、なにかやっているわけでもないけど、のんびり過ごしている。軽いバーンアウトだと思う。先週末は休みも取った。「hugo のテンプレート作り」のような新規開発を、どこかのもくもく会やイベントに行って、その場で集中してやったらいいんじゃないか?というアドバイスをいただいて、確かにそういうやり方もよいように思えた。今週末は課題管理のコンテンツを考えて、できればブログに書いてみようと思う。

lvm の論理ボリュームの結合

新規に almalinux 8 で仮想マシンを作った。デフォルト設定でインストールしたら //home でパーティション分割されていて、これは使い勝手が悪いなと思ってパーティションを結合することにした。

$ df -h
ファイルシス               サイズ  使用  残り 使用% マウント位置
devtmpfs                     1.9G     0  1.9G    0% /dev
tmpfs                        2.0G     0  2.0G    0% /dev/shm
tmpfs                        2.0G  8.6M  2.0G    1% /run
tmpfs                        2.0G     0  2.0G    0% /sys/fs/cgroup
/dev/mapper/almalinux-root    70G  6.5G   64G   10% /
/dev/mapper/almalinux-home   437G  5.0G  432G    2% /home
/dev/vda1                   1014M  221M  794M   22% /boot
tmpfs                        393M   12K  393M    1% /run/user/1000

基本的には次の記事をみてやったらうまくいった。

/home をバックアップする

# mkdir /home-bkup
# cp -a /home/ /home-bkup/

emergency モードに入る?

# systemctl emergency

結合したい領域を unmount して、home の論理ボリュームを削除する。

# umount /dev/mapper/almalinux-home
# lvremove /dev/mapper/almalinux-home
Do you really want to remove active logical volume almalinux/home? [y/n]: y
  Logical volume "home" successfully removed.

バックアップからデータを戻す。

# cp -a /home-bkup/ /home/

/etc/fstab から不要なパーティション設定を削除する。

# vi /etc/fstab
...
/dev/mapper/almalinux-home  /home  xfs  defaults  0  0  # <- この行を削除
...

root の論理ボリュームに余っている領域を拡張する。

# lvextend -l +100%FREE -r /dev/mapper/almalinux-root
  Size of logical volume almalinux/root changed from 70.00 GiB (17920 extents) to <507.04 GiB (129802 extents).
  Logical volume almalinux/root successfully resized.
meta-data=/dev/mapper/almalinux-root isize=512    agcount=4, agsize=4587520 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1    bigtime=0 inobtcount=0
data     =                       bsize=4096   blocks=18350080, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=8960, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 18350080 to 132917248

この時点で1つの領域に結合されたことがわかる。

# df -h
ファイルシス               サイズ  使用  残り 使用% マウント位置
devtmpfs                     1.9G     0  1.9G    0% /dev
tmpfs                        2.0G     0  2.0G    0% /dev/shm
tmpfs                        2.0G   78M  1.9G    4% /run
tmpfs                        2.0G     0  2.0G    0% /sys/fs/cgroup
/dev/mapper/almalinux-root   508G   14G  494G    3% /
/dev/vda1                   1014M  221M  794M   22% /boot

バックアップを削除する。

# rm -rf /home-bkup/

マシンを再起動する。

# reboot

これで問題なければ完了。

次開発の要件決めは既定路線

1時に寝て何度か起きて7時に起きた。エアコンを入れていると夜は寒くなってきた。

feedly pro+ にアップグレード

前からやろうやろうと思っていながら忘れて放置していた feedly のサービスに課金した。基本的に sns をやめていく方針でいるため、情報収集のソースを rss リーダーに戻そうと考えている。これまでも sns と並行で feedly を使ってはいたんだけど、もうちょっと feedly の機能も使ってインプットの効率を上げられないかと考え始めた。Pricing をみると、pro, pro+, enterprise の3つのプランがある。真ん中のプランが推しのようだったのであまり調べもせず Pro+ プランを選択した。いまのところ、検索の機能を使うぐらいでしかないが、そのうち ai 機能的なものも触ってみようと思う。

次開発の優先順位付けと担当者の割り当て

先週の要件発散会議 の続き。発散させた要件を整理して優先順位を決めて、担当者まで割り当ててしまった。課題管理がうまくできている必然なのか、なにも迷わずに自然にこのモジュールは○○さんでといった棲み分けもできて、それぞれが役割を果たせば開発の要件が満たせる体制になっている。全体像としての要件一覧は概ね用意した通りではあったものの、要件や設計の詳細の話しをしていると、私の要件の誤解もいくつかあって、それらは訂正しながら設計していくことにはなる。それでもメンバーも成長してきて、私がお膳立てしなくても、メンバーが自ら考えてうまくいくように設計してくれそうな雰囲気もみえてきたりしていて、それによって、私は面倒で厄介なインフラの再整備に注力できたりもしている。前開発がうまくいったので、なんとなく次開発もうまくいきそうな、始まる前から気を抜き過ぎにも思えるが、もう始まる前から開発が終わっている (うまくいくことが分かっている) ような感覚をもっている。できることは分かっていて、あとはどれだけの量を次開発で実装できるかといった、私が区切りの線をどこに引くかだけ決めればいいんじゃないかと考えている。よいチームになってきたなとちょっと誇らしい。

地方は都会の人たちにとっての消費の場ではない

0時に寝てうまく眠れなくて、吐き気がして3時頃に起きてそのまま起きてたらいつの間にか寝て8時に起きた。夜遅くにアルフォート食べたのがよくなかったかもしれない。

go アプリケーションのライセンスチェック

お手伝い先で開発しているプロダクトは原則として oss ライセンスにするといった方針らしい。公けにソースコードを公開していないものの、お客さんが望めばソースコードも提供するといった運用にしているらしい。実際にお客さんでソースコードを要求されたことはないという。そのため、自分たちの開発したアプリケーションを oss なライセンスで提供可能かどうかを、一応は、調べておく必要がある。プレスリリースもしているし、いつお客さんが使い始めるかもわからないので、プロジェクトの隙間のときにライセンスチェックをした。

ググってみたら google/go-licenses というツールがあってこれを使って自分たちが開発したモジュールのライセンスチェックをした。問題なく apache 2.0 のライセンスで提供できることを検証した。

  • インストール
$ go install github.com/google/go-licenses@latest
  • レポート出力
$ cd path/to/repository
$ go-licenses report ./...
  • ライセンスチェック
$ go-licenses check ./... 2>&1 | egrep "^(W|E)[[:digit:]]+"

コワーキングのオンラインイベント

月例のカフーツさんのオンラインイベントに参加した。前回の所感はここ 。8月は私の予定があわなかったのでイベントを欠席したが、7月の所感がないのはなぜか忘れてしまった。単純に忙しくて書く余裕がなかったのかもしれない。

今回のテーマは都会と地方のコワーキングスペースの運営の違いなどについてざっくばらんに雑談するといったイベントだった。後半に ONOMICHI SHARE というコワーキングスペースを運営しているごとうさんという方が参加されて、広島県尾道市という地方というバックボーンをもっていて、ごとうさんからの視点や考え方を話していただいて、いくつか示唆を受けることがあった。ごとうさんが言うには、都会から尾道市へ移住してくる人たちにはなにかしら目的があって来る、しかし、地方は都会の人たちが求めているなにかを消費するだけの場所ではないという考えを大事にしたいと話されていた。

私が地方出身の都会暮らしだから感じることがある。都会の人たちにとっての地方は娯楽とみられることが多い。わかりやすさのために、地方の不便さや独特の文化などを例にあげるが、そこに住んでいる人たちにとってはそれが日常だから何も思わないことを、都会の人たちは娯楽だと接しているようにみえることがよくある。そのギャップを埋める役割があって然るべきだと私からも思えた。要は勘違いした人たちを、現実に引き戻す役割というべきか。その話の延長上で、地方の人たちは暮らしをよくしようとか、世界をより良くしようとか、ビジネスに挑戦しようとか、そういったことをまったく考えていなくて、自治体がどんなに過疎化していっても、生活が不便になっても、この生活が一生続くと思ってなにもせず、そのまま暮らしているという人たちも多い。都会の人たちの役割の1つとして、そういった地方の人たちに世の中はどんどん進んでいて、新しいことに挑戦する価値や楽しさもあるんだよという気付きを与えることができるんじゃないかと、雑談しながら思えた。

おそらく、ごとうさんの話しを聞く限りでは、そういう仲介をする役割を担っているようにみえた。コワーキングスペースマネージャーも奥が深いという気付きを得た雑談だった。

プロジェクト管理のドキュメントや資料の更新

23時に寝て何度か起きて7時に起きた。

開発方法論/開発ガイドの更新

前回の改訂 から約4ヶ月ぶりに開発方法論と開発ガイドを改訂した。

  • 開発方法論: プロダクトで採用している開発方法論の概念をまとめる
  • 開発ガイド: 開発方法論を具体的に実践する方法についてまとめる

近いうち、チームに新規メンバーが入る。今回の開発を経て新たにわかったことや変わったところなどを更新するつもりで全体を読み直してみたが、大きく変わったところはなく小さいアップデートに留まった。開発方法論に 情報共有とコミュニケーションのレベル というタイトルで5段階のレベルについての考え方を追記した。この内容は私もまだ完全に言語化できているわけではない。「聞かなくてもわかる」という価値観の存在をまったく疑っていないが、その背景にあるコミュニケーションの在り方や人間関係や組織での運用についてまだ曖昧なところが多い。それも含めて考えるよい機会だと思ってうちのチームに向けた内容に整理し直してまとめてみた。もう2-3回ぐらいこのテーマで話しをしたりすると、より言語化できてもっとよいものができそうな気配は感じている。

fun/done/learn のカスタマイズ

昨年からふりかえりの手法として fun/done/learn という手法を採用している。2週間のイテレーションが終わったときに毎回このフレームワークを使って、やったことをメンバーに共有するといった用途のために使っている。大きな開発のふりかえりを行ったときにマイルストーンごとの fun/done/learn の個数の変化などもふりかえってはいるが、そこの統計値がなにかに役に立つようには、いまのところ、うちのチームでは思えない。

今回のふりかえりをしているときにメンバーから done はいらないのではないか?という意見が出た。この手法の発明者のオリジナルの記事 ファン・ダン・ラーン(FDL)ふりかえりボード と読むと、done = deliver だし、done しなかったことも含めてのふりかえりを実践していたことが伺える。うちらはやったことをふりかえるためのフレームワークとして活用しているため、done がデフォルトでプラス fun/learn が付くといった運用になっていた。その通りだなと納得して done に置き換わる、うちらの開発の運用にあうカテゴリを考えてみて give を採用した。ゴロがよいように fun/give/learn と呼ぶ。

give とは、このマイルストーンでやったことを形式知として、他のメンバーに共有可能な状態にしたという意図を表す。wiki を書いたりするのもよいし、テックブログを書くのもよい。暗黙知を形式知に変えるには少し手間暇がかかるのでちょうどよいカテゴリに思える。3つのカテゴリに属するときにもっとも価値が高いような運用にも向いている。そのためのボードも作って、これを jamboard の背景に設定してふりかえりをしている。何ヶ月か運用してみて、うまくいきそうだったら fun/done/learn の亜種としてどうだろう?といった提案のテックブログを書いてみたい。

slog の完全移行の少し手前

0時に寝て何度か起きて6時に起きた。土曜日から喉が痛くてコロナ感染の懸念もあったけど、前日は一日中休んでいたせいか、喉の痛みは全くなくなった。たまたまだったのかもしれない。

slog 移行

slog 勉強会 で学んだ LogValuer という interface を使うと、機密情報のログ出力をカスタマイズできる。要はパスワードのような文字列を *** に置き換えるといったことをしたい。もっともシンプルな機密情報を扱う型として Secret を定義した。この Secret でラップした文字列を扱う分には slog のロガーでそのまま出力しても問題ない。

type Secret string

func (s Secret) LogValue() slog.Value {
	return slog.StringValue("***")
}

func (s Secret) String() string {
	return string(s)
}

あと自前で定義していたロガーのログ関数を slog のトップレベル関数を使うように1つずつコードを書き直していった。機密情報に関するところで一部まだ置き換えていないところもあるが、98%のログ出力のコードは slog に直接置き換えた。時間がかかるだけの面倒くさい作業なので、こういうプロジェクトの隙間に地道にやるのがよいと思う。今回も移行にあたって slog のコードを少し読んだが、slog は本当に既存のログ出力の機能で大事なところだけをシンプルに実装していてよく出来ていると思う。

秋休み

日曜日は久しぶりに休もうと決意して、なにか本でも読もうと思っていたものの、機動戦士ガンダム00 を見返したりしていた。リアルタイムでみていたときはそれほど関心はなかったけれど、いま見返してみるとよい作品だなと思えるぐらいの印象が少し変わった。

日記書いて事務作業しただけ

22時から寝始めて何度か起きて7時に起きた。燃え尽き気味でぼーっとしている。起きたら (しんどくはないが) やや喉が痛くて、出張帰りだし、とうとうコロナに感染したかもしれないと思い、外出するときはずっとマスクを付けてた。

ストレッチ

今週も東京出張してきて、さらにいつもよりホテルへ歩く場所に泊まっていたせいか、まずまずの疲労度だった。全体的に疲労はあるものの、それでも先週のピークよりは改善したかもしれない。右足は依然として悪いものの、腰の張りもややあったかなと気になった。今回初めて行ったストレッチで腰をひねりながら上下に引っ張るようなストレッチをして、右と左でまったく伸びや張りが出る部位が異なっていることに気付いた。トレーナーさんによると、左右で筋肉の硬さが異なることからそうなっているのではないかとのこと。右腰から臀部にかけての硬さがみられるとのこと。今日の開脚幅は開始前155cmで、ストレッチ後158cmだった。この数値はいつも通りかな。全体としてあまり体調はよくない。

また podman に苦戦する

23時に寝て何度か起きて7時に起きた。出張帰りでなんかバテててなにもせず休んでいた。少し喉に引っかかりがある。出張で飲み歩いたし、そろそろコロナ感染?の疑いをもって生活してみる。

podman と dbus-daemon とsystemd の調査

2次開発の成果物をドッグフーディングの目的で社内へ導入する。メンバーが作業していて nginx が正常に動作しないという。ログをみろとすぐにコンテナネットワーク内の dns サービスが正常に動いていないということはわかった。podman は aardvark-dns というサービスを使って dns を管理する。但し、このサービスがまだまだ安定していなくて不具合があるのを以前にも確認した。このサービスの振る舞いがよく分からなくて、意図しない状況や状態に対して正常に動作してくれない。

他にも調査をしていて rootless で podman コマンドを実行すると次の issue で書かれているようなワーニングが出力される。dbus-user-session というパッケージを導入すれば解決するとある。

dbus-daemon のサービスは systemd で動いていて、systemd のユーザーモードと dbus が正常に動いていないというところまではすぐに分かった。その状態だと rootless な podman が正常に動作しないということもすぐに分かった。ここまではすぐに調査できたが、問題はどうやれば sytemd のユーザーモードを dbus を正常に動くように復旧できるのかがまったく分からない。systemd がそもそも難しいのに、そのユーザーモードは権限管理が関係するのでさらにもっと難しい。1日調べてお手上げで他の社員さんにも相談してみた。

今日は自分の作業は進捗しなかったけど、メンバーの作業の進捗をみていて、メンバーがはまっていたところを助言して、その問題は解決してうまくいって、それだけで満足していた。

次開発と要諦調和

0時に寝て何度か起きて7時に起きた。飲み歩いてお腹いっぱいでお酒もい飲んで寝たから連日でよく眠れなくて初めて泊まったホテルの部屋の印象が悪くなってしまった。ホテルに非があるとは思っていない。

3次開発の要件打ち合わせ

前回の開発課題の打ち合わせはここ 。2時間をとって要件を発散させる。

次は3次開発になるため、2次開発でできなかったこと + アルファな要件を発散させる。概ね予定調和にもなってしまって、私の中でモチベーションコントロールが難しい。私が準備していった展望や構想がブレていないことはよいことでもあるのだけど、会議がつまらないというか、私が緊張感を失ってしまう。私は自分の構想を一番理解しているのでそれをもっと明文化して関係者やメンバーに伝える必要がある。そこに私にはなかった刺激がいくつか入るとよいと考えている。1人の人間の考えることなんか、せいぜいうまくいって8割だと思う。残りの2割は誤っていたり、意味をなさなかったりするのではないか。だからこそ、他者の反論や別の視点の意見には注意している。

今回は用途の違う管理画面をどう設計するかが最も難しい意思決定の話題だった。いまも管理画面はあるが、一般ユーザーが使う情報更新のための管理画面を既存の管理画面に付加するか、独立した管理画面として新規に作るか。話し合った結果、後者のやり方で進めようと私は考えている。もともとの私の意見もそちら側であるし、次の開発体制やマイクロサービスに近いいまのアーキテクチャの構成を総合的にみてそれがよいと考えている。もうちょと突っ走ってやってみてメンバーから反発が起きないかを伺ってみることにする。

稀な出張飲み歩き

0時に寝てあまり眠れなくて7時に起きた、いつもと違うホテルのせいか、あまりうまく寝付けなかった。部屋も広くてよかったのになぜか落ち着けなかった。

プロジェクトの進捗報告

出張したときの月例報告の10回目。前回の進捗報告はこちら

概ね 事前に準備してあった資料 のまま次の3次開発へ進むことに決定した。いくつか経営者に確認することも用意していた。「よしなにはからえ」な方向で取り組めそうだ。1年近く開発を継続してきて、次の3次開発を終えれば品質面でも私からみて自信をもてるようにはなると思う。

そろそろ私の契約を終えてもいいんじゃないかと考えていたが、もう少し追加の開発に付き合ってほしいとのこと。それを受けて「もうちょっとだけ続くんじゃ」と自身のモチベーションコントロールをしていく。早ければ今月いっぱいで契約終了する可能性もあった。継続しても、あと3-4ヶ月程度で終えて、その後に私も3ヶ月ほど休もうとか考えていた。まだまだプロダクトの機能や品質に満足していない、私が長期休暇を取れる状態ではないぞという激励でもあったのかなと思う。

セルフ居酒屋

晩ご飯に 大崎一番家 さんへ行ってみた。

店主が1人でやっていて、お客さんはセルフで飲みものを手配する。冷蔵庫からお酒 (ハイビール、酎ハイ、瓶ビール) を取ってきて、氷も冷凍庫から勝手に容器に入れてもってくればいいと言う。あとで卓上に置かれた缶や瓶を数えて精算する。ボトルを入れているお客さんなんかはやってきて勝手に飲み始めたりもすると店主が話していた。食べものだけオーダーシートに書いて厨房にいる店主に声をかけて提出する。厨房の入口に置いていたら、都合のよいタイミングで受けとって料理を作ってもってきてくれる。こういうスタイルのお店を嫌う人もいるだろうけど、私は自分のできることが多いスタイルのお店は気楽で気に入ってしまった。店主も関西の人らしくて陽気な性格だった。料理が大皿なので1人だと2-3皿食べるとお腹いっぱいになってしまう。野菜サラダなんかは私は大皿でもりもり食べたいのでちょうどよかった。口コミでデミグラスカツがよいとあったので注文してみておいしかった。但し、1人で食べるには多過ぎで2-3人向けの分量だが。

こういう1人で全部やるという働き方そのものを私は好む。誰かと一緒に働くの、他の人間と一緒に働くのはどう繕っても気を遣う。居酒屋のような、本来は1人でできないことをお客さんの力も借りながら1人で成り立たせる工夫をあっぱれだと言いたい。以前 マイクロ法人のススメ に書いたが、1人で意思決定して楽しく働く、1人の会社が他の会社と協調して大きなお仕事や難しい課題を解決するという、新しい働き方に私も挑戦していきたい。

飲み歩き

大学の友だちに声をかけてみたら、そのとき浅草で働いていて、その後、ちょうどよい場所として新橋へ移動した。20時過ぎから新橋の居酒屋さんで飲んでいた。2-3年ぶりぐらいに会ったかな。社員が20人の頃に入社した会社がいまや社員が400人になっていて上場も視野に入れてお仕事しているとのこと。当然、その友だちも幹部社員になっていてすごいなぁと近況を聞いていた。マンションを3つ買ったとか話していた。

プロジェクトマネジメントやメンバーの育成など、私も最近はマネージャーをやっているからあーだこーだと話しをしていた。その友だちはもともとマネージャー職を目指していたので私よりもマネージャーとしての経験や知見が多い。その友だちも私に負けず劣らずのハードワーカーなので考え方は私と近いと思う。若い人に適正がなさそうでもどう教えるか、どこで見切るかといった話しが一番盛り上がった。その友だちは3年ぐらい面倒はみるが、それでダメなら適正がないと本人に告げて他の仕事に移ってもらうようにするという。適正がないと本人に告げることも優しさだという。たしかに大企業だと、まったくできない人が開発者として中堅社員になってたりすることもあり、それがプロジェクトの弊害になることを私は経験したことがある。あとお互いに年寄りでスキルもやる気もないのは無条件でダメみたいなところは一致した。以前、参加した オープンセミナーの懇親会 でも、成長しない社員に対してどう接するかの話しをしたことがある。そこでもこのままそのレベルで仕事を継続してもよいが、待遇はそれ以上あがらないことを伝えるとある管理職の方は話していた。

成長の度合いも個人差があり、どの程度をよしとして、どこで線を引くかは難しい。私はプログラミングが好きなら多少のスキルの個人差はあってもよいと考えている。しかし、会社になると組織に貢献しているかというのは大きな基準になるので必ずしも私の考え方は正しくはない。人間が人間を評価するのは本当に難しい。このまま小さい組織で評価とは無縁で働きたい。