冥冥乃志

ソフトウェア開発会社でチームマネージャをしているエンジニアの雑記。アウトプットは少なめです。

follow us in feedly

2018/2に読んだ本

ようやく、シュバルツバースから脱出しました。

なお、妻が入院してしまったので、オープンセミナー広島@2018の登壇はキャンセルさせて頂きました。残念です。準備は割としていたし、その後にチームギークを読みはじめて、テーマ的にもう少しブラッシュアップできそうだったので、なんとかして機会を作りたいな、とは思っています。

先月読んだ本

印象的な本

フィクション系

まあ、ARMSはともかくとして。

「クジラの子らは砂上に歌う」が、ガッツリ物語が動きだした感があっていいですね。泥クジラの面々が幸せになってほしいものです。

クジラの子らは砂上に歌う　11 (ボニータ・コミックス)

クジラの子らは砂上に歌う　11 (ボニータ・コミックス)

ちょっと意外だったのは「不滅のあなたへ」の展開ですね。あらすじ的なものを読んでいた限りは梶尾真治の「エマノン」シリーズ的な予測をしていたのですが、若干違う模様。とっかかり的にはよくある展開感を拭えなかったので、続刊を手に取るかどうかは少し微妙。

不滅のあなたへ（１） (週刊少年マガジンコミックス)

不滅のあなたへ（１） (週刊少年マガジンコミックス)

一番収穫だったのは「ユートロニカのこちら側」です。この作品で描かれているのは、ディストピアでもユートピアでもなく、もうすでにその辺に転がっている緩やかな変化の行き着く先でもあるわけで、SNSの炎上芸人の末路を見ているような気分にもなってきます。ただ、これに描かれているほど人間って反抗するのかな、とも思って、少し楽天的な結論に感じたのは私だけでしょうかね。

ユートロニカのこちら側 (ハヤカワ文庫JA)

ユートロニカのこちら側 (ハヤカワ文庫JA)

ノンフィクション系

「ファシリテーショングラフィック」は買います。自分でも買います。

ファシリテーション・グラフィック―議論を「見える化」する技法 (ファシリテーション・スキルズ)

ファシリテーション・グラフィック―議論を「見える化」する技法 (ファシリテーション・スキルズ)

「新潮45 薬害でっちあげ」は子宮頸がんワクチンに関するものです。でっち上げのやり口が整理して書かれていて、非常に参考になります。

薬害でっちあげ　あまりに非科学的な子宮頸がんワクチン阻止運動―新潮45eBooklet

薬害でっちあげ　あまりに非科学的な子宮頸がんワクチン阻止運動―新潮45eBooklet

「Scalaをはじめよう」は、Scalaもくもく会で教えて貰った本。復習するにはいい本でした。別の言語は習得していて、これからScalaと言う人には良い本なのではないかと思います。

Scalaをはじめよう！　─マルチパラダイム言語への招待─ (技術書典シリーズ（NextPublishing）)

Scalaをはじめよう！　─マルチパラダイム言語への招待─ (技術書典シリーズ（NextPublishing）)

近況整理

最終更新日(2018/2/22)

基本情報

今までのキャリア

プログラマ

個人的な志向としては、バックエンドとモデル層、アーキテクチャがきれいなことに惹かれるタイプで、フロントエンドは得意ではないです。RDBMS層はFirebird/Oracle/MySQL/SQL Serverなど現場にすでに導入されたものに合わせて利用していたので、一つの製品特性に特化するというより、クエリやアプリケーションレベルでのパフォーマンス向上のアプローチが多かったです。

  • Delphiでのwin32ネイティブアプリ保守開発
    • 自社オリジナルハードとのTCP/IP接続あり(シェイクハンドから)
    • エンディアンの変換など
    • 一人開発なので、サービスエンジニアチームと連携して保守体制を構築
      • ドキュメントの整備
      • 全国のサービスエンジニアへの連絡体制構築
      • 保守体制の整備
  • 派遣、客先常駐(Java他,オープン系)
  • イントラ系システム構築
    • データ連携基盤(HULFT,DataStageなど)が中心
    • Web系の開発でリーダー、イテレーティブな開発を推進(東京のビジネスチームと岡山の開発チームで)
  • パッケージ/サービス開発
    • REST API開発(Spring framework)
    • データ連携バッチ(Java)
      • データタイプとテーブル以外は固定になるケースが多いので、型クラスっぽいアプローチでETLのようなDSLを作った
  • 個人

