島までは遠い 〜サークルアラウンド株式会社代表佐藤のブログ〜

佐藤正志@サークルアラウンド株式会社のことが少しわかる場所。プログラマーを育てるトレーナーとして、現役のソフトウェア技術者として、経営者の端くれとして、想うことをつづる。

プログラマーの現場経験1年くらいの人に就活〜現場の仕事まで聞いてみませんか?

「プログラミングを仕事にしたい!」と思っている方や既に行動始めた方に向けて、弊社メンバーが企画したイベントが来年開催されます!あまり色々聞けないこともクローズドなイベントでツッコンで聞いてみると、あなたの欲しい情報が手に入る筈ですよ。

techdrive.connpass.com

就活前や就活中、以下のような不安ってあったりしませんか?

  • 仮に実際に就職できたとして、どんな働き方になっていくのかのイメージがわからない
  • 就職したいならどういうアプローチがあるのか
  • 就職を目指した時にやったほうが良い事があるなら知りたい

こういうことを色々な切り口から会話できるような場所を用意しました。大きく2パートにしています。どちらも時間の余裕を多めにとって、疑問を余す事なく聞きだせるような場づくりです。

  1. 登壇した方ご本人の目線からの自由なプレゼンを聞いた上での質疑応答
  2. 緩めの懇親会で抱えている疑問をジックリ聞く

登壇者については弊社の個別トレーニング受けた人になってしまっているので以下のような雰囲気です。多少のバイアスがある事はご理解くださいませ。

  • システム開発の受託、スタートアップ/自社サービスはバランス良い
  • 言語はRuby中心。お一人がiOSでSwift。

世間では様々なことがTwitterに流れてきたりするので「確からしいことがよくわからない」という方は多いと思います。生に近い最新の情報に触れることできっとあなたのお役に立てるはずです。

techdrive.connpass.com

「俺はお前のママじゃ無い」をカッコよく言おうと思ったら「自己管理型」という言葉が近いらしい

f:id:ms2sato:20190722174503j:plain

はじめに

自分なりにやっていることや考えていることについてうまい名詞があると他人に伝えやすくなると思います。 最近社内で伝えていたことに近い言葉が無いか探してみたら、少し前に目にした「自己管理型」という言葉が近そうだったのでメモしておきます。 ただ、実際にはチーム全体の自主性を考えた言葉の様子なので、私の思うそれとは若干違うのかもしれません。

私の考え方

  • 自分のタスクの管理は自分でできること
  • 気づいたことや問題と思うことを個々のタスクの中で感じたら、早めにまとめ役に相談して良いこと(勝手に忖度して引っ込めずに積極的に相談して良い)
  • 情報の流れはトップダウンよりもボトムアップの方が活発

なんとなく過去私が知っていた組織のパターンだとあまり上記の感じになっておらず、まとめ役がいちいち確認しているような気がします(ポーリングっぽい感じ)。そのタイミングを定例的にするか都度にするかはわかりませんが、全体像はまとめ役だけが理解しており、その人の手足を延長するような形でそれぞれのメンバーが存在しているイメージです。

求めるのはもう少し勝手に動いてくれるもので、手足が伸びたと言うよりも、良きに計らってくれて信頼が高いイメージでしょうか。放っておいても自分で管理してくれる雰囲気です。

その為の条件の一つは「自己のタスク管理を個人で行える」ということです。以前タスクの抜け漏れが多いメンバーによく言ってたのは「俺はお前のママじゃ無い」的な話でした。タスクの抜け漏れ自体はツールを上手に使うだけでかなり改善できるもので、「基本的にタスクが抜けるもの」という観点のチームと「基本的にタスクが抜けないもの」という観点で進められるチームでは信頼感がまるで違うと思っています*1

ところで「俺はお前のママじゃ無い」は、表現としてはわかりやすいものの、あまりカッコよく無いですね。

世間の内容を少し調べてみた

www.infoq.com

