自分なりに言語化ができたので、自社の文化のアピールがてら書くことにしました。
こんにちは。新卒で当社に入社して以来、そろそろ10年が経とうとしています。いくつかのロールを経て、今は社内SEとソフトウェアエンジニアを自称しています。橋本 (@hassaku_63)といいます。社歴が2桁年経とうとしていることに我ながら心底驚いています。ここまで長居するとは。
とりあえずは、IT の世界でものづくりをしているエンジニアのジュニア層に向けた意識でこの文章を書いてます。あとは、タイトルのような言葉に聞き覚えがある人に向けて書きました。
基本的に私の日常は開発寄りの仕事が多いので、なにか新しいシステムや機能、あるいは業務フローを構築するだとか、そういった「不確かな要求から、新しいモノを作る」ような仕事に従事するシーンを念頭に置きながら本記事を書きました。開発系以外の立場の方からすると、人によってはピンと来ない表現に映る箇所があるかもしれません。ひとまず筆者としてはこういうイメージで書いています...と、いうことを予めご承知いただけると幸いです。
また、社会人歴の長い人や、シビアに結果を求められる世界で戦ってきた方からすれば、ぶっちゃけ改めて語る必要もない、あるいは取るに足らない話に映ると思います。まあ、半分くらいはしくじり先生的なノリで読んでいただけたらと思います。ここに書いてあることはだいたい筆者個人の振り返りであり、自身が過去に担当してきた仕事だとかチーム事情だとかを前提にしています。
前フリ
会社や周囲の先輩社員は、口では表題のようなことを「歓迎する」だなんて言いますが、だからといって自分の中で素直に納得できるかどうかは別問題ですよね。理屈では理解できるものの、なかなか気が引けて実践できない、という方はそれなりに多いのかなと思いました。
これまでそうした考え方に馴染みがなかった人からすると、都合の悪い（ように見える）情報を報告することは、心理的なハードルが高いと思うのです。運良く うまくことが運び、結果的に期待されたモノを期待される時間軸で提示できるかもしれないと、分の悪い賭けに内心では薄々気づいていながらもベットしてしまいます。当然、戦績は芳しくありません。
かといって、それで失敗しても、それでもやはり躊躇するメンタルを完全に振り切れるわけではありません。どうしたらもっと割り切れるのでしょうか。
思うに、これは個々人の性分とスキルの話です。防御本能として身についてしまった考え方や反応はそうそう変えられません。ただ、私自身は現職のエンジニアとしての仮面を付けているときに限っては、その性分をある程度克服できるようになったと思います。元々の性分による傾向はあろうとも、だからといって無理なわけではない。スキルとして意識的に纏うことが可能な行動習慣でもあると考えています。
また、私自身は今回のような話を社会人やってく中での成長痛みたいなものと捉えており、時間が解決してくれる話だと考えています。自分でも改めて語るほどの話じゃないと思ってはいるのですが、実際に昔の私は「そういう」考え方をして萎縮していましたし、今後も似たような悩みを持つ後輩社員*1はたくさんいらっしゃるだろうとも思いましたので、過去の自分の供養がてら書いておくことにしました。
当事者以外の話
前提としての私のスタンスを表明しておきます。
誰かが、自身のタスク遂行時に遭遇した「不都合なこと」を他人に報告しづらいと感じていたり、あるいは「失敗できない／したくない」と感じているとしたら、おそらくその原因の何割かは所属先の集団（コミュニティ）がそういう空気を作っているか、あるいは接点のある既存メンバーから個別フォローができてないか、そのどちらかだと考えます。基本的には 先住民側に原因がある場合が多いと思います。そして、問題原因が特定個人に100%帰属するような話でもないと思っています。
今自身が所属しているコミュニティにおいて、
（他人の権利や名誉を不当に侵害しない限りにおいて）自分は自由に発言していいと思えること、あるいは
失敗や勘違いなど、一般には「恥」とされるようなことを言って／やってしまっても大丈夫なんだと思えること、
こうしたことを個々人の主観で信じられるかどうか、ということが非常に大きいと思います*2。仮に萎縮している新人や若手メンバーがいたとしても、それはその方が100％悪いという話にはなりえないですし、その逆も然りだと考えます。
とはいえ、集団が絡む要素は直接制御できない場合が多いですし、自分以外のものごとを変えるというのは難しいです。個人間のやりとりより主語が大きくなる問題を今ここで取り上げる気はないので、まずはいったん個々人がコントロールできる範囲でやれることを考えてみよう、という軸でこの記事を書いています。
「不都合に見えること」をどう解釈する？
会社の文化が、あるいは一緒に仕事しているメンバーが表題のような行動をちゃんと推奨するスタンスを明言していることと、報告者としてのご自身が心理的なハードルで「不都合な事実」の共有や「失敗」を躊躇してしまう、といった状況を前提として、処方箋になる かもしれない 話をします。
目先の話だけでなく、その外側の文脈や目的意識にも目を向ける
まずひとつは、細分化して担当が割り振られたタスク単位の視点ではなく、その親タスク、あるいはプロジェクトや組織にとってのゴールにも目を向けよう、という話です。
そのプロジェクトで期待されている成果を当事者全員で達成することが重要なのであって、そこに関わった個人がその部分要素にすぎない特定のタスクでどうこうなったというのは、多くの場合割と些末な話です。
萎縮して情報共有等のアウトプットがおろそかになっていたころの私は、自分が身近な同僚や上司にどう見られるのかの目先ばかり気にして大局的な「成果」に目が向いていませんでした。過程でどれだけコケても最終的に「成果」を出す、そのために手を尽くす、という覚悟は希薄でした。もっとはっきり言うと、自己保身の意識にすべてを持っていかれて頭いっぱいだったんでしょうね。
そして、これは完全に過去の自分への懺悔なのですが。過程のある一場面の恥だけを切り取って自分がどう見られるか気になっているのだとしたら、おそらくプライドの置きどころがズレてます。もう少し大局的な目で見て、そのプロジェクトや組織で求められる「成果」を出すことにプライドを持つ方が、より健康的だと思います。
メタファーで「不都合」と「失敗」を再解釈してみる
上記の話もあくまで理屈です。それで割り切れるならね。苦労しませんよねぇ。
昔の経験を振り返ったり、スクラム開発の経験などを経て思ったのが、仕事における「不都合な事実」とか「失敗」とかいうものは、推理モノの物語における「犯人の手がかり」に近いものなんじゃないか？ということです。
「真犯人の特定」が、仕事における「成果」の比喩に当たります。
犯人の手がかりは、多ければ多いほど推理の「確信度」を高める助けになります。そして、少ない手がかりから判断を見誤り、無実の人を犯人にしてしまったら、そこには損失しか残りません。
手がかりの発見は、遅れれば遅れるほど状況が悪くなります。その間にも犯人による被害が拡大する危険性があるわけですし、その手がかりを報告したのが遅れたばかりに手遅れになってしまうようなケースだってきっとあるでしょう。手がかりの発見はいつだって早い方が良いわけです。そして、真犯人を捕まえるという目的を達成するためには、どんなに手遅れだろうが損失を出そうが、手がかりは「あった方が良い」の一択しかありません。
何が「手がかり」になるのかは事前に分からない、ということも重要です。先入観で「これは関係ないな」と切り捨ててしまったり、見逃してしまった景色が後々の重要な伏線だった・・・なんて話は、物語の描写でも良く見かけることでしょう。他の手がかりから得た洞察や他者の視点が補完されることで、見過ごしてしまった手がかりに気づけるかもしれません。
物語の中腹でひとり足踏みしていてもシーンは転換しませんし、オチにもたどり着けません。さっさと試して失敗するだとか、不都合なことを早くレポートするだとかの行動は、さっさとシーン転換して話を進めるためのアクションだと思っておけばよいと思います。こういった意味でも、ご自身が遭遇した「気になること」、特にネガティブに見える情報はさっさとご自身のレポートラインに共有なり相談なりしちゃった方が良いですし、手を動かして得られる結果から学んでさっさと次の実験を開始する方向に振り切った方が、話が好転する期待値は高いように思います。
メタファーを踏まえて、どう考えるか？
ここまでで、メタファーとしてお伝えしたいことは書き切りました。少々くどいようですがもう少しだけ補足します。
手がかりが得られた時点で何が間違っていたか、あるいは何が正しかったのかの情報量は増えるので、成果に向かって一応前進はしているのです。なので、そもそも「恥」や「失敗」ではなく、正しい成果に向かうための新情報（＝手がかり）を手にした、と解釈するのが前向きだと思います。このへんは割と開発者的な気質が強く出た考え方かもしれませんね。ことにソフトウェア開発の文脈では、不都合の発覚それ自体を悪とするのではなく、その発覚（あるいは共有・報告）が遅くなったことに対しての反省比重を上げてみてはいかがでしょう。もっと早期に検出できる進め方がなかったかを掘り下げる方向で考察していく感じです。
「不都合」な情報を得るタイミングが遅ければ遅いほど、その時点までの投下コストは大きいわけですし、その後のリカバリに投じるコストも比例して大きくなることは容易に想像できます。そして、商売の世界は時間軸が適切でなければその成果に価値はないという場合も往々にして（というか、非常によく）あります。時間軸が前倒しになることは、多くの場合「価値」に直結します。だからこそ、できるだけ多くの手がかりを早く得られるような動き方・進め方をしたいのです。
先輩社員の立場として
いつの間にかいい歳になってしまったので、他のメンバーのサポートも含めて一緒に仕事をするような機会も増えてきました。そこで、私個人がジュニアなメンバーと組んで同じプロジェクトで仕事する場合の先輩社員側としての考えを書いておきます。こういうのは相手側の視点もあったほうがよいと思いますので。あくまでも私個人の考え方であることは予めご承知ください。
成果を出したいからこそ「手がかり」が必要
私自身は「不都合な事実」とか「失敗」を先ほど述べたメタファーのようなイメージで捉えています。顧客の課題をちゃんと解決できる成果物をきっちり作りきるためには、具体と抽象の間を何度も往復しながら試行錯誤したり、仮説を立てては検証したり、そういう反復的な活動を通して「手がかり」を徐々に増やし、「正しいベクトル」に向かっている確信を積み重ねていくことが必要です。
「手がかり」の発見が遅れるということは、私からすると「間違ったゴールに出航してしまった可能性」がそこそこ残っている状況で、なにもケアせずに航海を続けているようなものです。的外れなゴール設定をしてしまったら、何をどれだけ苦労して作ってもそれを「価値」とは呼べません。重要な不確定事項や自明でないディテールがある状況においては、できるかぎり段階的に 手がかりを増やせるようなアクションを積み重ねるような意識が重要だと考えます*3。
自らの職責として、チームメイトの成果と成長に貢献したい
一定以上のグレードになると、自分以外のメンバーのフォローもひっくるめて、プロジェクトもしくはその組織が目指す「成果」に貢献することが職責に含まれます。おそらく当社に限らずどこも似たような話はあろうかと思います。少なくとも、私は自分自身を「そういうこと」が期待される側の人間だと思ってやっています*4。このへんは自社の行動指針とか、グレードごとに定義されている期待値の情報、私個人が理想とするエンジニアとしての在り方などを指針にしています。
後輩社員が出してくれた成果はもちろんその後輩個人のものですが、フォローを任されている側の立場から見ても利害の方向は同じです。その後輩が望ましい成果を出すことは私にとっての成果でもありますし、もっと言えばその過程や結果を通して後輩社員に成長してもらうこともこちらにとっては成果です。なので、その後輩が担っている、あるいはお任せしたタスクの経過においてなにかしら芳しくない出来事があったとしたら、できるだけ早期に状況を発見し、最善の結果を出せるよう今打てる手を打っていきたいわけです*5。
道中のやりとりが多少増えようが、間違ったゴールに到着する前に軌道修正できるのならそっちの方がよっぽど嬉しいです。そう考えると、少しでも早く「手がかり」を増やせるような行動をしたいよねという意識が自然と働きますし、普段の行動も自ずとその方針に最適化されます。先輩社員の手間を取るだとか、的外れなこと言ったらどうしようだとか、しょうもないミスだと叱責されるだとか、そんな心配は「成果」の前には些末なことです。最後に勝てればいいのであって、残りの話は追加ボーナスです。
まとめ
「手がかり」を早期に得ることが成果に繋がる、という話でした。「不都合」や「失敗」と映るような出来事・状況の発覚は早いほど良く、そのためには、目の前の状況が「悪いニュース」であるかどうかを自分の先入観のみで判断せず、ありのままの事実や現状を報告し、適切に第三者の視点を入れることが非常に重要であることを改めて強調します。
私と組むことになる後輩社員の方は、私のことは "案件情報や技術が多少わかってる会話モード付きの ChatGPT（クセつよ）" 、ぐらいに思っておいてください。自分が「手がかり」を得て成果に近づくために用いる手段の1つやと、そのくらいで見ておいてくれれば良いです。
「他人に頼る」という選択肢を自ら排除して、縛りプレイをしていませんか。求められているのは手段を尽くして「成果」を出すことです。多くの場合において「あなた一人の力で完遂して欲しい」は要求事項ではありません。不都合な状況を早期に発見する、あるいはレポートするという行動は、当事者だけでなく周囲の関係者にとってもプラス行動です。起こった事実はもうどうにもならんので、一緒に次どうするか手立てを考えていきましょう。
あくまでも勝利条件は目的の達成ですから、そこにフォーカスできるとよいですね。そういう強い目的意識から出た言葉や行動を、私は支持します。
さて、、、だらだらと自説（？）を開陳しましたが、表現が違うだけで社会人として長く活躍されている方はおそらく近い考え方を部分的にでも持っている方は多いんじゃないかと思います。少なくとも私の観測範囲、当社に在籍して活躍されているメンバーに関しては、そういう傾向が強いと思います。
身内の贔屓目も大いにあると思いますが、意味不明な詰め方をしない、あるいは建設的にゴールに向かう会話ができる、そして目の前の同僚がそういう人だと信じた状態から会話を始められる、そういった点において当社はかなり働きやすい職場だと思ってます。当然のことながら「働きやすさ」というのはそれだけで決まるようなものではありませんし、職場を選ぶ理由も「働きやすさ」だけじゃない軸がいくつもあります。それでもまあ、私なりに当社のことは悪くない会社だと思っていますので、この文章を見て「悪くねぇな」と思われましたらぜひ当社の採用ページの方も見ていただけたら嬉しいです。
(p.s.) ちなみに当社では、人によって表現こそ違えど、ちょいちょい各所で同じ意図の言葉を見聞きする印象があります。あくまで私ひとりの印象ですし、それぞれの部門の内情として実際どうなんという話までは知りませんが、少なくとも私は会社全体の標語のように、共通語彙としてこういった言葉が使われている空気感は好きです。多分、その空気感の根っこはウチの代表がことあるごとに試行錯誤やフィードバックの重要性、当社の行動指針を繰り返し声に出して共有しているからだと思います。私が新卒入社した2015年ごろからほとんど変わらず一貫してます。ヤバいです。いい意味で。大事なことほど何回でも言葉交わさなあかんよな〜と思いました。
*1:先輩だの後輩だのと、年次だけの違いで何かをジャッジするかのような物言いは好きではないのですが、この記事では当社の社歴10年生としての立場で書いているため便宜上このように表記させてください
*2:巷ではこれに近い話を「心理的安全性」という言葉で表現することも多いと思いますが、あえて使いませんでした。私にとってはこの概念の理解はまだまだ難しいですし、良くも悪くも「便利な」言葉として使われがちで、本質的に私が言いたいことをうまく伝えられない気がしたからです
*3:これに似た、しかし全く異なる考え方として、動き出す前にすべてがクリアにできると信じて入念な検討・検証に時間を費やしすぎる...というのがあります。これはよくある間違いです。すべてが明確でなければ動けないというスタンスは、チャレンジの対極にある姿勢です。どう足掻いても時間とコストは有限なのです。すべての懸念が払拭できなくても決めねばならないシーンなどいくらでもあります。この考え方は事前に未来は予見できると言っているのにほとんど等しく、加えて自身で「決断」を背負う責任からも逃げているようにも映ります
*4:十全にできてないことも、よくあります
*5:逆に言えば、情報量が増えないまま時間だけ経過する状況というのは、現状把握や次の打ち手の検討をも停滞させることを意味します。不都合な状況が "今" 露呈すれば損失のポテンシャルはいったんその時点で底が見えますが、報告せず放置すれば損失のポテンシャルは今後も増大し続けます。言うまでもなく、後者の方がよっぽど状況が悪い。周囲もその方を適切サポートできなくなります。
hashimoto (@hassaku_63) / (執筆記事の一覧)
社内SE 的な仕事を割と長くやっています。推しサービスは AWS CDK と Step Functions
