なぜUPDATEDというサイトを始め、ミッションや価値観を言語化していくのか?

Keiichi Hashimoto Keiichi Hashimoto
なぜUPDATEDというサイトを始め、ミッションや価値観を言語化していくのか?

はじめに

はじめに、なぜUPDATEDというサイトを始め、シグマ(弊社)のミッションや価値観を言語化していくのか?について記載してみます。

UPDATEDは、シグマのミッション、価値観(バリュー)といった社内外で共有したいことを言語化して掘り下げる事を起点にしている。社内のメンバーは自分達がどういう考えで働くかという材料があると、日々の働き方や、困ったときの考えるポイントとなる。社外のパートナーやお客さんにとっては、こんな考え方してる会社なのかと、一緒に仕事をする判断材料になったり、良好な関係を築くための参考になったりするのではないかと思っている。

また、使っている技術やあるべきベストプラクティス、プロジェクトの進め方、開発者にとって良い文化を社内の認識合わせ向けにまとめていく事を第一歩としている。 その時の情報をまとめたブログというよりは最新の情報をまとめておいて、社内エンジニアへの周知や議論(口論?)の材料に使いたいと考えている部分が強い。

その結果が、一連の記事情報が価値を持った最新の考えにUPDATEされており、内部だけではなく社外やこれからエンジニアとして育つ若者に役に立つなんて事があったらとても素敵かもしれない。

でもビール醸造を始めたり本気でやっている遊びに記事も入るのでそちらも楽しみにして頂きたい。

我々のミッション

ミッションとは、少しお堅く聞こえるかもしれないが、企業の存在理由、任務や使命であり、何を目指し成し遂げたいかをあらわしたものである。 シグマコンサルティングの場合は、「技術【クラウドとコードとデザイン】の粋を尽くし、顧客と戦略を立て継続的な事業改善を行う。」をミッションとしている。

補足すると、シグマが今自信を持って誇れるのは、クラウドとコード、デザインの力。これらを組み合わせた「技術」が強いので、基本的に要件を適切に詰め、QCDのバランスを整えられればちゃんとプロジェクトを成し遂げられるようになっており、この数年デスマーチもプロジェクト遅延も無縁にある。運用でトラブルが後を引くような事も防いでいる。

ただ技術のみではなく、顧客と戦略をしっかりと立てて継続的に改善できる関係にないと、本来作るべきシステムやサービスが作れない事がある。顧客と戦略を立てられる関係は、例えば隷属していては出来ないし、フラットに意見を交わし、お互い尊重できる関係にないといけない。 エンジニアが一方的に疲弊するような関係では働く事ができない。また、チームを作り上げないと、誰か特定の人頼みになり、人が疲弊したり、継続的に改善し続けられない。 そうはならない事をミッションとして目指している。

より詳細に説明するためにミッションを掘り下げていく。長い話になり申し訳ないが、真面目な話をする時は本気で一気に書き上げたいと思う。

ミッションを達成するための価値観(バリュー)

ミッションを達成するために、僕らは日々以下のような価値観(バリュー)を突き詰めている。

  1. クラウドとコードとデザインでエンジニアの能力を最大化し、小さなチームでも当たり前に大きな仕事を成せるようにする。
  2. 顧客と対等に事業について話し合い、考え抜き、事業に貢献する仕様、実装をこれまで以上に突き詰める。
  3. 顧客とフェアに良好にプロジェクトを進行していくための体制、QCDのバランス、運営方法を突き詰める。
  4. エンジニアのみで構成される独特の企業文化と、うまくいくチーム開発について、突き詰める。
  5. 要件定義の進め方等、デザインフェーズの進め方、現状とても悩んでいること、解決していない業界問題を突き詰める。

それぞれの価値観(バリュー)について掘り下げていく。例えば↓にある「信頼関係」ってなんだろというように🤔という部分もあると思うので、そういった事は追々フォローしたい。

1.クラウドとコードとデザインでエンジニアの能力を最大化し、小さなチームでも当たり前に大きな仕事を成せるようにする

  • クラウドネイティブなアーキテクチャを磨き普及させる
  • クラウドの機能や作法を最大限に活かす開発手法を探求する
  • Azureでの開発とセキュリティを探求する
  • DevOpsを最適化し続ける
  • デザインと実装の協働を工夫していく
  • 小さなチームにおけるチームビルディング、チーム力、信頼関係の構築

2.顧客と対等に事業について話し合い、考え抜き、事業に貢献する仕様、実装をこれまで以上に突き詰める

  • 顧客、顧客業界におけるビジネスを理解する
  • 何を価値としたプロジェクトなのか明確にする
  • 適切な要件定義を行う
  • 継続的に改善するための仕様作りを行う(段階的にリリース等)

適切な要件定義って何だろう🤔というのは凄くあるので別にまとめたい。

3.顧客とフェアに良好にプロジェクトを進行していくための体制、QCDのバランス、運営方法を突き詰める

  • フェアな契約
  • 適切な体制
  • Quality、Cost、Deliveryのバランスのとり方
  • 顧客と共にプロジェクトを適切に進める方法、仕組み