自己組織化について論じている文章ですがここで言う 自己管理型チーム という言葉は私の理想と近そうです。「誰に責務を与えるか」は私が決めていますが、最終的に「どのように進めるか」はアサインされた人によって決められていくイメージですね。もっと上の権限を与えていくのも良いのかもしれませんが、メンバーの報酬や獲得して欲しい経験は私が握っていることが多いので、「自己管理していて欲しい」ということに集約されるのでしょう。

結果として期待していること。実際に起こること

以下のような感じですかね。

  • 「順調」という報告よりも「問題の相談」や「不安点の確認」のような 現在や未来のスムーズな進捗を確保する ための行動が増える。
  • 問題があれば勝手に相談くれるため、基本的にはこちらから義務感を持って話しかけなくともよくなる*2
  • まとめ役側のコストの低下

気をつけている事

物事よくわかっている人ほど「まとめ役の時間が貴重だからあまり話しかけてはいけない」と思ってくださるので積極的に話してくれなかったりしますが、個人的にはどんどん聞いて良いと思っています。問題や不安は前提知識が適切に伝わっていない場合にもよく起こりますし、必要な情報が揃っていないサインとも思います。この辺りを「まぁ、いっか」と放置したり「時間を奪う」と忖度した結果、あとでより大きな課題になって返ってくる事が多いのでは無いでしょうか。とりあえず相談しやすい空気をこちらが作り続けるのは結構大事ですよね。ちなみに自分の場合

  • 相談されたら出来るだけすぐ聞く。できない時は「xx分後」などと発信してこちらからアクションする。
  • 伝わっていなかった何かがあっても極端に不機嫌にならない。伝えたことを取りこぼしている様子ならこぼさない工夫を一緒に模索する。
  • 基本的にポジティブに聞く。問題や不安を増大させずに解消する方向へ舵を切る。

おしまいに

あんまりまとまってませんが「そんな感じに日々考えていますよ」ってことで。

*1:最終的に自身に合うツールや管理方法を確立してくれたので、件のメンバーのタスク抜けはとても減り、信頼できるようになりました

*2:私は無駄に話しかける時もそこそこあるんでついでに教えてもらえたりしますが

「フリーランスになればリモートワークができる」チョット待って!

f:id:ms2sato:20190516174404j:plain

はじめに

Twitter見てたら流れてきた話に反応します。 「『フリーランスになればリモートワークができる』という言葉、解釈が複数あるので気をつけてください」という話です。伝え方によってミスリードを起こすことができます。

私はプログラマについてしかよくわからないのでその観点で読んでください。あと、法律の専門家ではないので何か間違ってたらそっと教えてくれると、とっても嬉しいです。

前提の契約形態の知識(知ってる人は飛ばしてください)

前提となったTwitterの話題では契約の話も触れられてたのでちょっとおさらい。 フリーランスは「業務委託契約を結ぶ個人事業主」とさせてください(他にあるかは知りませんがこの辺りが崩れると事情が変わるかもしれません)。

契約でよくある形式は以下2つかと。まとめて業務委託契約と言ったりします。中身としては以下二つのどちらかを指しているはずです。私は専門家ではないですが、これくらいがポイントだと思えばいいかと。また、契約の形態に特徴はあっても優劣は有りません。そして契約なのでもしも不利だと思うのであればフリーランスなら自分で交渉しましょう。

請負契約

  • 「〇〇な仕様のものをいつまでに納品」というような「いつまでに、何を」を約束します。
  • 多くは全部完成して納品し、検収(お客様の確認)が終わったら請求書を書いてお金をいただきます。
  • 通常瑕疵担保責任が発生します。例えば「一年以内に不具合(仕様と合致しない事を不具合とする)が発生した場合には無償で修正する」など。

準委任契約

  • 「現場の指示に従って技術力を提供します」というような、時間貸しのような約束です。具体的な作業の内容は現場に任せられます。
  • 月や日、時間など稼働の単位を決めて、例えば月末などに「今月は◯時間働いたからおいくら万円」のような請求書を書いてお金をいただきます。
  • 通常瑕疵担保責任が発生しません。あくまで技術力を指示通りに提供した事で契約は満たしています。

※注意

