{"id":1271,"date":"2026-05-20T11:53:24","date_gmt":"2026-05-20T02:53:24","guid":{"rendered":"https:\/\/www.mindware-jp.com\/en\/?p=1271"},"modified":"2026-05-20T11:53:24","modified_gmt":"2026-05-20T02:53:24","slug":"from-the-tragedy-of-the-data-scientist-to-the-conditions-for-ordinary-consultants-and-engineers-to-become-fdes","status":"publish","type":"post","link":"https:\/\/www.mindware-jp.com\/en\/2026\/05\/20\/from-the-tragedy-of-the-data-scientist-to-the-conditions-for-ordinary-consultants-and-engineers-to-become-fdes\/","title":{"rendered":"From the Tragedy of the Data Scientist to the Conditions for Ordinary Consultants and Engineers to Become FDEs"},"content":{"rendered":"\n

In recent years, the role of the Forward Deployed Engineer<\/strong>, or FDE<\/strong>, has attracted increasing attention.<\/p>\n\n\n\n

An FDE is not simply a software engineer who writes code. Rather, an FDE works close to the customer\u2019s operational environment, understands business problems, and builds practical solutions using AI and software.<\/p>\n\n\n\n

At first glance, this looks like an ideal role for the AI era.
AI-assisted coding reduces the burden of implementation, allowing engineers to move closer to customer value. Companies, meanwhile, do not merely want to buy tools; they want people who can adapt AI to their actual business processes.<\/p>\n\n\n\n

However, this trend feels familiar.
It resembles the earlier boom around data scientists<\/strong>.<\/p>\n\n\n\n

In the 2010s, data scientists were celebrated as one of the most attractive professions of the century. Companies rushed to hire data science talent. Yet the results were mixed. In many organizations, data science projects ended as proofs of concept, analytical outputs failed to influence operations, and young data scientists struggled under excessive expectations.<\/p>\n\n\n\n

The FDE boom may repeat the same mistake.
However, if we correctly understand the tragedy of the data scientist, we can redesign the FDE role so that it does not depend only on a handful of superhuman individuals. Instead, ordinary consultants and engineers can become capable of performing FDE-like work under the right conditions.<\/p>\n\n\n\n

What Was the Tragedy of the Data Scientist?<\/h2>\n\n\n\n

The tragedy of the data scientist was that the role was almost entirely new.<\/p>\n\n\n\n

At the time, data scientists had few seniors to learn from.
Companies had not yet developed mature career paths or operating models for data science. Universities also lacked a sufficiently practical educational framework.<\/p>\n\n\n\n

Nevertheless, data scientists were expected to be universal professionals.<\/p>\n\n\n\n

They were expected to:<\/p>\n\n\n\n

    \n
  • understand statistics;<\/li>\n\n\n\n
  • build machine learning models;<\/li>\n\n\n\n
  • write Python or R code;<\/li>\n\n\n\n
  • process databases and messy data;<\/li>\n\n\n\n
  • understand business problems;<\/li>\n\n\n\n
  • present insights to executives;<\/li>\n\n\n\n
  • influence frontline operations;<\/li>\n\n\n\n
  • deploy models into business processes;<\/li>\n\n\n\n
  • and generate measurable business outcomes.<\/li>\n<\/ul>\n\n\n\n

    This was an unrealistic set of expectations.<\/p>\n\n\n\n

    Young people who had studied statistics, linear algebra, calculus, Python, and machine learning at university were suddenly expected to act as management consultants, data engineers, machine learning engineers, business transformation specialists, project managers, and organizational mediators.<\/p>\n\n\n\n

    As a result, many companies faced similar failures.<\/p>\n\n\n\n

    Analyses were produced but never used.
    Models were built but never deployed.
    Proofs of concept succeeded but never reached production.
    Analytical themes were disconnected from management priorities.
    Frontline employees did not trust the data.
    The necessary data was not even properly prepared.
    Data scientists themselves often did not know how their work would be judged.<\/p>\n\n\n\n

    In other words, the problem was not simply that individual data scientists lacked ability.
    The deeper issue was that the role itself was poorly designed.<\/p>\n\n\n\n

    The Gap Between University Education and Practice<\/h2>\n\n\n\n

    Data science education also contributed to the problem.<\/p>\n\n\n\n

    At universities, data science is often taught through statistics, mathematics, programming, and machine learning. These subjects are important. But in practice, the most important issues are not limited to solving equations or writing Python code.<\/p>\n\n\n\n

    More fundamental questions matter.<\/p>\n\n\n\n

    What is prediction?
    What is classification?
    What is causality?
    What is correlation?
    What is segmentation?
    How does a model simplify reality?
    What risks arise when that simplification is applied to business?
    Which decisions can analytical results support?
    In which situations should such results not be used?<\/p>\n\n\n\n

    These may sound like philosophical questions.
    But in business practice, they are extremely concrete.<\/p>\n\n\n\n

    For example, what does it mean to classify customers?
    Categories such as \u201chigh-value customer,\u201d \u201cchurn risk,\u201d \u201cprice-sensitive customer,\u201d or \u201cloyal customer\u201d do not exist naturally in the world. They are constructed by companies for the purpose of decision-making.<\/p>\n\n\n\n

    Demand forecasting is similar.
    Once a forecast is produced, inventory planning and promotional activity may change. In other words, prediction does not merely observe reality; it intervenes in reality.<\/p>\n\n\n\n

    Without understanding this relationship between models and the real world, learning statistical techniques and machine learning algorithms is not enough.<\/p>\n\n\n\n

    Another issue is that many university professors do not have extensive experience in corporate practice.
    They may be able to teach correct analytical methods, but they may not be able to teach why analyses often fail to create value inside real organizations.<\/p>\n\n\n\n

    They may not have experienced messy data, interdepartmental conflict, vague executive problem definitions, failed PoCs, skeptical frontline users, budget constraints, or the politics of implementation.<\/p>\n\n\n\n

    The tragedy of data science was that young talent was thrown into this huge gap between theory and practice.<\/p>\n\n\n\n

    Is the FDE the Return of the Data Scientist?<\/h2>\n\n\n\n

    The FDE role carries a similar danger.<\/p>\n\n\n\n

    FDEs are expected to:<\/p>\n\n\n\n

      \n
    • understand customer operations;<\/li>\n\n\n\n
    • structure business problems;<\/li>\n\n\n\n
    • build solutions using AI and software;<\/li>\n\n\n\n
    • implement APIs and data integrations;<\/li>\n\n\n\n
    • create prototypes quickly;<\/li>\n\n\n\n
    • deploy tools into real workflows;<\/li>\n\n\n\n
    • improve solutions through customer interaction;<\/li>\n\n\n\n
    • and produce business results.<\/li>\n<\/ul>\n\n\n\n

      This is also a very broad set of expectations.<\/p>\n\n\n\n

      However, there is one major difference between data scientists and FDEs.<\/p>\n\n\n\n

      Data scientists were often young professionals with limited practical experience.
      FDEs, by contrast, are more likely to be people with several years of experience as engineers or consultants.<\/p>\n\n\n\n

      In that sense, the FDE role is more realistic.
      It assumes some prior experience in customer communication, requirements definition, system development, business understanding, and project execution.<\/p>\n\n\n\n

      Even so, a major problem remains.<\/p>\n\n\n\n

      People who can handle both technology and business at a high level are rare.
      Moreover, even if AI-assisted coding reduces the burden of writing code, it does not eliminate the difficulty of building systems from scratch.<\/p>\n\n\n\n

      The truly difficult questions are not only about code.<\/p>\n\n\n\n

      What should be built?
      How much should be built?
      How should it fit into existing workflows?
      Which data should be used?
      How should permissions and security be designed?
      How much customization should be accepted for each customer?
      Who will operate the system after deployment?
      How should return on investment be explained?<\/p>\n\n\n\n

      AI-assisted coding alone cannot solve these problems.<\/p>\n\n\n\n

      Therefore, if FDEs are defined as superhuman individuals who can do everything, the tragedy of the data scientist may repeat itself.<\/p>\n\n\n\n

      FDEs Must Not Become Another Superhuman Role<\/h2>\n\n\n\n

      If we define an FDE as someone who can handle technology, business, customer communication, AI implementation, and project delivery all at once, most people will not qualify.<\/p>\n\n\n\n

      Of course, exceptional individuals exist.
      Some people can combine high-level engineering ability, customer communication, business understanding, AI expertise, and rapid delivery skills.<\/p>\n\n\n\n

      But a business model should not depend on such exceptional people.<\/p>\n\n\n\n

      The important question is how ordinary consultants and engineers can perform FDE-like roles under appropriate conditions.<\/p>\n\n\n\n

      To achieve this, the FDE role must be designed not as an individual talent problem, but as a system.<\/p>\n\n\n\n

      In other words, we should think of FDE capability as:<\/p>\n\n\n\n

      \n

      people \u00d7 semi-finished products \u00d7 templates \u00d7 AI assistance \u00d7 deployment methodology<\/p>\n<\/blockquote>\n\n\n\n

      This is the key to making the role scalable.<\/p>\n\n\n\n

      FDEs Need Semi-Finished Products, Not Blank-Slate Development<\/h2>\n\n\n\n

      The product best suited for FDEs is neither a fully standardized SaaS product nor fully custom software development.
      It is something in between: a semi-finished product<\/strong>.<\/p>\n\n\n\n

      A fully standardized SaaS product is often too rigid.
      Its screens, functions, data structures, and workflows are fixed. Even if an FDE enters the customer site, there may be little room for meaningful adaptation.<\/p>\n\n\n\n

      Fully custom development, on the other hand, is too heavy.
      If each project starts from scratch with requirements definition, design, development, testing, and maintenance, it becomes slow, expensive, difficult to scale, and hard to maintain.<\/p>\n\n\n\n

      The best fit for FDE work is a semi-finished product whose core functions are already built, but which can be adapted quickly to each customer.<\/p>\n\n\n\n

      Such a semi-finished product might include:<\/p>\n\n\n\n

        \n
      • completed core functions;<\/li>\n\n\n\n
      • a data ingestion mechanism;<\/li>\n\n\n\n
      • a standard user interface;<\/li>\n\n\n\n
      • authentication and permission management;<\/li>\n\n\n\n
      • AI model or LLM integration;<\/li>\n\n\n\n
      • reporting functions;<\/li>\n\n\n\n
      • business-specific templates;<\/li>\n\n\n\n
      • configurable prompts and settings;<\/li>\n\n\n\n
      • and limited extensibility through code when necessary.<\/li>\n<\/ul>\n\n\n\n

        With this kind of foundation, FDEs do not need to build everything from scratch.
        They can configure and adapt an existing base to the customer\u2019s business context.<\/p>\n\n\n\n

        This is the most important condition for ordinary consultants and engineers to become FDEs.<\/p>\n\n\n\n

        Conditions for Ordinary Engineers to Become FDEs<\/h2>\n\n\n\n

        First, let us consider the case of engineers.<\/p>\n\n\n\n

        Ordinary engineers are usually strong in technology.
        However, they may not have extensive experience in clarifying vague customer needs, structuring business problems, or explaining business value to executives.<\/p>\n\n\n\n

        For engineers to become FDEs, several conditions are necessary.<\/p>\n\n\n\n

        First, they need interview templates<\/strong> for understanding customer problems.
        If what to ask, in what order, and how deeply to investigate are standardized, even engineers with limited consulting experience can handle customer discussions more effectively.<\/p>\n\n\n\n

        Second, they need patterns for translating business problems into technical requirements<\/strong>.
        For example, common patterns may include customer support automation, VOC analysis, sales enablement, internal knowledge search, meeting analysis, competitive research, and demand forecasting.<\/p>\n\n\n\n

        Third, they need proposal and report templates<\/strong>.
        Business communication is often a weak point for engineers. Templates and AI assistance can help them explain technical outputs in business language.<\/p>\n\n\n\n

        Fourth, they need a semi-finished product that can be customized mainly through configuration.
        Data sources, prompts, analytical dimensions, report formats, user permissions, and screen displays should be adjustable without heavy coding.<\/p>\n\n\n\n

        Fifth, they need a methodology for limiting project scope.
        Engineers may take customer requests too seriously and fall into endless customization. FDEs need a commercial sense of where standard support ends and additional custom development begins.<\/p>\n\n\n\n

        In short, ordinary engineers do not need to become genius consultants.
        They need a structured framework that supports customer-facing work.<\/p>\n\n\n\n

        Conditions for Ordinary Consultants to Become FDEs<\/h2>\n\n\n\n

        Consultants face the opposite challenge.<\/p>\n\n\n\n

        They are often strong in problem framing, executive communication, business understanding, and proposal writing.
        However, they may lack the technical skills to build AI systems, connect APIs, process data, or deploy prototypes.<\/p>\n\n\n\n

        For consultants to become FDEs, several conditions are necessary.<\/p>\n\n\n\n

        First, they need a semi-finished product that can be used through no-code or low-code operations.
        They should be able to upload customer documents, select templates, define analytical dimensions, and generate AI applications or analytical reports without becoming full-scale engineers.<\/p>\n\n\n\n

        Second, they need to learn light technical extension using AI-assisted coding.
        Consultants do not need to become professional software engineers. But they do need enough technical supervision ability to ask AI to generate code, modify settings, perform simple data transformations, and use APIs at a basic level.<\/p>\n\n\n\n

        Third, they need to understand technical constraints.
        If consultants assume that AI can do anything, they will create unrealistic expectations for customers. They must understand what cannot be done without data, what cannot be guaranteed in terms of accuracy, what is limited by security requirements, and what creates excessive operational burden.<\/p>\n\n\n\n

        Fourth, they must move from producing documents to producing working systems.
        Traditional consulting often ends with reports and presentations. FDE-style work requires something closer to operational tools: AI applications, knowledge bases, analytical dashboards, or workflow support systems.<\/p>\n\n\n\n

        Fifth, they need a practical division of labor with engineers.
        Consultants do not need to implement everything themselves. A more realistic model is to handle the standard parts with semi-finished products and ask engineers to handle the technically difficult parts.<\/p>\n\n\n\n

        In short, ordinary consultants do not need to transform into full engineers.
        They need the ability to use AI and semi-finished products to turn proposals into working systems.<\/p>\n\n\n\n

        Conditions Required for FDE-Oriented Semi-Finished Products<\/h2>\n\n\n\n

        What kind of semi-finished product is suitable for FDE work?<\/p>\n\n\n\n

        First, it must separate what changes by customer from what does not.<\/p>\n\n\n\n

        The stable parts include authentication, user management, basic UI, data storage, logging, AI integration, access control, and basic analytical processing.<\/p>\n\n\n\n

        The variable parts include business terminology, data sources, analytical axes, prompts, report formats, workflows, KPIs, and external integrations.<\/p>\n\n\n\n

        If this separation is clear, FDEs can focus on customer value rather than reinventing the system each time.<\/p>\n\n\n\n

        Second, the product must include business-specific templates<\/strong>.<\/p>\n\n\n\n

        Examples include:<\/p>\n\n\n\n

          \n
        • VOC analysis kit;<\/li>\n\n\n\n
        • meeting and workshop analysis kit;<\/li>\n\n\n\n
        • competitive positioning analysis kit;<\/li>\n\n\n\n
        • internal knowledge utilization kit;<\/li>\n\n\n\n
        • sales proposal support kit;<\/li>\n\n\n\n
        • AI PoC starter kit;<\/li>\n\n\n\n
        • new business theme exploration kit;<\/li>\n\n\n\n
        • customer inquiry analysis kit.<\/li>\n<\/ul>\n\n\n\n

          With such templates, FDEs can choose a starting point based on the customer\u2019s problem.<\/p>\n\n\n\n

          Third, the product must provide a configuration interface.<\/p>\n\n\n\n

          FDEs do not only need a developer console.
          They need a field-oriented console that can be used during customer discussions.<\/p>\n\n\n\n

          They should be able to ingest data, select analysis types, adjust prompts, edit cluster names, change analytical dimensions, choose report formats, create shared links, and manage customer-specific models.<\/p>\n\n\n\n

          This allows FDEs to demonstrate value directly in front of the customer.<\/p>\n\n\n\n

          Fourth, AI assistance must be built in.<\/p>\n\n\n\n

          AI should help FDEs avoid starting from zero every time.
          It can support:<\/p>\n\n\n\n

            \n
          • interview question generation;<\/li>\n\n\n\n
          • problem structuring;<\/li>\n\n\n\n
          • interpretation of data fields;<\/li>\n\n\n\n
          • cluster naming;<\/li>\n\n\n\n
          • report drafting;<\/li>\n\n\n\n
          • suggestion of business improvement measures;<\/li>\n\n\n\n
          • proposal creation;<\/li>\n\n\n\n
          • partial code generation;<\/li>\n\n\n\n
          • and test case generation.<\/li>\n<\/ul>\n\n\n\n

            This allows average professionals to perform FDE work at a higher level.<\/p>\n\n\n\n

            Fifth, extensibility is necessary.<\/p>\n\n\n\n

            A semi-finished product is not a fixed SaaS product.
            Customers differ, and some level of code extension will sometimes be necessary.<\/p>\n\n\n\n

            A realistic balance is:<\/p>\n\n\n\n

            \n

            80% handled through configuration,
            15% handled through light AI-assisted coding,
            and only 5% requiring serious custom development.<\/p>\n<\/blockquote>\n\n\n\n

            What FDE Education Should Look Like<\/h2>\n\n\n\n

            FDE education should differ from traditional data science education.<\/p>\n\n\n\n

            It is not enough to teach statistics, mathematics, and Python.
            It is also not enough to teach software engineering alone.
            Nor is MBA-style business education sufficient.<\/p>\n\n\n\n

            What is needed is education in connecting technology with reality.<\/p>\n\n\n\n

            This includes:<\/p>\n\n\n\n

              \n
            • how to interview customers;<\/li>\n\n\n\n
            • how to read business workflows;<\/li>\n\n\n\n
            • how to identify data location and data quality;<\/li>\n\n\n\n
            • how to distinguish problems AI can solve from those it cannot;<\/li>\n\n\n\n
            • how to design PoCs;<\/li>\n\n\n\n
            • how to define scope with production deployment in mind;<\/li>\n\n\n\n
            • how to design prompts and data structures;<\/li>\n\n\n\n
            • how to validate AI outputs;<\/li>\n\n\n\n
            • how to understand security and governance;<\/li>\n\n\n\n
            • how to explain value to customers;<\/li>\n\n\n\n
            • how to show return on investment;<\/li>\n\n\n\n
            • and how to separate standardization from customization.<\/li>\n<\/ul>\n\n\n\n

              This is closer to practical professional education than traditional university education.<\/p>\n\n\n\n

              Therefore, FDE should not be regarded mainly as a new graduate role.
              It is more realistic to see it as a role that existing engineers and consultants can reach through retraining in the AI era.<\/p>\n\n\n\n

              The Role of Platforms Such as ThinkNavi \/ ConceptMiner<\/h2>\n\n\n\n

              In this context, platforms such as ThinkNavi \/ ConceptMiner may play an important role.<\/p>\n\n\n\n

              Companies do not struggle with AI adoption simply because they lack AI models.
              More often, they struggle because the structure of the problem is unclear.<\/p>\n\n\n\n

              What should be called the problem?
              Which documents are important?
              How should customer voices be classified?
              Along which axes should competitors be compared?
              How should meeting discussions be organized?
              How should new business opportunities be explored?
              How should internal knowledge be visualized?<\/p>\n\n\n\n

              These problems are not always well handled by simple RAG systems or chatbots.
              What is needed is a way to convert information into a conceptual structure that can be explored and used for decision-making.<\/p>\n\n\n\n

              ThinkNavi \/ ConceptMiner can become a semi-finished AI knowledge platform for FDEs and AI implementation consultants.<\/p>\n\n\n\n

              For example, an FDE can ingest a customer\u2019s documents, generate a concept map, extract major themes, explore them through AI chat, and produce a report.
              From there, the work can expand into VOC analysis, competitive positioning, internal knowledge utilization, meeting analysis, or new business exploration.<\/p>\n\n\n\n

              This is not fully custom development.
              It is also not merely an off-the-shelf SaaS product.<\/p>\n\n\n\n

              It is a semi-finished AI knowledge platform that can be tailored to each customer\u2019s knowledge and business problems.<\/p>\n\n\n\n

              The Essence of FDE Is Not a Super Consultant-Engineer, but a Systematized Practitioner<\/h2>\n\n\n\n

              If we think of FDEs simply as consultants who can implement or engineers who can consult, we will fall again into the myth of universal talent.<\/p>\n\n\n\n

              The essence is different.<\/p>\n\n\n\n

              An FDE is a practitioner who combines existing technical assets, semi-finished products, templates, and AI assistance to create value quickly in the customer\u2019s real environment.<\/p>\n\n\n\n

              The role should not depend on individual genius.
              It should depend on reusable systems.<\/p>\n\n\n\n

              Therefore, increasing the number of FDEs requires more than training individuals.
              It requires four things:<\/p>\n\n\n\n

                \n
              1. semi-finished products;<\/li>\n\n\n\n
              2. business-specific templates;<\/li>\n\n\n\n
              3. AI-assisted deployment processes;<\/li>\n\n\n\n
              4. standardized education and methodology.<\/li>\n<\/ol>\n\n\n\n

                If these four elements are in place, FDE will not remain a role for only a few superhuman individuals.
                Ordinary engineers and consultants will be able to perform FDE-like work after appropriate training.<\/p>\n\n\n\n

                Conclusion: How Not to Repeat the Tragedy of the Data Scientist<\/h2>\n\n\n\n

                The tragedy of the data scientist was caused by excessive expectations placed on young talent.
                After learning theory and coding, they were expected to define business problems, prepare data, build models, deploy systems, transform operations, and create measurable value.<\/p>\n\n\n\n

                FDEs face a similar danger.
                If we expect them to understand technology and business, communicate with customers, use AI, build solutions quickly, and generate results all by themselves, FDE will become another role reserved for a small number of superhuman individuals.<\/p>\n\n\n\n

                However, FDEs also have a better opportunity than data scientists did.<\/p>\n\n\n\n

                AI-assisted coding, semi-finished products, templates, and deployment methodologies can significantly reduce the burden on individuals.<\/p>\n\n\n\n

                What matters now is not celebrating the FDE title.
                What matters is creating the conditions under which ordinary consultants and engineers can practice FDE-like work.<\/p>\n\n\n\n

                Those conditions are:<\/p>\n\n\n\n

                  \n
                • do not build from scratch; use semi-finished products;<\/li>\n\n\n\n
                • absorb customer-specific differences through configuration;<\/li>\n\n\n\n
                • prepare business-specific templates;<\/li>\n\n\n\n
                • use AI to support interviewing, design, implementation, and reporting;<\/li>\n\n\n\n
                • clearly separate standard support from custom development;<\/li>\n\n\n\n
                • enable collaboration between consultants and engineers;<\/li>\n\n\n\n
                • design methods that move beyond PoCs toward real operation.<\/li>\n<\/ul>\n\n\n\n

                  The lesson from data science is clear.<\/p>\n\n\n\n

                  Do not place excessive fantasies on individuals.
                  Changing the job title does not solve the structural problem.<\/p>\n\n\n\n

                  To make FDE work, we must not turn people into heroes.
                  We must systematize the practice.<\/p>\n\n\n\n

                  At the center of that system will be semi-finished AI platforms, business templates, and AI-assisted deployment methodologies.<\/p>\n","protected":false},"excerpt":{"rendered":"

                  In recent years, the role of the Forward Deployed Engineer, or FDE, has attracted increasing attention. An FDE is not simply a software engineer who writes code. Rather, an FDE works close to the customer\u2019s operational environment, understands business problems, and builds practical solutions using AI and software. At first glance, this looks like an […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1271","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.mindware-jp.com\/en\/wp-json\/wp\/v2\/posts\/1271","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.mindware-jp.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.mindware-jp.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.mindware-jp.com\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.mindware-jp.com\/en\/wp-json\/wp\/v2\/comments?post=1271"}],"version-history":[{"count":1,"href":"https:\/\/www.mindware-jp.com\/en\/wp-json\/wp\/v2\/posts\/1271\/revisions"}],"predecessor-version":[{"id":1272,"href":"https:\/\/www.mindware-jp.com\/en\/wp-json\/wp\/v2\/posts\/1271\/revisions\/1272"}],"wp:attachment":[{"href":"https:\/\/www.mindware-jp.com\/en\/wp-json\/wp\/v2\/media?parent=1271"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.mindware-jp.com\/en\/wp-json\/wp\/v2\/categories?post=1271"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.mindware-jp.com\/en\/wp-json\/wp\/v2\/tags?post=1271"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}