投稿

ソニックガーデンの経営ポリシーのひとつは、一か八かをしないということ。身の丈にあわない賭けはしないので、身の丈にあった成長しかしないけれど、嫌な仕事でもやって急激に成長することよりも、今の楽しい仕事を長く続けることを大事にしているので、それで良いと考えてる。サステナビリティ重視。

生き残るために新規事業を、という話はよく聞くが、もし新規事業がうまくいったとして、既存事業で積んだ経験は活かせないために、社員は入れ替わることになるのではないか。結果として会社という器は生き残るかもしれないが、そこで働く人は生き残れない。だから誰もが自分の頭で考えていくしかない。

問題から疑ってかかるような教育を受けてないと、ビジネスでも与件の中でどう解決するかだけを追求しがちで、日本のサービスはそういう融通のきかないところが多くある気がする。もしビジョンをもっているのなら、前提を疑い、思考停止せずにルールから変えていくことを考えることこそが大事だと思う。

最近は社内で私の考えを共有する手段として、メディアでの対談や取材のときの録音データを配信することを試してる。オフィスが小さく在宅メンバもいなかった頃は、取材を受ければ、近くにいる皆に伝わったものだけど、今はそうはいかない。音声データなら、好きなタイミングで聴ける。社内ラジオだね。

継続は力なり、とはよく言ったもので、なんでも続けることで成果は出てくる。少しずつでもやっていれば、後々になると、大きな差になる。少しもやってなければゼロのままだ。だけど、なんだって続けることは、そう簡単ではない。新規事業や企画なども同じではないか。

業界がシュリンクしてる時に、出来ることは何か。世の中を変えることは出来ない。違う業界に移るしかない。企業なら、別の業種としての新規事業を起こすことだ。ただし、もし新規事業がうまくいった時に、それまでの人材ではやれない可能性が高い。個人で考えるなら、いずれにせよ職を変えるしかない。

経営の戦略を考える上で、会社の価値観がはっきりしていれば、判断に迷うことは少なくなる。沢山のアイデアはあっても、そこから価値観から鑑みれば選べる選択肢は限られてくる。都度の判断のスピードを上げるには、ブレない価値観を持つことが重要なんだな。

「フルスタックエンジニア」って違和感のある言葉。フルスタックエンジニアを自称するようなエンジニアには出会ったことがないし、自分のスキルを表すのに使いたいとは思わないよね。「フルスタックエンジニア」てのは求める側の言葉であり、エンジニアを高く売りたいキャリア業界の陰謀にすら感じる。

アジャイル開発に出会ったときに、開発スタイルも、お客さまとの関係も理想的だと感じたはずだ。そこで、既存のビジネスモデルの中でアジャイル開発を追求するか、理想を実現するために前提となるビジネスモデルから変えるのか。後者はアジャイルを目指していないけれど”be agile”だと思う。

新規事業で地球を救いたい、なんて突飛なことを言う人がいても良いけど、なぜあなたがするのか、なぜあなたが出来るのか、という意味付けがとても大事だ。根拠がなければ、居酒屋での妄想と変わらない。そのために何をしてきたのか、これから何をするのか。解決したい問題は自分の人生に近い方が良い。

ソフトウェア開発における網羅的かつ基礎的なスキルを判定するためには、デバックをしてもらって、どうやってそのバグを見つけたか、どういう思考をしたのか、を聞けば、だいたいわかりそう。作れるかどうか、よりも、デバックできるかどうか。

リモートワークが当たり前になっているので、オンラインだけで採用の面談したりもするし、お客さまとの仕事もする。「オンラインだけで出来るのか？」と聞いてくる人も多い。電話が登場したばかりの時代に、電話だけで要件を伝えると言えば、多くの人が心配したはずだ。「電話だけで出来るのか？」と。

今日は一日ずっと経営ミーティング。社員のキャリアパスについて、曖昧だった部分をロジカルにはっきりさせて、採用から新卒、中堅、その先まで一通り考えた。そうやって、来期からの4期目に入るための準備をするのが、このクォータでの経営の仕事。現場を任せて経営に専念させてもらえて助かります。

戦略では「そもそも」がキーワード。難しい状況を作っているのはそもそも何か見極めて、難しい戦局で戦うことを避けて、勝てる戦にしてから戦う。戦術では「とはいえ」がキーワード。与えられた難しい状況がある中で、とはいえ仕方がないので、なんとか最善を尽くして摺り合わせて勝つべく努力する。

創作活動をしたことがあれば、創作者に対して敬意がうまれ心ない批判は減るだろう。チームを率いるを経験すれば、リーダーの大変さを知り尊敬し、協力するようになるだろう。自ずと振る舞いが変わる。自分にできないことをする人を尊敬するようになる。色々とやって皆がお互いに尊敬しあえるといいね。

新規事業で誰の問題を解決しようとしているのか、とても重要。正解はないが、失敗は幾つか見てきた。エンジニアにありがちなのが、自分の問題を選ぶこと。救えるのが自分だけなら、最も楽な手段で満足して妥協してしまう。営業にありがちなのが、今、目の前にいる顧客だけの問題を選ぶ。それは受託だ。

社内に新しいツールや取り組みを提案するのは私からが多いのだけど、新しいものや現状から変化することは大変なことなので、メンバーから放置されることも多い。ただ闇雲に従うだけよりも全然良いとは思うが、だからといって何もしなければ、成長することはないので、根気良く取り組み続けるしかない。

ソースコードの品質を高めるには、どうすればいいか。例えば、最初のうちから、少しずつ、すべてのソースコードを、熟練者によってレビューしていくことだ。一部のソースコードでは駄目で、すべてのソースコードに目を通す。まるで無菌室のように、常にクリーンなソースコードの状態を保ち続けること。