契約書の分類は通例このような形であると言えるけれども、その内容は書かれている文章によって変わります。上記は分類としてはそういう形であると理解したほうがいいです*1

契約の形式と、労働の環境は別物です

「どの契約をすれば、リモートワークができますか?」と聞かれたら、どれでもできますし、どれでもできない可能性がありえます。書類の内容にどこで作業するかが明記されていればその場所に必ず縛られますし、書かれていなければお互いの相談によって決めることになるでしょう。

つまり「フリーランスになれば(必ず)リモートワークができる」というようなことではなく「フリーランスになれば(契約の内容次第で)リモートワークができる」ということです。どういう文脈で相手が言葉を発しているかにもよりますが、括弧に表現した部分について都合の良い解釈をしないように注意が必要です。

「そもそも、フリーランスにならなければリモートワークできないの?」

端的に言えば会社次第です。皆さんもよくご存知かとは思いますが、最近では「働き方改革」の風潮もあり会社が副業やリモートワークを実現することも増えていると思います。「フリーランスにならなければリモートワークはできない」と決めつけるのは早計です。

「リモートワークできる契約をしたいんだけど」

契約書を取り交わしたり、更新する際にご相談されるのが順当かと思います。ただ、私の観点だと以下のようなポイントはあります。

  • 「リモートでも成果量が下がらないだろう」というある程度の確からしさがあること。もしくは下がっても受け入れられる現場であること。
  • リモートではテキストコミュニケーション中心になりがちですが、この辺りが苦手ではないと推察できること。
  • 対面で確認ができない状況でも、ゴールを間違えないようなコミュニケーションを取る力量があると推察できること。

「請負で契約すれば」と思うかもしれませんが、世間でよく言われることに「フリーランスはすぐ逃げる」という事があります。都合が悪くなるといなくなってしまうフリーランスはよくいる様子です(私の知り合いにはそういう方はいないのでよくわかりませんが、経営者の方と話をするとそこそこあるようです)。請負で期限ギリギリに連絡が取れなくなってしまうようなことになれば事業としては痛手なので、ただ請負にすれば良いというものでもありませんよね。

結果的にリモートワークできるような立場を手に入れるには「仕事をある程度うまく進めるだけの仕事調整力やプログラミング力などの力量があること」というのはかなり確からしいことだと思います。

「業務未経験です。リモートワークしたいです。」

先述のようなポイントを抑えていると証明できる何かがあればできるかもしれませんが、ほとんどの方にはそれができないような気がします。よほどの幸運がなければ難しいのではないでしょうか。最初に一定の期間対面の時間を作りながら信頼を作ってリモートをいれていく人はいそうです。

私のプロジェクトでよく発生するリモートワークは GitHub-Flowを使い、Issue単位で仕事をこなしてもらう形& 時給時間単価での準委任契約です。プログラマとしてチームに参加するならこの辺りができると良いかもしれません*2

おしまいに

日本語難しいので、複数の解釈の余地があるようなことは丁寧に確認すべきかと。また、誰か一人が言っていることだけを盲信するのではなく、世間一般ではどうなのか、などの情報を自分から集めにゆくのは大切なことかと思います。特にフリーランスになるような方なら自分で自分を守らなければ。誰かが守ってくれるというような立場では無いですよね。

*1:例えば契約書を取り交わした後にE-mailなどで別の内容を取り交わして内容を上書きすることもできます。詳しいことは調べてみてください

*2:弊社のトレーニングはこの形式を基礎に作っているので、十分訓練した人は私たちのチームでうまく組めるだろうと考えています。いつも自社の宣伝をねじ込んでいくのは仕様です

「モデルの中からPOROを呼び出すのはどの程度認められるのか」気になります

はじめに

tech.medpeer.co.jp

この記事読んで思ったことを誰にともなくコミュニケーションしてみたくなったので書いてみます。当該の記事はリファクタリングの考え方としてとても好きです。その一方で過去私がとても苦しんだ事と同じ課題(もはやトラウマみたいな)を感じたのでアウトプットしてみたくなりました。

私の感覚

