ID:29390さん
2021年3月回 指名
3年後の目標や野望
ユーザーも開発者もビジネスオーナーも生き生きと使い育てられるソフトウェアを作る
まだ自分本位の視座ではありますが、次のようなことが継続的にサービスを提供するために必要と考え、これまで様々試行してきました。
- ユーザーが心地よく使える
- 開発している人たちもそれに対する誇りと成長実感を感じられる
- そのソフトウェアを用いてサービスを提供しているビジネスオーナーもアジリティ高くやりたいことを実現できる
単に目の前のものをスピード感持って実現するだけでなく、内部品質高く実現し開発者にとってもハッピーなシステムにし、かつ不確実性の高いビジネス運営に耐えられる変更可能性を維持するためには何が必要なのかを試行錯誤しています。
アジャイルなどでは、考え方とそのプラクティスが一気通貫していることを「ムーブメント」と称したりしますが、ムーブメントとして、いかにソフトウェアを抽象的な論理と具象的な技術スキルを一気通貫した状態で開発できるか、これに個人的に必要性を感じています。
また、移り変わっていく技術の隆盛を捉えた構成要素のアップデートをしていくことも「技術は手段」と言われつつも重要ですよね。松尾芭蕉の言葉を借りるならば、不易流行であらねば陳腐なソフトウェア開発作りになってしまうなぁと。
Kent Beck氏が『時をこえた建設の道』を読んでクリストファー・アレグザンダー氏の考え方「パタン・ランゲージ」を取り入れたUIパターンやその後につづくXPなどのパラダイムを生み出したように、温故知新の心得を持ちつつ世界のソフトウェアの歴史を一歩また前に進めるような貢献がしたいことが長期的な野望です。
まだどういう道筋が自分にとって出来ることなのかは模索していますが、少なくとも目の前で自分が携わるプロダクト・サービスはこのような意識を少しでも体現できるように日々思考を止めず自分自身の改善を続けていきたいです。
プロジェクト経験
このプロジェクト詳細は公開されていません
このプロジェクト詳細は公開されていません
このプロジェクト詳細は公開されていません
マネージメント能力
アピール項目
アウトプット
今後、身につけなければいけないと思っている技術は何ですか？
アジャイルテスティングのカバー領域を広げていくこと
アジャイルテストの4象限というものでテスト活動が分類されています。
現在自身が戦略と明確な言語化を持って行えているのがQ1（技術面かつ開発支援）で、少しずつ進めているのがQ2（ビジネス面かつ開発支援）という状況です。
ソフトウェアテストの活動としてそれだけにとどまらず、Q3・Q4への明確な領域拡大を目論んでいます。具体的には探索的テストとか脆弱性テストとかそういうたぐいだとイメージしていただければ良いかなと思います。
分散システムのプラクティスから導出されるアーキテクチャ設計
現代のソフトウェア開発において、もう分散システムのプラクティスを無視することはできなくなっています。実際の業務課題としても否応なしに発生しますし、課題解決のためにはこのアーキテクチャ設計は緊急度高く求められます。具体的には「Saga Pattern」とかそういう設計パターンのことですが、それを現場の課題を分析して適切に用いるパターン思考が課題になってくると感じています。
エンジニアリングマネージャーとしてのレバリッジの効かせ方
採用やチームメンバーの成長・支援、チームの拡大と成長にたいしてどのように戦略持って取り組んでいくかという、エンジニアリングマネージャーとしての技術を考えていかねばいけないなと感じています。
コーチングなりティーチング技法なりはレトロスペクティブ運営を考える際にすでに色々見回っているのですが、どちらかというと「どういうチーム・組織で、そのためにどのような個人が今後求められるか」といった視点について中長期的に捉える視点を強化していく必要を感じています。
あなたが一番パフォーマンスを出せるのはどんな環境ですか？
事業の意義の納得感と実際にそれに集中できる環境
現職で気に入っている点は、事業の意義が明確なミッションとしてあって、実際にそれをビジネスモデルとしても明確に現れていて、チームもそれに集中して働いている点です。
大前提として「自分が携わっているものが世の中を良くすることに貢献している」ことを実感できるからこそ、時に苦しい思いをしながらでも人生の大部分の時間を使おうと思えます。
特に納得感を感じやすいものの特徴としては「どういう人が使っているのかイメージしやすい」といったペルソナが明確だったりするものでしょうか。
エンジニアリングコミュニティへの貢献の理解・行動がある
私は実践・学習のフィードバックループの回し方として、ブログの公開やカンファレンスでの登壇などを行う機会が人よりも多いです。その背景には、ソフトウェア開発全体の歴史の流れに貢献していきたいというささやかな野望もあります。
そして、このようなエンジニアリングコミュニティへの貢献に対する価値理解を持っている会社であれば、自身の行動様式と価値観にマッチするためにパフォーマンスを出せると思います。
領域を広げようと思えば広げられる環境
様々な領域を担うゼネラリスト的なスキル構成になっていますが、これは２つの理由があると自己分析しています。
1. 複眼的視点の重要性
単一の領域だけではなく、複眼的にソフトウェアを捉えることが重要だと考えるためです。たとえば、PHPなど単一言語しかしらない場合それのみが打ち手となり取りうる設計実現方法のバリエーションがないですが、その他インフラ・フロントエンド領域は他言語についてもそれなりに精通すれば打ち手の数はn*nで増えていきます
アーキテクチャ設計においてもドメイン領域から導く視点・運用視点・ソフトウェアテスト視点・組織的観点等、複数の視点をミックスすることで見えてくるものがあります。
逆にいうと、職能的に単一の領域しかオーナーシップが持てない環境の場合は、パフォーマンスを出せないかもしれません。
2. わりと飽きっぽい個人的性格
同じことを思考している・行っているのに飽きてしまう傾向にあります。経歴を見ていただくと2年以上同一プロダクトに関わっていることからプロダクトがたくさんあればいいという話ではなく、ソフトウェア開発に携わる人間として進化していく向上心が満たされないことに対する感情が「飽き」という形で出てくる可能性があります。
なにか「成長機会を提示せよ」というタイプではなく「こっちに行きますね」と方向性を現場の課題解決とマッピングした上で自分で決めるタイプだと自己分析しています。
そういった動き方を奨励してくださる環境であれば、パフォーマンスが出せるかと思います。