力を抜いた年始の誓い
あまり、これ！って言う目標を立てて生活する事をしたくないです。結局人生ってなにが起きるか分からないしね。だから日々淡々と過ごす事を大切にしてきたよーに思います。
ですが、こうなりたい！って言うのはあるかも。
『部長になりたい』は無いけど、
『こういうチームのリーダーにはなりたい』とか。
『年収を○○もらいたい！』は無いけど、
『せめてこれぐらいは年収欲しい』とか。
書いていて考えると好き嫌いがはっきりしてなくて、なんとなく生きてきた感じがします。『それなりに』は満足できてなかったし、それを変えようと思うと、思いが強くないと変わらないよなぁ。
新しい環境で、それなりに出来てきてる感じがするけど、何を実現したいかをもっと具体的にしないといけない。やりたいことの方針は立てれてるので、具体的に深く考えて、日々の行動に落としこめることを目指す。
年末年始に色々あって、書けてなかったけど年始に思ってた事を公開しよう。
何かを人に依頼するときは、本当に気をつけて依頼しないといけないな。大事な時間を使ってもらう事だし、相手のこれまでの大事な経験を使うことになるので。そういう考え方を持ってる人と一緒に仕事をしたい。部下だからとかで、自分優先で考える人間とは一緒に仕事して、結果を出せても喜べない。それに今回は、その人にそう感じてたいたのに、進めようとしてしまってた。最初にそう感じた時点でやめるべきだったし、そのおかげで大事な方の時間も気持ちも無駄にしてしもたしなぁ。
無駄に年齢だけ重ねてきたと感じてモヤッと感が多すぎる年始やわ。なんとか仲間を増やしていきたい。半年後には幸せな気分でいたいな。
この一年の終わりに
気がついたら新しい環境で２ヶ月経ってます。なんやかんやと激動の２ヶ月だったと感じております。何が激動って、新しい仕事を覚える事よりも、新しい人との出会いが激動です。学生の時はクラス替えがあったりで新しい人と出会うことがあるけれど、社会人でIT関係の場合に、転職以上の人間関係の変化って無いです。プロジェクトが変わってとかもあるかもしれないけど、上司やメンバーが総入れ替えって！しかもお客様も！
前職ではラッキーな事に色々な方達と過ごす機会に恵まれたので、本当に良かったです。凄くコミュニケーションが取りにくい方や、天然の人や、明らかに悪意があってさぼる人、逆に本当に優秀過ぎる若手とか。友達が多い方では無いけれど、色んな人に仕事で出会えて良かったなあ。
これまで色々な縁に恵まれてきたと感じています。
・家族
・学生時代の友達
・結婚
・就職
・とんでもなく著名な方（の会社の方達も！）
・優秀な同僚
・イラっとさせられる同僚
・先輩、後輩
・反感、批判をしてくれる人
思い出すと色々出てくるなぁ。
今回、転職して新しい出会いが一杯ありました。
今、感じている事は、
・誠意を持って接する事
・感情的にならずにこちらの要望を伝える事
・感謝する事
がむちゃくちゃ大事だと言うことです。
前職のメンバーと先月末に飲みに行ったときにつくづく感じました。家に帰ってから奥さんに、「そらぁー、腹割って話できるし、楽しかったやろー」って言われました。やっぱり優位な立場にあった分、相手に気を使われてる事を意識して接する必要があるなと感じました。また来年メンバー増やして飲みにいくのが楽しみ。
そして今年できた新しい縁も大事にして行きたい！
ハロウィンなんか関係ない
これまでハロウィンとか体験する事も無かったし、今年も何も体験する事がなかった。仮装にはまったく興味は湧かないなぁ～。USJで流行りだしてからでも、行くような感じじゃなかったしなぁー。もう2年ぐらいして、子供ももう少し大きくなったら、一緒に行ったりするのかなー。
急に寒くなってきたけど体調を壊さずに過ごす事が出来てる。新しい環境で、手探りなところがあるけど、年の功と言うか、経験年数のおかけで、なんとか過ごせてる感じがする。入社前後であまりイメージが変わらなかったのも良かった。良いところと悪いところのイメージが両方あったけど、大体イメージ通り。ただ、課題をどう改善していくかは、人間力と技術力が必要に感じている。
まだまだ足りてないと感じることが多かった人間力。『軽い感じで声をかける』、『相手が嫌がることを嫌み無く伝える』、『イラっとしてるところを見せずに、うまく伝える』って言うあたりがやっぱり出来ないと感じた。相手に勢い良く、思い込みで喋られると駄目なんやなー。なるべくそう言う相手とは会話を避けるべきやなー。そうじゃないと関係性が悪くなる。。。そう言う形にはしたくない。
技術力に関しては、要件聞いて、カスタマイズして、導入して、運用して、保守して、バージョンアップしての一通りのライフサイクルを回す事に関する技術が試されてるよなー。前段の開発・導入は力になれそうな気がしてるけど、運用・バージョンアップのところがイメージがわかへん。そのあたりのサイクルを回せるようにサービス設計に貢献できたらええな。ほんまにソフトウェアは面白い、組織のコミュニケーションも考えるし、使うソフトの目利き力も必要やし、突破していく力がものすごく大事やし、やりがいがあるなぁ。
先月は、一旦慣れるのに精一杯になってしまったし、少し立ち止まって考えよう。おかげさまで、そう言う事を考える事を許して貰えるポジションだし。
まずは、年内のイメージから。
チームに資料作成・共有の流れを作りたいのと、主要アラートを減らして、前向きになれるチームの雰囲気にしたいな。ほんまに減らせられたやん！的な。
来年の上期はチームのバランスを考える事かな～。そこは全社的な能力バランスとか、後は下期に導入を目指す技術をチームで習得とか。コミュニケーションが向上できたところで、継続的デリバリーに持っていけるなら行きたいなぁ～。
次に三年後。やっぱり前職で出来てなかった、ソフトウェアの技術を使ってお客さんに、本当にインパクトがある製品を継続して提供出来るチームにしていたいなー。ヒヤヒヤはするけど、ほぼ安定運用していて、そこから2年後ぐらいのロードマップもあって、そしてたまに発生する障害も頻度が凄く低いとか。そして余裕もあるから、継続して学習時間がとれてる事。そんな組織にしたいなー。
そして10年後は？
技術を楽しんで、基礎学力である数学的な知識や、情報系の知識を身につけて、それを伝える仕事をしていたいな。それが今の会社のお客さん相手でもいいやろうし、現職で新しく知り合った関係の人でも良いし。そう言う下地がある人が多そうで良かった。やっぱり学習する組織で、学習する仲間と関係を続けたい。
もやっとしてるけど、昔よりははっきりしてきたかも。日々少しでも達成感を持って過ごそう。
台風とともに
今年も印象に残る災害がいくつか起きた。特に台風の被害が大きく、また事前にJRが止まると言うイメージが出来上がった年でもあったと思う。何をするにしても余裕を持ってやる事は良い事だと思う。起きてからだと遅いのだ。
9月末で（一応）約18年間近く勤めた会社を退職した。退職するまでに社名が4つ変わった。新卒で入った時にはこんな事になるとは想像してなかったし、『どうしたい』って事も無かったように思う。それなりに一生懸命働いて来たけれど、どう言う事がしたいって事は無かったように思う。ただ、場面ごとにはやりたい事を選択できてきたので、あまり後悔は無い（こうすれば良かったなぁ〜と言う気持ちはあるが）。
今はScalaをやり始めて、更にそれとは別に小学校の算数から数学を再勉強してて、遂には大学レベルの数学に入門し始める事が出来ている。昔は個人的にアプリ作って、Webシステム作って（Google App Engine）とかやってみたけど、どれも中途半端だと感じていた。そんな中、昔やりかけで終わったアセンブリ言語を勉強し直した。この『再勉強』が転機だったのかもしれない。『なんとなく分かった』レベルをなんとかしたくて、実際に環境を作って、手で入力して、学んだ事を簡単にまとめてって言うのを繰り返すようになった気がする。アセンブリを個人的に再勉強する事が出来て、仕事では死ぬほどSQL（Oracleだけど）とExcelを見て、データも一杯見て、Javaを少しだけ見てた状態から、あるWebのブログでScalaに出会い、勉強をしようと言う意欲を持つ事ができた。きっかけとなったブログに本当に感謝したい。Scalaを始めて3年以上経ったけど、本当にまだまだ未熟だ。。。と言うよりもそもそもデータ構造とアルゴリズムにも詳しく無くて、その辺りも学んでいたのだけど、ようやくAtCoderのABCのABは簡単に解けるようになってきた。これからC問題に取り組んでいきたい。『しっかり身についた知識』が無いと解けない問題があるので、ここもしっかり体に染み込ませて行きたい。
今日から新しい職場に出勤した。直近の約9年間とは異なり、10年近く前の状態の職場の雰囲気を感じた。『”課題”が組織をどのような形で維持するか？』ではなく、今日出勤して聞いた状況では、『ソフトウェアで解決可能な課題を、自分たちはどう会社として取り組むか？』であった。世の中に受け入れられている企業なので、お互いに学び、日々充実した生活を継続できるような組織になるように貢献できればと思う。
10年後どうしたいかを聞かれたのは唐突だったけど、技術を突き詰めたいか、管理職かと聞かれて、少し返答に困ったけど、管理職と答えた。前職では技術と答えていたのだが、前職の管理職の意味合いは『経営者（営業サイド）』的な意味合いが強かったので苦手意識があったのかもしれない。良い事業内容があって、企業としてもスケールする段階で、それなりの経験を重ねて来た自分にとって、メンバー間の調整と言う役割が役に立ちそうに感じているので、真摯に取り組みたいと思う。残り30年の人生の3分の1ぐらいはかける事になるだろう。
60歳の方の定年退職エントリーがあったけど、心からカッコいいと思った。自分には到底及ばないキャリアだけれども、60歳になっても学ぶ姿勢だけは真似したい。その年齢になるまで、新しい会社でも技術的に尖ったメンバーと長く働く事が出来ればと思う。
これだけ前向きになれる機会を貰えて自分はラッキーだ。
夏休みの宿題の残り
今年のお盆もなんだかんだとゆっくり休めました。休み中には子供とプールに行ったり、ゲームしたり、ポケモンGOしたりと普段の生活を楽しんだ感じです。今年は先々月に旅行も行けたので満足できた夏を過ごせました。
旅行前に割と大きな決断をしたのですが、その事が頭から離れない状態がしばらく続きました。悩んでも結局は答えを出していたので、結論は変わらないのですが、やっぱり切り替えはムズカシイと感じたものです。来月はこの事を振り返って買い手みよう。
そんなこんなで悩んでた答えを求めてお盆前に書籍を買って、子供と遊ぶ合間に読んでました。
Effective DevOps ―4本柱による持続可能な組織文化の育て方
1. 読もうと考えた動機
今の会社にいて、今の案件に携わっていて、なんとか解決策が無いか模索しているような感じ。『保守』として案件に携わっていて、業務内容の曖昧さにいつも迷っていたように思う。完全にバッチ処理なので、『使いやすさ』、『見た目』とか『広く一般的に受け入れらる』とか『モダンな』とかの要素が全く無かった。ただ単に速さ・正確性が求められていたように思う。ただし、『数字』を扱うシステムなので、その数値をどんな軸で見せるかと言うのは大事だったと思う。『窓口・営業・企画』や『基盤・運用』は別”組織”がやっていた。自分達は”上流工程”から流れてくる仕事を、うまくこなして、流れに乗せていたような感覚である。そんな中、たまたま本書の紹介を見かけたので、まとまった時間が取れそうだったので読んだ。あとで書くけど、”組織”や”上流工程”に対する課題に関して、解決可能な範囲は決まっていると感じた。読んでみて、凄く納得できる部分もあったし、参考になる部分もあった。但し、但し書きがあるような感じ。
2. DevOpsって
海外で始まった文化的な運動。まとめてくれてる資料はこちらです！これを読んで読んで見よって背中を押されたかも。
私は誤解なく書籍を購入したのだけど、DevOpsって言う単語だけで捉えると、”開発チームと運用チームの協力で色々自動化する事”や”ツールで自動化”みたいなイメージが先行してしまうと思う。（どう効率化するかを考えていて、DevOpsに興味を持ったのが元々の動機ですし）
この書籍に書いてある内容は、人間関係の大事な部分や、組織をどう作っていくかのところに力点が置かれており、ケーススタディ的な書き方がされている。特にIT系で花形と思われている開発側からの視点ではなく、運用やサポートチームからの視点が多い。
最初に説かれているのは、コラボレーションである。同じ目標に向かって、チーム内で協力しあって仕事を進める姿勢である。固定思考と成長思考の違いや、どう言った仕事の進め方がチームに影響を与えられるかが記述されている。特に自分に響いたのは、『感謝の表明』である。いつだったか忘れたけど、妻の母が私の事に対して、『あまりありがとうって言わへんよね』って言ってた事を聞いた。とりあえず感謝の気持ちがあったので、それ以来普通に言葉に出して、感謝の気持ちを普段から伝えるようになった。周囲にちゃんと伝わってるかどうかは自信は無いが、心がけているつもりだ。
次にアフィニティ（好み、相性とかの事？コラボレーションとの違いがイマイチピント来てません）。どちらかと言うと個人より、チーム間の関係に関して述べられている。このあたりは、昔父親と仕事について会話していた時に、「営業が仕事取って来なかったら、仕事無くなるやろ」って言われた言葉が重い。めったに父親とは仕事の話とかしなかったけど、これだけは強烈に覚えている。それ以来、”営業”と言う言葉に対する偏見は無くなったように思う。お互い一生懸命仕事してるよね。ちゃんとこっちから伝えれば、わかってくれる部分もあるよね。両輪やよねって思いが強い。それの開発と運用チーム版みたいな感じの事が書かれている。
あと、ツールとスケーリングについても書かれているけど、良かったら書籍を読んでください。
3. 感想文
書かれている事はもっともだし、解決できる課題も多いだろう。でも今自分が直面している課題に対しては、以下の部分が一番しっくり来た感じがした。
~ 黄金の手錠 ~
『すべてのチームや組織がすべての人に合うとは限らない。devopsやあなたが大切に思うその他のことを誰もが大切にしてくれるわけでもない。自分に合った新しい場所を見つけることがベストだという場合もあるのだ。』
ある程度経験を積んで、ある程度仕事をこなせるようになって、更に求められるようになっているけど、仕事って何か課題を解決した事に対する対価だったりと考えている。これまでしてきた開発だったり、調査だったり、Excelでのデータ整形も出し、進捗管理も、『誰かができない事』を助けてきていたように思う。現状は、既に自分じゃ無い誰かが出来るようになりかけているのに、”会社”の維持のために自分が居るような状況になっていたし、ビジネスモデルがそんなモデルだったんだよね昔から。そう言う文化が好きになれなくて、我慢もできなくて、違う”組織”で喜んで出来る事があるなら、そっちを取るべきだ。もちろん責任も伴うだろうけど、その緊張感も愉しめるなら本当に良い選択だと思う。
あとやっぱり契約関係については曖昧にするんじゃなくて、そこはきっちり周知していく必要があるんやな。っと思ったし、世の中そう言う流れも出て来ていると思う。
そういえば高校数学の学び直しがもう少しで終わりそうだ。これが終わったら更に深みにはまりたい。
この暑苦しい中で
それなりの経験を経て、ドキュメントとかコードとかをレビューする場面が多くなった。レビューの目的はその成果物の品質向上が目的だと思う。『思う』と書いたのは、レビューの際に目的として『教育（むしろ指導？）』も含まれる場合が多々あるからだ。過度な指導は、品質向上にならずにむしろ隠蔽体質方向になると感じている。ここ最近過度な指導を見かける場面が多いので、少し考えてみたい。（コードレビュー特有の事は書いてませんし、意見がかける自信が無い）
1. レビューの基礎知識
システム開発の中でレビューと言うと以下の２つに分類できる。
- プロジェクトを推進するためのレビュー
- 品質に主眼を置いたレビュー
１は『プロジェクト』全体がどうだったかとかをポイントごとに確認しあったりする事だろう。そのポイントは規模によって変わってくるものになる（進捗会議的なもの含む）。
2に関してが、今回色々振り返りたいレビューについてだ。参加者や記録の取り方などで複数の方法がある。
こんなにあるんですね。。。これまで『なんとなく』会話していた事が”ピアデスクチェック”だったりしたんですね。
インスペクションが一番高コストで、アドホックが一番低コストとなっている。ここで言うコストとは、参加者の人数、事前準備が必要かどうか、実施中に記録をとる必要があるか、指摘事項を追跡する必要があるかどうかと言った、関係者がかける”時間”の事を言っている。
まずは同じチームで開発するにあたって、この辺りのレビュー手法についての基礎知識は合わせておく必要があるのだろうな。用語が与えられて初めて意味を理解するようなイメージである。
2. 実際のところは？
今回、いくつかレビューを紹介しているサイトを読んでいると割と『表現の良し悪しをレビュー時に指摘しない』と書かれているものがあった。まずはこの事について、私自身が感じている対処をかいておきたい。
・誤字、脱字
人によって、この指摘が多い場合が存在する。これが多い場合はレビュー時間が長くなり、指導の側面が強くなる。多いメンバーには自覚してもらい、全員を集める前に一度マメな人間にチェック、指摘、修正してもらう方が良いのだろう。
・体裁
これも多くなると指導の側面が強くなる。個別の成果物の構成とか表現とかには工夫の必要性が無いはずだ。ある程度共通化しておく必要性があるし、チーム共通の暗黙的な約束事はルール化しておく必要があるのだろう。ちょっとした図を書く際でも、左から右への構成をとるのか、上から下への構成をとるのか、強調する際の色合い、表形式の場合とか。こう言ったルールを守れない場合には、もう少し噛み砕いて説明し、練習させる場面が必要なのだろう。
・伝え方は？
つい自分も乱暴な言い方をしてしまう場合がある。それに自分が正しいと言う前提で言ってしまう場合がある。厳しい言い方をして通じる場合もあるように見えるが、結局は相手が萎縮してしまい、その後のコミュニケーションコストが上がってしまうと感じている。
・修正されているかの確認は？
これが１番の悩みどころだ。最低限の本質的なところだけを指摘していても、伝わっておらず、次回確認したら修正されていないって事が度々ある。その時のNGワードが『以前言ったよね？』、『２回目やで！』とかである。やはりもう一度、指摘の意図を丁寧に伝える必要がある。その場で、相手がしっかり理解できているかの確認が大事なのだろう（それもあるので軽微な指摘をしないようにするのが有効なのだろう）。どうしても度々起こるようであれば、まずは『記録する』文化を持っていない可能性がある。これが出来ない方は、ほぼ100%修正される事は無い。記録もできていないようであれば、逆に指摘事項をまとめて記載したものを渡して、ひとつづつ指摘を潰して行く経験を一緒に積むのが良いと思う。こう言った段階を踏んでいけば、良い意味でのあうんの呼吸がチームでも生まれてくるのだろう。
・場所、時間
自席でする場合も多いが、集中するためにもやはり打ち合わせスペースでした方が良いだろう。あと、始める時間も多少余裕を持って進める時間にしておくべきだし、集まってするのは長くても１時間以内にすべきだ。そこまで時間をかけるなら、事前に各自資料を読み込む時間をとる事や、軽微な指摘をまとめて後で共有すると言った事にした方が良い。また、重い指摘事項は記録に残して、後で個別に対応する事にした方が良い。時間が解決してくれる場合も多々ある。
3. 大事な事は
やっぱりメンバーの成長を促す事は過度な指導は良く無い。それならば決まり切ったレビュー作法（原則）を共有して、それを守ってもらうように合意していく事が大事なのだろうな。完全に要件を満たせていない、設計書、コードの部分的な事に疑問を呈すぐらいのレビューが一番理想なのだろう。その指摘事項は後から必ず担当者が解決する前提として。大きく方向性に誤りがある場合には、そのような場面になる前に仕事を依頼する側がこまめに大枠をチェックするべきなのであろう。また、どうしても大方針の誤りが続く場合には、前向きな教育を十分にすべきだろうな。
- その指摘は一方的な正義になっていないか？
- 教育的指導的な指摘事項が増える可能性はその成果物に無いか？
- その担当者に教育は行えているか？
厳しい指導で品質に対する姿勢が良くなる場面があるかもしれないが、その指導は一言だけで済ますべきなのだろう。長時間（30分以上！）、複数回（３回以上）にわたって受ける厳しい指導は相手が萎縮するだけで、何も効果は望めない。
---------------
以下に参考にさせて頂いたリンクを掲載させてもらいます。
若干古いですが、このドキュメントを参考に記載してみます。
[高信頼化 ソフトウェアのための 開発手法 高信頼化 ソフトウェアのための 開発手法ガイドブック]
https://www.ipa.go.jp/files/000005144.pdf
あとそう言えば、先月は残りの人生に大きく影響を及ぼす決断をしたり、子供が夏休みに入ったり、色々他にやって見たい事が出てきて、数学の目標は未達です。今月こそは！
初夏に将棋の定石
小さい頃は勝てなくて面白くなくなった将棋ですが、遂に将棋ウォーズで難しいもほぼ勝てるようになってきました。他人と対局はまだしていませんが。
小学生向けの入門書も軽く読んで見たのですが、全然頭に入ってこないです。やっぱり実践で覚えて行かないとダメですね。序盤、中盤、終盤の局面があって、最初の頃に駒組みで、攻めの形と守りの形を固めておかないと、簡単に負けてしまうし、ちょっとした誤った駒の配置をしてしまうと、飛車とか角とかがすぐ取られてしまいます。ちゃんと本を買って勉強する機会をとりたい。
数学に関して再勉強しているのですが、かなり遅々として進まず。ようやく微分入門が終わって、積分入門に着手という感じです。進捗は良くないのですが、少しでも進めていきたいと思います。このあたりは競技プログラミングの問題が解けるようになってきた時の感覚（達成感）と似たような感じが出てきているので続けられる気がします。
6月の梅雨の間は若干仕事が忙しく、夜も遅くなる時があったり、地震でバタバタする時もあったりしました。が、ようやくScalaの勉強会を開催することができました。社内向けに作ってた資料とかを思い出して、個人的に焼き直ししたような感じです。集まってくれた方には感謝の気持ちでいっぱいです。
仕事で勉強会をやる時にも感じるモヤモヤ感なのですが、やっぱり個人の知識のレベル感、好きの方向性の違いを吸収するのは難しいなぁ〜と言う感想です。もちろん、場所や時間の制約もあるのですが、継続していくとなると、同じような気持ちのメンバーが集まらないと続けるのは難しい。けど、１番重要なのは自分の気持ちだと思います。これからもScalaを地道に続けて、なんとかコードを書き続けたいな。それが実現しやすいのがOSSの仕組みだしね。
勉強会に関しては、数打ちゃ当たる作戦で一歩前に進めたけど、また元の場所に戻ったとしても、また色々考えて進めて行きたいな。
そのためにも今月はしっかり数学を目標たててすすめよう。積分入門終えて、数学3もほぼ終わりかけが目標。