長くなるので後の方に色々細々した気持ちを書きますが、今の私はモデルのリファクタリングについて下記の記事をかなり重要視しています。その観点で当該のサンプルをリファクタリングするとどうなるかを書いてみると良いと思いました。

techracho.bpsinc.jp

上記記事に従うと、今回の場合「処理が複雑になった(という前提ですよね?)」と考えてServiceを採用するか、「あるユースケースにおける保存処理に介入する」と考えてDecoratorを採用するのが妥当な気がします。というわけで二つ書きました。そして私ならこれらの二つのどちらかがシックリくると考えて、元記事でのリファクタリング結果には意見を提示すると思います*1

Serviceを採用した場合

class Message < ApplicationRecord
  has_many :mentions
  belongs_to :creator, class_name: 'User'
  belongs_to :channel

  def here?; end # 省略
  def channel?; end #省略
end

class MentionNotifier
  def self.call(message)
    self.new(message).call
  end

  def initialize(message)
    @message = message
  end

  def call
    ActiveRecord::Base.transaction do
      return false unless @message.valid?
      @message.save!
      create_here_menthin if @message.here?
      create_channel_mention if @message.channel?
    end
    @message
  end

  private

  def create_here_mention
    members = @message.channel.members.active - [@message.creator] # これはMessageのメソッド化しそうですが、本題とはずれるのでこのまま
    create_mentions(members)
  end

  def create_channel_mention
    members = @message.channel.members - [@message.creator] 
    create_mentions(members)
  end

  def create_mentions(members)
    members.each do |member|
      @message.mentions.create!(to: member, chennel: @message.channel)
    end
  end
end

# 使い方(create アクションの中の想定)
message = Message.new(params)
MentionNotifier.call(message)

Decoratorとしての切り出し

class Message < ApplicationRecord
  has_many :mentions
  belongs_to :creator, class_name: 'User'
  belongs_to :channel

  def here?; end # 省略
  def channel?; end #省略
end

class MentionNotifier
  attr_accessor :message

  def initialize(message)
    @message = message
  end

  def save
    ActiveRecord::Base.transaction do
      return false unless @message.valid?
      @message.save!
      create_here_menthin if @message.here?
      create_channel_mention if @message.channel?
    end
    @message
  end

  private

  def create_here_mention
    members = @message.channel.members.active - [@message.creator] # これはMessageのメソッド化しそうですが、本題とはずれるのでこのまま
    create_mentions(members)
  end

  def create_channel_mention
    members = @message.channel.members - [@message.creator] 
    create_mentions(members)
  end

  def create_mentions(members)
    members.each do |member|
      @message.mentions.create!(to: member, chennel: @message.channel)
    end
  end
end

# 使い方(create アクションの中の想定)
message = MentionNotifier.new(Message.new(params))
message.save

モデルの中からPOROを呼び出すのはどの程度認められるのか

「今回選ばれた例が通知をする処理だから上記のような形の方がシックリくるのではないか」

と思われてしまうと本題と外れてしまうので章立てしました。私がRailsでコードを書き始めて当初悩んだことの一つがこの「モデルの中からPOROをバンバン呼び出すのはアリなのか」ということなんです。

私にとってJavaの業務系でのコードのスタイルがキャリアの初期にあった為か、POJO を中心とする書き方が身についており、肥大化するモデルの処理や、通知などの内容は元記事のコードのようにモデルの中からPOROを呼びたくなっていたんです。ただ、ロジック層に入ってPOROから(ActiveRecordに強く縛られた)モデルを呼び、さらその中で業務に関連したPOROを...と呼ばれるのが不自然に感じられていたんですね。

そういう中で出会ったのが先に紹介した肥大化したActiveRecordモデルをリファクタリングする7つの方法(翻訳)の記事です。この記事は悩んでいた私に一つの考え方を指し示してくれました。「基本的にModelを渡す形で良い」という事です。この記事に出会ってからは私が抱えていた悩みはスッと晴れました。手本とするのに適切であると思っています*2