マネージャ

  • OEM開発チームの立て直し
    • チームの役割整理
    • ふりかえりを通じた継続的な開発プロセスの改善
    • テスト/レビュー体制の構築
    • カンバンの導入
    • それらが円滑に進むような案件スケジュールの調整
  • ゼロからのプロダクト開発チーム立ち上げ
    • ビジネスサイドとプロダクトの方向性の検討、初期コンセプト策定、ロードマップの合意
    • デザイン会社とのやりとり、デザインの検討
    • 開発範囲の検討と仕様の策定
    • データ連携部分の実装
    • リリースを踏まえたアーキテクチャ検討
    • 受入テスト、リリースノート作成
  • 既存チームの交通整理
    • 外部チームとのやり取りの一元化
    • パッケージバージョンアップとカスタマイズのスケジューリング

これからやりたいこと

起業じゃないの？という話もあるんですが、自分の中で起業がやりたいことにつながらない気がしているので、当面はそのつもりないです。

Manager as a Service

これからのマネージャの強みは、様々な現場の様々なケースに対応できることだと思います。そのため、一つの会社/チームにすべてのリソースを割り振るのではなく、サービスとしてマネージャを共有してもらい、並行して走る他の現場の様々な問題を抽象化して各現場に生かすスタイルを模索したいです。

そのため、フルコミットするまで必要としていないけど、マネジメントで悩みを抱えているチームをスポットで支えるということもやってみたいと思っています。ゆくゆくはエンジニアチーム以外のマネジメントもできるようにしていきたいです。

フルリモートマネージャ

これからエンジニアに限らず、様々な業種でリモートワークが選択できるようになるはずです。そうなると、基本的にチーム全体が1つのサイトにそろっていないことを前提としたマネジメントが求められます。そのような状況の中で、マネージャの専門性というのもこれから変わっていくのではないかと思います。

具体的には、

  • リモートでのコミュニケーション促進
  • フロー/ストック情報の取り扱い
  • リモートを前提とした可視化のための環境整備

があげられると思います。

エンジニアが価値を出せる組織づくり

速く言えば、プロ野球でGMと呼ばれるポジションとグランドキーパーを併せ持ったようなポジションです。現場のニーズに合わせて採用計画を立てて実施、エンジニアが価値を出すことに集中して、それを周りから理解してもらえるようなエンジニア組織のあり方を模索したいです。

やりたくないこと

  • 勤務体系に柔軟性のない働き方
  • メンバーを信頼しない働き方

2018/1に読んだ本

「時のオカリナ 3D」は片がついて、次はEXPERTモードでシュバルツバースラスト。

今月はオープンセミナー広島の準備を始めたところなので、数は少ないですね。来月まではこんなペースかと。実は私、登壇することになっております。

osh.connpass.com

先月読んだ本

印象的な本

フィクション

今月は該当なしですね。アニメで見たものの再読ですし。

来月には楽しみにしてたこれを読むのでこれが入ってくるかなあ、とは思いますが。

ユートロニカのこちら側 (ハヤカワ文庫JA)

ユートロニカのこちら側 (ハヤカワ文庫JA)

ノンフィクション

とにかくこれが面白かったです。

症状を知り、病気を探る 病理医ヤンデル先生が「わかりやすく」語る

症状を知り、病気を探る 病理医ヤンデル先生が「わかりやすく」語る

本来は専門書(看護系の学生向け？)なので、門外漢が楽しむとかちゃんとした読み方ではないのでしょうが。

ドクターGとか大好きなんですよ。事象から小さなヒントを見つけてロジックを組み立てていくやり方が気持ちいいんですよね。ケースとしてのクリティカル度合いが違うことが多いですが、システムトラブルに対応している時なんかを思い出します。アプローチの面では同じかと。

こちらもよかったですね。

異文化理解力――相手と自分の真意がわかる ビジネスパーソン必須の教養

異文化理解力――相手と自分の真意がわかる ビジネスパーソン必須の教養