この辺の適切という言葉も🤔なのでもう少し言語化して仲間と共有したい

4.エンジニアのみで構成される独特の自社文化と、うまくいくチーム開発について、突き詰める

  • 自社文化の明文化
  • チーム開発の考え方
  • 各自の働き方

この辺のうまくいっている各自の働き方が自由になるように集団で工夫していく、というのは他の会社でも中々みないので、どこかで言語化したい。

5.要件定義の進め方等、デザインフェーズの進め方、現状とても悩んでいること、解決していない業界問題を突き詰める

  • 要件定義の進め方
  • デザインフェーズの進め方
  • 適切なお金の取り方

業界では、正解が決まっておらず、学問、方法論がたびたび議論される点でもある。

言語化は大切だけど一つの手段

これまで説明したように言語化したら、考えをさらにまとめる事ができたり、仲間と共有出来ることが増えるかもしれないという期待感はかなりあります。ただし、言葉で表現する段階にないもの、言語化が適していないものもあり、何でもかんでも言語化すればよいというわけではない、という認識で取り組んでいく事も大事かもしれません。 あと、ルールを作るような事は狙っていません。あくまで自由であり自分の意思が起点。

Updateは楽しい

一度言語化したものは年月が経つと変化していく。ノウハウ等は技術革新によって急激に変化、陳腐化していく場合もある。 これらは、常に更新、Updateしていくと、都度思考をゼロから始めなくて良いのではないか、過去の自分や組織と向き合えて楽しいのではないか、といった仮説をもっています。

ので、このサイトはブログとは違いWikiに近い手法になると考えています。

  • プロジェクト管理で突き詰め続けている考え方、学び
  • 今Azureを使った上での最良のセキュリティ対応
  • 最新のデプロイ方法
  • 最新の運用監視

このように最新という形で価値のある情報がまとまるという、ブログとは違った更新価値のあるサイトを目指しておりupdatedという仮題をつけました。

更新するので、中途半端な状態(TODO)が含まれる形でも良しとしているため、お見苦しい部分とか後で書くなんて部分もあるかもしれませんが、ライブ感があると言うことでご容赦いただきたい。

最後に期待する未来や記事を書くモチベーションについて共有したい。

言語化するモチベーション

この言語化はだれのために行うのか、モチベーションになることを考えたい。

ベストプラクティスが洗練されるはず

過去を振り返ると、個々人で勝手に、属人的にやることによって良い方法を編み出せることもあった。

しかし、運用環境が増えたり業務が一定量を超えると、ベストプラクティスを共有したり、寄せないと、全てが別々の案件になり、手伝うのが辛くなってくる。

このように辛いと感じていることの共有も必要だった。個々人で勝手にやっているのは、ベストプラクティスを知らないケースにも起因している。

まず先に共有ありきで、ベストプラクティスを使わないメンバーとの相談はそれからでもできる。

ノウハウについて

  • DevOpsに限らず、ECで強く求められる外部連携先(決済とか、基幹とか、SaaSとか)の仕様が個人のブラックボックスに入らないように、可視化したいと考えている。

哲学について

  • 自社にとって良いビジネス、悪いビジネスを定義しないと、持っていきたい理想系にチームでたどり着けないので、哲学を共有する。

顧客との相互理解につながるかも

  • 顧客と良いチームを組むために、弊社の開発に対する考え方、価値観を共有する。
  • クラウドの価値、開発の価値、チームビルディングの価値を顧客と共有する。
  • 要件定義の進め方、デザインフェーズの進め方など、顧客側でも理解が薄い部分の補足となる情報を目指す。

のような狙いがある。顧客に伝わってないから、行き違いがあるというのは悲しい話なので、回避したい。

僕らの少数精鋭は業界の未来に役立つかも

少数精鋭で大きな仕事をしている僕らのやり方は、業界の役に立つもの、10年後にこの業界に入ってくる方に希望となるものが含まれていると信じて働いている。

世の中のエンジニアが小さなチームで大きな成果を出すようになるほど、SI業界に渦巻く問題

  • 例えば資本の大きい企業に頼むことにより発生する多重請負 -下請けが仕様に意見を出さず言いなりで作るという構図
  • 資本の大きい発注者と受注者の隷属的な関係によって開発側の意見が通らなくなる(Xペイの話のように)
  • 継続的な改善に大きなコストがかかり、適切な保守体制が組めなかったり
  • 新しい技術にトライする文化が作れず遅れていく

こういったSI業界の課題を解決する事にも繋がると僕らは考えている。 また、今後この業界を志す若者にとっての希望の一端となることも目指せたら。

最後に

挑戦的な試みなので、正直なところ、うまくいくかはわからないので、興味があったり楽しいことから書いてみます。

断片的なものになってしまうかもしれないけどそ、社内のエンジニアや、顧客、業界を鼓舞するエモい内容を少しでも生み出したいと考えています。

SIという業態が生まれ変わり、エンジニアが誰でも小さなチームで大きな仕事をするという世界、10年後にこの業界に入る若者が希望を持てる、そんなビジョンに近づく一つの足場になれますように。

お問い合わせはこちらから

問い合わせる

関連記事

TOP