ただ物事には例外がつき物なので「〇〇なケースでは認めて良いのでは?」というのもありそうです。私だとSTIしている複数のクラスからそれぞれの型に関連したPOROを生成させるメソッドを作りたいと思うことはよくあります。これは認めても良いかもと感じています。

そんな私が今回の記事を読んだ時に「あれ?私の過去の悩みって結構無駄だった?」なんて変な汗が出てしまったのでした(笑) というわけで、この話題について多くの方々がどのように考えていらっしゃるのか大変興味があります。もしも何か良い指針があれば私もそれを知りたいのです。

おしまいに

特にRailsでは慣習や大勢のパターンに合わせた書き方を強く推奨することで、多くのプログラマーがプロジェクトを移動しても活躍しやすいという土壌があると思っています。少し前にも「Serviceクラスをどのように書くべきなのか」などの話題があったりしましたね。こうやって「xxxなケースはyyyな解法が概ね良い*3」という事が積み重なってより良い開発をお互いにできる気がしています。ということもあり「私はこうかなー」というのを書いてみました。

また、スルーしてしまいましたが元記事の主題であるサービスクラスの書き方については、下記に倣っている様子なので「ですよね〜」と思って拝見していました*4techracho.bpsinc.jp

*1:開発の仕事の中でレビューする際に、私個人の哲学を押し付けて良い場合は限られていると考えています。だからこういうシーンでは大抵自分の意見を提示してみてコミュニケーションを取ります

*2:自分ところのトレーニングでもこの内容はよく紹介しています

*3:最高で無くても良く、一般的に皆がある程度納得できるものであれば良いというイメージです

*4:私だとメソッド名固定に強いこだわりは無かったりしますが

「Pythonによるはじめての機械学習プログラミング(ジェンガ本)」は機械学習の素晴らしい実践的なとっかかりを提供しています

はじめに

著者の一人、島田さんから献本いただきました。ありがとうございます。 知り合った頃は学生だった島田さんが、CTOとして大活躍して、今度は本まで出されるということでオッサン目頭が熱くなります。

GWの最初にとにかく読み終えておきたかったので初日の課題にしました。いつもならコードを試しながらなのですが、この本に限っては私が機械学習についてあまり知識がない為「手を動かす前にまず全体を読み切ってしまおう」という流れで、先刻読み終えたところです。厚さの割にスイスイ読めました。

勧めたい読者像

私の理解ではこの本は「機械学習に無知なシステム開発者に対する、素晴らしい実践的なとっかかり」を作るための一冊だと思っています。もう少し分解して対象者を書くと以下のような感じでしょうか。

  • Pythonを扱ったことがある、もしくは書かれたPythonのコードを処理を類推しながら読み進められる人。
  • 機械学習全般には詳しくないけれども、とっかかりになる道具の扱い方や解説を求めている人。
  • 機械学習ライブラリを扱った際に、どのようにWEBなどのシステムに組み込むのかのとっかかりが気になる人。

また、機械学習というと画像や文章など様々なところで応用がなされるものだと思いますが、本書で主に解説されているのは以下でした。

  • 教師ありデータを元にしたデータ予測(scikit-learn)
  • 自然言語解析を利用した類語検索や文書分類(Word2vec, Gensim, PyTorch)

このあたりに興味のある人は特に満足度が高いでしょう。画像や動画を処理したいような方は別の入り口から入る方が良いかもしれません。

全体的な章立て

大きく分けて4部で構成されています。

  • 第1章 Pythonによる機械学習プログラミングの準備
    • WindowsやLinuxなど各環境ごとのインストールから、Visual Studio Codeのデバッグ実行までスクリーンショットなど交えて丁寧に解説されていました。まだ試してはいませんが、これに沿ってやればそれほど苦しまずに環境を手に入れることができそうです。
  • 第2章 Pandasによる前処理とデータの分析
    • 機械学習を実際に始める前に行うべきデータの整理や基本的な操作について書かれています。こちらもかなりページを割いて丁寧に手法が示されていると感じました。
  • 第3章 scikit-learnではじめる機械学習
    • 機械学習についての導入から実践的な内容が記されています。詳しくは後述。
  • 第4章 GensimとPyTorchを使った自然言語処理
    • Word2vec を用いた単語のベクトルを使ってベクトルの引き算から単語を推察したり、文書を分類したりします。