借りて読んだのですが、身になることは多かったです。国だけじゃなくて、企業文化とか業界的なものも考えておいたほうがいいかも。

「ホワイトボードチャレンジで遊んでみよう vol.1」を開催しました

脊髄反射でやってみようと思ったことを実行に移せた時ってスッキリしますね。

gbdaitokai.connpass.com

当日の様子はこちら。

ちなみに、写真の光の加減がなんかおかしいですが、レンズカバーの部分にヒビが入ってたっぽい。そろそろ替え時ですかな。。。

ホワイトボードチャレンジ is 何？

デザイナーとクライアント、タイムキーパーに別れて、お題について短時間でロールプレイするプロダクトデザインの訓練です。詳しくは今回実施のきっかけとなった下記ブログを。

blog.haiji.co

今回の実施方法

今回は2サイクル実施。ブログのやり方を何点かカスタマイズして実施しています。

まず、今回の参加人数が7人ということがあり、3人ずつのチームにすると余ってしまうため、1サイクル目ではクライアント役を、2サイクル目ではデザイナー役を一人増やすチームを作って見ました。

また、クライアント役の人がイメージ膨らませるための時間を20分の前に明示的に5分ほど設けました。

また、ブログでは全体の流れを20分間でデザイナーが配分するとなっていましたが、最初から息継ぎのタイミングも自分でコントロールするのは難しかろう、というのもあって、目安の時間でタイムキーピングしてみました。

最後のプレゼンテーションは、連続して取らず、せっかくなので他チームも合わせて聞く場にしました。デザイナーからクライアントに向けてプレゼンをしてもらった後にクライアントとタイムキーパーからそれぞれ感想を聴いて、他チームからもコメントあれば、という感じで。

手探りでしたが、割とうまくいった気がしてます。

所感

いや、もう、しんどいです。3〜4サイクルやってみれたら良いかな、とか思ってたんですが、最初は無理じゃないかと。完全にインターバルトレーニングです、これ。

私は、今回デザイナー役は時間がなかったのですが、クライアントとタイムキーパーで得られた気づきがいくつかありました。

  • (短時間というのもあるが)ユーザのメリットというか選ぶ理由まで落とし込めないことが多い、提供側の理屈になってしまう
  • 利害関係なく、一歩引いて見るとどちらのメリットも冷静に感じることができる
  • 思考を喋りながらまとめていくのは、慣れてないと難しい
  • デザイン中にクライアントの人が隣にいるか、少し離れるかでコミュニケーションと満足度が変わりそう(距離感とコミュニケーションのシミュレーションができそう)
  • クライアント二人はデザイナーにとってハードモードだと思う

次回以降で改善したいところ

  • プレゼン後のコメントあたりが非常に面白いけど、残す余裕がなかったので残るようにしたい
  • 実際の体験も、そのあとのコメントも学びがあったので、最後に全員でYWTあたりやって記録すると良いのでは？
  • お題ジェネレータが欲しい

そんなに準備せずに取りかかれたし、2〜3週に一回くらいのペースでやれたら良いなあ、と思ってます。

「少女終末旅行」の最終回が、自分たち夫婦の理想的な終わり方なんだと思った件

この最終回は連載の方です。

www.kurage-bunch.com

こういう終わり方なんだろうな、と思ってましたし、この作品世界には都合の良い救いは不要だろうなとも思ってましたが、いい具合に静かな終わり方をしてくれました。特に印象に残ったのは以下のセリフが使われているシーン。

……何もわかんないけど…
生きるのは最高だったよね

もうね、あの見開きのコマが美しすぎて。最後の晩餐、いつものように眠る二人。この後にあることはわかりきっていますし、あまり想像の余地も残されていませんが、それでも余韻を残していくれるいい終わり方でした。

最近、二人だけで老後を迎えることについてよく考えます。この作品を読んで、最終回まで到達し、私たち夫婦も彼女たちと同じく、年を追うごとに様々なものがこぼれ落ちていって、いつかは二人以外の何もなくなるんだろうなあ、と感じたわけです。その時に、ただ日々と同じように最後に向き合えればいいなあ、と強く思います。せっかく二人で生きると決めたわけだし。