読み進めて感じたこと

この本は最初から読み始めると第2章が長い割になかなか想像している内容が出てこない為、やきもきしてしまうかもしれません。 「何かデータを処理するいわゆる『機械学習っぽさ』を体験したい」という人は第3章から入ってみても大丈夫かもしれません*1。この章を読んでモチベーションを高めてから第2章でも良い気がします。ただし本書は「第2章も含めて初めて完成する」と思うので以下に記します。

3章の内容はとても良いバランスを突いています。

  • 機械学習についての概論的な導入、現場における課題感など
  • データとコードを使った具体的な処理
  • 実際にWEBのシステムに組み込むための考え方

まで通して説明されているのは、冒頭に私が書いた「とっかかり」を与えたいという本書の目的感によるものではないでしょうか。

また、折に触れてS3にデータを置いておく話が出るとか、サンプルがWEB-APIを作成するものであったり、解説にマイクロサービスという言葉が出ていることからも「実際のシステム開発の現場」について著者が強く意識していると感じます。

そしてこの第3章を読了すると、丁寧で多少冗長にも感じた第2章がいかに大切なものだったかが見えてきました。第3章に倣って実際に大量のデータを扱おうと考えると、第2章の話題を避けて通ることができないはずです*2。第3章や第4章を完成するための大きなパーツとして第2章が存在していると理解しています*3

第4章は大量のテキストが行き交う現代のシステムにどうしてもやりたくなる自然言語の処理について書かれており、興味深く読ませていただきました。単語ベクトルという考え方を導入することで言葉の相関を整理することができ、それによって言葉の類推的なことができたり文書を分類することができるというものなので、実際の自分のサービスでもやってみると有意義な結果が得られそうに思います。

本を読んでフムフムするより実際に稼働しているシステムの情報を使って手を動かした時、4章の評価が適切にできるような気がしました。

おしまいに

とりあえずこれまで「機械学習難しそうだしよくわからない言葉いっぱい出てきそうだからなぁ」と敬遠していたシステム開発者だったらこの"ジェンガ本"は一度目を通してみて損がない一冊だと思います。弊社トレーニングで機械学習コース作るときは教材にしたいです。

Pythonによるはじめての機械学習プログラミング[現場で必要な基礎知識がわかる]

Pythonによるはじめての機械学習プログラミング[現場で必要な基礎知識がわかる]

  • 作者: 島田達朗,越水直人,早川敦士,山田育矢
  • 出版社/メーカー: 技術評論社
  • 発売日: 2019/04/19
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る

*1:このことは本書の「はじめに」にも書かれているそうですが私読んだはずなのにスコーンと抜けてました ^^;

*2:私だととりあえずGoogleDocsに貼って色々コネコネしてしまいそうですが、そんなことしなくていいんですね...

*3:私はまだ機械学習を利用したシステムを組んだことはありませんが、第2章のように「雑多なデータを扱いやすい形に編集したり、可視化して傾向を掴むなどすることは実際にシステムに組み込むよりも時間のかかる大切なプロセスだ」とのメッセージではないかと感じています

現場未経験のプログラマーが最初の現場で心がけると良さそうなこと

f:id:ms2sato:20190426001814j:plain

はじめに

弊社のチームトレーニングの中で伝えるようなことと、現場でチームを率いるリードプログラマーとして、経営者としてのいくつかの切り口を混ぜて「こうあってくれたら嬉しい」「こういうことを期待している」というのをまとめてみます。

適切なタイミングで質問できているか意識してほしい

  • 抱え込んで質問できない人
  • 考えないで質問してしまう人

どちらの極端も困るのです。ようするにバランスなんです。このあたりのバランスを崩している人は以下のようなことを日々言われているのでは無いでしょうか。

  • 「どうして相談しなかったの?」「早く聞いてよー」「今まで何をやっていたの?」
  • 「調べた?」「試した?」「読んだ?」

例えば私がよくやるのは「15分悩んで手が動かせない時には何か欠けている情報や経験があるから、誰かに相談したほうがいい」というようなことを伝えます。この15分は最短の時間で、この時間を相手の成長に合わせて伸ばしていきます。この手の「質問タイミング」について一緒にやっている先輩と相談するのは良い試みだと思います。

「実は適切に質問するのは結構難しい」と思ってくれたら一歩前進かもしれません。

「タスクの完遂」の前に「成長の機会」と捉えてほしい

「なんでもいいから言われたタスクをこなさないとクビになるかもしれない」 と思ってしまう瞬間があるかもしれませんが、行なっている業務がプログラミングであるなら(ロジックを書かない他の業務だと違うかもなので一概にそうだとは言い切りませんが)よほど酷くない限りそんなことはありません。もしもそういう強迫観念にかられて

「振られたタスクの内容と似たようなことをしているコードがないか、ソースを探してコピペする」

という行動をしていたら黄色信号です。もちろん参考にするのはありなのですが、理解しないでコピペするだけの行為ではいつまでも成長がありません。こういう行動を続けてしまうと、一年経っても同じことしかできない可能性があります。それはとても困りますよね。

タスクを完遂する中であなたの成長があることを期待されています。それはコードの書き方だけではなくて、質問の仕方や調べ方など、全方位的に可能性が広がっています。タスクをこなすごとにあなたのやれることが適切になっていっていれば、それはおそらく現場から望まれていることです。

ちなみにこういう「今望まれていることは何か」を発信してくれる現場とそうでない現場があると思います。こういう点についてコミュニケーションしてみるのは良いことかもしれません。

できれば長く付き合ってほしい

これは特に中小企業の経営者からは切実に望まれていることだと思います。その背景を以下に書いてみます。弊社は今の所この心配があまり無い状態ではありますが、気持ちとしてはこんな感じです。

あなたは最初からプラスの存在ではありません

多分大抵の人は気づいていると思いますが、最初からいきなり利益が出せるような働きができることなどまず無いです。もしも軽快にタスクがこなせているとすると、それは誰かのフォローや適切な対応の結果によるものでしょう。以下はその一例です。

  • タスクが「誰かによって」適切に分解されている
  • 適当なレベルのタスクが「誰かによって」選択されて担当させてもらえている
  • 補助的な知識の補足が「誰かによって」うまいことなされている

「誰かによって」と出てきていますが、端的に言うと「これを誰かがやってくれている時点でそこそこコストがかかっている」ということになります。だから自分がスイスイこなせている場合でもトータルでプラスになっているかは疑わしいのです。

マイナスなのにどうして置いてくれるの?

ちゃんとした経営者ならそこそこ長い目線で物事を考えています。例えばあなたが一年以上かけて成長した先に、これまでのマイナスを取り返してプラスになってくれることを期待しています。多くの経営者にとってこれは 投資 なんです。投資をして数年後に取り返す、ということを想定しています。

回収できないなら次は行えない

あまりに簡単に短期間で離脱されてしまうと、それまでかけたコストが回収できないので同様の施策を行うことに臆病になります。結果として「現場未経験の人を雇うのはやめよう」という判断になる可能性もあります。この事実をどのように受け止めるかは個人の自由だと思いますが、少なくともそういうことを知っていて欲しいと思っています。

もちろん本当にひどい現場もあるので、そういう場所は早く離れて正解だとは思います。

おしまいに

最初の仕事の現場は大切にして欲しいと思っていますし、雇用のミスマッチがなるべく発生しないことを切に願っています。成長して卒業して行くのは当然起こりうることだと思いますが、得るべき体験が得られる方が皆にとってハッピーかなと思います。

「状況に合わせて適切に情報が流れるのが良い組織ではないか」という仮説

f:id:ms2sato:20190411141726j:plain

はじめに

長すぎたのでブログ化

組織化について

基本的に組織化されている状態について多くの人が思い浮かべるだろう表現を書いてみると「トップからの情報がツリー状に伝達されることで効果的に末端まで行き渡るさま」だと思う。これはいわゆるトップダウンという山型の組織である理由だろうとも感じる。

表現を変えると「トップの意思の素早い全体反映に特化した情報伝達の形態」とも言えるかもしれない。

ただ、これについて多少のイメージの違いがあり「末端で起きていることの中枢への伝達」についても考えるべきではないか、というのが私の仮説である。

人体を参考に表現する

基本的に私たちは大脳で考え、行動している。頭で考えたことが手足に伝わり、体を動かしている。これは通常時の体にとってはごくごく当たり前の事だろう。

逆に通常ではない状況を考えてみる。たとえば熱したヤカンに触れてしまった時、たとえば尖がった針が指に刺さった時、危機的な状況があると体は大脳に情報が完全に届く前に反射を始める。それと意識する前に指を引っ込めるはずだ。

前者はトップダウンで大脳から情報が伝わっているが、後者は大脳での意識の前に小脳などで判断し行動している。危機的状況への対応とはこのようにショートカットして起こるべきなのかもしれない。

組織に戻してみる

これを実際の組織に置き換えると、順序を通り越して一気に判断まで持っていくことが必要ではなかろうか。その際「通常伝わってくる山型の経路をショートカットして直接判断できる存在まで伝達する」べきかもしれない。

私自身の場合だと、経営や営業からコードを書くところまである程度把握しているので*1、コードを書く現場で起きていることも自分の判断が行える。針が刺さったところを見せて貰えれば「どうしておけば良いか」ある程度責任を持って判断できると思う。

このような感じに2-3ステップすっ飛ばして「責任を持って瞬間的に判断できる」存在まで情報を伝えてしまうのは大事な気がする。特に何か問題が起きた時に「そのレイヤーではどうしようもないかも知れないが、他の人なら十分調整できる」という事は多数ある為だ。わかりやすい例を挙げれば「開発が遅れているけれども、営業が顧客と相談すれば期日を伸ばせるので、開発が残業地獄にならなくても済む」というような事がよくあるという事。

弊社について振り返る

今のところ自分は大脳と小脳を兼ねているので、基本的に会社の隅々まで意識を行き渡らせようとしている。以下のような事はそういう自分の感覚の発露でもありそうだと振り返って感じた。小脳としては指先が傷ついたりしていないかを常に確認したいのだ。

  • 必要そうな時に気軽に声かけしてもらうように*2して、なるべく早くその人と直接会話する。
  • 自分が帰るのは他のメンバーより早い事が多いが、出ていく際にデスクを回って声かけをしている。
  • なるべくメンバー全員が昼食を一緒にとるようにしていて、雰囲気が感じられるようにする。
  • オフィスで過ごしている際に自然に雑談している(これは意識していないので単純にキャラクターの問題だけれど、プラスに働いていると思う)。

どこかで小脳的な存在にバトンタッチする必要は感じていて、どのようにシフトしていくのかは課題でもある。

(おまけ)今後のことを考えてみる

人数が増えて、並行して進むプロジェクトが増え、書かれるコードが増えると、私の能力が会社のボトルネックになってしまうと感じ始めた。

実際最近コードレビューをメンバー相互にやって良い形に移譲したりしている。これはこれで正直不安な事もあって「どんなコードが書かれているかを自分が保証しているから自信が持てている」状態を捨てなければならないから。

多分「プロジェクトに責任を持つ存在がコードについても保証できる人である」というのは至極理想的な状態で、それを崩すのは本当は良い形では無いのだろう。弊社の扱うプロジェクトは規模が比較的小さいのだから、理想的な形を追っても行けるのでは無いかと思っている。まだまだ工夫の余地があるのだ。

今後今までよりももう少し人数規模が大きくなる想定で進んでいるので、私の今の仕事をうまく別の人に移譲するのは大事な事だけれど、スムーズなやり方を模索しないといけない。

こういうポジティブな悩みが発生しているのは良い傾向でもあるので、向き合ってうまく着地させたい。

*1:最近怪しくなってきてて課題の一つではあるが

*2:これ自体も色々と工夫が必要そうだけれど